作者 | Anna Bryk 市場研究專家

原文 | Microservices and Container Security: 10 Best Practices

容器使微服務在開發人員中很受歡迎，因為微服務具有快速部署、服務獨立性增強等優點，使得現在許多公司開始接受微服務。然而，從單體架構遷移到微服務架構也會引發許多問題，其中安全問題最為重要。

用於單體應用程式的傳統安全工具並不能用於保護微服務和容器。基於微服務架構的應用程式包含數千個容器，這極大地擴大了×××範圍。將容器視為服務單元大大降低了應用程式的透明性和可審計性。

這些安全問題引發了關於這種軟體開發新方法到底是“解決問題”更多，還是“製造問題”更多的激烈爭論。那麼，我們如何將安全性引入應用程式的同時，又不損失使用微服務方法的好處呢?

在本文中，我們觀察了安全方面的挑戰，並提供了一份確保微服務和容器安全的行業最佳實踐列表。本文對微服務實踐者和對該技術不熟悉的人都很有用。

目錄

一、什麼是微服務和容器?

二、微服務和容器的安全挑戰。

三、確保微服務和容器安全的10個最佳實踐：

1. 建立不可變的容器
2. 僅從可信來源執行映像
3. 使用登錄檔安全訪問影象
4. 每個主機部署一個微服務
5. 強化主機作業系統
6. 以深度防禦的方式保護微服務
7. 將自動化的安全測試整合到構建或CI過程中
8. 使用容器本地監控工具
9. 使用業務流程經理
10. 使用API訪問控制安全訪問微服務

一、什麼是微服務和容器?

美國國家標準與技術研究院(National Institute of Standards and Technology,以下簡稱：NIST)將微服務定義為鬆散耦合的自包含服務，它是應用程式元件體系結構分解的結果。這些服務可以使用標準通訊協議和一組定義良好的API相互通訊。這個定義意味著開發人員需要將應用程式服務分解成獨立的單元，這些單元可以相互連線並部署在任何基礎設施中。為了在任何裝置上實現微服務部署，開發人員將微服務放入容器中。

二、微服務和容器的安全挑戰

關於微服務的安全問題通常源於以下內容：

• 許多活動部件

基於微服務的應用程式是由許多活動部件組成，這使得它們比單體應用程式更復雜。一個應用程式可以包含部署在數千個容器中的數百個微服務。對於開發人員來說，這意味著包含1000個dll的單塊程式碼應該被分解成相同數量的微服務。這使得程式碼更加安全和易於維護，同時也使得基於微服務的應用程式更容易受到網路×××。

• 通訊風險

此外，介面驅動的開發方法需要定義良好的REST API，以確保微服務能夠建立彼此一致的通訊。與元件內部通訊的單體應用程式不同的是，基於微服務的應用程式元件在外部和內部環境中都通訊，這帶來了速度和安全方面的挑戰。開發人員必須更加註意安全性，因為他們必須保護比單體應用程式中更多的東西，保證通訊的安全性，並保護更大的×××面。

對於容器相關的安全挑戰，由於所有操作都應該維護安全，因此存在廣泛的問題。

• 容器技術的漏洞

容器技術的核心元件——容器、影象、暫存器、編配程式和主機作業系統——也可能成為網路罪犯的目標。例如，×××者可以破壞影象並訪問應用程式或資料檔案。此外，×××可以用惡意程式碼感染容器，並使用它×××其他容器、主機作業系統或其他主機。

• 更多的人可以使用程式碼

雖然DevSecOps旨在打破團隊之間的障礙，確保持續整合和持續部署(CI/CD)，但它也會導致在分散式工作環境中更改程式碼的風險增加。

在選擇適當的安全措施時，請記住，這些措施不應該與對開發人員如此有吸引力的優點相悖 : 例如輕量級服務、簡化程式碼構建和打包、即時啟動能力以及按需靈活擴充套件。如果安全措施使這種方法不再有用，那麼它們很可能被忽略或拒絕。

