文件執行雲端治理原則
本文說明如何定義及記錄雲端治理原則。 雲端治理原則會指定雲端中應該或不應該發生的情況。 雲端治理小組應該為風險評估中所識別的每個風險建立一或多個雲端治理原則。 雲端治理原則會定義與雲端和 互動的護欄。
定義記錄雲端治理原則的方法
建立方法來建立、維護及更新管理雲端服務使用的規則和指導方針。 雲端治理原則不應對特定工作負載而言是唯一的。 目標是產生不需要頻繁更新的雲端治理原則，並考慮雲端環境中雲端治理原則的影響。 若要定義原則檔方法，請遵循下列建議：
定義標準治理語言。 開發用於記錄雲端治理原則的標準結構和格式。 原則必須是項目關係人清楚且權威的參考。
辨識治理的不同範圍。 定義並指派專為組織內獨特角色量身打造的特定治理責任。 例如，開發人員會控管應用程式程序代碼。 工作負載小組負責單一工作負載，而平臺小組負責管理工作負載所繼承的治理。
評估雲端治理的廣泛影響。 雲端治理會產生摩擦。 尋找摩擦與自由之間的平衡。 當您開發雲端治理原則時，請考慮治理對工作負載架構、軟體開發實務和其他領域的影響。 例如，您允許或不允許決定工作負載架構，並影響軟體開發實務。
定義雲端治理原則
建立雲端治理原則，概述如何使用和管理雲端來降低風險。 將經常性原則更新的需求降到最低。 若要定義雲端治理原則，請遵循下列建議：
使用原則標識碼。 使用原則類別目錄和數位來唯一識別每個原則，例如 SC01 作為第一個安全性治理原則。 隨著您新增風險，依序遞增標識符。 如果您移除風險，則可以在序列中留下間距，或使用最低的可用數位。
包含原則語句。 製作解決已識別風險的特定原則聲明。 使用明確語言，例如 must、should、must、not 和 not't。 使用風險清單中的強制控件作為起點。 專注於結果，而不是設定步驟。 將強制執行所需的工具命名為 ，讓您知道監視合規性的位置。
包含風險識別碼。 列出原則中的風險。 將每個雲端治理原則與風險產生關聯。
包含原則類別目錄。 將治理類別，例如安全性、合規性或成本管理納入原則分類。 類別有助於排序、篩選和尋找雲端治理原則。
包含原則用途。 說明每個原則的目的。 使用原則滿足的風險或法規合規性需求作為起點。
定義原則範圍。 定義套用此原則的內容和物件，例如所有雲端服務、區域、環境和工作負載。 指定任何例外狀況，以確保沒有模棱兩可。 使用標準化語言，以便輕鬆地排序、篩選及尋找原則。
包含原則補救策略。 定義對違反雲端治理原則的預期回應。 針對風險嚴重性量身打造回應，例如排程非生產違規的討論，以及立即針對生產違規進行補救工作。
如需詳細資訊，請參閱 雲端治理原則範例。
散發雲端治理原則
將存取權授與需要遵守雲端治理原則的每個人。 尋找讓貴組織中人員更容易遵守雲端治理原則的方法。 若要發佈雲端治理原則，請遵循下列建議：
使用集中式原則存放庫。 針對所有治理檔使用集中式且易於存取的存放庫。 請確定所有項目關係人、小組和個人都能存取最新版本的原則和相關文件。
建立合規性檢查清單。 提供原則的快速且可採取動作的概觀。 讓小組更容易遵守，而不需要流覽廣泛的檔。 如需詳細資訊，請參閱 範例合規性檢查清單。
檢閱雲端治理原則
評估及更新雲端治理原則，以確保它們在治理雲端環境中保持相關且有效。 定期檢閱有助於確保雲端治理原則符合不斷變化的法規需求、新技術，以及不斷演進的商業目標。 當您檢閱原則時，請考慮下列建議：
實作意見反應機制。 建立方法來接收雲端治理原則有效性的意見反應。 從受原則影響的個人收集輸入，以確保他們仍然可以有效率地執行工作。 更新治理原則，以反映實際的挑戰和需求。
建立以事件為基礎的檢閱。 檢閱和更新雲端治理原則以回應事件，例如失敗的治理原則、技術變更或法規合規性變更。
排程定期檢閱。 定期檢閱治理原則，以確保它們符合不斷演進的組織需求、風險和雲端進步。 例如，在與項目關係人一起的一般雲端治理會議中包含治理檢閱。
加速變更控制。 包含原則檢閱和更新的程式。 確保雲端治理原則與組織、法規和技術變更保持一致。 請明確說明如何編輯、移除或新增原則。
識別效率不佳。 檢閱治理原則，以尋找並修正雲端架構和作業中的效率不佳。 例如，不要要求每個工作負載都必須使用自己的 Web 應用程式防火牆，請更新原則以要求使用集中式防火牆。 檢閱需要重複工作的原則，並查看是否有辦法集中處理工作。
雲端治理原則範例
下列雲端治理原則是參考的範例。 這些原則是以範例風險清單中的範例為基礎。
| 原則標識碼 | 原則類別 | 風險標識碼 | 原則陳述式 | 目的 | 範圍 | 補救 | 監視 |
|---|---|---|---|---|---|---|---|
| RC01 | 法規合規性 | R01 | Microsoft Purview 必須用來監視敏感數據。 | 法規合規性 | 工作負載小組、平台小組 | 受影響的小組立即採取行動，合規性訓練 | Microsoft Purview |
| RC02 | 法規合規性 | R01 | 每日敏感數據合規性報告必須從 Microsoft Purview 產生。 | 法規合規性 | 工作負載小組、平台小組 | 在一天內解決確認稽核 | Microsoft Purview |
| SC01 | 安全性 | R02 | 所有用戶都必須啟用多重要素驗證 （MFA）。 | 降低數據外泄和未經授權的存取 | Azure 使用者 | 撤銷使用者存取權 | Microsoft Entra ID 條件式存取 |
| SC02 | 安全性 | R02 | 存取權檢閱必須在每月 Microsoft Entra ID 控管 進行。 | 確保數據與服務完整性 | Azure 使用者 | 立即撤銷不符合規範 | ID 治理 |
| SC03 | 安全性 | R03 | Teams 必須使用指定的 GitHub 組織來保護所有軟體和基礎結構程式代碼的裝載。 | 確保程式代碼存放庫的安全和集中式管理 | 開發小組 | 將未經授權的存放庫轉移至指定的 GitHub 組織，以及不符合規範的潛在紀律處分 | GitHub 稽核記錄 |
| SC04 | 安全性 | R03 | 使用公用來源連結庫的小組必須採用隔離模式。 | 在整合至開發程式之前，請確定連結庫安全且符合規範 | 開發小組 | 拿掉不符合規範的連結庫，並檢閱受影響專案的整合實務 | 手動稽核（每月） |
| CM01 | 成本管理 | R04 | 工作負載小組必須在資源群組層級設定預算警示。 | 防止超支 | 工作負載小組、平台小組 | 立即檢閱、調整警示 | Microsoft 成本管理 |
| CM02 | 成本管理 | R04 | 必須檢閱 Azure Advisor 成本建議。 | 優化雲端使用量 | 工作負載小組、平台小組 | 60 天后的必要優化稽核 | Advisor |
| OP01 | Operations | R05 | 生產工作負載應具有跨區域的主動-被動架構。 | 確保服務持續性 | 工作負載小組 | 架構評估、兩年一次檢閱 | 手動稽核（每個生產版本） |
| OP02 | Operations | R05 | 所有任務關鍵性工作負載都必須實作跨區域主動-主動架構。 | 確保服務持續性 | 任務關鍵性工作負載小組 | 在90天內 更新進度檢閱 | 手動稽核（每個生產版本） |
| DG01 | 資料 | R06 | 傳輸中的加密和待用加密必須套用至所有敏感數據。 | 保護敏感數據 | 工作負載小組 | 立即加密強制執行和安全性訓練 | Azure 原則 |
| DG02 | 資料 | R06 | 所有敏感數據都必須在 Microsoft Purview 中啟用數據生命周期原則。 | 管理資料生命週期 | 工作負載小組 | 在 60 天內實作，每季稽核 | Microsoft Purview |
| RM01 | 資源管理 | R07 | Bicep 必須用來部署資源。 | 標準化資源布建 | 工作負載小組、平台小組 | 立即 Bicep 轉換計劃 | 持續整合和持續傳遞 （CI/CD） 管線 |
| RM02 | 資源管理 | R07 | 卷標必須使用 Azure 原則 在所有雲端資源上強制執行。 | 加速資源追蹤 | 所有雲端資源 | 更正 30 天內的標記 | Azure 原則 |
| AI01 | AI | R08 | AI 內容篩選組態必須設定為中型或更高。 | 降低 AI 有害輸出 | 工作負載小組 | 立即更正措施 | Azure OpenAI 服務 |
| AI02 | AI | R08 | 客戶面向 AI 系統必須每月進行紅色小組處理。 | 識別 AI 偏差 | AI 模型小組 | 立即檢閱，修正遺漏的動作 | 手動稽核（每月） |