第一次世界大戰之后，為了防止德軍突襲，法國花重金用了十幾年時間在德法邊境建造了一座延綿390公里的防御工事，內設大炮、壕溝、堡壘，甚至是廚房、醫院、工廠，深溝高壘、四通八達——這就是大名鼎鼎的“馬奇諾防線”。但如我們所知，這個原以為牢不可破的防御線最終并沒有讓法國把德軍阻擊在外，相反地，由于對馬奇諾防線的盲目自信和過度依賴，導致法國備戰懈怠，二戰中，德軍繞道比利時，翻越了天險阿登高地，從防線后方直接兵臨巴黎城下。

軍事家們認為，馬奇諾防線失效的原因在于“完全防御”軍事思想的失效。和一戰不同，二戰講求的是機動靈活作戰，但法國并沒有借馬其諾防線主動組織進攻，而是選擇了嚴防死守，當德軍從缺口直驅巴黎的時候，防線的士兵還在原地等著人家從正面進攻，而城內的人們甚至還沉迷在燈紅酒綠之中。

其實，像“馬奇諾防線”這樣，外面看似厚墻高筑，里面實則十分松散的狀態，就很像計算機概念中的“防火墻”。過去，大多數企業都信奉“內網式安全”，認為只要把數據放在“墻內”就能安全無虞——但是很顯然，這樣的安全策略就像是二戰中失效的“馬奇諾防線”一樣已經過時。

[[422677]]

容器安全新挑戰，“內網式安全感”不復存在

和二戰的情況類似，如今企業所處的外部經濟環境震蕩多變，要求大家在業務發展過程中必須靈活且高效應對，這就是為什么近幾年來，容器應用開始大行其道的重要原因。由于能夠滿足企業快速響應、敏捷開發的需求，容器已經成為企業應用交付的主流形式。

但是，相較于傳統應用而言，容器天然在隔離和安全性等方面存在著“缺陷”，這些“缺陷”隨著容器一起跑在所謂的企業內網中，如果不能很好地識別并修復，分分鐘就會成為“馬奇諾防線”上的缺口，給企業帶來不可估量的損失。

面對這種情況，靠砌“一道墻”就擁有的安全感就蕩然無存，換句話說，企業必須重新審視并調整自己的安全策略。

首先，來看看容器給企業帶來了哪些方面的安全挑戰。

我們知道，目前Kubernetes已經成為應用創新的標準平臺，而DevOps也已經成為支持云原生應用開發和運維的主流實踐方法論。在這樣的開發理念之下，企業應用往往需要同步在本地數據中心和云上部署和交互，這意味著，物理安全邊界將會消失，安全隱患變得無處不在，傳統安全策略中通過構建一個“安全邊界”，把非信任域的東西阻擋在“墻”外的做法自然就不合時宜。

所以，企業想要推行和使用容器，有幾個問題必須要考慮：

第一，軟件供應鏈的安全性。由于容器應用中有很多代碼、組件來自于開源社區或者第三方外包開發，如果不能對其中的高危漏洞有效識別，或者被別有用心者利用，就等于把有問題的代碼提供給了使用者，使整個鏈條上的安全體系“崩塌”;

第二，基礎設施的安全性。如今，很多企業仍然傾向于使用“DIY”的Kubernetes平臺，再配上一些安全掃描的工具，這樣的基礎設施實際上很難滿足和評估企業在安全合規方面的要求，會使得整個平臺或業務暴露在風險之下。另一方面，Kubernetes的安全責任相對分散，全責不明確也會造成管理的松散，不利于安全策略落實;

第三，應用負載的安全性。容器改變了傳統的應用部署模式，不僅應用生命周期被大幅縮短，部署密度也越來越高，傳統安全策略很難適應需求。另外，在對應用(尤其是第三方應用)進行容器打包之后，它的行為是否正常、能否達到安全標準，用過去的安全系統也很難進行全面監控，如有問題就會直接對業務產生影響。

換言之，企業要改變的不僅僅是某一個安全技術手段，而是整個安全策略。

安全意識“前移”，從被動防御到主動防護

如果吸取法國“馬奇諾防線”安于防守的教訓，這意味著，企業首先要做的就是化“被動”為“主動”，優先占據主動權，而不是等著攻擊發生后才做出反應。放在容器安全這件事上，也就是說，企業必須把安全意識和手段“前移”。

有相關調查顯示，從應用研發、構建、部署到運行的不同階段，期間產生的安全成本是逐級遞增的。舉例來說：如果在研發階段發現漏洞，只要由開發人員直接修復即可，成本低而且效率高;如果等到發布后才檢測出漏洞，那就需要安全人員給出方案，與研發人員溝通，再由測試人員驗證，不僅相對成本高，而且還存在一定的線上風險;而如果等到應用運行了一段時間后漏洞才被發現，那就不只是補救的問題了，一方面企業需要付出額外的金錢、溝通成本和修復時間，另一方面還需要運維、發布、業務等大量人員的介入，給企業帶來的風險和成本壓力是數十上百倍的。

