你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
修改 Azure 登陆区域体系结构以满足多个位置的要求
许多行业的组织都受到监管要求，包括数据驻留、数据安全和数据主权要求。 某些组织需要遵守多个地理位置的冲突法规。 在这种情况下，他们需要根据所有适用的法规修改其 Azure 登陆区域体系结构。
例如，可能有两个相互矛盾的法规：法规 A 和法规 B。法规 A 可能需要在国家或地区 A 中的数据驻留，而法规 B 可能需要在国家或地区 B 中的数据驻留。
此类监管冲突适用于：
跨国公司（如跨国公司或非政府组织）必须遵守其所在国家或地区的当地法规。
向多个位置的组织提供解决方案的独立软件供应商（ISV），解决方案必须遵守每个位置的本地法规。
ISV 为需要遵守其运营的每个国家或地区的当地法规的跨国组织提供解决方案。
如果只需要满足一组法规要求，请参阅 “定制 Azure 登陆区域体系结构”以满足要求。
法规注意事项
法规要求通常与数据保护、数据驻留、数据传输、隔离或人员清理相关。 这些要求在多个地理位置之间可能会发生冲突。 例如，欧盟（EU）法规可能需要在欧盟国家/地区驻留数据，而英国法规可能需要在英国进行数据驻留。
如果法规导致策略控制冲突，则必须相应地调整 Azure 登陆区域体系结构和策略分配。 有关详细信息，请参阅 本文中的“需要修改的方案”部分。
当应用多个法规时，如果满足以下条件，则无需修改 Azure 登陆区域体系结构：
多个法规需要相同的 Azure Policy 分配。
一个法规中的控制是另一个法规的超集。 超集控件会自动应用于这两个法规。
多个法规中的控制不重叠。 实现多个控制集时，单个实现涵盖所有法规。 Azure Policy 分配是互补的。
各种法规有不同的实施类型。 从监管的角度来看，你选择哪个实现并不重要。 例如，可能有两个法规具有不同的授权模型，但两个授权模型都是可以接受的。 可以选择最适合组织的实现。
提示
应尽量少分配策略和例外或豁免。
ISV 注意事项
ISV 有三种部署模型。
纯软件即服务（SaaS）：ISV 以服务的形式提供解决方案。
客户已部署：客户在自己的环境中部署解决方案。
双部署 SaaS：此模型结合了客户部署的模型和纯 SaaS 模型。
在纯 SaaS 模型中，ISV 负责代表客户管理合规性。 ISV 必须向客户证明合规性，并可能向审核员或监管机构证明合规性。 如果使用 SaaS 模型，则体系结构可能会受到多个可能冲突的法规的约束。 ISV 必须管理这些各种法规的合规性。 有关详细信息，请参阅 本文中的“需要修改的方案”部分。
在客户部署的模型中，客户负责管理合规性。 对于此模型，ISV 不需要修改登陆区域。 但是，解决方案部署在客户部署的登陆区域中，包括任何策略控制和自定义策略。
提示
ISV 可以针对特定符合性要求的策略计划来测试解决方案。 这种做法可以帮助最大程度地减少客户用来满足其合规性要求的策略冲突的可能性。
在双部署 SaaS 模型中，客户部署和纯 SaaS 模型的所有注意事项都适用。
跨国组织的注意事项
跨国组织使用各种结构来组织其 IT 治理。
分散式结构：IT 功能在每个地理位置本地管理。
集中式结构：IT 功能由集中位置（通常是组织的总部）管理。
混合结构：全局 IT 函数集中提供，而每个地理位置中仅需要本地的 IT 函数进行管理。
在分散式方案中，本地 IT 团队负责管理合规性，并且可以相应地定制其登陆区域。
在集中方案中，中心 IT 团队负责管理合规性，并确保解决方案满足跨国组织运营的所有地理位置的本地合规性要求。 各种地理位置的符合性要求可能会冲突，可能需要修改登陆区域。
在混合方案中，分散式和集中式方案的注意事项适用。 集中式组织提供本地组织在其环境中部署的解决方案。 集中式组织还测试这些解决方案是否部署在本地组织的所有登陆区域中。
需要修改的方案
如果存在分配给各种部署的冲突策略集，则可能需要修改登陆区域。 可能有多个解决方案或单个解决方案需要提供给各种地理位置或数据分类。
所需的修改量取决于监管所要求隔离程度。 监管条件越多，登陆区域就越需要修改。 例如，如果法规需要清除人员、各种标识提供者或目录、单独的管理基础结构或单独的连接基础结构等条件，则登陆区域需要进行广泛的修改。 如果法规仅要求隔离应用程序和连接基础结构，则登陆区域需要最少的修改。
Microsoft Entra 租户
建议 对大多数方案（包括跨国方案）使用单个 Microsoft Entra 租户 。 但是，在某些情况下，你可能更喜欢或需要多个 Microsoft Entra 租户，例如：
如果需要 将公司 Microsoft Entra 租户与 SaaS Microsoft Entra 租户 分开，以提高安全性，并在产品和业务运营之间创建明确的边界。
如果存在冲突的法规适用，并且你需要为不同的监管制度单独使用 Microsoft Entra 租户。 例如，法规可能具有许可和国籍要求，这些要求需要在 Microsoft Entra 租户之间 完全隔离，或者需要单独租户的数据驻留要求。 常见方案包括需要部署 SaaS 解决方案的独立实例的 ISV 或需要部署同一解决方案独立实例的跨国组织。
跨多个 Microsoft Entra 租户进行协作时，需要仔细规划重大挑战和需求。 仅创建满足操作或法规要求所需的最低 Microsoft Entra 租户数。 可以使用管理组和 Azure 基于角色的访问控制（RBAC）来管理对单个租户下的订阅和资源的访问权限，如下一部分所述。
提示
为登陆区域选择的 Microsoft Entra 租户不会影响应用程序级身份验证。 无论选择哪个租户，你仍然可以使用其他标识提供者。 对于受管制行业的公共部门客户和客户，通常在与已批准的标识提供者（如政府拥有或已认证的标识提供者）集成时提供最终用户标识。
下图显示了可用于组织 Microsoft Entra 租户的选项。
提示
如果有多个 Microsoft Entra 租户来满足法规要求，请根据地理位置而不是特定法规命名租户，例如 示例关系图中的 contoso-ops-us.com 。
有关详细信息，请参阅 Azure 登陆区域和多个 Microsoft Entra 租户 以及 Azure 登陆区域的 ISV 注意事项。
管理组
如果不需要单独的 Microsoft Entra 租户以提供严格的隔离，则应在单个 Microsoft Entra 租户中部署多个 Azure 登陆区域。 可以调整管理组层次结构，以满足冲突法规的要求。
可以为要分离的每个法规集部署完整的登陆区域体系结构。 此模型需要最少的自定义项，并使你能够利用现有自动化进行部署。
注意
此关系图不显示所有管理组。
共享平台管理组
如果法规允许，则可以共享平台管理组。 可以为需要分隔的每个法规集在登陆区域管理组下创建单独的管理组。 可以将相应的策略分配给每个应用程序管理组。 应用程序登陆区域共享平台管理组下的管理组。 应用程序管理组中的资源也可以由订阅或资源组分隔。
此管理组层次结构是一种简单且经济高效的设计，用于将应用程序与冲突法规隔离。 但是，在此设计中，用于连接、标识/安全性和管理的平台管理组必须共享相同的策略集。 如果法规对共享连接基础结构、标识服务、密钥管理服务或整个环境的基础结构施加了限制，则可能需要为每个平台管理组设置不同的策略集。
隔离标识和安全性
如果法规阻止共享标识和密钥管理基础结构，则可以划分平台管理组。 在共享平台管理组中保留用于连接和管理的管理组，并具有与每组法规关联的标识和安全管理组。
此管理组层次结构比完全共享的平台管理组要复杂得多，因为必须部分副本 (replica)平台管理组。 若要限制复杂性，可以为每个法规集和共享环境部署完整层次结构，并忽略或删除多余的管理组。
隔离连接
许多法规具有与处理和存储特定地理位置中的数据相关的要求，对用户如何连接到应用程序的要求很少。 对于这些法规，可以共享连接管理，如前面的体系结构所示。 可能没有任何法规要求在多个区域中复制基础结构，但可能需要出于延迟目的。 分配的策略需要支持在多个区域中复制基础结构。
当法规有冲突的连接要求时，可以创建一个与每组法规关联的连接管理组。 此结构类似于以前的体系结构，该体系结构将标识和安全管理组与每组法规相关联。
如果法规与连接性以及标识和安全性冲突，则可以使用以下设计。
