目錄領域1：云計算概念和架構 22學習目標 23定義云計算 23抽象與編排 24云計算模型 24云服務模型 25云服務模型 26云部署模型 27參考和架構模型 27基礎設施即服務 28平臺即服務 29軟件即服務 30一切皆服務 31重疊的服務模型 32CSA企業架構模型 32云安全范圍、責任和模型 33責任共擔模型 34云安全框架和模式 36簡單的云安全流程模型 37總結 38領域2：云治理 41學習目標 42云治理 42云采用與治理 43云治理的復雜性 43有效的云治理 47云治理實施模型 48安全冠軍 49治理層級 50基本治理原則與指南 52云注冊表 54云安全框架 562.3.4策略 58云安全控制目標 59責任共擔模型 61關鍵戰略和概念 62DevOps 62零信任安全策略 63人工智能與機器學習 64總結 66領域3：風險、審計與合規 68學習目標 68云風險管理 68云?險 69建立云風險概況 70了解云風險管理 72評估云服務 75云注冊表 78合規與審計 80合規性類型和云影響 81云相關法律法規示例 82合規繼承 84司法管轄區 86云保障機制 87合規?件 88治理、風險與合規：工具與技術 89支持治理、保證和合規的非技術工具 90?持治理、保證和合規的技術 91總結 92領域4：組織管理 95學習目標 95組織層級模型 964.1.1定義 96組織安全目標 97云服務提供商內的組織能力 98在提供商內部構建層級模型 99管理組織級安全 100身份提供者和用戶/組/角色映射 101云服務提供商（組織）策略 101通?組織共享服務 104集成云安全和管理平臺 105混合云和多云部署的注意事項 107混合云安全的組織管理 108多云安全的組織管理 109IaaS/PaaS多云的組織管理 109SaaS混合云和多云的組織管理 111混合云和多云的零信任安全策略 112總結 113領域5：身份與訪問管理 116學習目標 116云中的IAM有何不同 117基本術語 1185.3聯合 120常見聯合標準 120聯合身份管理的工作原理 121管理云計算的用戶和身份 123強身份驗證和授權 125身份驗證和憑證 126權利和訪問管理 127條件訪問、令牌、會話和IAM邊界管理 129特權用戶管理 131公有云的IAM策略類型 132最小權限與自動化 133身份與零信任 134客戶身份 134總結 135領域6：安全監控 138學習目標 1386.1云監控 138日志和事件 139告警和監控 140日志和警報的及時性 140監測關鍵指標 141云遙測源 141管理平面日志 141服務和應用程序日志 142資源日志 142云原生工具 142云原?CSP安全?具和容器監控 143云遙測限制 145采集架構 146日志存儲與保留 146級聯日志架構 147云安全監控策略指導 148安全數據湖 150檢測與安全分析 150?較不同的檢測?具 151安全監控與分析實踐 152云檢測與響應 153高級監控：金絲雀和蜜罐 155生成式AI安全監控 156生成式AI與慮 156總結 157領域7：云基礎設施與網絡安全 159學習?標 159云基礎設施安全 160安全架構：良好架構的支柱 160基礎設施安全技術 162CSP基礎設施安全責任 163基礎設施即代碼 164云遷移架構和安全影響 166云?絡基礎知識 167SDN的安全優勢 168最?可行?絡 168基于SDN的常?組件 170云?絡安全組 172超越安全組 173容器?絡 1747.3云連接 176連接資源 176連接虛擬?絡（在CSP內） 178連接到數據中?和提供商之間 180零信任和安全訪問服務邊緣 182云基礎設施和?絡的零信任 182軟件定義邊界和零信任?絡訪問 186安全訪問服務邊緣 189總結 190領域8：云工作負載安全 193學習目標 193云工作負載安全簡介 193云工作負載的類型 194云工作負載：短期和?期運? 195對傳統工作負載安全控制的影響 196軟件成分分析 197軟件物料清單 1988.2虛擬機 199虛擬機挑戰與緩解措施 199使用工廠創建安全的虛擬機鏡像 201使?部署流水線創建安全鏡像 203快照和公開曝光/泄露 205容器安全 206容器鏡像創建 206容器?絡 206容器編排與管理系統 206容器編排安全 208管理容器漏洞 210容器的運?時保護 211PaaS安全 212PaaS的通?安全實踐 212加密和訪問控制 213保護特定PaaS 213保護無服務器或函數即服務 214FaaS安全問題 215?服務器的IAM 217?絡連接和訪問模式 217環境變量和機密信息 218人工智能工作負載 218人工智能系統威脅 219人工智能緩解策略 220總結 221建議 221補充指南 224領域9：數據安全 225學習目標 225數據分類與存儲類型 226數據分類 226數據狀態 227云存儲類型 227保護特定云工作負載類型 229數據安全工具與技術 230訪問控制與策略 231云數據加密 232密鑰管理服務和自帶密鑰 236數據加密建議 237云數據泄露防護 238數據安全態勢管理 239保護特定存儲類型 239對象存儲安全 239云數據庫安全 240數據湖安全 242人工智能的數據安全 243總結 245領域10：應用安全 247學習目標 248安全開發生命周期 248CSA安全開發生命周期 248安全設計與架構之威脅建模 249安全開發 250測試：部署前 251測試：部署后 252安全云應用架構 253云計算對架構安全的影響 253架構的彈性設計 254基礎設施即代碼和應用程序安全 255安全的最佳實踐 256身份和訪問管理對應用程序安全的貢獻 257設置應?程序組件的權限 257密鑰管理 258DevOps與DevSecOps 260DevSecOps 261CSADevSecOps的六大支柱 261DevSecOps實踐 263無服務器和容器化應用程序注意事項 266無服務器和容器對應用程序安全的影響 266總結 267領域11：事件響應與韌性（恢復力） 271學習目標 271事件響應與韌性（恢復力） 272事件響應生命周期 272準備階段 274事件響應準備和云服務提供商 275云事件響應?員培訓 276支持云事件響應流程的更新 276支持云事件響應的技術更新 278檢測與分析 280檢測與威脅檢測器 281云對事件響應分析的影響 282分析優先級：RECIPEPICKS 284云系統取證 284遏制、根除與恢復 28611.4.1遏制 28611.4.2根除 28711.4.3恢復 288事后分析 28811.6韌性（恢復力） 289IaaS/PaaS韌性工具 290SaaS韌性 291總結 292領域12：相關技術與策略 295學習目標 29512.1零信任 295零信任的技術目標 296零信任業務目標 299零信任支柱與成熟度評估模型 300零信任設計和實施步驟 305零信任與云安全 306人工智能 308AI與云安全 308AI賦能安全 310威脅與漏洞管理 312云威脅管理更新 313云威脅情報來源 316總結 317領域領域1：云計算概念和架構該領域為云安全聯盟(CSA)安全指南的其它章節內容提供了概念性的框架。它描述和定義了云計算，列出了基本術語，并詳細說明該?檔其余部分所使用的整體控制、部署和架構模型。云計算可以從多個視角來審視，其可以是?項技術、?組技術的組合、?種運營模式（或模型）、商業模式（或模型），或者是?它已經成為主導的數字化轉型模型。盡管云安全聯盟早期版本中的參考模型仍然相關，但它們需要更新以反映持續的進步（例如，來自云服務提供商（CSP）的新工具和技術、零信任、人工智能以及不斷發展的實踐），隨著行業的成熟。這些更新雖然必要，但仍無法完全涵蓋未來幾年自動化和人工智能能力的快速發展。客戶（CSC）CSP（即“重新托管”或“提升和遷移”）好處與正確理解云計算模型、云原生能力和服務的適當使用緊密相關。本領域旨在建立其余指南和建議的基礎。其目的是提供云計算的共同語言和理解，同時突出云計算與傳統計算之間的差異。除了已經提到的云計算好處外，本領域還將幫助云安全專業人員及其他相關利益相關者采納確保更好安全態勢的云計算方法。云安全聯盟并不打算創建一個全新的分類法或參考模型。我們的目標是提煉并協調現有的模型——特別是《NISTSP800-1452》、《ISO/IEC22123-1:20233》和《ISO/IEC22123-2:20234》的工作——關注云計算領域專業人員最相關的安全考慮。為了進一步增強對基本原則的理解，并探討實施云安全實踐的具體主題和實際策略，本指南提供了附加參考資料。學習目標在此領域，您將學習：云計算的定義識別云計算模型識別云計算中的參考架構和架構模型了解云安全的范圍、責任劃分和模型定義云計算云計算是一種運營模型和一組技術，用于通過對計算、網絡、存儲等資源的抽象來管理共享并且能夠退役，從而提供類似公用事業的按需分配和消費模型。其好處包括利益相關者的協作、敏捷性、彈性、可用性、復原力和成本減少。以下是來自美國國家標準與技術研究院(NIST)和國際標準化組織(ISO)和國際電?委員會(IEC)關于云計算的定義：NISTSP800-145將云計算定義為一種模型，用于實現對可配置共享計算資源(例如，網絡、服務NISTSP800-145將云計算定義為一種模型，用于實現對可配置共享計算資源(例如，網絡、服務器、存儲、應用和服務)池無處不在的、便捷的、按需的網絡訪問，可以通過最少的管理工作或服務提供商交互來快速供應和釋放資源。ISO/IEC22123-1:2023將云計算定義為一種范式，它能夠實現通過網絡訪問可擴展且具彈性的可共享的物理或虛擬資源池，并可按需進行自助式資源調配和管理。簡而言之，云計算將一組資源（如處理器和內存）放入一個大型資源池（術實現）。云客戶（CSC）根據需求（例如：8CPU16GB內存）從資源池中請求所需的資CSCCSC使用完資源后，可以將其釋放回資源池供他人使用。云可以由幾乎任何計算資源組成，從處理器、內存和網絡等原始基礎設施資源，到更高級的500名員工訂閱一個客戶關系管理（CRM）使用一個由成百上千組織共享的服務，這和在計算云上啟動100臺遠程服務器一樣，都是云計算的一部分。抽象與編排排（及自動化）CSCCSC定義“云的所有基本特征。CSC共享同一個資源池，但它們通常在邏輯上，甚至在物理上，CSPCSCCSC數據的機密性和完整性至關重要。此外，CSP能夠衡量和約束資源的過度使用，CSC提供服務的可用性至關重要。多租戶不僅限于跨組織使用，還可以促進在單個組織內不同單位之間的資源分配，這通常被稱為“私有云。云計算模型云安全聯盟采用NISTSP800-145模型作為云計算的標準定義。CSA還支持更詳細的ISO/IEC22123-1:2023和22123-2:2023模型，它們也作為參考模型。在本領域中，我們將同時引用這兩種模型。NIST根據五個基本特征、三個云服務模型和四個云部署模型來描述云計算，下面的章節將對這些內容進行總結。圖1：基于NIST和ISO/IEC標準的云計算模型概述云服務模型NIST模型通過五個基本特征來描述云，這些特征將云計算與傳統托管服務或其它類型的云服務（如托管和虛擬化）區分開來。了解這些特征對于充分利用云計算的潛?和制定云所采?的戰略規劃?關重要。以下是NIST描述的五個基本特征。資源池化：云計算通過多租戶模型將各種物理和虛擬資源進行池化，用于服務多個CSC（云客戶）。這些資源，例如存儲、處理器、內存和網絡帶寬，會根據需求動態分配和重新分配。廣泛的網絡訪問：Web從而支持多種異構客戶端平臺（例如服務器、移動電話、筆記本電腦、物聯網設備和平板電腦等）。快速彈性：資源可以快速、彈性地進行配置，在某些情況下，甚至可以自動完成，以便CSC來說，提供的能力通常看起來是無限的，并且可以在任何時候以任意數量購買。計量服務：云系統通過某種適當的抽象層次自動控制和優化資源使用（活躍用戶帳戶等）CSPCSC，能夠根據使用量進行計費，促進了成本效益和責任感（例如按需付費模式）。按需自助服務：CSCCSP（云服務提供商）自動進行配CSC可自動獲得所需計算的運行時間和?絡存儲量，?無需與每個CSP進?人工交互。ISO/IEC22123:2023列出了六個關鍵特性，前五個與上?NIST特性相同。唯?的新增特性是多租戶，它與資源池化不同。云服務模型NIST定義了三種服務模型，分別描述了云服務的不同基礎類別：軟件即服務(SaaS)：CSP管理和托管的應?程序。CSC使?Web瀏覽器、移動應?程序、應?程序編程接(API)或輕量級客戶端應?程序訪問它。在此模型中，CSC只關?應?程序的配置，?不關?底層資源。平臺即服務(PaaS)：抽象并提供平臺，例如應?程序平臺（即可執行開發和運?代碼的地?）、數據庫、?件存儲和協作環境。其它示例包括?于機器學習、?SaaS功API訪問的應?SaaS不同，PaaSCSC管理底層平臺，但不需要管理虛擬基礎設施。(IaaS)：提供對基礎計算資源池的訪問，例如網絡或存儲。在IaaS中，CSC負責管理底層虛擬基礎設施，如虛擬機、網絡、存儲和運行的應用程序。ISO/IEC22123-3:2023SaaS、PaaSIaaS（SPI）服務模型層（應用、平臺和基礎設施能力類型）緊密關聯。它進一步擴展到云服務類別，如通信即服務（CaaS）、網絡即服務（NaaS）、數據存儲即服務（DSaaS）和數據恢復即服務等。SPI層，而其他云服務則無法嚴格劃分為單ISO/IEC這是一個描述工具，而不是嚴格的框架。兩種方法都是有效的，但由于NIST模型更加簡潔且廣泛使用，它是CSA研究中主要采用的定義。云部署模型NIST和ISO/IEC使用相同的四種云部署模型；這些模型描述了技術的部署、消費和應用方式，涵蓋了所有服務模型。公有云：云基礎設施向公眾或?型?CSP私有云：云基礎設施僅供單個組織運營。它可能由組織或第三?管理，并可以位于本地或托管在外。社區云：（全要求、政策、合規要求）CSC（CSC）或第三方管理，且可以位于本地或托混合云：云基礎設施由兩個或多個云（即私有云、社區云或公有云）組成，這些云保持獨立的實體，但通過標準化或專有技術綁定在?起，從?實現數據和應?程序的可移植性（云突發以在云之間進行負載均衡）。其它部署模型：多云：在多云環境中，CSC使?來?CSP的多種云服務（例如應?程序和系統）。通常采?這種?法來減少對單?云提供商的依賴，并在架構設計中構建技術彈性。混合多云：公有云和私有資源的組合，通常連接到傳統數據中?。參考和架構模型有廣泛的技術和方法正在發展，用于構建和操作云服務，這些技術和方法可能使任何單一的參考或架構模型過時。本節的目標是提供?些基礎知識，并為理解復雜和新興的模型提供基線，以幫助安全專業?員做出明智的決策。我們推薦ISO/IEC22123和NIST500-292作為深?的參考架構模型，作為NIST云計算定義的合理補充。此外，我們建議探索CSA企業架構模型，它旨在整合來自四個獨立組織架構的特性。看待云計算的?種?式是將其視為?個堆棧，其中SaaS構建在PaaS之上，?PaaS?構建在IaaS之上。這并不代表所有（甚至大多數）真實世界的部署模型，但它可以作為有?的參考基線。SPI堆棧正在不斷發展，隨著服務提供的不斷成熟，我們看到服務模型之間出現重疊，并且彼此的區別也越來越不明顯。因此，?先讓我們了解?下每個云服務模型的標準架構（即SPI堆棧中的層），然后通過?些?例來展?這些界限是如何模糊的。最后，我們以CSA企業架構模型作為結束，該模型可以幫助任何正在開發跨平臺能力和模式或對集成多云?法感興趣的?。基礎設施即服務物理設施和基礎設施硬件構成了IaaS的基礎。借助云計算，我們可以抽象和把資源池化，但在最基本的層?上，我們始終需要物理硬件、?絡和存儲來構建。這些資源通過抽象和編排匯集在?起。抽象（通常通過虛擬化）將資源從物理限制中解放出來，以實現匯集。然后，?組核?連接和交付?具（編排）將這些抽象的資源綁定在?起，創建資源池，并以?動化的方式將它們分配和交付給CSC。編排通常使?API來實現。API通常是云中組件的底層通信?法，其中?些組件會暴露給CSC來管理資源和配置。如今，?多數云API都使?表述性狀態轉移(REST)API的方式實現資源調用，它通過HTTP運?，?常適合互聯?服務。在大多數情況下，這些API都是遠程可訪問的，并且包裝在基于Web的用戶界面中。這種組合是云管理或控制平面，因為CSC使用它來管理和配置云資源，例如啟動虛擬機實例或配置虛擬軟件定義網絡。從安全角度來看，這與保護本地基礎設施的最大不同在于，管理接口現在是通過網絡提供的。如果攻擊者妥協了管理平面，他們將獲得對云基礎設施的特權訪問。以下是一個極簡化的IaaS計算平臺架構示例。圖2：IaaS計算平臺的簡化架構該示例展示了一個IaaS計算平臺，具有運行虛擬化管理程序（Hypervisor）和編排軟件的物理服務器。云控制器分配資源，創建虛擬實例，配置網絡和存儲，并為CSC提供訪問實例的連接信息。平臺即服務在所有的服務模型中，PaaS是最難明確描述的，因為PaaS的產品種類繁多，?法各異。PaaS服務通常集成應?程序開發框架、中間件能力以及數據庫、消息隊列和事件?志等?持服務。這些服務允許開發人員使用該平臺所支持的編程語言和工具構建應用程序。在現實中經常見到的一種選擇是構建在IaaS之上的平臺。例如，集成、持久性和中間件層構建在IaaS平臺上，然后將其池化、編排，并通過API作為PaaS服務提供給CSC。這可以是使?修改后的數據庫管理系統軟件實例來構建和部署的數據庫即服務(DBaaS)。CSCAPI和/Web控制臺管理數據庫，并通過常規數據庫?絡協議和/或API訪問數據庫。在PaaS中，云用戶只能看到平臺（或利?平臺的應?程序表?層），?看不到底層的基礎設施。在我們的示例中，數據庫服務會根據實際需要按需擴展或收縮，?CSC?需管理單個服務器、?絡、補丁等。以下是展示PaaS在IaaS架構上運行的簡化架構。圖3：在IaaS上構建的PaaS的簡化架構PaaS不一定需要建立在IaaS之上；它也可以是定制的獨立架構。其定義特征是CSC訪問和管理平臺，而不是底層云基礎設施。一個可能的例子是一個定制的AI和機器學習集成服務，支持諸如AI驅動的開發工具、機器學習運維（MLOps）和AI生命周期管理等用例。軟件即服務SaaS服務是完整的應?程序，涵蓋了典型的?型軟件平臺的所有架構的復雜性。許多SaaSCSP基于IaaS和PaaS構建，原因在于更高的敏捷性、韌性和經濟效益。?SaaS應?IaaSPaaSCSP。許多應?程序還提API。它們通常需要?CSCWeb瀏覽器、API和移動應?程序。SaaS服務往往具有應?程序/邏輯層和數據存儲、API和表?層服務，通常?持Web瀏覽器和移動應?程序用戶接口以及Internet（）API以下是來自實際SaaS平臺的簡化架構，但已去除對具體產品的引用。

圖4：基于PaaS和IaaS構建的SaaS平臺的簡化架構?切即服務(XaaS)是?個?泛的術語，涵蓋了通過互聯?提供的各種服務的本質，?IDC數據中心的提供。此模型是云計算的基礎，其中“X”可以表??乎任何以服務的形式提供給用戶的服務、應?程序或平臺組件，例如安全即服務（SecurityasaService）、數據庫即服務（DBaaS）、目錄即服務（DirectoryasaService）、身份即服務（IdentityasaService）、AI即服務（AIasaService）。這些幾乎總是符合IaaS/PaaS/SaaS模型，但在命名上更具描述性和特定性。重疊的服務模型雖然SPI云服務模型通常以層次結構表?，每一層都建?在其下?層（IaaS、PaaS、SaaS）之上，但這些服務的實施和實際使??式可以更加靈活。SPI堆棧是理解不同云服務模型的有?指南。認識到固有的靈活性和重疊層?常重要。SPI實施不需要建?在嚴格的層次結構上，模型之間的界限通常很模糊，這被稱為重疊服務模型。重疊服務模型不是由嚴格的層次結構定義的，通常同時封裝了多種服務模型的特征。SaaS（Web瀏覽器提供的完整應用程序）PaaS（用于集API）的特征。CSA企業架構模型CSA企業架構（EA）既是一種方法論，也是一個工具集。它是一個框架，即一種全面的方法，用于構建安全的云基礎設施架構。可以用來評估改進機會、創建技術采用路線圖、識別可重用的安全模式，并根據一組共同的能力評估不同的云服務提供商（CSP）和安全技術供應商。為了創建CSA企業架構，CSA研究團隊參考了以下四個領域的四個?業標準架構模型：業務運營支持服務（BOSS）Sherwood應用商業安全架構（SABSA）IT運營服務（ITOS）IT基礎設施庫（ITIL）技術解決方案服務（TSS），包括基礎設施（InfraSrv）、信息（InfoSrv）、應用（AS）和展示（PS）開放組應用框架（TOGAF）安全與?險管理(SRM（Jericho論壇）圖5：CSA企業架構的構建模塊CSA將最好的架構范式結合成一種全面的方法，用于云安全，并結合了業務驅動因素。CSA企業架構支持云服務在企業商業模型中的價值主張。CSA企業架構被NISTSP500-292采納，進一步鞏固了CSA方法的重要性。云安全范圍、責任和模型云安全和合規性包括安全團隊在傳統IT環境中已經負責的所有任務，只不過這些任務轉移到了云端。識別安全需求、選擇適當的云服務，并實施控制措施以有效緩解云計算中的風險，是一個迭代的過程，由“共享責任”原則進行劃定。我們將基于這一原則描述模型。我們將概述安全責任的劃分，其中CSP負責基礎設施安全，而CSC負責他們部署的應用和數據。責任的劃分會在不同的服務模型（IaaS、PaaS、SaaS）和CSP之間有所不同，這突顯了CSC理解其職責劃分的重要性。此外，我們還探討了框架和工具的作用，如CSA共識評估倡議問卷（CAIQ）和CSA云控制矩陣（CCM），它們有助于促進合規性并與安全標準對齊。所有傳統的安全領域依然存在，但風險的性質、角色和責任的分配，以及控制措施的實施，都經常快速變化。盡管安全和合規性的整體范圍沒有改變，但任何特定云角色所負責的部分確實發生了變化。可以這樣理解：云計算是一種共享的技術模型，不同的組織負責實施和管理堆棧的不同部分。因此，安全責任也在堆棧中分布，并因此在參與的組織之間分配。這通常被稱為“安全責任共擔”（SSRM），有時簡稱為SRM。可以把它看作是一個責任矩陣，具體取決于特定的云提供商以及特性/產品、服務和部署模型。責任共擔模型CSPCSC共同努??CSP?泛使?，CSP負責安全運營和控制的界限。界限以下是CSPCSC構建的任何CSC的責任。隨著服務模型的改變，這種情況會有很?SSRM模型概述了CSP負責“云”的安全職責，職責包括基礎設施、硬件和?絡。然?，CSC負責他們在云中部署的內容。不同的服務模型下，責任劃分會有所不同。無論是IaaS、PaaSSaaS，每種服務模型的CSP之間也可能存在差異。因此，CSC必須了解這種責任劃分，CSP從?層次來看，安全責任與每個角色在架構堆棧中控制的程度相關。軟件即服務（SaaS）：CSP負責大部分的安全，因為云用戶只能訪問和管理他們使用的應用，而不能修改應用的工作方式。即使CSC在每個安全領域的責任較小且有限，但通常不會為零。例如，SaaSCSP負責外部安全、日志記錄/監控/CSC仍然負責授權和權限的管理。平臺即服務（PaaS）：CSPCSC負責在平臺上實施的所有內容，包括如何配置任何提供的安全特性。因此，責任劃分更加均衡。例如，使用DBaaS時，CSPCSC負責其他所有部分，包括使用數據庫的哪些安全特性、管理賬戶或身份驗證方法。基礎設施即服務（IaaS）：與PaaS類似，CSP負責基礎安全，而CSC負責他們在基礎設施上構建的所有內容。與PaaS不同的是，這將把更多責任放在CSC身上。例如，IaaSCSPCSC完全負責如何根據服務中提供的工具定義和實施他們的虛擬網絡安全。隨著堆棧的逐步向下，CSPCSC的責任增加。IaaS因此客戶需要負責操作系統和應用程序的安全。PaaS處于中間位置，可能在平臺內提供某些安CSCAPI調用并維持安全配置。SaaSCSP負責整個堆棧，因此他們有責任保護服務中的所有信息。正如你所想象的那樣，數據安全對于SaaSCSP至關重要，因為一旦發生泄露或故障，可能會引發“銀行擠兌”務。當使用云代理商或其他中介和合作伙伴時，這些角色會變得更加復雜。理解CSP的責任結束的地方和CSC的責任開始的地方是至關重要的。云計算不僅僅是利用云服務，更是要通過認識到CSC在合作中的角色，確保以安全的方式利用云資源。CSC必須定期審查和理解他們的責任，尤其是在配置和管理方面，以確保安全策略/措施與組織中所使用數據和資源的敏感性對齊。下圖說明了SSRM，突出顯?了不同服務模型中的CSP和CSC之間的職責劃分。該模型強調了每個參與者對架構堆棧的不同程度的控制和責任：圖6：安全責任共擔有效云安全的關鍵是了解任何云項?中的責任劃分。?論CSP提供何種具體的安全控制，準確了解誰負責什么?關重要。這種理解使組織能夠通過其度量填補控制空?或考慮替換CSP。對于IaaS，用戶直接控制安全性的能??常?，?對于SaaS，則較低。為了確保云中安全責任的明確分配，我們建議采取以下措施：CSPCSC特性，以便客戶做出知情決策。CSP還應設計和實施這些控制措施。CSC應建立一個角色與責任矩陣，明確他們在安全方面的責任。該矩陣應記錄誰負責實施特定的安全控制，并確保與相關的合規標準對接。CSA提供了幫助滿足這些要求的工具：CAIQCSP記錄其安全和合規控制。CCM列出了云安全控制并將其映射到多個安全和合規標準。CCM也可以用于記錄安全責任。這兩份文件需要根據具體的組織和項目需求進行調整，但它們為確保合規性要求提供了全面的起點模板，并且對確保合規性要求至關重要。關于SSRM的更多資源和指南包括：CSA企業架構：CSA企業架構部分。CCM責任共擔模型：這一映射幫助用戶理解云安全責任，展示了不同服務模型（IaaS、PaaS、SaaS）CSPCSC負責的安全控制。CCM實施指南：CSPCSCCCM中的控制所有權和實施指南。云安全框架和模式云安全框架和模式是幫助指導安全決策的?具。“模型”一詞可能有些不清楚，因此我們將其分為以下類型：概念模型：或者框架包括?于解釋云安全概念和原則的可視化和描述，例如本?檔中的NIST模型。控制模型：或者框架對特定的云安全控制項或控制類別進?分類和詳細說明，例如，CSACCM。參考架構：是?于實現云安全的模板，通常是通?的。（IaaS的安全參考架構）。它們可以?常抽象，接近概念，也可以?常詳細，直?特定的控制和功能。設計模式：是針對特定問題的可重復使?的解決?案。在安全領域，IaaS的?志管理就是?個例?。與參考架構?樣，它們或多或少可以是抽象的或具體的，甚?臺上的常?實現模式。這些模型之間的界限經常模糊和重疊，這取決于模型開發?員的?標。即使將它們歸為“模型”?類也可能不準確，但由于我們看到的這些術語在不同來源中交替使?，因此將它們歸為?類是有意義的。CSA推薦以下幾種模型：CSA企業架構（EA）CSA云控制矩陣（CCM）ISO/IECCD27017.22ISO/IEC27017.22是基于ISO/IEC27002的云服務信息安全控制的實踐規范草案，正在開發中，計劃取代ISO/IEC27017:2015。景?確定必要的安全性和合規性需求以及任何現有的控制措施CSP、服務和部署模型定義架構評估安全控制識別控制差距設計和實施控制措施以填補空白評估控制措施的有效性管理隨時間推移的變化每個云項?，即使是在同?個CSP內，也可能需要獨特的配置和技術。因此，根據每個項?的具體要求和特點進?評估?常重要。例如，在?個CSP中部署在純IaaS上的應用程序的安全控制可能與使用來自同?提供商的更多PaaS的類似項目?常不同。關鍵在于識別需求、設計架構，然后根據底層云平臺的功能確定差距。這就是為什么在實施CSP和架構的基本原因。這通常是?了解何時使?原?云服務控制以及何時在外部實施控制以彌補差距是?會對整體安全架構產生重大影響。總結CSA11個領域，重點介紹了云計算關注的領域，并針對云環境中的戰略和戰術安全“痛點”進?了調整，并可應?為兩?類：治理和運營。治理領域范圍?泛，涉及云計算環境中的戰略和策略的問題，?運營領域則側重于架構中更具戰術性的安全問題和實施等相關方面。1標題描述云計算概念和架構了解面向云安全專業?員的云計算概念和架構。主題包括云模型、安全框架、云原?能力、抽象、編排和多租戶，強調敏捷性、彈性和安全性。云治理學習以安全性為重點的云治理，涵蓋DevOps、DevSecOps、零信任和AI/ML等戰略。了解框架、風險管理、合規性，并建?有效的治理結構，如云卓越中?（CCoE）和云注冊表。?險、審計和合規涵蓋云環境中的?險管理、審計流程和合規性。了解云?險評估、合規性要求、法律和審計流程。主題包括合規性繼承和利?CSP的合規性來滿?監管標準。組織管理涵蓋使?CSP來管理和保護云環境，重點關注組織層次結構、IAM/多云安全性和零信任戰略。學習實施有凝聚的安全控制，并管理不同的云基礎架構。?份和訪問管理涵蓋云環境中的?份和訪問管理(IAM)IAM模型、零信任戰略和?動化，以增強云安全性和合規性。云安全監控??級監控?具。主題包括SSRM、?志存儲、?絲雀、蜜罐令牌以及生成式AI在增強云安全??的作?。云基礎設施和網絡涵蓋管理和保護云基礎設施，包括安全架構設計、軟件定義網絡（SDN）、基礎設施即代碼（IaC）和安全云連接。它強調零信任、安全接入服務邊緣（SASE）保護云資產。云工作負載安全涵蓋保護云中的?作負載，包括虛擬機、容器、無服務器函數、PaaS和AI時保護和IAM云數據安全全，以及AI云應用安全學習云應用安全，專注于保護應用免受外部威脅。了解關于軟件開發生命周期（SDLC）、威脅建模、安全編碼和測試。主題包括基礎設施即代碼（IaC）、DevOps、第三方庫和新興的云安全技術。事件響應與韌性（恢復力）涵蓋云環境中的事件響應和業務恢復能?，這對組織的安全?關重要。了解基于CSA和NIST指南的CIR題包括準備、檢測、遏制、（系統）恢復和（業務）恢復戰略。相關技術與戰略涵蓋云安全戰略，重點關注零信任、AI集成以及威脅和漏洞的管理。學習通過多因子?份驗證、加密、AI威脅檢測和持續監控來保護云應?、系統和數據。建議了解云計算之間的差異以及抽象和編排如何影響安全性。NISTCSASSRMCSCCSP使?CSA的CAIQ等?具和?檔來評估和?較云提供商。云提供商應記錄其安全控制和特性，并使?CSACAIQ等?具發布它們。使?CSACCM等?具來評估和記錄云項?的安全性和合規性要求和控制，以及每個要求和控制的負責?。使?云安全流程模型來選擇提供商、設計架構、識別控制差距并實施安全和合規控制。其它指導CCSK具包|CSA云安全聯盟詞匯表|CSACSA云控制矩陣(CCM)|CSACCM-Lite和CAIQ-Lite|CSACCMv4實施指南|CSACSA企業架構參考指南|CSA企業架構到CCM責任共擔模型|CSA2：云治理在促進透明度和對既定標準的問責制。有效的治理實踐涉及戰略指導、?規性監控和補救、預算分配和成本控制。IT治理確保信息和相關技術能夠?持企業戰略和?標的實現。信息系統審計師協會將治理定義為：信息系統審計師協會將治理定義為：“治理確保利益相關者的需求、條件和選擇得到評估，以確定需要實現的平衡且一致的企業目標；它通過確定優先級和決策來設定方向，并監測績效和合規性，確保與既定方向和目標的一致性。”組織可以通過遵循?業特定的治理標準和框架來加強治理實踐。例如，ISO/IEC38500:2024IT治理??的指導。ISACACOBITIT治理和管理提供了全?的實施指南。關于治理標準的更多信息：ISO/IEC38500:2024IT治理ISACACOBIT企業IT治理和管理的業務框架ISO/IEC27014:2020信息技術安全技術信息安全治理開放群組云治理框架以下是影響IT治理的部分法律法規?例：格雷姆-?奇-?利雷法案(GLBA)薩班斯-奧克斯利法案(SOX)健康保險流通與責任法案（HIPAA）通?數據保護條例（GDPR）學習目標此領域，您將學習到以下內容：確定云治理的目的。定義云治理中的治理層級體系。探索影響云計算治理的關鍵戰略和概念。云治理云計算的多租戶特性、責任共擔模型、敏感數據的重新分配、關鍵應?程序和基礎設施的托管，以及安全和隱私問題，迫切需要有效的治理機制。因為存在各種法規、管轄權、安全和隱私的要求，合規性是業務上云時一個主要的問題。如果沒有完善的治理政策，安全問題、財務和?險可能會導致云運營成本急劇增加，并使業務上云成為企業的不明智選擇。成本效益和快速上線是上云的主要驅動因素之?。許多組織認為云計算是?種通過從資本性?出模式轉向運營性?出模式（例如，按需付費和基于訂閱模式）來實現成本節約的?常?的遷移策略是將傳統現有的應?程序和基礎設施不做任何改變直接遷移到云上。如果這樣保持現有體系結構不變直接遷移上云，安全和隱私的治理就成為首要問題，因為轉向新技術平臺可能會帶來新的技術?險。此外，云客戶（CSC）還需要與云服務提供商（CSP）責任共擔。戰略創新是上云的另?重要驅動因素。許多組織將軟件視為可以提供競爭優勢的戰略資產。云計算提供了快速開發和部署軟件的能?，使組織能夠快速將新產品和服務推向市場。然?，從治理的?擁有強?的安全設計流程?關重要，以確保云中的軟件開發、測試和部署是安全可靠的。本次討論的要點包括：上云的驅動因素包括節約成本、運營性支持模型、實現組織?標及戰略創新的需求。上云需要考慮的治理因素不僅包括將信息?險（數據、應?程序、主機操作系統、?供應鏈）和物理?險控制在可接受的?平（稱為?險偏好）。還需要評估IT?標是否與業務?標相?致，以及確保遵守法律和法規的要求，包括隱私義務。組織應該根據具體的業務?策略。云采用與治理云計算影響安全治理的主要方式有兩種：1、引?(SRM)CSPCSC共同承擔。更復雜的問題是，在某些情況下第三?服務提供商被引?到供應鏈中，每個服務提供商都存在??的安全?險。即使部分責任被轉移給這樣的第三?，但最終責任仍然由CSP或CSC承擔。2、由云計算固有特性造成的技術和運營差異。在云計算出現之前，IT安全治理在很?程度上依賴于數據中?內運?的固有特性。數據中?的資源是有限的，包括空間、計算、?絡等都是有限。?且這些資源都處于相對隔離的物理環境中。組織結構、策略和控制措施都圍繞這些資源的稀缺性進?調整。公有云則完全相反。雖然云提供商的容量也不是?限的，但有充足的容量來滿足云客戶的需求。云是分散的，不同的團隊可以使?登錄名和信?卡配置整個資源棧，如果沒有有效的治理，這些資源就不會受到集中的管控。云也從根本上改變了我們管理這些資源的?式。雖然資源可以被分散，但在公有云中，核?管理平面是統?的，并向互聯?開放。由于沒有物理?絡邊界，任何擁有正確憑據的?都可以訪問管理平?并重構整個虛擬基礎設施。這種分布式架構與泛網絡管理平?相結合的方式，需要新的、針對云的治理策略。總之，云計算通過分布式基礎設施管理、提供統?的接口實現資源訪問的方式，徹底改變了IT治理。組織必須在接受這些變化同時確保安全性和控制?，發揮云計算的優勢。云治理的復雜性隨著組織越來越多地采?云服務，它們在新的商業模式、技術和管理方面都?臨著獨特的治理挑戰。這些挑戰要求組織更新其治理框架以適應云環境。PaaS、SaaS和IaaS共同的考慮因素包括控制和問責、合法性以及云服務提供商（CSP）和云客戶(CSC)之間的關系。本節列出了這些考慮因素，強調了為了有效管理云環境所需要調整的治理策略。以下考慮因素概述了組織在管理云環境時必須解決的關鍵治理挑戰和必要的調整：控制和問責IT基礎設施的直接控制，從?迫使組織采?新的治理框架和流程。使?云解決?案不意味著將控制責任外包給第三?或第四?。云使?多種不同的責任共擔模型（SRM），具體取決于云服務提供商（CSP）云客戶（CSC）?不是實際測試。法律和合規性云服務和數據可能跨越多個司法管轄區，迫使客戶遵守更多的法律法規，尤其是有關隱私??的。數據所有權和分類以及隱私控制可能不是直觀清晰的，需要仔細檢查。可?性和透明度對于某些云服務，可?性和透明度可能具有挑戰性。定制和標準化云服務提供商可能僅僅提供標準產品，?法根據云客戶的具體需求進?定制。云服務提供商可能表現出不同的能力成熟度級別、不同的服務、許可證和模型，想要找到?種適用于所有的云策略是非常困難的。治理復雜性云服務通常是建?在云服務提供商之上，這使得治理活動的范圍具有挑戰性（IaaSSaaS服務）。由于難以明確云服務提供商（CSP）和云客戶（CSC）的責任界限，混合云模型可能會使治理變得更加復雜。CSP和CSC的責任動態變化CSPs可能會迅速變化，這必須在治理模型中加以考慮。使?CSC以及?向云的安全?具的知識。下圖概述了不同云服務模型相關的特定復雜性，強調了每種模型獨特治理挑戰和責任。圖7：服務模型特定的復雜性有效的云治理需要靈活?強?的策略，以應對IaaS、PaaS和SaaS模型的獨特挑戰。通過理解和管理這些復雜性，組織可以確保其云環境中的安全性、合規性和運營效率。云治理的復雜性：部署模型更進一步，還必須考慮與不同云部署模型相關的治理復雜性。以下部分將探討不同部署模型的治理挑戰和責任。圖8：部署模型特定的復雜性公有云：公有云是最流?的云部署模型，為所有客戶提供標準服務。公有云提供商通常拒絕定制請求，因為這會使治理變得復雜。公有云提供商自己管理的基礎設施、服務和雇員。治理挑戰來自客戶初始配置，并隨著時間的推移而逐漸增加。試等操作，并降低了對基礎設施的可?性。這些挑戰需要使?供應商?險管理、服務?平協議(SLA)、第三?審計和合規性報告等新的治理方法。這些?法的有效性是通過衡量減輕了多少云計算?險進行評估的。私有云：私有云可以由組織或第三?擁有、管理或托管。?我管理的私有云的治理類似于傳統的IT治理，但也必須解決云特有的問題，如攻擊向量、多租戶和?動化。由第三?管理的私有云治理方式最接近我們已知的傳統外包模式。治理挑戰包括理解責任共擔矩陣、制定SLAs以及構建第三?監控能力以跟蹤策略違規和內部威脅。?個重大的挑戰是讓平臺保持最新服務，需要特別關注。混合云：混合云服務結合了私有云和公有云模型。它們可以通過多種?式實現，從而使策略指南和責任共擔模型（SRM）變得復雜化。治理挑戰包括協調提供商和客戶之間的SLAs和責任、保護內部邊界、擴展安全配置，并解決云安全和成熟度??的技能差距。社區云：社區云是指由第三?管理和托管的?系列服務，由多個組織共享但不完全公開，從?降低了多租戶的挑戰。治理挑戰包括識別利益相關者、構建正確的責任共擔模型（SRM）以及專注于使?相同社區云的組織之間的關系和?險。有效的云治理有效的云治理需要建?一個強?的框架和?組策略，以確保有效、安全和合規地使?云資源。它需要實施強?的控制框架和策略來安全、合規和?效地管理云資源。其中包括：定義角色和職責建?云卓越中心或類似機構進?需求收集基于?險的規劃?險與補救措施管理數據和數字資產分類遵守法律和監管要求維護云注冊表建?治理層級結構利?云特定的安全框架定義云安全策略設定控制?標并指定控制規范通過實施這些組件，組織可以最?限度地發揮云計算的優勢，同時降低潛在風險。下?我們探討有效云治理的?些關鍵組件。云治理實施模型云卓越中?（CCoE）和云咨詢委員會(CAC)模型是實施有效云治理?泛采?的?法。云卓越中?包括?作成員和推廣者。云咨詢委員會提供?層的贊助和認可。更具體地說：云卓越中?（CCoE）是?個集中式團隊或部?，為組織或者其他部?提供上云和使?云的相關指導、最佳實踐和?持。CCoE幫助確保與云客戶的?標和標準的?致性。CAC可以包括來?IT、?險管理、合規性、安全和?般業務職能的?級領導小組，負責制定云客戶戰略和運營的愿景和?向。CAC在此處不深?介紹，但需要了解它的重要性。云卓越中?（CCoE）和CAC是云客戶IT治理和安全的推薦組件。它們作為集中化樞紐，負責領導云計算倡議，并推動戰略性、安全、合規和有效的上云活動。并?所有云客戶都使?相同的術語，但從功能?度來看，這些結構強調了有效云治理所需的關鍵要素。?云卓越中?（CCoE）的主要功能之?是提供戰略指導。它確保云計劃與云客戶的整體業務?標相?致。通過這種方式，CCoE確保上云能夠?持云客戶的目標，并幫助客戶取得成功。CCoE還可以制定使用云的治理框架。這包括創建符合外部法規和內部最佳實踐的策略和標準。CCoE負責管理?險、確保數據隱私和安全，并維護云環境中的合規性。CCoE傳播有關云技術和安全措施的知識。它為其他部?提供培訓機會和資源，促進了整個組織范圍內?致的云技能水平。這確保員?擁有必要的技能和知識，能夠有效且安全地利?務。CCoE的主要關注點。它將安全性嵌?到云基礎設施中，確保云部署在設計時就處于安全狀態。CCoE確保滿?云客戶的安全和隱私要求，并應對不斷變化的威脅態勢。CCoE鼓勵跨職能部門的協作，包括IT、安全、合規性和財務等部?。這種協作?法確保云決策的全面性，包括成本、安全性、合規性和業務需求等方面的綜合考慮。CCoE還促進創新和適應性。?勵探索新的云服務和技術，并在組織內推廣創新?化。同時，CCoE能夠適應技術和業務環境的變化，確保云客戶能夠有效地利?最新云技術。最終，CCoE對于云客戶尋求有效且安全地利?云技術的?常有?。它超越了技術范疇，專注于將上云與業務戰略相結合，同時確保云環境中的治理、安全性和合規性。下圖說明了CCoE中的關鍵角色。圖9：CCoE中的關鍵??安全冠軍除了設?云卓越中?（CCoE）之外，云客戶還可以在合規、企業?險、法律、??資源、財務和IT等業務部?內任命安全冠軍。安全冠軍（安全倡導者）了解云安全的重要性，因此可以充當安全倡導者，幫助推動實施安全最佳實踐和控制措施。安全冠軍（安全倡導者）應該從團隊內部任命，并發揮實際作?。他們通常不是安全組織的成員，?是組織內部團隊的成員。這種區別使他們能夠專注于在特定團隊動態下實施具體的安全措施。組織需要將下列安全角色進行區分：安全冠軍、業務信息安全官(BISO)、?席信息安全官(CISO)、信息安全官(ISO)。例如，在DevOps團隊中，安全冠軍的理想候選?通常是團隊內的開發?員、系統管理員或DevOps平臺?程師。他們對團隊動態和技術能力有充分的理解，使他們能夠有效地倡導安全。他們已經具備了理解云服務和DevOps實踐中特定安全挑戰和解決?案的知識和專業技能。安全冠軍在DevSecOps流程中，整合安全實踐??發揮著?關重要的作?。作為安全團隊和開發團隊之間的聯系?，他們在分配權限方面發揮著關鍵作?。通過在團隊內部倡導安全，安全冠軍在云和DevOps/SRE團隊中推廣安全?化。安全冠軍在開發相關團隊中更為普遍，但也可以在其他業務部?中扮演重要角色。為了培養安全冠軍的技能和興趣，為他們提供有趣且互動的安全培訓?常重要。例如，關于道德?客的研討會是提?他們實際安全技能的有效?法。然?，重要的是不要強迫安全冠軍成為全職的安全專家。他們可以是開發?員或者管理員，只要接受額外的安全培訓，就可以擔任團隊中的聯絡員和專家。賦能安全冠軍的?標是讓他們發揮咨詢的作?，?不是讓他們承擔更多額外職責。避免過度疲勞很重要。通過賦能安全冠軍，云客戶可以有效地彌合安全與開發之間的差距，培養云和DevOps團隊中的安全?化。總之，安全冠軍在推廣云、DevOps團隊和業務團隊內的安全?化方面?關重要。通過賦予他們適當的經驗、培訓和指導，云客戶可以在開發流程中有效地整合安全實踐，最終會改進的安全成果。治理層級云治理的?個關鍵方面是建?治理層級。這涉及定義與云相關問題的決策流程和升級路徑。治理層次確保在云客戶內在適當級別做出決策，并且有明確的責任和義務。云客戶可以利?云特定的安全框架來指導其云治理?作。信息安全中的治理層級是確保組織系統和數據安全的結構化方法。此層級的頂部是框架，它提供了一套?絡安全實踐指南。框架的?NIST(CSF)(CCM)、互聯?安全中?(CIS)和IANS云安全成熟度模型(CSMM)。這些框架是組織建?全態勢的總體結構，可以用來指導企業方針。策略是治理層級的下?級。它們是敘述性文檔，概述了組織的安全要求。策略將框架中的指導?針轉化為清晰且可操作的聲明，該聲明用于指導組織的安全實踐活動。框架通常要求組織制定具體策略，以確保符合監管和合規要求。控制?標?策略更具體，側重于安全控制的預期結果。它們定義了最?化?險和維護安全環境的目標。例如，控制?標可能會規定所有用戶登錄云平臺必須使?多因素?份驗證(MFA)。控制目標為組織提供了明確的?向，指導完成安全方面的任務。圖10：結構化安全治理層次結構控制規范和實施指南是治理層級的基礎層。它們是實現控制?特定的云服務提供商和平臺而不同，例如AWS或Azure實現所需的安全結果。例如，為了滿?多因素身份驗證（MFA）的控制?標，AWS的控制規范可能要求所有用戶都啟?MFA進行控制臺訪問，并且IAM(?份和訪問管理)的?戶需要附加“MFARequired”管理策略才能進?API訪問。通過自動化，控制規范可以驗證合規性。值得注意的是，控制?標可能導致多種控制規范，因為云基礎設施內的不同環境或技術可能需要量身定制的實現才能滿?所需的安全結果。治理層級為組織提供了一個結構化的信息安全?法，確保安全實踐與?業標準、合規性和監管要求相?致。通過遵循治理層次結構，組織可以建?強?的安全策略，并有效地保護其系統和數據。基本治理原則與指南為了建?牢固的上云治理框架，第?步就是確定基礎治理原則。這些原則將作為指導方針，云治理框架應該為上云流程定義關鍵角色和利益相關者，包括?級管理?員、IT和技術?員、業務專家和安全利益相關者。治理層級確保與?業標準和監管要求保持??強?的安全態勢。下圖說明了云治理流程的關鍵要素，包括?險容忍度、數據分類和控制目標。圖11：云治理流程確定風險承受能?風險容忍度對于理解云環境運營時可接受的?險?關重要。?險容忍度是指云客戶在追求其?標的過程中，管理層愿意允許的任何特定?險的可接受程度。這個決定綜合考慮了定性和定量因素，例如財務、法律、聲譽和運營影響等。通過評估風險容忍度，云客戶可以建?明確的安全態勢，并在整個上云過程中做出明智的決策。云卓越中?（CCoE）或云團隊應記錄并告知領導層有關上云的?險，并在規定的風險容忍度范圍內運營。風險評估應基于對組織相關的不良?絡和運營事件的可能性和重?影響進行分析，可以使?影響可能性矩陣或信息風險因?分析(FAIR)等評估?法來實現。數據和資產分類數據和資產分類是云治理的關鍵??。云客戶需要根據敏感度、關鍵性以及與損失相關的潛在影響對數據和資產進?分類。正確的數據分類將有助于選擇適當的安全控制措施，并確保符合保護數據的法律、法規和合同要求。常?的分類可能包括公共數據、內部數據、機密數據和絕密數據。數據和資產的分類會影響它們在云中的存儲和處理?式，以及保護它們可能需要的控制措施（法律、監管、組織）。云注冊表應記錄此分類以供參考。此外，數據的位置在云計算中是?個關注點，因為數據可能托管在另?個司法管轄區，甚?有時云客戶都不知情。?些政府或機構對跨境數據傳輸有限制，或要求額外的控制，例如歐盟《通?數據保護條例》（GDPR）。識別法律和法規要求識別適?于不同司法管轄區或?業處理的數據類型的法律法規要求?關重要。例如，如果云客戶正在處理歐盟公民的個?數據，則需要遵守GDPR。同樣，如果云客戶在美國處理健康信息，則需要必須遵守《健康保險流通與責任法案》(HIPAA)。除了法律法規的要求外，根據風險評估確定的具體風險項也很重要。這確保了云治理框架的全?性，并與整體?險管理策略保持?致。需求、標準、最佳實踐和合同義務要建立健全的治理框架，必須符合既定的標準、最佳實踐和合同義務。這包括遵守CSACCMISO/IEC27001、ISO/IEC27017、NISTCSF或CISBenchmarks等標準和最佳實踐。了解云服務提供商的合同義務非常重要。這包括確定云客戶和云服務提供商之間的共同安全責任，以及他們之間合同中列出的任何具體安全要求。此外，還應考慮與云客戶和第三?合作伙伴的合同義務，因為它們可能會影響云計劃。在云供應鏈中，這些組織是云客戶和云服務提供商的合作伙伴。了解當前的最佳實踐也很重要。CSP通常會推薦使用云服務的最佳實踐（例如，AWSWell-ArchitectedFramework,AzureWell-ArchitectedFramework,IBMCloudWellArchitectedFramework,GoogleCloudArchitectureFramework）。雖然云客戶可能需要根據具體的需求調整這些實踐，但最佳實踐是建?安全云環境的寶貴參考點。云安全并?一塵不變。它需要根據特定情況進?定制，包括?業、?險容忍度和法律法規等要求。隨著新威脅的出現和法規的演變，持續監控和調整適應是必不可少的。云客戶需要確定各個供應商提供的適當服務，并配置這些服務以滿?要求和合規標準。咨詢關鍵利益相關者為了建立強大的上云治理框架，與關鍵利益相關者進?協商非常重要。這可以確保云安全策略與業務目標保持?致。此外，為了滿足已確定的需求，云客戶應制定明確的行動計劃，并實施適當的安全、隱私和數據保護的控制措施。該計劃應列出實施必要控制措施的具體步驟和時間表，以確保云環境的安全性、隱私和合規性。云注冊表為了促進有效的云治理，云客戶可以建?云部署注冊表和云服務注冊表。它們在云治理中各?發揮著不同的作?（CSC可能使?不同的術語）。從高層次上，云服務注冊表是指哪些云平臺和服務得到了哪些批準數據類型的列表（例如，SaaS提供商X被批準?于類型Y的數據）。云部署注冊表是?種工具，?于維護組織在多個提供商和服務中的云資源清單。這是?個集中式倉庫，保存有關組織部署的云資源的信息，包括所有權、使?情況和安全控制等詳細信息。此云注冊表有助于確保云資源管理的透明度和可問責性。與資產注冊表類似，通過擁有全?的云注冊表，云客戶可以有效地管理和保護其云資源。?些云客戶使?標準?險登記表來跟蹤云服務和部署。只要該登記表可供安全和運營團隊使?、并保持更新，包含本文所述信息，就是可以接受的。構建云部署注冊表時，包含如下重要的元素：1(CSP)：記錄每個帳戶的云服務提供商，包括AWS、AzureGCP等主要提SalesforceMicrosoft365SaaS平臺。此信息有助于了解所使?的底層基礎設施和服務。2ID：為每個云環境分配?個唯?ID應出現在?其他監控?具中，為每個環境提供精確的參考點。3、描述性名稱：提供?個有意義的名稱，準確描述每個云環境的?途或性質。這有助于更容易地識別和理解組織內每個環境的作?。4、合規分類：根據監管和合規需求（如PCIDSS、HIPAA、GDPR等）對每個環境進?分類。正確的分類可確保適當的安全措施和控件被應用，并滿?合規性要求。5、?險分類：評估并標記每個環境的?險級別，以符合云客戶的?險管理策略。這有助于采用適度資源和精力處理風險，并確保實施了適當級別的安全控件。6、環境分類：區分不同類型的環境，例如開發、準備和?產。這樣的分類使得每個環境都根據其特定要求進?配置，有助于治理和管理。7、所有者：確定每個云環境的業務所有者。這確保了決策和資源分配的可問責、責任和清晰的溝通渠道。8、技術聯系?：為每個環境的技術問題和運營管理指定?個聯系?。這有助于簡化溝通，并確保及時解決技術難題。9、云服務供應商聯系?：客戶支持和賬戶管理的聯系信息。此信息對于解決任何與服務相關的問題以及與云服務供應商保持良好關系?關重要。云部署注冊表功能擁有維護良好的云部署注冊表可帶來多種好處：更好的云資源可見性和控制：全?從?實現有效的資源管理、優化和變更管理。?致的治理框架應?：通過詳細的注冊表，云客戶可以確保在所有環境中應?框架、策略和程序。響應事件并進?有效協調。符合策略和法規：根據合規性需求對環境進?分類，云客戶可以確認他們遵守內部策略和外部法規，從?最大限度地減少不合規的?為。如果尚未編制云注冊表，請先編制云注冊表，并確定所有必要元素，收集每個環境所需的信息。根據計劃的時間間隔定期審查和更新云注冊表。此外，每當業務環境發生重?變化、法律/法規/合同變更、云基礎設施發生變化或組織結構發?變化時，都要更新注冊表。這可確保注冊信息保持準確和最新，從??持有效的治理和?險管理。云安全框架框架的主要目的之?是組織確定安全控制目標的優先級。這些目標代表組織為實現期望的安全結果?設定的具體目標。框架為分類這些目標提供了結構，并幫助組織確定最有效的實施和管理這些目標的?法。通過組織安全控制目標，框架使云客戶能夠系統性地處理云安全問題，并確保所有必要的控制措施得以落實。云特有的安全框架是專?為云環境設計的，并考慮了云計算的獨特特性。這些框架解決了按需資源分配、責任共擔和快速彈性等??的問題。通過使用特定于云的框架，云客戶可以確保其安全程序符合云的具體要求和挑戰。相關云框架的示例如下：CSA云控制矩陣(CCM)ISO/IEC27017:2015BSI云計算合規標準清單(C5)NISTSP800-53Rev.5信息系統和組織的安全和隱私控制PCIDSS支付卡數據安全標準委員會云計算指南如果云客戶已經使?信息安全框架，但該框架未能有效涵蓋云的特征，則可以考慮增加云的補充框架。這種理念是將特定于云的安全框架與現有的主框架?起使?。許多現有的安全框架最初并不是為云計算設計的，可能?法充分解決特定于云的活動。通過使?云補充框架，云客戶可以專注于云安全活動，同時仍然利用現有框架進行其他安全領域的工作。NIST網絡安全框架NIST發布的?(CSF)為?業、政府機構和其他組織提供了?種公認的結構化安全?CSFCore提供了高級?絡安全結果的六種功能分類，任何組織（?論其規模、部?或成熟度如何）使?它來更好地理解、評估、確定優先級和協商?CSF組織?絡安全?險管理?命周期的高級策略視圖：治理（GV）：建?并監控組織的網絡安全風險管理策略、期望和策略。識別(ID)：幫助確定組織當前的網絡安全風險。保護（PR）：采取安全措施來防?或降低?絡安全風險。檢測（DE）：發現并分析可能的網絡安全攻擊和危害。響應（RS）：對檢測到的網絡安全事件采取?動。恢復（RC）：恢復受網絡安全事件影響的資產和運營。CSA安全、信任、保證和風險注冊云安全聯盟（CSA）有一項STAR計劃，包括安全、信任、保證和?險。STAR計劃是?項旨在提?云服務的透明度和可信度的計劃。該計劃為云服務提供商記錄其安全實踐，并為云客戶提供了?個框架來評估云服務提供商的安全態勢。CSASTAR計劃由兩個主要部分組成：1、CSASTAR證明：在此過程中，云服務提供商會根據CSACCM的安全控制項進行?我評估，并公開其評估結果。這提供了云服務供應商的安全狀況透明度，讓云客戶能夠針對是否使?其服務做出明智的決策。CSASTAR認證：這需要獨?的第三?機構對云服務提供商進行評估，評估標準包括CSACCM和其他公認的?業標準（ISO/IEC27001）CSASTAR認證表明云服務提供商已經實施了強有力的安全措施和實踐。通過促進標準化安全評估和提?透明度，CSASTAR計劃使云客戶能夠評估云服務提供商的安全性、隱私性和合規性。這反過來?有助于云客戶在選擇和使用云服務時做出明智的決策，從?促進云?業的信任和可靠性。云控制矩陣CSACCMv4包含17個控制域。它全面涵蓋了從治理和風險管理到運營安全和數據隱私等各種安全主題。因此，對于希望增強云安全性的云服務提供商和云客戶而言，是一個寶貴的資源。CCM的主要優勢之?是它與ISO/IEC27001/27002、PCIDSS、NISTCSF等領先標準保持?致。通過與這些成熟框架保持協調?致，CCM確保組織可以在多種標準和法規下實現合規性。這種?致性還擴展到STAR計劃，進?步提高了其在?業中的可信度和相關性。CCM是專為云環境量?定制的，?常適合保護多租戶、分布式和動態云系統。與NISTCSF等更通?的安全框架不同，它專注于云計算的獨特挑戰。此外，CCM允許進行控件定制，使云客戶能夠根據其特定的云架構、交付模式（IaaS、PaaS、SaaS）和合規需求調整安全控制。CCM的另?個重要優勢是它?持云治理。它幫助云服務提供商建?和維護可靠的云治理計劃，從?有效地管理和監督云?險。這有助于確保云部署與組織目標相一致，并符合相關法規。CCM通過不斷更新來反映最新的云安全最佳實踐。云服務提供商和云客戶可以依靠CCM作為可靠的資源來滿?他們的云安全需求，并維持最新狀態。總體??，云安全框架是云客戶建?強??有效的云安全計劃的必備工具。通過選擇特定的云框架、附加云安全框架、確認組織安全控制目標，云客戶可以全?解決云安全問題，并使其流程與云的獨特要求保持?致。策略信息安全策略對于建?強?的安全框架?常重要。策略管理著組織信息資產的保護，并概述了必要的控制?標。例如，請參閱CIS36發布的NISTCSF策略模板指南。為了確保策略的有效性，建議組織領導層正式批準這些策略。這樣的批準賦予策略的權威性，并表明領導層致力于執?這些策略。有了領導層的?持，策略的實施將更加有效。通常，遵守各種監管和法律框架在信息安全策略的制定中發揮著重要作?，例如數據隱私的GDPR或針對財務報告的薩班斯法案(SOX)。組織需要制定具體策略來滿?這些合規標準，這對于確保符合外部要求和避免處罰至關重要。策略類型組織通常實施的信息安全策略有以下?個示例：信息安全策略是定義信息安全計劃應如何運?的最?其他策略?件，?不是試圖包含所有具體的技術要求。可接受使?策略(AUP)定義了組織IT資源的適當用途。遠程?作策略概述了遠程?作時，要對員?采取的安全措施和?為。云服務使?策略規定了在云中使?數據的要求。數據處理策略描述了數據如何分類、處理、存儲和處置，以維護其機密性、完整性和可性。信息安全策略是必不可少的可執行?件，它通過為安全實踐和?為提供清晰的框架來推動安全實踐并加強?絡安全?化。它們確保在不同環境中應?適當級別的保護。員?必須熟悉自己特定的信息安全策略，并理解自己在維護這些策略??的作?，以促進整體安全態勢。云安全控制目標云安全控制目標是云環境中所需的控制清單。這些目標是面向結果的，這意味著應該優先考慮結果?不是實現方式。這些目標應按照SMART原則（具體的、可測量的、可實現的、有時限的）進?衡量。控制目標應該與平臺無關，這意味著沒有特定的云服務提供商或技術限制控制目標。這使得控制目標適?于各種云環境，確保其相關性和有效性。實施的每個安全控制措施都應?少對應?個特定的控制?標。這確保了每項措施都有明確的?的，并有助于實現云環境的總體安全目標。最后，控制措施應給出明確定義，并專注于實際的安全結果的實現，避免使?模糊指令。?標應詳細說明，提供明確的指導?向，但不必過于具體，以免變成按部就班的操作程序。總之，云安全控制?標指導在云環境下建?強?的安全態勢。它們具有適應性、可衡量性和以結果為導向，與云計算的動態特性相?致。組織可以通過遵循這些?標，增強云安全性并降低潛在?險。將控制目標映射到框架安全計劃中的控制?標應該與所使?的框架保持?致。這種結構化方法確保了計劃涵蓋所有必要的領域。計劃的一致性也與?型組織的結構和運營職責相對應。框架是安全計劃的基礎，概述了總體結構和?法。另???，控制?標定義了期望的結果和?標。將控制?標與框架相關聯，可確保計劃具有適當的、明確的范圍。值得注意的是，如果控制?標與框架不?致，則表明該戰略存在差距。應解決這種不?致問題，以確保該計劃的全?有效。同樣，在框架中特定類別的控制?標也不足以表明存在需要解決的運營缺陷。為了保持這種映射關系，建議直接將它包含在控制目標庫中。這樣可以方便地進行參考，并與文檔相一致。CSACCM是?個?范框架，具有與相關框架、標準、法律和監管要求的全?映射列表，使其成為進行復雜治理時參考的寶貴資源。控制規范以滿足特定安全要求。需要注意的是，控制規范應針對特定供應商和技術，這意味著不同的云服務提供商之間可能存在顯著差異。例如，考慮實施多因素認證（MFA）的要求。啟?MFA的技術程序將因云服務提供商?異。每個云服務提供商都有自己獨特的配置和實施MFA的?式，因此需要創建特定于不同云服務提供商的控制規范。另?個可能會存在差異的控制規范是?絡安全。默認情況下，Azure將其?絡設置為對?站連接開放，這意味著必須配置額外的?絡安全組才能確保安全環境。另一方?，AWS將其?絡默認設置為?站連接的最低權限級別，從而提供了更?級別的安全性。此外，Azure?持允許和拒絕?絡安全規則設定，?AWS僅?持允許規則并拒絕所有其他流量。這些差異解釋了需要根據特定的云服務提供商定制控制規范。此外，控制要求可能會根據數據或資源的分類?有所不同。例如，如果云客戶處理個??份信息(PII)，則默認設置可能會具有更嚴格的控制要求。另?方?，被視為公開的數據可能具有較少的限制要求。在定義控制規范時，考慮數據或資源的敏感性是?常重要的。在某些情況下，控制措施?法在云服務提供商的?態系統內完全實施，可能需要第三方?這些?具可以提供額外的功能，并增強云環境的安全態勢。當使?第三方?具時，定義控制規范非常重要，如：為了滿?控制?標和要求，如何配置?具。這確保第三方?具有效地集成到安全策略中。控制規范應隨著時間推移?不斷發展，以適應技術進步、新產品以及新的威脅和攻擊媒介。修訂并采?修訂后的最新規范具有重要的意義。責任共擔模型責任共擔模型(SSRM)是?個基本的云安全概念。它規定了云客戶和云服務提供商有不同但互補的責任，以確保云服務正常運?并保持安全狀態。這種責任共擔可以擴展到云服務提供商和云客戶之外，涉及其他提供服務的各?，例如支持云服務提供商、代理商和云平臺集成商。IT團隊如何在其組織內的不同控制功能中映射責任共擔模型。組織需要對其計劃部署的?作、負載數量和在云中使?的服務進?當的探索，例如：需要多少?來操作控制才能使服務值得信賴？某些決定將由此產生：組織是否需要擴大內部規模，如：通過雇用全職員?或與外部顧問合作？在組織內部需要明確責任并反映在企業運營?式中，以避免其責任結束和云服務提供商責任開始之間出現的差距。在雙?的協議中描述這些責任并且確切解釋會很有益處。云服務的變化?傳統IT服務更加迅速，新服務不斷發布，舊服務不斷被淘汰。因此，隨著提供商增加新的服務和升級現有服務，責任共擔模型可以隨著時間而演變。例如，如果云服務提供商停?某項特定的服務，那么最重要的就是了解誰負責管理