導讀 | Gartner將容器安全列爲其本年度十大安全顧慮之一,或許是時候進一步審視並找出切實的容器安全實現方案了。 |
保護Docker和容器基礎設施安全須要打組合拳,綜合運用策略、工具和審慎的應用檢查。
Gartner將容器安全列爲其本年度十大安全顧慮之一,或許是時候進一步審視並找出切實的容器安全實現方案了。雖然容器已面世十年,但其輕量且可重用的代碼、靈活的功能和更低的開發成本,令容器的流行程度有增無減。但沒有什麼工具是萬能的。咱們不妨再仔細考察一下保護開發環境所需的各類工具、容器自身所用工具和出於監視/審計/合規目的的工具吧。
從如下幾個基本步驟開始:linux
1. 熟悉雲提供商交付的工具安全
第一步就是熟悉雲提供商的內置安全措施,好比 Azure Security Center、谷歌Kubernetes Engine、谷歌 Cloud Security Command Center和亞馬遜Inspector。其中有些是通用安全工具而非容器專用,好比 Azure Security Center。工具
2. 熟悉原生Docker相關安全功能學習
包括運用策略防止資源濫用、設置訪問控制組和確保清除沒必要要的root權限。加密
3. 考慮GitHub開源項目設計
某些狀況下,Bench Security之類檢查代碼中最佳安全實踐的項目,以及相似seccomp的其餘Linux原生工具,是節省開支的不錯選擇。
總有不少軟件有待學習和理解,但應重點查看幾個經常使用功能,包括爲用戶及最終生成的應用所設的身份及身份驗證措施,以及控制這些訪問權限的機制。另外,還須要可以檢查並審計日誌文件,要能瀏覽並過濾日誌文件以提供有益安全態勢的可操做信息。最後,還要有用於保護API密鑰和SSL憑證之類祕密的底層基礎設施。這些祕密必須以加密形式存儲。
是否是有點頭暈目眩了?這還纔剛剛開始呢。想要保護公司環境中的容器,下面三個領域是你不得不仔細考慮的。日誌
4. 保護開發環境blog
因爲容器對開發人員而言很是有用,因此推動到DevSecOps很是有必要,但要記得在建立容器時即添加安全措施,而不是在項目匆忙上馬留下諸多漏洞以後。保證應用安全歷來都是最佳實踐。在選擇正確的安全工具以前,你須要回答如下幾個重要問題:
(1) 可以自動化哪些工做流以保持應用安全?
有些工具備助於實現該操做,尤爲是在編排方面。然而,不少編排工具專一於容器管理和擴展問題,未必考慮到安全細節。找到功能和防禦之間的恰當平衡或許沒那麼容易。
(2) 應用和用戶訪問控制的粒度該設成多細?
這裏有必要了解這些控制的實現機制及其侷限。好比說,哪些代碼段和容器具有root/內核訪問權限,是否須要這麼高的權限來完成任務。
(3) 應該使用運行時應用自防禦(RASP)技術嗎?
必須的。就像專一應用的RASP常規工具,有些工具專一於容器運行時應用保護,要麼有靜態掃描,要麼利用開發環境持續集成。由於容器代碼不停在變,持續集成的形式至關有用;並且擁有持續代碼審計也能夠在不得不修復或更新時節省大量時間。一款好RASP容器工具應能標記異常行爲,緩解潛在威脅,並可以隔離特定事件以供後續進一步取證分析。事件
5. 防禦託管着容器的底層主機資源
大多數狀況下,這意味着運行精簡版LInux,只留下必要的服務以減少潛在攻擊界面。有些工具就是設計來強化主機自身的。另外一個辦法是採用上面提到過的Docker控制組,以及隔離名字空間以反映你的安全策略和防止容器間相互感染。有些商店使用來自雲提供商的虛擬專用鏈接來實現該隔離操做。該過程包含應用訪問級別和其餘機制來隔離工做負載,以及限制每臺主機上運行的容器數量。出於這個緣由,有些商店甚至一臺主機只運行一個容器。
6. 保護容器內容安全
這裏討論的是鏡像的軟件供應鏈。這是構建容器的基石,因此一項重要的基本功能就是要可以保證鏡像源完整性防禦,也就是當員工或提供原始容器鏡像的開源項目對鏡像作了修改時,你得清楚到底改動了哪些東西。 鑑於不少容器都在互聯網上共享的事實,可以掃描容器鏡像以確保不受感染是一項頗有用的功能。那麼,你的掃描頻率如何,能不能自動化掃描呢?能從可信源獲取鏡像當然很好,但每一個人都會犯錯,意外引入安全問題是不可避免的。 不過,對有些商店,你卻不用擔憂容器裏有哪些漏洞。這聽起來使人驚訝,但確實有意義——只除了一點:除非你能保證容器邊界足夠安全,或者你應用程序的實際代碼不觸及容器代碼有漏洞的部分。你對自家安全工具的自信程度,多是決定漏洞容忍度的最終因素。