利用風險評估的見解,團隊現在制定政策來處理這些風險。 對於每個重大風險或風險組,應有一個或多個對應的治理策略。 記錄雲端治理原則時,請考慮下列最佳做法:
1. 建立標準的政策格式和語言
為所有原則建立一致的範本或格式。 每個政策文件(或部分)都應包含關鍵元素,例如 ID、陳述式、範圍。 使用清晰、明確的語言。 政策旨在作為權威參考,因此它們應該易於利害關係人理解,沒有誤解的餘地。 例如,決定要求的標準措辭,例如「必須」或「不得」,並避免使用模糊的術語。 標準化格式 (例如具有 ID、類別、用途的原則) 可讓原則更易於瀏覽和維護。
2. 定義雲端治理策略
建立雲端控管原則,概述如何使用和管理雲端以降低風險。 最大限度地減少頻繁政策更新的需求。 若要定義雲端治理原則,請遵循下列建議:
使用原則識別碼。 使用原則類別和數字來唯一識別每個原則,例如第一個安全控管原則的 SC01 。 當您新增風險時,依序遞增識別碼。 如果您移除風險,您可以在序列中留下間隙,或使用可用的最低數字。
包括政策聲明。 制定解決已識別風險的具體政策聲明。 使用明確的語言,例如 必須、 應該、 不得和 不應該。 使用風險清單中的強制控制作為起點。 專注於結果而不是配置步驟。 命名強制執行所需的工具,以便您知道在何處監控合規性。
包括風險識別碼。 在政策中列出風險。 將每個雲端控管原則與風險產生關聯。
列入政策類別。 將治理類別 (例如安全性、合規性或成本管理) 納入原則分類中。 類別有助於排序、篩選和尋找雲端治理原則。
包括政策目的。 說明每項政策的目的。 使用原則所滿足的風險或法規合規性需求作為起點。
定義原則範圍。 定義此原則適用的內容和對象,例如所有雲端服務、區域、環境和工作負載。 指定任何例外狀況,以確保沒有歧義。 使用標準化語言,以便輕鬆排序、篩選和尋找原則。
包括政策補救策略。 定義違反雲端治理原則所需的回應。 根據風險的嚴重性來調整回應措施,例如安排討論非生產違規事項,以及立即展開針對生產違規的補救行動。
如需詳細資訊,請參閱 範例雲端治理原則。
3. 散發雲端治理策略
將存取權授與需要遵守雲端治理原則的每個人。 尋找方法,讓組織中的人員更輕鬆地遵守雲端治理原則。 若要散發雲端控管原則,請遵循下列建議:
使用集中式原則存放庫。 使用集中式、易於存取的儲存庫來處理所有治理文件。 確保所有利害關係人、團隊和個人都能存取最新版本的政策和相關文件。
建立合規檢查清單。 提供快速且可操作的政策概觀。 讓團隊更容易遵守規定,而無需瀏覽大量文件。 如需詳細資訊,請參閱 範例合規性檢查清單。
4. 檢閱雲端治理原則
評估和更新雲端治理原則,以確保它們在管理雲端環境時保持相關性和有效性。 定期檢閱有助於確保雲端治理原則符合不斷變化的法規需求、新技術和不斷發展的商務目標。 檢閱政策時,請考慮下列建議:
實施反饋機制。 建立接收雲端治理原則有效性意見反應的方法。 收集受政策影響的個人的意見,以確保他們仍然能夠有效率地完成工作。 更新治理政策以反映實際挑戰和需求。
建立基於事件的評估。 檢閱和更新雲端控管原則,以回應事件,例如失敗的控管原則、技術變更或法規合規性變更。
安排定期審查。 定期檢閱治理原則,以確保它們符合不斷變化的組織需求、風險和雲端進步。 例如,在與持份者的定期雲端治理會議中納入治理檢閱。
促進變更控制。 包括政策審查和更新的流程。 確保雲端治理原則與組織、法規和技術變更保持一致。 明確如何編輯、移除或新增原則。
識別低效率。 檢閱治理原則,以找出並修正雲端架構和作業中的低效率問題。 例如,不要強制每個工作負載都必須使用自己的 Web 應用程式防火牆,而是更新原則以要求使用集中式防火牆。 檢閱需要重複努力的政策,看看是否有辦法將工作集中化。
雲端治理原則範例
下列雲端治理原則是範例,以供參考。 這些原則是以 範例風險清單中的範例為基礎。
| 原則識別碼 | 政策類別 | 風險標識碼 | 政策聲明 | 目標 | Scope | Remediation | 監測 |
|---|---|---|---|---|---|---|---|
| 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 使用者 | 因不合規而立即撤銷存取權 | 身份識別治理 |
| SC03 | 安全性 | R03 號 | 團隊必須使用指定的 GitHub 組織來安全裝載所有軟體和基礎結構程式碼。 | 確保程式碼儲存庫的安全且集中管理 | 開發團隊 | 將未經授權的儲存庫轉移到指定的 GitHub 組織,並可能因不合規而受到紀律處分 | GitHub 稽核記錄 |
| SC04 | 安全性 | R03 號 | 使用公用來源程式庫的小組必須採用隔離模式。 | 在整合到開發流程之前確保程式庫安全且合規 | 開發團隊 | 移除不合規的程式庫,並審查受影響專案的整合實務 | 手動稽核 (每月) |
| CM01 | 成本管理 | R04 | 工作量團隊必須在資源組層級設定預算警示。 | 防止超支 | 工作負載團隊、平台團隊 | 即時審查、警報調整 | Microsoft 成本管理 |
| CM02 | 成本管理 | R04 | 必須檢閱 Azure Advisor 成本建議。 | 最佳化雲端使用 | 工作負載團隊、平台團隊 | 60 天後強制性最佳化稽核 | Advisor |
| 作品01 | Operations | R05 | 生產工作負載應該具有跨區域的主動-被動架構。 | 確保服務連續性 | 任務團隊 | 架構評估,每半年一次的審查 | 手動稽核(每個產品發行版本) |
| OP02 | Operations | R05 | 所有關鍵任務工作負載都必須實作跨區域主動-主動架構。 | 確保服務連續性 | 關鍵任務工作負載團隊 | 90 天內更新,進度審查 | 手動稽核(每個產品發行版本) |
| DG01 | 資料 | R06 號 | 傳輸中和靜態加密必須套用至所有敏感資料。 | 保護敏感資料 | 任務團隊 | 即時加密執行和安全培訓 | Azure 原則 |
| DG02 | 資料 | R06 號 | 必須在 Microsoft Purview 中針對所有敏感性數據啟用數據生命週期原則。 | 管理資料生命週期 | 任務團隊 | 60天內實施,每季審核一次 | Microsoft Purview |
| 馬幣01元 | 資源管理 | R07 | Bicep 必須用來部署資源。 | 標準化資源佈建 | 工作負載團隊、平台團隊 | Bicep 立即轉換計劃 | 持續整合和持續交付(CI/CD)流程 |
| 馬幣02 | 資源管理 | R07 | 必須使用 Azure 原則在所有雲端資源上強制執行標籤。 | 促進資源追蹤 | 所有雲端資源 | 正確標記在 30 天內完成 | Azure 原則 |
| AI01 | AI | R08 號 | AI 內容篩選設定必須設定為中等或更高。 | 減少 AI 有害輸出 | 任務團隊 | 立即糾正措施 | Azure OpenAI 服務 |
| AI02 | AI | R08 號 | 客戶面向的人工智慧系統每月必須由紅隊進行安全測試。 | 識別 AI 偏見 | AI 模型團隊 | 立即審查,針對疏漏採取糾正措施 | 手動稽核 (每月) |