確保您遷移到混合云

Infosec 專家 Rani Osnat 提出了安全挑戰，并為將其 IT 堆棧遷移到私有云和公共云環境的組織提供了希望。

大多數組織已經在使用的私有云和公共云基礎設施的結合帶來了獨特的安全挑戰。組織采用公共云的原因有很多——從無需容量規劃負擔的情況下實現快速增長，到利用靈活性和敏捷性提供以客戶為中心的服務。但是，這種使用可能會使公司面臨威脅。

由于監管要求或其他偏好要求某些應用程序保留在私有（本地）基礎設施上，因此許多組織選擇維護私有和公共基礎設施的混合。此外，組織通常同時使用多個云提供商或保留在提供商之間移動的選項。然而，這種混合方法帶來了獨特而多樣的安全挑戰。不同的云提供商和私有云平臺可能提供類似的功能，但實施安全控制的方式不同，以及不同的管理工具。

那么問題就變成了：一個組織如何在不同的云中保持一致的治理、策略執行和控制？它如何確保在它們之間移動時保持其安全狀態？幸運的是，專業人員可以采取一些步驟來確保應用程序的持續安全，從開發的早期階段開始，一直延伸到整個生命周期。

舊的安全工具在云中不再有效

出于多種原因，并非在云中誕生的安全工具無法保護在云中運行的應用程序。首先，與傳統的瀑布方法相比，它們無法應對云原生應用程序顯著加快的開發周期。使用云原生 CI/CD 的組織不是每隔幾個月發布一次版本，而是不斷地集成和部署應用程序和更新，有時每天多次。這就要求采用一種自動化的方法來確保安全——一種嵌入到開發早期階段的方法，這樣它就不會成為減緩開發和運營的瓶頸。

此外，在動態和多樣化的云環境中，安全解決方案不能再期望或依賴永久的基礎設施和位置。如果在過去，我們知道某個服務器運行某個應用程序（例如，Microsoft Exchange 服務器或數據庫），那么我們不能假設今天同樣的情況也適用。現代云應用程序解決方案與應用程序本身相關，而不是與其 IP 地址或特定服務器位置相關聯。工作負載的自動編排意味著數據庫現在可能在一個容器上運行，而在 10 分鐘后在另一個具有不同 IP 地址的容器上運行。或者，也許明天，整個集群將完全遷移到不同的云提供商。這就是為什么組織需要使用更現代的、特定于云的解決方案，而不是不適合云的舊解決方案。

云提供商自己的安全工具：有限的答案

主要的云提供商都使用所謂的“責任共擔模型”，在非常簡單的層面上，它區分了“云的”安全（提供商的責任）和“云中的”安全（客戶的責任）。“共同責任”并不轉化為共同責任。談到公有云數據中心的物理安全，組織不必擔心；云提供商以最高標準運行此類安全性，類似于主要銀行和政府機構所采用的安全性。但對于其他一切，責任完全在于客戶組織——事實上，Gartner 預測，到 2025 年，99% 的云安全故障將發生在客戶方面。

云安全提供商 (CSP) 提供的工具通常只能部分覆蓋客戶需求，并增加客戶對云提供商的依賴，但在保護多云環境，尤其是私有云方面并不同樣有效。

新堆棧非常適合安全性

好消息是，用于運行新堆棧的技術（例如容器和 Kubernetes）可實現比以往任何時候都更好的安全性，并且具有更精細的可見性和自動化。如果正確應用安全控制，它們還可以更輕松地跨私有云和公共云環境傳輸安全性。

由于容器是可移植的，而 Kubernetes 可以在任何云環境中運行，如果您附加專門用于保護容器的安全工具，您可以在任何地方統一運行它們，而不管您的應用程序在哪里。

由于云環境的復雜性和涉及的許多移動部件，規劃技術堆棧需要一種整體方法來保護應用程序的整個生命周期——從開發到生產。這種方法應該能夠處理跨基礎設施組件和應用程序代碼的多個安全漏洞，無論是管理漏洞、錯誤配置、惡意軟件還是行為異常。

云中誕生的方法

公司現在不僅誕生在云中，而且還專門著手保護新的云原生堆棧，從容器到虛擬機和無服務器。云原生應用程序保護平臺 (CNAPP) - Gartner 命名的一個新類別 - 保護企業應用程序免受攻擊，這些攻擊隨著云采用的增長而增加。

雖然云安全的未來是光明的，但現在是不確定的。這是由于專門針對云基礎設施和供應鏈的攻擊的數量和復雜程度的增加。一個易受攻擊或配置不當的 Kubernetes 節點將在短短 20 分鐘內成為目標。這些復雜的攻擊可能會導致各種惡意結果，從加密貨幣挖掘到憑據盜竊，從 rootkit 安裝到網絡遍歷。

將更多工作負載轉移到云端的競賽與保護這些工作負載的能力之間的滯后源于知識和技能不足，但有一些平臺可以彌補這些差距。更重要的是，由于高水平的策略驅動自動化、攻擊面的減少以及檢測應用程序組件的最小漂移或行為異常的能力，公司可以實現前所未有的安全水平。作為開發、部署和運行云應用程序不可或缺的一部分的安全方法是前進的方向。