随着容器的持續流行，将應用改造成雲上的微服務，對于很多希望it營運更加靈活高效的企業來說是顯而易見的下一步。但是，在容器化應用并且部署之前，需要首先確定你的應用是安全的。雲托管的微服務所帶來的安全挑戰，和傳統應用情況并不完全一樣，我們必須妥善解決這些問題，避免暴露重大的安全漏洞。
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的工作流和容器這樣的技術轉變，微服務的安全會變得越來越容易管理。但是，現在，微服務能使用的安全工具的缺失意味着企業需要特别前瞻性地保護計劃在微服務架構下運作的軟體。
本文作者：佚名
來源：51cto