雖然越來(lái)越多的企業(yè)開始采用容器化的云原生應(yīng)用，但傳統(tǒng)的安全措施卻無(wú)力應(yīng)對(duì)新技術(shù)發(fā)展帶來(lái)的挑戰(zhàn)。當(dāng)下云原生雖說(shuō)異?；馃幔瑓s沒(méi)有一個(gè)清晰的路線圖，能夠指明在容器化過(guò)程中，各個(gè)階段該如何做好安全。由于容器化的每個(gè)階段都會(huì)帶來(lái)新的安全挑戰(zhàn)，企業(yè)必須在做好基礎(chǔ)架構(gòu)的同時(shí)，確保每個(gè)階段的安全?？梢灶A(yù)見，從第一個(gè)容器化應(yīng)用開發(fā)到管理數(shù)千個(gè)容器過(guò)程中，安全需求也在不斷變化。

為此，青藤發(fā)布國(guó)內(nèi)首個(gè)“容器安全成熟度模型”，旨在幫助企業(yè)在采用容器和容器擴(kuò)容過(guò)程中能夠更好理解并成功應(yīng)對(duì)所產(chǎn)生的各類安全挑戰(zhàn)。

一、引言

無(wú)論應(yīng)用是在容器中運(yùn)行，還是在虛擬機(jī)、主機(jī)上運(yùn)行，發(fā)生安全事件的后果都是相同的。此外，在安全事件發(fā)生后，無(wú)論打多少補(bǔ)丁，也無(wú)法挽回已泄露的敏感數(shù)據(jù)。據(jù)調(diào)查報(bào)告《2020年容器與Kubernetes安全狀況》顯示，94%的受訪者表示，在過(guò)去12個(gè)月中發(fā)生了容器安全事件。

在過(guò)去12個(gè)月中遭遇過(guò)容器安全問(wèn)題類型和比例

在很多情況下，企業(yè)并不完全了解容器化架構(gòu)所面臨的安全挑戰(zhàn)，更不用說(shuō)如何主動(dòng)應(yīng)對(duì)這些挑戰(zhàn)。這時(shí)，常見的做法就是將之前的安全策略應(yīng)用到容器中來(lái)，但這并不一定適合新的應(yīng)用體系架構(gòu)和開發(fā)工作流程?？偟脕?lái)說(shuō)，就是容器使用率不斷提高，但安全總是落后一步。

下文將針對(duì)容器安全成熟度模型進(jìn)行詳細(xì)解釋，旨在幫助企業(yè)更好了解需要部署哪些重要工具，采取哪些措施，來(lái)滿足當(dāng)前和未來(lái)容器安全需求。

二、容器安全成熟度模型

第1階段：實(shí)驗(yàn)學(xué)習(xí)

在這個(gè)階段，主要是開發(fā)人員自己學(xué)習(xí)如何在機(jī)器上使用容器。例如，通過(guò)一些不進(jìn)入生產(chǎn)系統(tǒng)的項(xiàng)目做練習(xí)。在這一階段，所涉及的應(yīng)用大多是一些基本應(yīng)用。

這階段可能持續(xù)數(shù)月之久。由于只有個(gè)別開發(fā)人員在學(xué)習(xí)和測(cè)試容器，因此只要項(xiàng)目不是用于生產(chǎn)，就不需要專用的安全工具，也不需要改變以往安全策略。與往常一樣，開發(fā)人員只需確保安全編碼。但是，這個(gè)階段安全也是聲明式的和自動(dòng)化的，是開發(fā)工作流程的一部分，而不是在完成應(yīng)用構(gòu)建后才解決安全問(wèn)題。

雖說(shuō)，在該階段安全并不太重要，也不會(huì)犯什么錯(cuò)誤。但是，如果組織機(jī)構(gòu)打算擴(kuò)展容器化項(xiàng)目，則需要確保讓每個(gè)人都了解，安全風(fēng)險(xiǎn)和復(fù)雜性會(huì)在擴(kuò)展后迅速增加。在第1階段和第2階段之間的安全挑戰(zhàn)存在巨大差異的，這會(huì)讓許多組織機(jī)構(gòu)措手不及。

