保護微服務架構的10個有效方式

微服務與容器類似，但不完全相同。我們將微服務看做分子，容器看做原子；微服務可以在容器中執行，反之亦然。微服務經由應用程式程式設計介面（api）實現通訊，作為應用程式的整個生態系統或架構的一部分。

微服務有幾個優點：快速啟動，可以重複使用，提高可擴充套件性，甚至可以包含不同的編碼語言。只需要調整乙個或兩個微服務，而不是整個程式，更新應用程式很容易。微服務可以幫助促進和跟蹤更改、解決問題、提高容錯並提高效能。

與其他技術一樣，微服務也存在安全風險，以及適當的使用方法。看起來微服務是分子內的原子這樣的關係，但是漏洞仍然存在，即便只有乙個微服務可能被破壞，仍然是一種風險。此外，過多的微服務也可能增加複雜性，並且使安全難以實現，特別是不同的開發人員和開發方法在整個應用程式中的應用。

nginx產品主管owen garrett談及微服務安全時表示：「微服務具有不同於單片架構的安全風險，主要包括：

通訊變化：單片應用程式使用程序之間的記憶體通訊，而微服務通過網路通訊。移動到網路通訊引起了速度和安全性的問題。

資料儲存：微服務使用很多資料儲存，這提供了微服務和緊耦合的服務之間的隱式服務的機遇。

技術專長：如果現有團隊沒有適當的管理微服務的經驗，微服務會造成額外的複雜性，反過來又會造成安全漏洞。」

以下將介紹10個保護微服務架構的途徑：

1、在開發微服務時，建立通用的可重複編碼標準，可以在其他地方重複使用，減少可能導致可利用漏洞或公升級特權的差異。

2、將渠道控制在最低限度，考慮每個特定的微服務被損害之後會造成什麼後果，並且注意如何調整並保護微服務。

3、使用訪問控制向程序或個人提供資料。盡可能在單獨的功能和環境中使用分段，例如，如果沒有必要建立或更改現有資訊，那麼僅僅檢查清單可用性的微服務應該被授予資料庫的讀取許可權，而不是讀/寫許可權。

4、在微服務的**中使用安全規則，而不是通過外部方法在實現之後應用。

5、盡可能使用集中的安全或配置策略，可以跨平台應用，以建立一致性並減少人員分析或互動的必要性。

6、多人審查微服務的**，以減少人為錯誤，以及提供對**可行性的洞悉。

7、完全記錄每個微服務以說明其服務的功能，可以暴露出潛在的弱點

8、完全對映微服務之間的通訊方法，以便識別潛在的問題區域以及可能表示漏洞或劫持的不規則行為

9、當使用外部訪問時，對傳輸中的資料和禁止時使用加密

10、對微服務進行定期**和使用評審，並刪除過時或未使用的服務。