安全——《微服务设计》读书笔记
身份認證和授權
? ? ??1.單點登錄（SSO）
? ? ? 當主體試圖訪問一個資源，他會被定向到一個身份提供者那里進行身份驗證，身份提供者驗明正向后會發消息給服務提供者，讓服務提供者來決定是否允許它訪問資源。
? ? ? SAML和OpenID Connect/OAuth2.0是企業領域中占據統治地位的單點解決方案。
? ? ? 2.單點登錄網關
? ? ? 現在問題來了，多個微服務是不是也要單獨地與單點登錄系統交互，顯然這樣是不合理的，這意味著大量的重復工作。我們可以使用單點登錄網關來幫助我們完成這一工作，在使用者通過單點登錄網關后，可以將用戶名和角色等用戶信息放入HTTP頭信息，傳遞給下游服務。
? ? ? 同時，網關應該提供的是粗粒度的身份驗證，而不應該過于具體，如我們可以使用它來完成對是否登錄、取角色、是否訪問某個服務這類的驗證，而不應該具體到“是擁有view.html頁面50條還是100條數據的導出權限”。
?
網絡傳輸和服務間傳輸的身份驗證和授權
??? ? 從瀏覽器中輸入用戶和密碼，到真正的服務提供者，這中間是一個漫長的過程，通過HTTP有很高的風險，因為用戶和密碼并沒有以安全的方式發送，任何中間方都可以看到HTTP頭的信息并讀取里面的數據，因此HTTP基本身份驗證通常應該使用HTTPS進行通信。
? ? ? 使用HTTPS時，瀏覽器到服務器的通信將獲得強有力的保證，但是服務器端要管理的SSL證書，這有一個額外的行政和運營負擔，同時SSL上的流量不能被反向代碼服務器（如Varnish或Squid）所緩存，這意味著，如果你需要緩存信息，就不得不在服務端或瀏覽器內部實現，你可以在負載均衡中把HTTPS的請求轉成HTTP請求，然后在負載均衡之后就可以使用緩存了。
? ? ? 如果你已經在使用SAML或OpenID Connect作為身份驗證和授權方案，你可以在服務之間的交互中也使用它們。你可以針對服務也創建一些憑證，如果憑證被泄露，只需要撤銷有限的受影響的憑證即可。（這里我感覺像配置Git的SSH PublicKey和PrivateKey一樣。）
? ? ? 同時我們也可以使用TLS（Transport Layer Security安全傳輸協議），在這里，每個客戶端都安裝了一個X.509證書，用于客戶端和服務器端之間建立通信鏈路，服務器端可以驗證客戶端證書的真實性。當你特別關注所發數據的敏感性，或無法控制發送數據所使用的網絡時，才考慮使用這種技術。
? ? ? 另一種方式，我們還可以使用HTTP之上的HMAC（Hash-based Message Authentication Code基于哈希的消息碼）對請求進行簽名，它是OAuth規范的一部分。使用HMAC，請求主體和私有密鑰一起被哈希處理，生成的哈希值隨請求一起發送，服務器使用請求主體和自己的私鑰副本重建哈希值，如果匹配則接受請求。這樣做的好處是，如果一個中間人更改了請求，那么哈希值會不匹配，服務器便知道該請求被篡改過，且私鑰永遠不會隨請求發送，因此不會存在傳輸過程中泄露的問題，而且通信更容易被緩存，生成哈希的開銷要低于處理HTTPS的開銷。
? ? ? HMAC也存在缺點，首先客戶端和服務器端需要一個共享的、以某種方式交流的密鑰，其次這是一個模式而不是標準，可以參看AWS的S3 API，最后請求中所帶的其他數據，對網絡嗅探來說仍然是可見的。
? ? ? 另外，在大部分的組織內部，服務間的通信被認為是安全的，而沒有采取任何防備。我們也可以采用上面的方式對組織內部的通信進行安全加固。
?
提供出的公共API安全：API密鑰
? ? ??API密鑰允許服務識別出是誰進行調用，然后對他們能做的進行限制，限制通常不僅限于對特定資源的訪問，還可以擴展到類似于針對特定的調用者限速，以保護其他人服務調用的質量。
? ? ? 通常情況下，我們會在系統中集中管理API密鑰，API網關（API Gateway）模型在這個領域很受歡迎。
?
一個問題：代理人欺騙
? ??? 當我登錄了系統后，我再通過嘗試，看是否能夠獲得其他客戶或者訂單的信息，它們原來不屬于我，但由于接口只是提供order/12345之類的規則，并沒有驗證信息，萬一這樣成功了呢？那么我就可以作為一個假的代理人去欺騙系統的數據。
? ? ? 解決這個問題的方法是在應用程序中加入驗證，使這個人只能查詢自己的訂單，也可以在請求中加入原始的憑證。
?
靜態數據的安全
? ? ??有些組織中，服務器中的靜態數據是完全沒有加密的，這有可能會生成安全漏洞。有一些產品已經提供了加密算法，比如SqlServer和Oracle就提供了可以加密表的某一列值的功能，同時我們可以采用已知的加密算法（不要自己去嘗試寫一套加密算法）對靜態數據進行加密，同時對備份也進行加密。
?
全面防御
? ??? 我們應該從瀏覽器到應用程序服務器再到數據庫都存在安全防御措施，防火墻（設置允許的入口和出口）、日志（不要將敏感的數據寫到日志中）、入侵檢測系統（IDS，可以監控網絡或主機，當發現可疑行為時報告問題）、入侵預防系統（IPS，監控可疑行為并阻止它的發生）、網絡隔離（我們可以把服務放進不同的網段）、操作系統（自動定時打補丁、設置OS的安全策略等）。
?
舉個例子
? ? ??先看一下不安全的架構
? ? ??
? ????在這里，所有的請求都使用普通的HTTP傳輸，但我們希望在傳輸的過程中數據不要被篡改；同時我們要限制公共API的使用范圍和使用頻率；另外我們希望第三方系統與我們的交互是受保護的，而避免被競爭對手所獲取；我們希望客戶服務中的數據是完全加密的，這樣即使發生拖庫的情況，黑客也不能獲取相應的數據。
? ? ? 基于這些設定，我們提供了一種安全的架構，如下所示：
? ? ??
?
一些可供借鑒的法則和實踐
? ? ? ?OWASP十大列表和SP安全測試框架
? ? ? 微軟安全開發生命周期（http://www.microsoft.com/en-us/sdl/default.aspx）
?
參考
? ? ? 《微服務設計》（Sam Newman 著 / 崔力強 張駿 譯）
相關文章：?
微服務的概念——《微服務設計》讀書筆記
微服務架構師的職責——《微服務設計讀書筆記》
建模:確定服務的邊界——《微服務設計》讀書筆記
微服務集成——《微服務設計》讀書筆記
服務的協作：服務間的消息傳遞——《微服務設計》讀書筆記
拆分:分解單塊系統——《微服務設計》讀書筆記
部署:持續集成（CI）與持續交付（CD）——《微服務設計》讀書筆記
測試——《微服務設計》讀書筆記
監控——《微服務設計》讀書筆記
原文地址：http://www.cnblogs.com/gudi/p/6684548.html
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
總結
以上是生活随笔為你收集整理的安全——《微服务设计》读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 未来的C#之只读引用与结构体
- 下一篇： 开发者需要理解的分布式原语