隨著數據的創建、存儲和使用持續顯著加速，安全漏洞和數據完整性風險也在全面升級。這些趨勢令人擔憂，最近的一個 study–查看勒索軟件和災難恢復準備的要求–表明到 2022 年，將近 80% 的組織接受調查的人啟動了災難響應。更重要的是，83% 的人經歷過數據損壞，最令人擔憂的是，近三分之二的人表示勒索軟件攻擊導致數據無法恢復。
確實，目前沒有可以考慮的應用程序類型完全免受勒索軟件的侵害。在這種情況產生的各種可能性中，有一種風險會給正在為 Kubernetes 重構其應用程序的組織帶來風險。重構是一種越來越流行的應用程序部署方法，通過這種方法，應用程序被分解為一系列隨後可以獨立運行的服務。這提供的主要好處之一是可以更有效地使用應用程序的底層硬件，同時還可以根據需要擴展每個服務，而不會影響其他服務和資源。
儘管 Kubernetes 和容器代表了一個作為交付高性能軟件基礎架構的流行且經過驗證的方法，那些採用該技術的人通常會很快意識到與重構相關的數據保護和安全問題可能會帶來重大挑戰。
為了給這些問題一些背景信息，IDC 還發現，目前，大多數容器化應用程序是從遺留代碼重構而來的，因此已經可以在裸機服務器或虛擬機上運行。重構過程並非沒有復雜性——一個常見的障礙是需要修改應用程序的現有元素以支持容器化。特別是，容器化帶來的好處可能很難實現，採用容器的組織希望看到安全性得到提高，但發現這是實現最具挑戰性的目標之一。
這些問題有可能以各種方式影響安全。例如，Pod 是 Kubernetes 部署的重要組成部分，它們的作用是託管每個應用程序進程的容器。每個 Pod 都有一個 IP 地址，可以直接與另一個 Pod 通信。但是，推薦的方法是使用服務，這些服務是可通過單個固定 DNS 名稱或 IP 地址訪問的 Pod 集。 Kubernetes 上的大多數應用程序都依賴服務進行通信，可能會暴露對 Pod 的訪問或由於頻繁重啟而導致集群內的網絡問題。因此，這可以為不良行為者提供切入點。
引起關注的其他主要原因之一是與供應鏈攻擊相關的風險。由於容器化應用程序是為自動化而設計的，尤其是在更新代碼時，一些 Kubernetes 部署可能會在不驗證更新或潛在漏洞的情況下不斷拉取應用程序的最新 Pod，從而增加使用該技術的組織的風險狀況。
加劇這些問題的是，目前從事設計和推出基於容器的生產應用程序的團隊缺乏技能和知識。在沒有將數據保護和網絡安全集成到開發工作流程的情況下部署的任何應用程序都可能更容易受到勒索軟件攻擊。
不妥協的保護
到為了幫助減輕攻擊可能對容器基礎設施造成的風險和影響，組織需要首先確定應重構哪些應用程序以及應如何集成相關數據。以此為基礎，還可以在整個過程的早期階段考慮安全和恢復技術。特別是，那些負責重構應用程序的人應該通過使用本機功能或尋求與有助於解決他們擔憂的數據保護解決方案的集成來專門解決最主要的容器安全風險。
這樣，容器化應用程序可以更有效地抵禦勒索軟件、惡意軟件和一系列其他可能破壞遣返的安全風險，即它們能夠恢復到任何給定安全事件之前應用程序的運行方式。
提供整體保護，組織應該仔細考慮他們選擇的數據保護技術。例如，實施本機解決方案可以確保數據保護也作為以容器為中心的策略的基本要素來解決。依靠這種方法，開發和安全團隊可以對他們提供最高級別的保護和彈性的能力充滿信心，同時確保利益相關者從推動這些創新的快速採用的固有性能和敏捷性中受益
圖片來源:kentoh/Depositphotos.com
Anthony Dutra 是 Zerto，一家 Hewlett Packard Enterprise 公司。