很多資深的安全專業(yè)人士都知道，許多甚至是大多數(shù)正在運行的容器具有高?；驀乐芈┒础Ａ钊烁鼮椴唤獾氖?，這些漏洞很多都已經(jīng)有了可用的補丁，因此可以(但尚未)修復。但云不應該是更安全嗎？

編輯搜圖

壞習慣在云上延續(xù)

把本地的信息系統(tǒng)遷移到云端，并不可意味著原來的工作環(huán)境或流程瞬間就得變得高效易用，安全更是如此。事實上，安全往往是人們最不想解決的問題，因為它往往會拖慢或影響業(yè)務。

以多因素身份驗證(MFA)為例。太多的人都知道，或者至少聽說過，信息系統(tǒng)的安全訪問應該實施MFA。安全公司Falcon的Sysdig數(shù)據(jù)顯示，48%的機構(gòu)沒有對root權(quán)限的賬戶啟用MFA。此外，27%的機構(gòu)使用root帳戶做管理任務，這明顯違反了所有的安全基準的建議。

身份和訪問管理(IAM)是最關(guān)鍵的云安全控制之一，我們應該圍繞它開發(fā)新的、云原生的流程。云團隊應該創(chuàng)建適用于特定任務的IAM角色，禁止額外的權(quán)限，以及對使用人進行角色培訓。不管怎樣，啟用MFA吧！

不完整的安全左移

復雜的流程轉(zhuǎn)換需要時間，而且通常要分階段進行。數(shù)據(jù)顯示，48%的鏡像首次漏洞掃描是在CI/CD管道中或容器注冊表中進行，也就是說，在部署運行之前。

這個數(shù)據(jù)意味著許多企業(yè)已經(jīng)開始“安全左移”。但另一方面，意味著更多的企業(yè)(52%)是在鏡像運行時才做第一次掃描，耽誤了潛在關(guān)鍵漏洞的發(fā)現(xiàn)。

部分原因是我們?nèi)匀粌A向于推遲安全評估以節(jié)省時間。另一種可能的解釋是，工作負載的一個子集并未包括在“左移”任務中。具體來說，許多不包含組織創(chuàng)建的自定義代碼的第三方應用程序，都屬于這一類。例如，Kubernetes組件、Web服務器和負載均衡可能要在軟件測試階段完成后很久才能配置。

這兩種情況，雖然 左移”都在發(fā)生，但并不完全。最先進的團隊正在使用他們的CI/CD管道測試所有工作負載的安全性，包括基礎(chǔ)設(shè)施組件，如主機、集群、容器等的部署清單。

風險也應該左移

當我們談論對風險的接受時，通常會認為這是最后的手段?！霸谶@一點上我無能為力，所以我將其記錄下來，然后一切交給上帝?！?

然而，越早發(fā)現(xiàn)風險來源，就越有能力為其制定有效的緩解措施。我們可能最終仍會運行有著關(guān)鍵高危漏洞的容器，但如果我們積極考慮與這些漏洞相關(guān)的風險，并實施控制措施來降低風險，安全態(tài)勢可能就不會那么糟糕。

當大家越來越擔心軟件供應鏈的安全性時，有必要考慮一下，那些第三方組件中有多少運行時漏洞，即使這些三方組件我們的軟件可能都沒有使用。

在軟件交付過程的早期，識別易受攻擊的依賴關(guān)系可以節(jié)省大量時間，并極大的降低風險暴露。我們無法修復所有的漏洞，但許多漏洞可以通過額外的安全控制進行管理。至少，應該記錄在案，以便于查看。

點評

如今，數(shù)以十億計的容器在云中運行。未來這個數(shù)字只會增加，同理，攻擊面和潛在風險也一樣會增加。事實上，新的工具和新的環(huán)境既是創(chuàng)新的機會，也往往會成為“技術(shù)欠債”的開始。但既然，我們已經(jīng)從過去的經(jīng)驗教訓中認識到了這個問題，為什么我們不能在一開始就放慢速度，把安全做好，做早？這就是云原生安全的核心推動力。