在 Microsoft Cloud for Sovereignty 中中使用客户管理的密钥加密
计划实施 Microsoft Cloud for Sovereignty 的客户可能需要使用数据加密功能来满足数据主权要求。 对数据主权有严格要求的客户应该制定在云中实施密钥管理的计划。 本文指导云架构师、加密系统负责人和其他技术决策者制定在 Azure 中实施平台级加密的计划。 平台级别的加密计划通常包括确定密钥管理要求、做出技术选择以及为要使用的 Azure 服务选择设计和配置。 此过程涉及跨三个领域做出技术决策：
- 定义密钥管理要求：您的组织需要采取哪些措施来保护敏感的客户数据和敏感的加密材料？
- 选择数据加密功能保护客户数据：应如何、在何处以及何时在 Azure 中加密客户数据？
- 选择密钥管理解决方案来保护客户密钥：应使用哪个密钥存储来保护用于加密 Azure 中客户数据的数据加密密钥？
定义密钥管理要求
密钥管理要求可以包括有关所使用的加密服务的技术要求以及与性能、安全性和主权相关的操作要求。 在决定何时以及如何加密 Azure 工作负荷中的数据时，建议从组织的数据分类系统开始。 通过使加密要求与数据分类（不是特定系统或解决方案）保持一致，组织可以更灵活地在工作负荷迁移计划期间选择最佳加密级别。
基于数据分类的加密要求还允许采用分层方法，让关键性较低的工作负荷可以利用更简单的解决方案，同时为具有较高固有风险级别的工作负荷保留最复杂的配置。 此方法的一个示例是允许使用 Microsoft 管理的密钥来加密开发环境的存储帐户，同时要求生产存储帐户使用客户管理的加密密钥。
在组织清楚地了解加密要求与数据分类的关系后，他们可以开始为计划使用的 Azure 服务选择功能。 其中一些功能的运行方式可能与相似的本地系统不同，因此鼓励组织熟悉 Azure 中加密的工作原理，并查看设计加密解决方案的建议和最佳做法。 以下文章提供了有关客户需要做出的一些技术选择的其他视角，可以作为开始有关组织的云密钥管理目标的对话的有用起点。
选择数据加密功能
很多 Azure 服务使用完全由 Azure 生成、存储和管理的密钥来实现加密，无需任何客户交互。 这些平台管理的密钥可以帮助组织以很少的运营开销实现加密。 但是，具有严格数据主权要求的客户可能需要选择特定的平台加密功能来保护给定 Azure 服务中静态的敏感数据。
对于高度敏感的数据，很多常用的 Azure 服务允许客户使用客户管理的密钥 (CMK) 实现双重加密。 在 Azure 服务中实施客户管理的密钥可以帮助客户保护存储在这些服务中的数据免遭未经授权的访问。
在 Azure 中实施客户管理的密钥可能会增加工作负荷的成本和复杂性，因此鼓励组织评估每个工作负荷和数据分类级别对此功能的需求。 仅针对需要的工作负荷和数据类型实施客户管理的密钥有助于减少不处理敏感数据的工作负荷的运营开销。
如果需要客户管理的密钥，则需要为每个相应的 Azure 服务进行配置。 组织可以通过建立组织范围的标准和可重复的设计模式来实现这些功能，进而帮助简化部署或迁移计划工作。 以下文章提供了有关如何在 Azure 中配置静态数据加密的更多信息：
了解如何配置常用的 Azure 服务以使用客户管理的密钥加密静态数据：
- 将 CMK 与存储帐户结合使用
- 在 AMD 机密 VM 的机密计算中使用 CMK
- 将 CMK 与虚拟机托管磁盘结合使用
- 将 CMK 与 Azure SQL DB 结合使用
- 将 CMK 与 Azure Cosmos DB 结合使用
- 将 CMK 与 Azure Monitor 结合使用
选择密钥管理解决方案
虽然使用客户管理的密钥进行双重加密等功能可以帮助保护 Azure 服务中维护的客户数据，但基于云的密钥管理解决方案有助于保护加密密钥和用于加密敏感数据的其他加密材料。 有严格数据主权要求的客户应根据其保障需求和工作负荷的风险状况选择合适的密钥管理解决方案。
处理敏感数据的工作负荷可能受益于 Azure Managed HSM 等解决方案提供的额外保证，包括 FIPS-140-2 3 级验证硬件安全模块，这些模块具有额外的安全控制，可保护存储的加密材料。
以下文章提供了客户可以用来为确定的场景选择合适的密钥存储的指导。 另外还提供了有关 Microsoft 如何管理客户在其加密解决方案中使用的加密服务的信息。
密钥管理操作模型
Azure Key Vault 以不同的方式实现基于角色的访问控制，具体取决于您使用的是 Azure Key Vault 的标准/高级层还是 Azure Key Vault 托管 HSM。 访问控制的这些差异可能会影响组织使用这些功能的方式。 本节介绍了这些差异，以及它们可能如何影响组织选择设计云密钥管理操作流程的方式。
FIPS-140 3 级验证的合规性约束
FIPS-140 3 级验证需要基于身份的运算符标识。 这些安全措施已在支持 Azure 中的 Key Vault 服务的基础 HSM 硬件中进行部署和验证。 因此，Azure Key Vault 中的 RBAC 功能依赖于基础硬件的 RBAC 功能。
Azure Key Vault 托管 HSM 利用在硬件级别实现的本地 RBAC 分配，允许在安全域范围内（例如，HSM 范围内）或按密钥分配角色。 这意味着密钥创建需要对整个安全域有管理权限，因为无法为还不存在的密钥分配权限。 此设计的影响是，任何需要在 mHSM 实例中存储密钥的人都必须对存储在该安全域中的所有密钥具有完全权限，或者向对安全域具有所需权限的集中式团队请求密钥。 这代表建议为每个应用程序创建单独密钥库的 Azure Key Vault 指南会有变化。
Azure Key Vault 托管 HSM 中的密钥管理操作
要订立密钥管理操作流程，客户应该确定是否需要 Azure Key Vault 托管 HSM 作为解决方案体系结构的一部分。 计划使用托管 HSM 的组织应首先熟悉用于管理和加密操作的访问控制模型，并了解如何分配基于角色的访问控制。
了解有关托管 HSM 中的访问控制的更多信息：
计划使用 Azure Key Vault HSM 的组织应查看托管 HSM 的内置 RBAC 角色和允许的操作列表，并专门计划如何解决以下操作场景：
- 在托管 HSM 中创建新密钥
- 使用控制平面管理现有密钥的操作，如密钥更新或密钥轮换
- 应用程序或服务使用数据平面处理现有密钥
目前，分配创建新密钥的权限的唯一方法是分配另外包括其他权限（如密钥轮换和删除）的角色，如 Crypto User。 因此，授予应用程序团队成员在托管 HSM 中创建自己的密钥所需的权限可能会违反最低权限原则，因为该用户还会具有 HSM 中所有密钥的管理权限。 可以通过引入具有提升权限、能够推进密钥创建请求的集中式团队来解决此问题，或者引入可通过利用托管 HSM REST API 的 IT 服务管理流程来推进新的密钥创建请求的自动化来加以解决。