容器脆弱性風險:工具和優(yōu)秀實踐
容器正在迅速成為云原生生態(tài)系統(tǒng)中計算和工作負載部署的實際形式。
云原生計算基金會(CNCF)最近發(fā)布的云原生報道顯示:96%的組織不是在積極地使用容器和Kubernetes,就是在對容器和Kubernetes進行評估。容器的優(yōu)點是眾所周知的,比如可移植性、一致性和高效性。但同時,容器也隱含著一些安全問題。
容器安全是一個復雜的事情,它類似于是網(wǎng)絡(luò)安全的一個拓展。容器安全要求人員、流程以及技術(shù)的結(jié)合,其中人員是最重要的部分。因此,那些期望廣泛應(yīng)用容器的組織應(yīng)該幫助現(xiàn)有的職工提高技術(shù)水平,并引進一些具有必要技能的新員工,從而確保一個安全的云原生操作模式。其中,容器是該模式的關(guān)鍵組成部分。
目前,最大的政府機構(gòu)和技術(shù)方面的權(quán)威對軟件供應(yīng)鏈安全的關(guān)注正不斷升溫,這需要達到一定的嚴格度和成熟度,然而大多數(shù)組織都達不到該水平。在密切關(guān)注行業(yè)最佳實踐和指導的基礎(chǔ)上,通過實施下述的實踐和工具,我們就可以更加接近安全容器使用預期的最終狀態(tài)。
容器,云安全中相互交織的部分
首先,了解容器在云環(huán)境中的角色以及容器之間的交互是非常重要的。云原生生態(tài)系統(tǒng)通常具有云安全的四個C:云(cloud)、集群(cluster)、容器(container)以及代碼(code)。云的脆弱性、Kubernetes 集群以及應(yīng)用程序,其本身就具有一些安全問題,但這些超出了這里所要討論的范圍。
容器安全并非微不足道的小事。特別是由于容器存在的狀態(tài),例如映像或者運行時的容器,以及容器中的層和代碼。CNCF發(fā)布的白皮書《Cloud-Native Security》 在推動更好地了解云原生應(yīng)用、容器及其生命周期方面,起了個好頭。
注意容器可移植性的危險
容器的可移植性是它最為顯著的優(yōu)點之一。但這既是優(yōu)點,也是缺陷。由于容器通常是在多租戶架構(gòu)上運行的,所以如果向一個容器中引入脆弱性,然后進行分發(fā),那么實際上就是把該脆弱性發(fā)送給了使用該映像的所有人。并且還可能將它運行的環(huán)境置于風險之中。這意味著容器映像的可移植性以及分布式等特性可以被廣泛地利用和共享。這使得容器與其他問題聯(lián)系在一起,例如:開源代碼、基礎(chǔ)設(shè)施即代碼(laC)。這些都是本身就帶有脆弱性的。
容器通常是由外部的開發(fā)人員構(gòu)建,然后分發(fā)給企業(yè)的。這意味著諸如安全編碼實踐和容器安全最佳實踐等是一個很好的起點,但后者意味著什么呢?
在容器投入生產(chǎn)之前,對其進行掃描以檢測脆弱性
已經(jīng)出現(xiàn)的一些基本的最佳實踐包括:通過掃描(CI/CD)管道中的容器來防止脆弱性被引入到運行時的生產(chǎn)環(huán)境。Anchore和Trivvy 等開源代碼,以及Snyk等行業(yè)領(lǐng)導者都是很好的選擇。
在管道部署活動期間掃描容器,更為廣泛地推動了安全的左移。在管道中捕捉容器的脆弱性,可以防止脆弱性被引入到生產(chǎn)環(huán)境中,同時也可以預防不法分子趁虛而入。這比直接在生產(chǎn)環(huán)境中修補脆弱性,更加的高效,同時也降低了風險和成本。
因為許多容器是開發(fā)人員用來部署應(yīng)用而創(chuàng)建的,所以這些工具可以幫助他們解決問題。這比創(chuàng)建一個可能會人手不夠,且負擔過重的安全團隊來進行反復溝通,更加的有效。從而也避免了價值交付瓶頸期的產(chǎn)生。
盡管如此,在管道中掃描容器映像并不是一個萬全之策。容器映像通常情況下被存儲在存儲庫中,一旦部署到生產(chǎn)環(huán)境,就將以運行狀態(tài)存在。所以關(guān)鍵點是:在兩種環(huán)境中都要掃描它們。新漏洞是不斷出現(xiàn)的。因此,簡單地從存儲庫中提取以前掃描過的映像,并在不進行新掃描的情況下部署它,就可能會忽略掉一些自上次掃描以來發(fā)現(xiàn)的新漏洞。
同樣的道理也適用于生產(chǎn)運行中的脆弱性。由于潛在的訪問控制不良情況的發(fā)生,運行狀態(tài)下的的容器可能已經(jīng)遭到了篡改。我們可以通過識別運行時容器中的脆弱性,并利用工具通知相關(guān)工作人員來進行相應(yīng)的調(diào)查以及潛在的干預。
使用容器映像簽名
映像簽名是保護容器工作負載的另一個關(guān)鍵活動。我們都知道:網(wǎng)絡(luò)安全的CIA三要素:保密性、完整性以及可用性。容器映像簽名就類似于一種確保容器映像完整性的工具。它能夠確保你正在使用的容器映像是沒有被篡改,并且可信任的。這部分的操作可以集成到DevOps工作流中,也可以在注冊表中完成。
對于容器映像簽名,有若干選項可供選擇。最值得關(guān)注的其中一個是Cosign,它支持映像簽名以及驗證和存儲。同時,它還支持一些其他選項,比如硬件、密鑰管理服務(wù)(KMS)、以及自帶的公鑰基礎(chǔ)設(shè)施等。
另一方面,無鑰簽名正逐漸嶄露頭角,并且受到了像Chainguard等創(chuàng)新團隊的支持。無鑰簽名的本質(zhì)是支持“短期”密鑰,這種“短期”密鑰與身份綁定,并且僅在進行簽名活動的這段時間內(nèi)存在。
為容器映像構(gòu)建軟件物料清單
即使是容器,同樣也無法避免軟件供應(yīng)鏈中的一些安全問題的。企業(yè)正在設(shè)法利用工具來為其容器映像生成軟件物料清單 (SBOMs)。其中最著名的一個例子是Anchore的Syft 工具。Syft 可以為容器映像創(chuàng)建SBOM,并把此部分操作集成到CI/CD工作流程中。同時,Syft還可以使企業(yè)對其在容器生態(tài)環(huán)境中運行的軟件有更深入的了解,并在其他Log4類型場景發(fā)生時更好地做出響應(yīng)。
這種程度的可視化在傳統(tǒng)上是難以捉摸的。但在白宮和相關(guān)聯(lián)邦機構(gòu)(如網(wǎng)絡(luò)安全行政令EO)命令的指導下,各組織開始越來越關(guān)注軟件供應(yīng)鏈安全。NIST等組織發(fā)布了更新的安全軟件開發(fā)框架(SSDF),該架構(gòu)要求將SBOM應(yīng)用到歸檔和軟件發(fā)布保護等活動中。隨著SSDF的發(fā)布,對于安全開發(fā)實踐的關(guān)注度將會越來越高。
基于容器映像的SBOM需求是在推動認證的發(fā)展。這一點是TestifySec以及NIST在其軟件供應(yīng)鏈安全指南中所倡導的。NIST要求對SSDF進行認證,而SSDF則要求使用SBOM。還有一些創(chuàng)新的選項可以進一步加強SBOM,例如Syft,它可以支持 in-toto 規(guī)范的SBOM認證。這種認證方式幫助簽名者證明:SBOM正是容器映像內(nèi)容的準確表示。
點評
容器因其可移植性、簡單的可擴展性以及較低的管理負擔等優(yōu)點,被越來越廣泛地應(yīng)用于應(yīng)用軟件的部署當中。但是,容器既不提供不可滲透的安全邊界,也并不以此為目標。容器所帶來的安全隱患同樣應(yīng)受到相應(yīng)的關(guān)注與重視。