你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
记录云治理策略
本文介绍如何定义和记录云治理策略。 云治理策略指定云中应或不应发生的情况。 云治理团队应为风险评估中标识的每个风险创建一个或多个云治理策略。 云治理策略定义与云中交互的防护措施。
定义用于记录云治理策略的方法
建立一种创建、维护和更新治理云服务使用的规则和准则的方法。 云治理策略不应对特定工作负荷是唯一的。 目标是生成不需要频繁更新的云治理策略，并考虑云治理策略在云环境中的影响。 若要定义策略文档方法，请遵循以下建议：
定义标准治理语言。 开发用于记录云治理策略的标准结构和格式。 这些策略必须是利益干系人明确和权威的参考。
识别不同的治理范围。 定义并分配专为组织内的独特角色定制的特定治理职责。 例如，开发人员控制应用程序代码。 工作负荷团队负责单个工作负荷，平台团队负责管理工作负荷所继承的治理。
评估云治理的广泛影响。 云治理会产生摩擦。 在摩擦与自由之间找到平衡。 在制定云治理策略时，请考虑治理对工作负荷体系结构、软件开发做法和其他方面的影响。 例如，允许或禁止的内容决定了工作负荷体系结构并影响软件开发实践。
定义云治理策略
创建概述如何使用和管理云来降低风险的云治理策略。 最大程度地减少频繁策略更新的需求。 若要定义云治理策略，请遵循以下建议：
使用策略 ID。 使用策略类别和数字来唯一标识每个策略，例如 SC01 作为第一个安全治理策略。 添加新风险时按顺序递增标识符。 如果消除风险，则可以在序列中留出空白，也可以使用最少的可用数字。
包括策略语句。 制定解决已识别风险的特定策略声明。 使用明确的语言，如 必须、 应、 不得和 不应。 使用风险列表中的强制控制作为起点。 专注于结果，而不是配置步骤。 为强制实施所需的工具命名，以便知道在何处监视符合性。
包括风险 ID。 列出策略中的风险。 将每个云治理策略关联到风险。
包括策略类别。 将治理类别（如安全、合规性或成本管理）包括在策略分类中。 类别有助于对云治理策略进行排序、筛选和查找。
包括策略用途。 声明每个策略的用途。 使用策略作为起点所满足的风险或法规合规性要求。
定义策略范围。 定义适用于哪些和谁，例如所有云服务、区域、环境和工作负载。 指定任何异常以确保没有歧义性。 使用标准化语言，以便可以轻松对策略进行排序、筛选和查找。
包括策略修正策略。 定义对违反云治理策略的所需响应。 根据风险的严重性定制响应，例如计划针对非生产违规的讨论，并立即对生产违规进行修正。
有关详细信息，请参阅 示例云治理策略。
分发云治理策略
向需要遵守云治理策略的每个人授予访问权限。 查找使组织中人员更容易遵守云治理策略的方法。 若要分发云治理策略，请遵循以下建议：
使用集中式策略存储库。 对所有治理文档使用集中且易于访问的存储库。 确保所有利益干系人、团队和个人都可以访问最新版本的策略和相关文档。
创建符合性检查列表。 提供策略的快速且可操作的概述。 使团队更容易遵守，而无需浏览广泛的文档。 有关详细信息，请参阅示例符合性检查列表。
查看云治理策略
评估和更新云治理策略，以确保它们在治理云环境中保持相关且有效。 定期评审有助于确保云治理策略符合不断变化的法规要求、新技术和不断发展的业务目标。 查看策略时，请考虑以下建议：
实现反馈机制。 建立有关云治理策略有效性的反馈的方法。 收集受策略影响的个人的输入，以确保他们仍然可以有效地完成工作。 更新治理策略，以反映实际挑战和需求。
建立基于事件的评审。 查看和更新云治理策略以响应事件，例如失败的治理策略、技术更改或法规合规性更改。
安排定期评审。 定期查看治理策略，确保它们符合不断变化的组织需求、风险和云进步。 例如，在与利益干系人举行的定期云治理会议中包含治理评审。
促进更改控制。 包括策略评审和更新的过程。 确保云治理策略与组织、法规和技术更改保持一致。 明确如何编辑、删除或添加策略。
识别效率低下。 查看治理策略，以查找和修复云体系结构和操作中的低效问题。 例如，无需要求每个工作负荷使用其自己的 Web 应用程序防火墙，而是更新策略以要求使用集中式防火墙。 查看需要重复工作的策略，看看是否有办法集中工作。
云治理策略示例
以下云治理策略是参考的示例。 这些策略基于示例风险列表中的示例。
| 策略 ID | 策略类别 | 风险 ID | 策略语句 | 目的 | 范围 | 修正 | 监视 |
|---|---|---|---|---|---|---|---|
| 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 顾问成本建议。 | 优化云使用情况 | 工作负荷团队，平台团队 | 60 天后强制优化审核 | 顾问 |
| OP01 | Operations | R05 | 生产工作负荷应跨区域具有主动-被动体系结构。 | 确保服务连续性 | 工作负荷团队 | 体系结构评估、两年一次评审 | 手动审核（每个生产版本） |
| OP02 | Operations | R05 | 所有任务关键型工作负荷都必须实现跨区域主动-主动体系结构。 | 确保服务连续性 | 任务关键型工作负荷团队 | 在 90 天内汇报进度评审 | 手动审核（每个生产版本） |
| DG01 | 数据 | R06 | 传输中的加密和静态加密必须应用于所有敏感数据。 | 保护敏感数据 | 工作负荷团队 | 即时加密强制和安全培训 | Azure Policy |
| DG02 | 数据 | R06 | 必须在 Microsoft Purview 中为所有敏感数据启用数据生命周期策略。 | 管理数据生命周期 | 工作负荷团队 | 在 60 天内实施季度审核 | Microsoft Purview |
| RM01 | 资源管理 | R07 | Bicep 必须用于部署资源。 | 标准化资源预配 | 工作负荷团队，平台团队 | 即时 Bicep 过渡计划 | 持续集成和持续交付（CI/CD）管道 |
| RM02 | 资源管理 | R07 | 必须使用 Azure Policy 对所有云资源强制实施标记。 | 促进资源跟踪 | 所有云资源 | 在 30 天内正确标记 | Azure Policy |
| AI01 | AI | R08 | AI 内容筛选配置必须设置为中等或更高。 | 缓解 AI 有害输出 | 工作负荷团队 | 立即纠正措施 | Azure OpenAI 服务 |
| AI02 | AI | R08 | 面向客户的 AI 系统必须每月进行红团队化。 | 识别 AI 偏见 | AI 模型团队 | 立即查看，纠正错过操作 | 手动审核（每月） |