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

做者 | Anna Bryk 市場研究專家

原文 | Microservices and Container Security: 10 Best Practices

容器使微服務在開發人員中很受歡迎，由於微服務具備快速部署、服務獨立性加強等優勢，使得如今許多公司開始接受微服務。然而，從單體架構遷移到微服務架構也會引起許多問題，其中安全問題最爲重要。

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

這些安全問題引起了關於這種軟件開發新方法究竟是「解決問題」更多，仍是「製造問題」更多的激烈爭論。那麼，咱們如何將安全性引入應用程序的同時，又不損失使用微服務方法的好處呢?

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

目錄

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

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

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

1. 建立不可變的容器
2. 僅從可信來源運行映像
3. 使用註冊表安全訪問圖像
4. 每一個主機部署一個微服務
5. 強化主機操做系統
6. 以深度防護的方式保護微服務
7. 將自動化的安全測試集成到構建或CI過程當中
8. 使用容器本地監控工具
9. 使用業務流程經理
10. 使用API訪問控制安全訪問微服務

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

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

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

關於微服務的安全問題一般源於如下內容：

• 許多活動部件

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

• 通訊風險

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

對於容器相關的安全挑戰，因爲全部操做都應該維護安全，所以存在普遍的問題。

• 容器技術的漏洞

容器技術的核心組件——容器、圖像、寄存器、編配程序和主機操做系統——也可能成爲網絡罪犯的目標。例如，×××者能夠破壞圖像並訪問應用程序或數據文件。此外，×××能夠用惡意代碼感染容器，並使用它×××其餘容器、主機操做系統或其餘主機。

• 更多的人可使用代碼

雖然DevSecOps旨在打破團隊之間的障礙，確保持續集成和持續部署(CI/CD)，但它也會致使在分佈式工做環境中更改代碼的風險增長。

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

3、確保微服務和容器安全的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)進行加密。

結論

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