第2階段：正式啟動(dòng)

在這個(gè)階段，容器化已不再是個(gè)別開發(fā)人員的業(yè)余項(xiàng)目，而是由團(tuán)隊(duì)或業(yè)務(wù)部門開展一部分正式項(xiàng)目。這時(shí)，開發(fā)團(tuán)隊(duì)會(huì)用容器創(chuàng)建一個(gè)用于生產(chǎn)的新應(yīng)用或?qū)F(xiàn)有應(yīng)用容器化。

大多數(shù)組織機(jī)構(gòu)在開發(fā)其第一個(gè)容器化應(yīng)用時(shí)，可能會(huì)使用下列其中一種方法：

將現(xiàn)有應(yīng)用容器化

將現(xiàn)有應(yīng)用的一部分內(nèi)容容器化

從頭開始在容器中開發(fā)新應(yīng)用

無(wú)論開發(fā)團(tuán)隊(duì)采取哪種方式，這一階段屬于概念驗(yàn)證階段，主要了解云原生技術(shù)會(huì)帶來(lái)效益，以及應(yīng)用是如何在容器中運(yùn)行的。

開展一個(gè)正式項(xiàng)目，就需要多人合作，這時(shí)就有必要建立一個(gè)鏡像倉(cāng)庫(kù)了。組織機(jī)構(gòu)可以創(chuàng)建私有鏡像倉(cāng)庫(kù)，通過(guò)策略規(guī)定誰(shuí)可以訪問(wèn)鏡像或鏡像倉(cāng)庫(kù)，確保鏡像來(lái)源可信。畢竟攻擊者通常會(huì)通過(guò)鏡像倉(cāng)庫(kù)中的受損鏡像，獲得對(duì)某個(gè)應(yīng)用的初始訪問(wèn)。

這個(gè)階段的第一個(gè)核心問(wèn)題是認(rèn)知偏差。從開發(fā)人員到習(xí)慣使用傳統(tǒng)工具的安全專家，幾乎沒(méi)有人完全了解容器中可能出現(xiàn)潛在安全問(wèn)題。這種知識(shí)或技能上差距會(huì)導(dǎo)致公司“所采取的安全”措施與“應(yīng)該采取的安全措施”之間會(huì)出現(xiàn)差距。

這一階段的第二個(gè)核心問(wèn)題是沒(méi)有做好未來(lái)規(guī)劃。只考慮當(dāng)前階段所需的工具和安全需求，而沒(méi)考慮容器化項(xiàng)目擴(kuò)大使用范圍之后所需的安全能力。公司在此階段必須考慮以下注意事項(xiàng)：

合規(guī)策略。容器安全不只是使用安全工具就可以徹底解決，還必須制定一些策略，這樣才能夠確保在整個(gè)容器生命周期中落實(shí)合規(guī)要求。雖說(shuō)大多數(shù)公司早已經(jīng)制定了一套安全策略來(lái)管理應(yīng)用開發(fā)，但也需要根據(jù)容器化應(yīng)用的特定環(huán)境，修改安全策略，滿足容器安全需求。

漏洞管理。在開發(fā)過(guò)程中，漏洞管理最重要的環(huán)節(jié)就是鏡像掃描。不同的掃描工具，其掃描的粒度也不同。有些掃描工具能夠發(fā)現(xiàn)操作系統(tǒng)漏洞和某些特定語(yǔ)言才會(huì)有的漏洞，而有些卻無(wú)法掃描每個(gè)鏡像層或某些開源軟件包。

配置管理。在該階段，DevOps和安全團(tuán)隊(duì)可以采用CIS基準(zhǔn)中針對(duì)Docker和Kubernetes的配置指南。在該階段，團(tuán)隊(duì)可能仍會(huì)手動(dòng)進(jìn)行配置管理，但是自動(dòng)執(zhí)行配置檢查的工具將改善安全狀況并減少運(yùn)營(yíng)工作量。

