评估主权要求
Azure 的 Microsoft Cloud 采用框架是一个完整的生命周期框架，可帮助云架构师、IT 专业人员和业务决策者实现云采用目标。 它提供帮助创建和实施云业务和技术策略的最佳做法、文档和工具。 有严格主权要求的公共部门组织可以将主权目标纳入规划工作中，让有关云采用的战略决策与这些主权要求保持一致。
本文重点介绍了组织可能希望评估、确定和记录主权要求的方面，并就这些要求可能适合与 Azure 云采用框架相关的更广泛的规划工作的方面提供建议。
确定主权数据
数据主权要求可能包括保留数据所有权以及指定数据存储、使用和传输方法的强制要求。 有时，数据主权要求还可能包括有关数据驻留的限制或强制要求。 在组织的云之旅中尽早了解这些要求可以帮助建立数据主权的通用设计模式，而不是期望工作负荷负责人开发解决方案来满足主权要求。
采用 Azure 云采用框架的组织将在规划阶段确定要迁移到云的候选工作负荷，然后在准备阶段设计托管这些工作负荷的环境。 这些活动可以让组织确定需要在目标状态云环境中进行特殊处理的主权数据类型。
Microsoft 使用多种类型的数据，如提供给 Microsoft 的个人信息以及上载到云服务以提供联机和专业服务的客户数据。 Microsoft 的数据保护责任记录在 Microsoft 产品和服务数据保护附录 (DPA) 中，并包含在组织与 Microsoft 的协议中。 DPA 中指定了 Microsoft 管理的不同数据类型，并描述了 Microsoft 用于保护这些数据类型的做法。
很多组织都有现有的数据治理计划，指定处理敏感数据的要求，可以使用此信息来确定数据主权要求是否适用于所有数据分类或仅适用于数据分类的子集。 当组织在云服务中上载和维护数据时，他们需要负责按照数据处理要求准确地分类、标记和管理数据。 有些组织可能希望利用云采用作为审查数据分类计划的机会。
有关数据分类如何应用于云采用的更多信息，请参阅 Azure 中的数据分类和云治理指南。
数据主权要求示例
具有严格数据主权要求的组织在将工作负荷迁移到云时可能必须针对以下代表性场景中的一部分进行规划。
数据分类标签
分类标签标识具有特殊处理要求的资源。 分类标签应用于文档，也可以应用于资产。 客户可以使用 Azure 中的本地标记功能将分类标签应用于计算服务和数据存储等资源以及 Azure 中的逻辑结构（如订阅和管理组）。
有关更多信息，请参阅 Azure 中的标记和 Microsoft Purview 电子数据展示解决方案。
数据分类边界
当组织选择聚合类似分类的数据（或应用程序）时，通常会部署安全外围作为允许数据存储的位置的边界。 当客户在 Azure 中部署工作负荷时，可以使用订阅和管理组在组织的云环境中创建逻辑边界。 这些边界帮助减轻与未经授权的访问相关的保密风险以及与数据聚合和归属相关的隐私风险。
具有严格数据主权要求的组织可能需要考虑是否要在分层模型中组织环境，其中较高的特权级别继承较低的特权级别（例如，如 Bell-LaPadula 模型），或者是否愿意实现非分层模型，使用强制访问控制来创建将环境的一部分与环境的其余部分分隔开的边界。 在 Azure 云采用框架的准备阶段设计登陆区域时，有关组织如何管理数据分类边界的决定至关重要。
有关更多信息，请参阅 Azure 中的管理组和数据治理。
数据驻留
必须满足数据驻留要求的组织应该特别注意他们需要哪些 Azure 服务来支持工作负荷，以及这些服务在哪些地方在地理位置上可用。 Azure 服务部署在支持低延迟网络连接和可用性区域等功能的区域中。 这些区域按地域分组，提供额外的复原能力和灾难恢复功能。
如果组织需要维护工作负荷的数据驻留，需要确保所使用的 Azure 服务在首选区域和地域可用。 此外，有些服务是在全球范围内部署的，不在给定区域或地域内为该服务中存储的数据提供数据驻留。
有关数据驻留、Azure 区域和可用性区域以及 Azure 服务的区域可用性的详细信息，请参阅以下文章：
数据的所有权、保管和可移植性
具有严格数据主权要求的客户通常会遇到很多以下相关问题：谁保留 Azure 中存储的数据的所有权、谁可以访问该数据，以及如果客户选择将工作负荷转移到另一个平台，这些数据会发生什么情况。 这些要求的范围和特征可能有所不同，但它们通常与以下基本问题相关：当您将数据托管在 Microsoft cloud service 中时，数据会发生什么情况。
为了帮助在高级别上解决这些问题，为客户提供一个确定适用于云服务提供商的数据主权要求的起点，Microsoft 发布了一系列有关保护和管理客户数据的文章来解决其中很多问题，这些文章在信任中心在线提供。
有关详细信息，请参阅 Microsoft 的数据管理。
在云中维护运营主权
运营主权要求可能会影响 Azure 中环境的设计、更新和管理方式。 因此，在作为 Azure 云采用框架准备阶段的一部分最终确定技术设计之前，清楚地了解这些要求非常重要。 常见的运营主权要求可能包括：
- 对管理人员的地点和国籍的限制。
- 限制云服务提供商的特权访问的访问控制要求。
- 高可用性和灾难恢复方面的强制要求。
清楚地了解意图以及这些要求减轻的风险非常重要，因为这些要求中有很多在云中是使用与本地的常用方法不同的方法满足的。
组织确定运营主权要求后，可以选择适当的技术和管理主权控制，来提供适当水平的风险缓解和保证。 选择主权控制时，了解选择一些可以提供额外运营主权的功能会限制组织采用其他 Azure 服务的选项，这一点很重要。
例如，需要对 Azure 工作负荷进行机密计算的组织必须将体系结构选择限制为可以在 Azure 机密计算上运行的服务，如机密虚拟机或机密容器。 因此，将运营主权要求与给定的数据分类相关联通常是一个好主意，而不是采用所有工作负荷和数据都必须满足最严格的主权要求集的方法。
此外，一些运营主权要求，如自给自足（例如，能够独立于外部网络和系统运行），在 Azure 等超大规模的云计算平台中是不可行的，这些平台依赖定期平台更新来让系统保持最佳状态。
运营主权要求示例
一些常见的运营主权要求以及可以满足这些要求的相关 Azure 服务和功能的示例如下：
软件安全
软件安全要求可以包括开发活动，如应用特定的加密保护、执行代码审查以及执行应用程序安全和渗透测试。 还可以包括运营流程，如访问控制的实施、加密技术的使用以及监视安全事件。
Microsoft 提供不同功能来帮助客户满足 Microsoft 开发和客户开发的软件的运营主权要求。 Microsoft 在为 Azure 开发平台级软件时采用安全开发生命周期 (SDL)。 SDL 的 12 个做法已纳入 Microsoft 的工程流程和程序，并会作为 Microsoft 保证活动的一部分定期进行评估。 此外，Microsoft 还提供帮助客户采用安全开发生命周期做法作为软件开发生命周期一部分的功能。
有关详细信息，请参阅 Microsoft 安全开发生命周期和 Azure 上的安全开发最佳做法。
基础结构安全
在 Azure 上运行的工作负荷可以利用 Microsoft 开发的很多功能来确保平台的完整性。 这些功能包括固件、软件和主机基础结构。 组织可能有运营主权要求，需要将数据与云运营商隔离。 Azure 提供的功能可供客户利用公有云的敏捷性和复原能力，同时保持与云服务提供商及其管理人员的隔离。 具有与硬件级证明、软件完整性验证（例如，安全启动）和安全密钥管理相关要求的组织，可以查看 Microsoft 的平台完整性和安全做法，并可以访问审核文档来验证这些功能的实现。
有关详细信息，请参阅平台完整性和安全性和 Azure 基础结构安全。
对静态数据、传输中的数据和使用中数据的加密可以帮助满足与数据机密性和隐私相关的各种运营主权要求。 但是，需要这些功能的组织需要规划加密密钥的创建和管理。 Azure 提供了广泛的静态数据加密模型供客户选择，从为云中托管的数据提供零知识加密的客户端加密方法，到提供最高程度的与本地云服务的互操作性的服务托管密钥。
此外，希望最大限度地减少对主机操作系统、内核、虚拟机监控程序和管理人员等平台组件的信任需求的组织可以实施对使用中的数据加密。 Azure 机密计算包括部署在基于硬件的安全性 enclave 中的若干计算服务，这些服务使用 Intel Software Guard Extensions (SGX) 或 AMD 安全加密虚拟化 (SEV-SNP) 对内存中的数据进行加密。
具有运营主权要求需要实施加密的组织应该熟悉 Azure 中的以下加密功能：
运营和复原能力
运营安全要求既适用于 Microsoft 创建和管理的用于运营 Azure 平台的平台级软件，也适用于作为工作负荷一部分的客户管理的软件。 云计算的共享责任模型将管理责任从客户转移到云服务提供商。 根据所使用的云服务的类型，Microsoft 可能负责管理和更新我们的数据中心、操作系统和服务运行时中的裸机基础结构。 Microsoft 的安全工程组织实施了一项运营安全计划，该计划以 Microsoft 安全开发生命周期 (SDL) 的做法以及运营安全做法为基础。 这些做法包括由 Microsoft 安全响应中心实施的机密管理、渗透测试和安全监视。
在极少数情况下，Microsoft 可能需要访问客户数据来解决可能影响服务的问题。 具有与变更控制和 Privileged Access Management 相关的运营主权要求的客户可能需要启用 Azure 客户密码箱，以可以作为 Microsoft 支持工作流的一部分批准访问请求。
此外，对平台软件更新的批准和安排有严格要求的客户可能需要考虑 Azure 专用主机，它让客户可以使用维护配置来控制主机级平台维护活动。 此外，客户应该检查其复原能力要求，确定用于托管工作负荷的服务和区域是否存在任何基于主权的限制。
围绕运营连续性的运营主权要求（例如，要求将工作负荷部署在高可用配置中以维持正常运行时间）可能与与数据驻留相关的数据主权要求相冲突（例如，将工作负荷限制在不提供不同位置的地理边界内）。
组织应该尽早评估这些要求并考虑平衡这些要求的最佳方法。