三、確保微服務和容器安全的10個最佳實踐

本篇文章的微服務和容器安全最佳實踐清單，基於行業專業知識、領先的微服務從業人員提供的安全建議和官方行業標準，這些內容反映在以下檔案中：

NIST Special Publication 800-180, NIST

Definition of Microservices, Application Containers and System Virtual Machines

   NIST特別出版物800-180：微服務、應用程式容器和系統虛擬機器的定義

NIST Special Publication 800-190, 
Application Container Security Guide

   NIST特別出版物800-190：應用容器安全指南 

NISTIR 8176, 
Security Assurance Requirements for Linux Application Container Deployments

   NISTIR 8176：Linux應用程式容器部署的安全保證要求

DWP Security Policies and Standards, 
Security Standard - Microservices Architecture (SS-028)

   DWP安全策略與標準：安全標準——微服務體系結構(SS-028)

關注Java技術zhai公眾號，後臺回覆“架構資料”，即可獲取整理好的微服務資料

現在讓我們進一步瞭解如何保護部署在容器中的微服務。

1.建立不可變的容器

開發人員傾向於讓shell訪問影象，這樣他們就可以在生產中修復它們。然而，×××者經常利用這種訪問方式注入惡意程式碼。為了避免這種情況，需要建立不可變的容器。在出現任何缺陷或漏洞時，開發人員可以重新構建和重新部署容器。遠端管理是通過執行時API或通過為執行微服務的主機建立遠端shell會話來完成的。容器的不可變特性也會影響資料永續性。開發人員應該將資料儲存在容器之外，以便在替換其中一些資料時，新版本仍然可以使用所有資料。

2.僅從可信來源執行映像

對於擁有現成可用容器的開發人員來說，有許多開放原始碼包，包括Node.js.、Apache Web伺服器和Linux作業系統。但是，出於安全目的，你需要知道容器的來源、更新時間以及它們是否沒有任何已知的漏洞和惡意程式碼。最好是建立一個可信的映像儲存庫，並僅從該可信源執行映像。此外，開發人員應該在將容器投入生產之前檢查指令碼中的應用程式簽名。如果米在多個雲環境中執行，那麼可以使用多個映像儲存庫。如果想使用來自其他來源的影象，建議使用掃描工具掃描它們的內容。

3.使用登錄檔安全訪問影象

Docker Hub、Amazon EC2容器註冊中心和Quay容器註冊中心等註冊中心幫助開發人員儲存和管理他們建立的映像。這些註冊中心還可以用於提供基於角色的訪問控制、只接受來自可信來源的容器、不斷更新已知漏洞列表以及標記易受×××的映像。

基於角色的訪問控制非常重要，因為你需要控制誰可以將更改引入容器。最好限制對特定管理帳戶的訪問：一個負責系統管理，一個負責操作和編排容器。

此外，你應該確保註冊中心驗證每個容器的簽名，並且只接受來自可信來源的簽名。你的登錄檔還應該包含一些功能，幫助你不斷檢查影象內容的已知漏洞，並告知安全問題。

4.每個主機部署一個微服務

基於微服務的應用程式可以部署在同一個主機上，也可以部署在多個主機上。因此，這種部署模型導致了管理的複雜性。考慮哪些容器應該部署到哪些主機上，哪些容器需要相互訪問，以及如何自動擴充套件軟體容量，最佳實踐是在單個主機作業系統核心上對特定微服務的容器進行分組。這種方法在深度上提供了額外的防禦，可以給×××者在危害不同群體時增加難度。如果你的環境比較大，有很多主機，請自動化這個過程。

5. 強化主機作業系統

雖然大多數建議都涉及到微服務和容器的安全性，但是還需要確保主機作業系統的安全性。首先，NIST建議使用特定於容器的主機作業系統，因為它們沒有不必要的功能，×××面會比通用主機小得多。使用允許使用路由器或防火牆控制出口流量的平臺也是可取的。

