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

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

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

容器安全新挑戰(zhàn)，“內(nèi)網(wǎng)式安全感”不復存在

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

新聞名稱：“馬其諾防線”失效，如何做好容器云安全？
文章出自：http://jinyejixie.com/news15/202365.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、移動網(wǎng)站建設、網(wǎng)站排名、響應式網(wǎng)站、建站公司、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)