隨著容器的持續流行，將應用改造成云上的微服務，對于很多希望IT運營更加敏捷高效的企業來說是顯而易見的下一步。但是，在容器化應用并且部署之前，需要首先確保你的應用是安全的。云托管的微服務所帶來的安全挑戰，和傳統應用情況并不完全一樣，我們必須妥善解決這些問題，避免暴露重大的安全漏洞。

[[171223]]

　　1.什么讓微服務如此不同

　　要理解為什么必須保護微服務，比如那些運行在Docker容器里的應用，你首先需要理解微服務和傳統應用之間的主要區別。

　　傳統來說，程序員構建“單體”應用。也就是說應用使用的整個軟件堆棧被組織成一個單一的可交付的實體。比如，你的團隊可能已經通過編寫前端代碼為應用構建了web應用，將其和MySQL數據庫集成來存儲數據，并且將所有東西打包到一個基于Linux的虛擬機鏡像里，從而可以將其部署到公有云服務，比如AWS或者Azure上。

　　微服務方案通過將應用分解成模塊化碎片改變了這一切。它們是分布式的，并且通常并不依賴于特定類型的操作系統來運行。這意味著上述描述的應用并不會以虛擬機鏡像的形式分發。相反，前端代碼可以被打包進一個容器鏡像。數據庫可以運行在單獨的容器里。所有這些容器都在Docker或者其他容器平臺上運行，并且底層操作系統或者托管它們的云環境和容器本身并不相關。

　　2.微服務和安全

　　微服務消除了一些和單體應用相關的安全挑戰。它們讓應用環境更加一致，簡化了安全監控。它們還增加了應用不同部分之間的隔離性，降低了入侵應用的一部分就可以控制整個堆棧的風險。并且它們可以幫助提供抵御分布式拒絕服務攻擊的彈性，因為容器可以帶來更大的靈活性和可擴展性，并且能夠更好地抵御通過向服務器發送過多請求來摧毀其基礎架構的攻擊。

　　保護微服務架構時也會遇到一些挑戰。包括：

　　更大的攻擊面。有更多的組件意味著有更多黑客可以利用的可能漏洞。比如，單體軟件堆棧可能不依賴于網絡在前端應用和數據庫之間發送信息，而容器通常是這么做的。這帶來了新的可能的攻擊向量。

　　更少的內部一致性。微服務的優勢之一是它們允許開發人員在開發語言和框架間輕松改變。比如，如果你目前用PHP開發應用，但是想切換成Go，那么當應用前端和堆棧其他部分解耦合時就很容易完成這樣的切換。但是應用內部可以按照開發人員喜好頻繁改動的事實也意味著更少的一致性。無論何時發生變化，也正是新的安全漏洞可能產生之時。

　　現有工具無法保護微服務。大部分目前可用的久經考驗的安全工具都是在微服務變革之前設計的。新的方案正在涌現，但是目前的事實是，很多漏洞掃描工具在容器或者其他基于微服務的應用上無法正常工作。

　　全新的信任關系。容器化基礎架構的優勢之一是可以從公開存儲庫里免費快速地下載并且部署容器鏡像。想要搭建MySQL數據庫或者Ubuntu Linux服務器?一個簡單的docker --pull 命令就能夠在幾秒內獲得所需的容器鏡像。缺點正是這些來自于公開存儲庫的容器鏡像。這并不意味著這些鏡像不安全，但是的確意味著如果使用這些鏡像，你就和堆棧里的第三方軟件合并了。你無法保證不受你控制的代碼的安全性。

　　3.保護微服務的步驟

　　制定正確的策略，可以減輕在云上運行微服務架構的應用程序相關的安全風險。如下步驟特別有效：

　　保護內部環境。雖然微服務涉及更多部分，但是可以通過確保托管微服務的環境的盡可能安全來降低總體安全風險。如果在云上運行Docker 環境，這意味著確保除了你沒有其他人能夠訪問你的云主機，并且除非必要，將 Docker容器配置成拒絕公開網絡的連接。

　　使用安全掃描器。大部分傳統的安全工具仍然在嘗試適用微服務的過程中。但是已經有一些好用的工具可用，比如Docker Security Scanning和CoreOS的Clair。這些工具幫助你尋找并且解決容器內的安全漏洞。

　　使用訪問控制。可以在軟件堆棧的不同層面使用訪問控制限制來降低安全風險。比如，在管理層面，必須確保能夠運行Docker命令的用戶才有執行Unix系統的Docker CLI工具的權限。還可以在大部分容器存儲庫里配置訪問權限，避免公開的訪問。

　　確保溝通。確保負責構建并且部署企業軟件的團隊的所有成員不斷地溝通，而不是各自為戰。這樣能夠確保運維的所有人都知道upstream或者downstream所發生的變化——以及可能的安全隱患。

　　越來越多的企業開始向基于DevOps的工作流和容器這樣的技術轉變，微服務的安全會變得越來越容易管理。但是，現在，微服務能使用的安全工具的缺失意味著企業需要特別前瞻性地保護計劃在微服務架構下運行的軟件。