很顯然，許多組織在積極采用云。但問題是，他們完全了解云嗎?是否知道如何保護在云端構建的應用程序?就像任何新興技術一樣，種種神話和誤區自然隨之出現。

說到安全，哪怕小小的失誤都會導致違規或網絡攻擊，從而使貴組織蒙受慘重損失。為了盡量減小這種事情的可能性，有必要了解最常見的云原生安全誤區以及對策，確保貴組織避免不必要的風險。

別讓云原生誤區破壞安全

要建立更強大的安全態勢，第一步是教育：知道在云原生環境中不該做什么與知道該做什么同樣重要。

本文旨在揭穿云原生安全方面最常見的誤區，并給出切實可行的建議。

誤區一：云提供商負責所有安全措施

許多組織以為，由于將應用程序托管在云服務提供商(CSP)處，該CSP就提供所有安全措施，但事實并非如此。實際上，云服務提供商和組織分擔安全方面的責任。

簡單來說，CSP保護應用程序在上面運行的基礎設施，組織負責保護應用程序內的活動和數據。CSP確保它們運行的計算、存儲和數據庫服務是安全的。由于CSP采用多租戶模式，其中許多應用程序共享相同的服務器，因此它們還提供公司之間的硬隔離。

云提供商無法在組織的應用程序內實施安全措施。這是由于每家組織以獨特的方式構建應用程序、使用存儲空間和配置系統——這意味著CSP不可能對應用程序內的安全采取一刀切的解決方案。雖然一些提供商提供開箱即用的安全功能，比如AWS Control Tower，但組織須支付額外費用，仍要做大量的定制工作。

使用云的所有組織為其應用程序及各部分(包括操作系統、源代碼和數據)的安全負責。組織可以采取的最強有力的安全措施之一是，通過授權實施訪問控制。授權確保用戶及其他技術只能在需要時訪問所需的系統和數據。下面探討如何實施授權。

誤區二：你可以在云原生環境中使用同樣的本地安全措施

組織犯的另一個常見錯誤是，試圖將來自本地環境的安全措施原封不動地搬到云端。基于邊界的安全措施(比如防火墻和瀏覽器隔離系統)在云端不起作用，因為網絡不再是可以通過周圍設置屏障來保護的靜態環境。

相反，如果黑客闖入網絡，你必須專注于保護數據安全。同樣，這時候訪問控制和授權有了用武之地。然而，與基于邊界的安全一樣，傳統的本地訪問控制措施不適用于云。

由于微服務架構、容器化應用程序和應用編程接口(API)，需要自己的授權策略和安全配置的單個組件急劇增多。單點登錄、SAML、OIDC和OAuth2等傳統技術可以幫助你解決應用程序的身份驗證，但無法幫助解決授權，這仍然取決于你的開發人員。

你應該在云原生環境中使用策略即代碼。策略即代碼意味著，你將標準的軟件工程實踐運用于管理系統的規則和條件(版本控制、代碼審查、自動化測試和持續交付等)。有了策略即代碼，策略與應用云平臺分離開來，這意味著可以在不更改應用代碼的情況下更改策略。策略即代碼的去耦性使團隊更容易編寫、擴展、監測、審計和協作策略。

誤區三：策略執行需要定制的解決方案

最后一個誤區來源于現實，因為創建定制的單個策略一度是控制訪問的唯一方法，但現在不再是這樣了。現有技術使組織能夠跨諸多云原生應用程序、服務和平臺，運用統一授權策略。

可以理解為什么組織仍會有這種信念。軟件開發通常依賴創建一次性定制解決方案，以解決某個問題，因為每家組織配置系統和基礎架構的方式不一樣。多年來，授權策略也是如此。但在云原生環境下，由于獨立的組件數量更多，以這種方式對待策略執行更耗時、更乏味、更容易出錯。

與其為每組新的策略需求實施定制解決方案，不如考慮通過策略即代碼將策略決策與業務邏輯的其余部分分離開來，并依賴額外技術幫助你跨云原生堆棧，高效地運用和擴展統一授權。

Open Policy Agent(OPA)是一個開源策略引擎，讓你可以編寫和驗證策略即代碼。Styra在2018年將它捐給了云原生計算基金會，2021年它達到了畢業狀態。由于組織可以在整個云原生技術堆棧中使用同樣的語言和策略框架，OPA簡化了策略創建和日常治理。策略是用Rego編寫的，Rego是專門針對復雜的層次數據結構表達策略而構建的。又由于它是開源的，所以有豐富的生態系統，組織可以從中獲取對開發者友好的工具和集成，還有提供建議的從業者社區。

原文標題：??Debunking the Top 3 Cloud Native Security Myths??，作者：Torin Sandall