其次，CIS Docker基準測試可以提供一系列檢查，為你提供關於如何加強系統的良好基線。很可能，它會建議你做以下工作：

• 建立使用者認證
• 設定訪問角色
• 指定二進位制檔案訪問許可權
• 啟用審計資料的日誌記錄

為了避免資料被盜，限制對底層作業系統資源的容器訪問，並將容器彼此隔離。最佳實踐是在核心模式下執行容器引擎，而在使用者模式下執行容器。此外，Linux提供了多層安全性，限制了容器的功能。Linux中的安全性可以通過使用核心安全特性和模組(如Linux名稱空間、Seccomp、Cgroups、SELinux和Linux功能)來實現。

6. 以深度防禦的方式保護微服務

這種方法是微服務安全的最重要原則之一，因為它建立了多個安全層以防止×××，包括過濾通訊流、對微服務的訪問進行身份驗證和授權以及使用加密技術等安全措施。保護你的內部環境不受任何外部連線的影響是第一層防禦。如果使用來自公共儲存庫的映像，這可能對應用程式構成安全風險。通過已知的私有網路管理主機，這樣就不會有公開的×××面。

7.將自動化的安全測試整合到構建或CI過程中

有許多工具可以在構建或CI過程中自動測試容器。例如，HP Fortify和IBM AppScan提供了動態和靜態應用程式安全測試。你還可以使用像JFog Xray和Black Duck Hub這樣的掃描器來實時檢查容器中已知的漏洞。這些工具標記了已發現的問題，並允許你採取適當的行動。

8.使用容器本地監控工具

當我們處理Docker時，我們使用Docker安全掃描器或其他特別設計的工具來檢測對我們的應用程式的任何潛在威脅。當安全掃描發現惡意軟體和已知漏洞時，監控工具會檢測出你沒有預料到的問題。監控工具首先收集事件，然後根據安全策略檢查事件。確定性策略可以定義哪些服務可以執行，以及允許哪些容器發出外部HTTP請求。動態策略可以建立正常通訊活動的基線，並通知流量峰值或異常流量。

9.使用編排經理

微服務編排可以通過兩種方式實現：

• 通過使用API閘道器作為編排層
• 通過將編排編碼作為獨立的微服務

協調器從註冊中心提取影象，將這些影象部署到容器中，並管理它們的執行。協調器提供的抽象允許你指定給執行定映像所需的容器數量，以及需要為它們分配哪些主機資源。使用編排管理器，不僅可以自動化微服務的部署，還可以確保一定級別的安全性。例如，編排器允許你管理容器的叢集、隔離工作負載、限制對元資料的訪問和收集日誌。

許多編排管理器還擁有內建的祕密管理工具，允許開發人員安全地儲存和共享祕密資料，比如API和SSL證書、加密金鑰、識別符號和密碼。有許多編配管理器，如Kubernetes、Swarm和Mesos以及Azure、GCP和AWS提供的雲本地管理系統。

10.使用API訪問控制安全訪問微服務

API是包含微服務應用程式的關鍵。基於這種技術的軟體具有多個獨立的API服務，這些服務需要額外的工具來管理。因此，確保安全身份驗證和授權的API訪問控制對於微服務安全性至關重要。開發人員和管理員通常使用OAuth/OAuth2伺服器來獲取使用API進行身份驗證的令×××。出於安全原因，還應該確保所有客戶機-伺服器通訊在傳輸過程中使用傳輸層安全(TLS)進行加密。

結論

向微服務的轉變使開發人員能夠改進他們的應用程式和基礎設施。然而，這些技術需要一種完全不同的安全方法。對於基於微服務的軟體，一個全面的安全程式應該處理其整個應用程式的生命週期。使用所描述的最佳實踐，可以確保容器和微服務的安