如果雲更安全 為什麼還是被入侵？

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

壞習慣在雲上延續

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

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

身份和訪問管理(IAM)是最關鍵的雲安全控制之一，我們應該圍繞它開發新的、雲原生的流程。雲團隊應該建立適用於特定任務的IAM角色，禁止額外的許可權，以及對使用人進行角色培訓。不管怎樣，啟用MFA吧!

不完整的安全左移

複雜的流程轉換需要時間，而且通常要分階段進行。資料顯示，48%的映象首次漏洞掃描是在CI/CD管道中或容器登錄檔中進行，也就是說，在部署執行之前。

這個資料意味著許多企業已經開始“安全左移”。但另一方面，意味著更多的企業(52%)是在映象執行時才做第一次掃描，耽誤了潛在關鍵漏洞的發現。

部分原因是我們仍然傾向於推遲安全評估以節省時間。另一種可能的解釋是，工作負載的一個子集並未包括在“左移”任務中。具體來說，許多不包含組織建立的自定義程式碼的第三方應用程式，都屬於這一類。例如，Kubernetes元件、Web伺服器和負載均衡可能要在軟體測試階段完成後很久才能配置。

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

風險也應該左移

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

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

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

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

點評

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