This post is also available in: English (英語) 简体中文 (簡體中文) 日本語 (日語) 한국어 (韓語)
如果您像我一樣，您也可能會對於跟上五花八門的「現狀」報告感到有點力不從心。而我只談論網路安全領域的內容 — 從 SBOM 到開放原始碼，再到我們自己的 2024 年雲端原生安全報告。
儘管如此，每份報告都充滿引人入勝的見解和關鍵重點，反映其調查所處的生態系統現狀。我們的報告也不例外。如果您是雲端投資激增的眾多企業之一 (每年的雲端服務相關投資金額超過 1000 萬美元)，那麼這份報告至少可以讓您放心，您並不孤單。
首先，我們可以處理一些或許無聊但有其必要的可信度細節。
「2024 年雲端原生安全現狀報告」提供來自10 個國家/地區 (從企業到中小型企業) 超過 2,800 多名受訪者的調查數據，其中包括開發、IT 和安全職能部門的領導階層和從業人員等各種角色。廁所位於大廳左側，如果發生火災，請在 E 停車場集合。好的，我想是切入正題的時候了。
我們與 AI 之間愛恨交織的關係
任何一個編寫各種類型程式碼的人都一定都看過類似提示：
「我正在開發一個 Terraform 專案，並且需要根據特定要求佈建 AWS EC2 執行個體：它的類型應為「t2.micro」，位於「us-east-1」區域內，並包含「Name」標籤 (設為「MyInstance」) 和「Environment」標籤 (設為「Development」)。是否能請您提供用於定義此資源的 Terraform 程式碼片段？」
(摘自 The New Stack 上這篇精彩的文章。)
當然，如果只是想要創造一些可能有用的東西，其確實能發揮作用！但是事情還沒結束。產生程式碼的能力是開發人員的「糖果火箭燃料」，直接影響我們如何激勵他們的行動。時間是一個重要因素，就像是各種競爭性新功能的上市時間一樣。
毫不令人意外地，雖然 100% 的受訪者都已採用 AI 輔助的應用程式開發 (和安全性)，例如各種可用的 Copilot，但仍有許多人對於與 AI 生成式程式碼有關的安全風險感到憂心不已。尤其是應用於公用 LLM 的 AI，根本就是一台垃圾進垃圾出的機器。在公共領域中，安全編碼範例少之又少，業界相當擔心開發人員可能會求助於 AI，無意中引入更多原本可能已經避開這些程式碼的不安全預設值。
儘管眾人都已意識到存在這樣的風險，但是這種一致性的作法正代表著我們可能需要實施 (額外的) 監管來平衡速度更快的創新和安全步伐。
我們與 AI 的關係並未就此結束。繼去年針對雲端原生生態系統的攻擊大幅增加之後，將近一半的安全專業受訪者都預期 AI 驅動的供應鏈攻擊也將隨之激增，許多人都預測這些攻擊者將能規避傳統的偵測技術。
企業意識到 AI 同時作為創新推動者和潛在攻擊途徑所帶來的認知失調，並凸顯在追求 AI 優勢與嚴格安全措施之間取得平衡的必要性。
我的數據在哪裡？
根據報告，數據洩漏事件有上升的趨勢，雖然 AI 的輔助是可能的原因但並未獲得證實。受訪企業均表示洩露增加的幅度相當大，已超過 60%。事實上，有 45% 的企業報告指稱，進階持續性威脅 (APT) 和隱匿性攻擊確實有所增加，而且這些攻擊可能很長一段時間都未被偵測到。我們不僅需要主動監控以及進階威脅偵測與回應，更迫切需要在雲端環境中部署強大的數據安全措施。
數據就是珍貴資產！雖然阻斷服務攻擊 (包括勒索軟體) 實際上仍構成威脅，但是我們藏匿在雲端原生防火牆之後的數據才是許多攻擊者的目標。
不僅城牆建得更高、門口還有龍把守著，並且加倍守衛人數，為整個城堡帶來更複雜的可觀察性。然而，許多企業其實並不知道黃金藏在何處。
雖然可能讓人難以置信，不過確實仍有 50% 的企業依賴手動審查對雲端中的敏感數據進行分類和識別。我們需要一套現代化的解決方案，特別是考慮到除了從受管理服務中得知的數據以外，我們的雲端環境中還潛藏著未受管理數據解決方案和影子數據時，這樣的需求自然就不言可喻。一個簡單的容器化數據庫快取個人可識別資訊 (PII) 潛伏在 Kubernetes 叢集中需要進一步探索和分類，只有透過自動化才能解決，以藉此偵測及保護我們全然未知的數據。
我們已知的未知資產則包括針對內部解決方案所廣泛採用的 AI 數據。我們知道這對於數據安全構成全新且令人興奮的挑戰，例如，就以用於訓練及代表各種模型及服務的數據來說，必須確保其存取權限受到控制。這還不包括建置和監控已部署的 AI 輔助式應用程式目錄。
我們並不只是在談論客戶數據/黃金。雖然只有 38% 的企業表示在密碼管理方面遭遇困難，但有超過 43% 的企業表示，在過去的一年，他們的密碼暴露情況有所增加。
使用工具解決問題！
如果您從未參加過 CISO 系列「超級網路星期五」活動，我衷心推薦您參加。他們與網路安全專家們進行高度互動且非常有趣的訪談。具體來說，他們有一個「BAD IDEA」的環節，聽眾可以針對指定的問題提出最糟糕的解決方案。對於這樣一個環節，「使用工具解決問題」將是一個具有諷刺意味的回答。
受訪的企業平均使用 16 個雲端安全工具，但是 90% 的受訪者表示，使用的單點工具數量不斷擴增，反而造成安全盲點。這樣的情況已經影響他們處理風險的優先順序以及防範威脅危害安全效用的能力。
但這種具諷刺意味的情況並未就此結束。幾乎所有安全專業受訪者都同意，其企業需要一種解決方案，能夠自動識別最有可能導致攻擊的弱點和錯誤設定，並且提供立即的補救措施。聽起來他們可能需要 CNAPP。
接下來讓我們談談這些威脅。對你我來說都息息相關！
DevSecOps 會在什麼時候達成？我賭 100 美元會在 2037 年 12 月。SecOps 和 DevOps 團隊之間尚未上演「攜手共進」的情節，因為超過 80% 的 DevOps 仍然將安全性視為一種限制因素。事實上，設置門檻本來就是安全團隊的工作，這是他們應該做的事情。也是一種必要之惡。設置門檻的問題更可能在於，將安全整合到開發環境的方法 (以及在某種程度上整合到開發人員的思維中) 還沒有達到應有的簡化程度。
對立的雙方都缺乏同理心。超過 90% 的安全團隊認為開發人員應該只需要編寫安全的程式碼。問題就解決了！事實上，成功的關鍵介於兩者之間。了解 AI 是否會成為絕佳的 DevSecOps 融合劑，或者其是否會在提高開發速度的同時加劇問題惡化，這些都是都非常值得探討的議題。
未來趨勢
隨著企業開始因應雲端原生安全的複雜性，該報告提供寶貴的建議來加強其安全狀況：
- 從雲端移轉計劃一開始就優先考慮安全性、將其嵌入整體策略中，以避免弱點、數據洩露和違規處罰。
- 有鑑於雲端服務市場的複雜性和多樣性，應徹底研究各種工具和廠商，評估最適合企業需求、預算和策略目標的選項。
- 促進開發和安全團隊之間的協作，調整優先順序並簡化流程以減少衝突並確保高效率、安全的應用程式部署。
- 雲端原生應用程式中資源和數據的激增是真實存在的。無論企業規模大小，從手動轉向現代化都是一條必經之路。
- 隨著雲端持續重塑數位環境，企業必須在安全策略中隨時保持警戒和主動。在加強防禦的同時積極創新，企業將可以因應雲端原生時代的複雜度，並且釋放其成長和轉型的全部潛力。
進一步了解
不要錯過這份 2024 年雲端原生安全現狀報告。立即下載。