“馬其諾防線(xiàn)”失效，如何做好容器云安全？

“高筑城墻以御外敵”的時(shí)代已經(jīng)過(guò)去，未來(lái)，企業(yè)的應用將變得無(wú)處不在，安全隱患也隨之無(wú)處不在。于企業(yè)而言，必須轉變開(kāi)發(fā)、運營(yíng)和安全策略。

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

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

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

安全新挑戰，“內網(wǎng)式安全感”不復存在

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

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

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

首先，來(lái)看看容器給企業(yè)帶來(lái)了哪些方面的安全挑戰。

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

所以，企業(yè)想要推行和使用容器，有幾個(gè)問(wèn)題必須要考慮：

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

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

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

換言之，企業(yè)要改變的不僅僅是某一個(gè)安全技術(shù)手段，而是整個(gè)安全策略。

安全意識“前移”，從被動(dòng)防御到主動(dòng)防護

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

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

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

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

舉個(gè)例子，比如在過(guò)去的應用開(kāi)發(fā)過(guò)程中，一般是由編程人員寫(xiě)好代碼放到源代碼庫，然后通過(guò)CI工具把代碼打包成鏡像，同時(shí)調用靜態(tài)掃描工具進(jìn)行安全掃描，確認無(wú)誤后通過(guò)CD工具推向測試云，最后再交付到生產(chǎn)云進(jìn)行上線(xiàn)?？梢钥吹?，這整個(gè)過(guò)程依賴(lài)的實(shí)際上還是靜態(tài)掃描。但是，如今很多網(wǎng)絡(luò )惡意行為都是動(dòng)態(tài)的，靜態(tài)掃描存在明顯短板。而解決辦法就是，在已有的CI/CD流水線(xiàn)中，增加一個(gè)安全合規測試云環(huán)節——也就是說(shuō)，在完成功能測試之后，先部署到安全合規的測試云中進(jìn)行動(dòng)態(tài)和靜態(tài)的安全合規測試，最后再推向生產(chǎn)云運行。

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

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

通過(guò)可視性和一致性，為開(kāi)放混合環(huán)境下的安全運營(yíng)護航

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

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

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

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

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

總而言之，“高筑城墻以御外敵”的時(shí)代已經(jīng)過(guò)去，未來(lái)，企業(yè)的應用將變得無(wú)處不在，安全隱患也隨之無(wú)處不在。于企業(yè)而言，必須轉變開(kāi)發(fā)、運營(yíng)和安全策略，通全局、求主動(dòng);而于技術(shù)服務(wù)商而言，能否成就企業(yè)觸及這一目標，實(shí)現跨環(huán)境的開(kāi)放安全運營(yíng)，將成為競爭力所在。