第3階段：生產(chǎn)部署

到這個(gè)階段，組織的第一個(gè)應(yīng)用已投入生產(chǎn)運(yùn)行。編排工具開始成為容器化應(yīng)用生產(chǎn)部署的一個(gè)關(guān)鍵部分。使用Kubernetes、MESOS、Swarm等工具可以自動(dòng)執(zhí)行與容器運(yùn)行相關(guān)的大多數(shù)操作任務(wù)。以Kubernetes為例，當(dāng)容器在Kubernetes中運(yùn)行時(shí)，它們被打包在Pod單元中。Pod可以包含一個(gè)或多個(gè)容器，但是同一Pod中的所有容器將共享相同的資源和本地網(wǎng)絡(luò)。

雖然編排工具可以讓容器應(yīng)用更具彈性并易于擴(kuò)展，但編排工具的使用也帶來(lái)了其自身的威脅向量。編排工具本身就會(huì)引入漏洞，而且其配置也會(huì)對(duì)組織機(jī)構(gòu)的整體安全狀況產(chǎn)生很大影響。此外，編排工具的默認(rèn)配置并不安全，如果忽略這些默認(rèn)配置會(huì)帶來(lái)巨大的安全風(fēng)險(xiǎn)。例如，Kubernetes的Kubeconfig文件是攻擊者獲得對(duì)應(yīng)用的初始訪問(wèn)的一種常用方法。

在此階段，要實(shí)現(xiàn)容器和編排工具的安全性，團(tuán)隊(duì)必須注意事項(xiàng)：

擴(kuò)展配置管理，在此階段，還需要加強(qiáng)容器和編排工具的配置管理。對(duì)于容器，需要做到以下幾點(diǎn)：

•確保實(shí)現(xiàn)正確的容器配置，不會(huì)產(chǎn)生計(jì)劃之外的特權(quán)用戶

•以非root用戶身份運(yùn)行容器

•在容器中使用只讀根文件系統(tǒng)

•使用秘鑰管理工具，而不要將秘鑰存儲(chǔ)在鏡像中

•調(diào)整容器的權(quán)限，確保訪問(wèn)限制盡可能嚴(yán)格

•設(shè)置容器的內(nèi)存和CPU限制，讓其能夠滿足功能需要求，但不能再執(zhí)行其他操作

對(duì)于編排工具(以Kubernetes為例)：

•使用命名空間隔離資源

•限制Pod之間的通信

•使用Pod安全策略限制Pod可以實(shí)現(xiàn)的功能

設(shè)置運(yùn)行時(shí)安全。應(yīng)用投入生產(chǎn)后，必須能夠檢測(cè)到應(yīng)用中出現(xiàn)異常行為，這可能是發(fā)生安全事件的前兆，包括：

•容器中運(yùn)行了哪些進(jìn)程

•是否有足夠的信息來(lái)評(píng)估每個(gè)容器的風(fēng)險(xiǎn)并相應(yīng)地確定修復(fù)的優(yōu)先級(jí)

•是否存在異常網(wǎng)絡(luò)流量，是否存在策略太寬松，導(dǎo)致發(fā)生安全事件后影響范圍過(guò)大

設(shè)置網(wǎng)絡(luò)分段。如何管理網(wǎng)絡(luò)分段將取決于具體應(yīng)用，但是網(wǎng)絡(luò)分段的原理沒(méi)有變化。應(yīng)允許每個(gè)Pod僅與執(zhí)行其功能所需的內(nèi)部或外部資源進(jìn)行通信。

滿足合規(guī)需求。合規(guī)要求取決于應(yīng)用的功能以及所在的行業(yè)。

第4階段：快速擴(kuò)容

在第一個(gè)應(yīng)用投入生產(chǎn)取得成功后，組織機(jī)構(gòu)就會(huì)將更多的應(yīng)用容器化，然后投入生產(chǎn)。這時(shí)，容器化所涉及的工程師和團(tuán)隊(duì)的數(shù)量增加了。