正因如此，把安全理念貫穿到DevOps 全流程中，“糅合開發、安全及運營理念以創建解決方案的全新方法”，越來越成為業界共識——這就是DevSecOps，它的基礎思想，即是“開發安全左移(SHIFTLEFT)”。

可以這么理解，所謂“左移”實際上就是把安全意識從運行階段，前置到容器構建和CI/CD階段，從而避免造成運行后不可挽回的損失以及高昂的補救成本。

舉個例子，比如在過去的應用開發過程中，一般是由編程人員寫好代碼放到源代碼庫，然后通過CI工具把代碼打包成鏡像，同時調用靜態掃描工具進行安全掃描，確認無誤后通過CD工具推向測試云，最后再交付到生產云進行上線。可以看到，這整個過程依賴的實際上還是靜態掃描。但是，如今很多網絡惡意行為都是動態的，靜態掃描存在明顯短板。而解決辦法就是，在已有的CI/CD流水線中，增加一個安全合規測試云環節——也就是說，在完成功能測試之后，先部署到安全合規的測試云中進行動態和靜態的安全合規測試，最后再推向生產云運行。

尤其是針對第三方外包廠家提供的應用，這樣的思路尤為受用，因為越來越多的廠家都在用容器方式打包應用，但這些應用的開發流程對于企業來說就是一個“黑盒子”，如果還采用傳統的鏡像文件靜態掃描，那就很難保障容器平臺安全。

但是，換個角度再來看這個問題。我們知道，大多數企業選擇使用開源技術或者容器應用，都是為了避免“重復造車”，加快敏捷開發，如果為此令企業處處擔心安全漏洞，要求企業自己能夠配備非常復雜的安全監管機制，這并不現實。對于企業而言，需要的是開箱即用的安全策略，并且，希望能夠為實際運行的容器環境自定義多因素策略。

通過可視性和一致性，為開放混合環境下的安全運營護航

顯然，作為企業級Kubernetes解決方案的“核心玩家”，紅帽對這個問題的考慮是具有前瞻性的。在OpenShift上，紅帽為容器和云原生應用提供了從構建、部署到運行的持續安全性，并且，能夠從容器云平臺自身以及多集群管理等多個方面，滿足企業多維度的安全需求。

為了不錯漏任何一塊“拼圖”，紅帽還在今年年初收購了Kubernetes原生安全領域服務商StackRox，通過將其能力輸入到OpenShift，實現了優勢互補，并據此打造了紅帽容器安全管理平臺RHACS(Red Hat Advanced Cluster Security)。通過這一平臺，紅帽能夠幫助企業做到把安全設計前移到容器構建和CI/CD階段，從而為整個IT堆棧以及整個生命周期實現更高的安全性提供統一的解決方案。

具體來說，RHACS可以在以下幾個場景保障容器應用的安全使用：首先，是漏洞管理，通過對漏洞的識別、分類、報告，確定優先級并進行及時修復，保護系統免遭潛在鏡像和運行容器中的已知漏洞威脅;其二，是配置管理，確保應用部署和配置的過程符合最佳安全實踐;其三，是風險分析，也就是通過對某個對象的綜合安全指標分析，確認最嚴重的問題進行優先處理;其四，網絡細粒度安全管理，通過網絡監控實現應用的網絡隔離和訪問控制策略，實時監測應用的異常網絡行為;其五，在合規方面，RHACS可以幫助企業滿足監管和企業自身安全要求，輕松生成報表并按照要求進行審計和整改;其六，實時對運行環境中的威脅進行檢測，并根據風險級別高低，提供給相關人員進行主動及時響應。

值得一提的是，這一系列安全管理操作都可以通過可視化的方式實現。也就是說，相關人員都能夠通過平臺直觀地看到系統中有多少高危漏洞、合規要求是否滿足、哪些位置存在高風險，以及應用部署后對安全合規的影響等等。如此一來，就能大大減少實施安全性所需的時間和精力，簡化安全性分析、調查和補救工作。

當然，這些能力并不只局限于紅帽的OpenShift，在收購之后，StackRox將繼續支持多個Kubernetes平臺，包括Amazon Elastic Kubernetes Service(EKS)、Microsoft Azure Kubernetes Service(AKS)以及Google Kubernetes Engine(GKE)等等。這意味著，企業用戶將能夠真正地在開放的混合云環境中，構建、部署、運行各種應用，并且享用到更高級別、更全方位的安全保障。

總而言之，“高筑城墻以御外敵”的時代已經過去，未來，企業的應用將變得無處不在，安全隱患也隨之無處不在。于企業而言，必須轉變開發、運營和安全策略，通全局、求主動;而于技術服務商而言，能否成就企業觸及這一目標，實現跨環境的開放安全運營，將成為競爭力所在。