云為什么還是會被入侵

張格

很多資深的安全專業人士都知道，許多甚至是大多數正在運行的容器具有高危或嚴重漏洞。令人不解的是，這些漏洞很多都已經有了可用的補丁，可以（但尚未）修復，云不應該是更安全嗎？

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

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

身份和訪問管理（IAM）是最關鍵的云安全控制之一，我們應該圍繞它開發新的、云原生的流程。云團隊應該創建適用于特定任務的IAM角色，禁止額外的權限，以及對使用人進行角色培訓。

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

這個數據意味著許多企業已經開始“安全左移”。但另一方面，意味著更多的企業（52%）是在鏡像運行時才做第一次掃描，耽誤了潛在關鍵漏洞的發現。

部分原因是我們仍然傾向于推遲安全評估以節省時間。另一種可能的解釋是，工作負載的一個子集并未包括在“左移”任務中。具體來說，許多不包含組織創建的自定義代碼的第三方應用程序，都屬于這一類。例如，Kubernetes組件、Web服務器和負載均衡可能要在軟件測試階段完成后很久才能配置。這2種情況，雖然“左移”都在發生，但并不完全。最先進的團隊正在使用他們的CI/CD管道測試所有工作負載的安全性，包括基礎設施組件，如主機、集群、容器等的部署清單。

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

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

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

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

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