在這一階段，復(fù)雜性成為主要問(wèn)題。復(fù)雜性不僅會(huì)給安全帶來(lái)挑戰(zhàn)，還會(huì)給事件響應(yīng)和合規(guī)帶來(lái)挑戰(zhàn)。在該階段，組織機(jī)構(gòu)的治理策略對(duì)于確保開發(fā)、測(cè)試、部署和運(yùn)行應(yīng)用的標(biāo)準(zhǔn)工作流程至關(guān)重要。這些策略包括安全防護(hù)，確保在整個(gè)組織機(jī)構(gòu)中統(tǒng)一安全處理，并最大程度地降低個(gè)人錯(cuò)誤的風(fēng)險(xiǎn)。

在這一階段，應(yīng)主要注意以下方面：

自動(dòng)化至關(guān)重要。隨著公司處理的集群越來(lái)越多，手動(dòng)進(jìn)行配置管理或手動(dòng)篩選原始事件數(shù)據(jù)來(lái)分析運(yùn)行時(shí)行為，已不太可行。自動(dòng)化變得尤其重要，通過(guò)自動(dòng)化工具實(shí)現(xiàn)統(tǒng)一行安全策略是唯一可行方法。

更復(fù)雜的合規(guī)要求。在此階段，重要的是要追蹤，哪些應(yīng)用或微服務(wù)要滿足哪些合規(guī)要求，并通過(guò)合規(guī)檢查來(lái)查看它們是否滿足合規(guī)要求。

服務(wù)隔離和分段。隨著服務(wù)數(shù)量的增加以及合規(guī)和安全生態(tài)系統(tǒng)變得越來(lái)越復(fù)雜，在服務(wù)之間進(jìn)行適當(dāng)?shù)牧髁扛綦x和分段至關(guān)重要。

第5階段：在全組織機(jī)構(gòu)范圍內(nèi)采用容器

這個(gè)階段，所有新應(yīng)用都在容器中開發(fā)，并且還可能將現(xiàn)有應(yīng)用移入容器。組織機(jī)構(gòu)將在基礎(chǔ)結(jié)構(gòu)和安全方面遇到新問(wèn)題。在該階段，大多數(shù)組織機(jī)構(gòu)將考慮不只是使用編排工具來(lái)進(jìn)行編排。他們將使用服務(wù)網(wǎng)格之類的技術(shù)來(lái)管理服務(wù)之間的交互方式，并了解各個(gè)服務(wù)的行為以及服務(wù)之間的通信。

隨著將更多層(例如Kubernetes和服務(wù)網(wǎng)格)添加到堆棧中，有太多的按鈕需要控制，已無(wú)法再用手動(dòng)控制，因此自動(dòng)化變得至關(guān)重要。在該階段，優(yōu)化和自動(dòng)化至關(guān)重要。組織機(jī)構(gòu)應(yīng)不斷尋找簡(jiǎn)化開發(fā)和運(yùn)營(yíng)的流程，簡(jiǎn)化與編排工具的交互界面，并實(shí)現(xiàn)重復(fù)性工作的自動(dòng)化運(yùn)行。

例如，容器和編排工具的默認(rèn)配置一般不太安全，因此公司需要依靠自動(dòng)化來(lái)確保，在公司范圍內(nèi)統(tǒng)一實(shí)行符合其標(biāo)準(zhǔn)和配置的安全規(guī)定。在第5階段新加入的其他技術(shù)層也有一套針對(duì)他們自身的配置、隔離和漏洞管理的最佳實(shí)踐辦法。

在容器化進(jìn)程中，這一階段成熟度最高，所有新開發(fā)都是在容器中完成的，因此，每個(gè)人都會(huì)步入一個(gè)未知的世界，出現(xiàn)第二次技能差距。每次將新的層或技術(shù)添加到堆棧中時(shí)，都會(huì)產(chǎn)生新的學(xué)習(xí)曲線。同時(shí)，隨著應(yīng)用變得越來(lái)越復(fù)雜，新的威脅向量可能會(huì)出現(xiàn)。組織機(jī)構(gòu)需要確保他們擁有的安全工具能夠隨著它們添加這些新技術(shù)，增強(qiáng)容器安全。因?yàn)殡S著應(yīng)用控件的復(fù)雜性增加，可見性和自動(dòng)配置管理的重要性成倍增加。

