《微服務設計》閱讀筆記（九）安全

《微服務設計》，Building Microservices，作者Sam Newman，譯者崔力強、張駿，人民郵電出版社，2016年。

筆記中有些內容直接引用原書。

================================================================

第九章 安全

1. 身份驗證和授權

身份驗證是確認他是誰的過程。對要驗證的人或事，稱之為主體。授權機制使得能夠將主體映射到他可以進行的操作中，即他能做什麼，不能做什麼。

常見的單點登錄實現。單點登錄（Single Sign-On, SSO），在企業級領域佔據統治地位的是SAML和OpenID Connect。SAML是基於SOAP的標準，使用複雜，OpenID Connect已成為OAuth 2.0具體實現的一個標準，在互聯網可以用Google的外部身份提供者，但在內網則缺少身份提供者。OpenAM和Gluu也是選擇。

單點登錄網關。使用單點登錄網關作為代理與身份提供者握手，避免每個服務都要實現與身份管理者握手的功能。Shibboleth工具和Apache一起用，能很好處理與基於SAML的身份提供者的集成。不要將所有的安全措施放在網關上（所有雞蛋同一個籃子），不要將太多功能由網關實現（高耦合點，受攻擊面越大）。

細粒度的授權。通過判定更細的角色或用戶組，進行細粒度授權。這樣能夠減少微服務本身的處理工作量。但不要過於細，會增大系統維護的工作量。粗粒度與細粒度的權衡要結合組織架構考慮。

2. 服務間的身份驗證和授權

在邊界內允許一切。在邊界內對服務的任何調用都是默認可信的。優點：簡單。缺點：難以應對中間人攻擊等入侵了網路並滲透進系統的攻擊。這不是一個好的方式。

HTTP(S)基本身份驗證。允許客戶端在標準的HTTP頭中發送用戶和密碼，服務端驗證確定客戶端許可權。優點：容易理解，支持廣泛。缺點：HTTP有風險，HTTPS更安全；服務端需要管理SSL證書；SSL上的流量不能被反響代理伺服器（如Varnish或Squid）所緩存，需要自己做；如果已經用SSO方案，融合帶來工作量；無法確認請求來源。

使用SAML或OpenID Connect。優點：有現成的解決方案，可以進行細粒度身份驗證。缺點：要考慮如何安全存儲憑證；實現時代碼工作量較大。

客戶端證書。TSL（Transport Layer Security， 安全傳輸層協議）是SSL在客戶端證書方面的繼任者，每個客戶端都安裝一個X.509證書。缺點：證書管理工作更加繁重。

HTTP之上的HMAC。基於哈希的消息碼（Hash-based Message Authentication Code）對請求進行簽名，是OAuth規範的一部分，被廣泛用於AWS的S3 API。優點：可檢測消息被篡改；不會發送私鑰；通信能被緩存。缺點：客戶端和服務端需要找到好的方式交流密鑰；缺乏一個優秀、開放且有效的實現方式；

API密鑰。允許服務識別出是誰在調用，然後針對性地限制。對程序比SAML更易用。解決方案在開源和商業領域有很多選項。

代理問題。小心混淆代理人問題。

3. 靜態數據的安全

深度防禦很重要。記住基本的原則。

使用眾所周知的加密演算法。靜態數據加密，可以選擇已實現的AES-128或AES-256。密碼使用加鹽密碼哈希技術。

一切皆與密鑰相關。密鑰的存儲管理，可以選擇單獨的安全設備來加密和解密數據，或使用單獨的密鑰庫，或資料庫內置的加密支持（如SQL Server的透明數據加密）。不要自己實現方案，而是研究和使用已有的方案。

選擇你的目標。仔細研究加密哪些數據。

按需解密。第一次看到數據就加密，需要時才解密。

加密備份。

4. 深度防禦

防火牆。如ModSecurity。

日誌。可幫助檢測發生了不好的事情，敏感信息不要存在日誌中。

入侵檢測（和預防）系統。

網路隔離。不同服務可以放在不同網段，通過VPN隔離，定義互連規則（peering

操作系統。打補丁自動化，微軟的SCCM或紅帽的Spacewalk工具。查看Linux本身安全模塊的發展，如AppArmour、SELinux以及GrSSecurity這三個工具。

5. 一個示例

對於不同的請求源使用不同的安全措施，如瀏覽器使用HTTP&HTTPS，第三方消費者使用API密鑰，第三方版稅系統使用客戶證書。服務與外部使用網路防禦，服務之間使用HTTP，客戶數據進行加密。

6. 保持節儉

只存儲完成業務運營或滿足當地法律所需要的信息，德語Datensparsamkeit。

7. 人的因素

8． 黃金法則

不要實現自己的加密演算法，不要發明自己的安全協議。

9. 內建安全

熟悉OWASP十大列表和OWASP的安全測試框架。採用幫助探測系統漏洞的自動化工具。ZAP（Zed Attack Proxy）：重現對網站的惡意攻擊；針對Ruby的Brakeman：通過靜態分析發現導致漏洞的編碼錯誤。可以參考微軟的安全開發生命周期（Security Development Lifecycle）中的一些模型。

10. 外部驗證

找外部團隊進行安全評估。

11. 小結

識別風險級別，採用不同的方案。深度防禦很重要。基於瀏覽器的應用程序安全的概念可以參考OWASP（Open Web Application Security Projects）。密碼學可參考Niels Ferguson、Bruce Schneier和Tadayoshi Kohno所寫的Cryptograph Engineering。不要忽視人的因素。

BrianZhang：《微服務設計》閱讀筆記(一)微服務zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（二）演化式架構師zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記(三)如何建模服務zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（四）集成zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（五）分解單塊系統zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（六）部署zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（七）測試zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（八） 監控zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（十）康威定律和系統設計zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（十一）規模化微服務zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（十二完結篇）總結zhuanlan.zhihu.com軟體開發之路zhuanlan.zhihu.com
推薦閱讀：