三、做好容器化進(jìn)程中每一步的安全

任何組織機(jī)構(gòu)都無(wú)法實(shí)現(xiàn)絕對(duì)的安全，但是需要在容器化進(jìn)程中，最大限度地確保容器安全。很多時(shí)候，做好容器安全的關(guān)鍵不在于技術(shù)，而在于各團(tuán)隊(duì)之間協(xié)作，以及對(duì)安全是否足夠重視。

在早期階段就重視安全。組織機(jī)構(gòu)需要采用“安全左移”的方法，將安全從一開始就集成到開發(fā)過(guò)程中來(lái)，這在容器化過(guò)程的任何階段都是很有用的。在開發(fā)過(guò)程中盡早關(guān)注安全不僅有助于提高安全性，而且，還可以減少在部署過(guò)程中在最后一刻出現(xiàn)意外情況。

加強(qiáng)與安全團(tuán)隊(duì)的協(xié)作。安全團(tuán)隊(duì)?wèi)?yīng)該與DevOps團(tuán)隊(duì)合作，這種協(xié)作在開發(fā)過(guò)程的每個(gè)階段都很重要。安全團(tuán)隊(duì)不應(yīng)該只專注于發(fā)現(xiàn)問(wèn)題所在，更應(yīng)該成為內(nèi)部培訓(xùn)師，加強(qiáng)DevOps團(tuán)隊(duì)對(duì)安全的理解。

預(yù)測(cè)未來(lái)的需求。組織機(jī)構(gòu)不應(yīng)該等到應(yīng)用投入生產(chǎn)，才去關(guān)注容器安全?？偸窃诎l(fā)生安全事件后，才去打補(bǔ)丁，這樣會(huì)讓組織機(jī)構(gòu)總會(huì)暴露在一些風(fēng)險(xiǎn)之中。

明確安全的最終負(fù)責(zé)人。為提高安全效率，安全要采用一種靈活的責(zé)任制。不同類型的應(yīng)用可能需要不同的結(jié)構(gòu)，但是在每種情況下，都必須指定一個(gè)人作為安全主管。共同承擔(dān)安全責(zé)任可能會(huì)導(dǎo)致所有人覺(jué)得自己不負(fù)責(zé)安全問(wèn)題。

準(zhǔn)確評(píng)估不同應(yīng)用和基礎(chǔ)架構(gòu)的安全需求。每個(gè)應(yīng)用的安全需求不盡相同。面向公眾的應(yīng)用比內(nèi)部應(yīng)用遭受的風(fēng)險(xiǎn)更大;受到嚴(yán)格監(jiān)管的行業(yè)比其他行業(yè)的組織機(jī)構(gòu)更需要增強(qiáng)安全性。因此，要確定組織機(jī)構(gòu)要規(guī)避風(fēng)險(xiǎn)，需要實(shí)現(xiàn)什么級(jí)別的安全性。

四、總結(jié)

容器作為一種輕量化、可移植的虛擬技術(shù)，使用非常便捷，越來(lái)越多的企業(yè)選擇使用容器技術(shù)。但在組織機(jī)構(gòu)內(nèi)不同的容器化階段，該采取怎樣的安全措施，很多企業(yè)并沒(méi)有一個(gè)明確的路線圖。本文介紹的容器安全成熟度模型，將容器安全分為五個(gè)階段，介紹了每個(gè)階段面臨的安全挑戰(zhàn)，以及應(yīng)該采取的安全措施，希望能夠讓正在進(jìn)行容器化的各個(gè)企業(yè)，加強(qiáng)對(duì)容器安全的了解，有效應(yīng)對(duì)安全挑戰(zhàn)。

（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）