你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
根据要求定制 Azure 登陆区域体系结构
提供了多个参考实现选项作为 Azure 登陆区域指南的一部分：
- 具有 Azure 虚拟 WAN 的 Azure 登陆区域
- 具有传统中心和支路的 Azure 登陆区域
- Azure 登陆区域基础
- 面向小型企业的 Azure 登陆区域
这些选项可以通过使用在设计领域中提供 Azure 登陆区域概念体系结构和最佳做法的配置来帮助你的组织快速入门。
参考实现基于 Microsoft 团队从与客户和合作伙伴的互动中得到的最佳做法和经验。 这些知识代表了 80/20 规则的“80”。 各种实现将影响作为体系结构设计过程一部分的技术决策。
由于并非所有用例都是相同的，因此并非所有组织都可以按预期方式使用实现方法。 在确定定制要求时，需要了解这些注意事项。
Azure 登陆区域中的登陆区域原型是什么？
登陆区域原型描述了确保登陆区域（Azure 订阅）在特定范围内满足预期环境和合规性要求所需的真实情况。 示例包括：
- Azure Policy 分配。
- 基于角色的访问控制 (RBAC) 分配。
- 集中管理的资源，例如网络。
由于 Azure 中策略继承的工作方式，可将资源层次结构中的每个管理组视为对最终登陆区域原型输出的贡献。 设计较低的级别时，请考虑在资源层次结构中的较高级别应用了什么。
管理组和登陆区域原型之间有着密切的关系，但管理组本身并不是登陆区域原型， 而是构成了用于在环境中实现每个登陆区域原型的框架的一部分。
你可以在 Azure 登陆区域概念体系结构中看到这种关系。 策略分配是在中间根管理组（例如 Contoso）中创建的，用于必须应用于所有工作负载的设置。 在层次结构的较低级别创建更多策略分配，以满足更具体的要求。
管理组层次结构中的订阅位置确定了 Azure Policy 和访问控制 (IAM) 分配的结果集，这些分配将被继承、应用并强制实施到该特定登陆区域（Azure 订阅）。
可能需要更多流程和工具来确保登陆区域具有所需的集中管理资源。 示例包括：
- 用于将活动日志数据发送到 Log Analytics 工作区的诊断设置。
- Microsoft Defender for Cloud 的连续导出设置。
- 具有用于应用程序工作负载的托管 IP 地址空间的虚拟网络。
- 将虚拟网络链接到分布式拒绝服务（DDoS）网络保护。
注意
在 Azure 登陆区域参考实现中，使用具有DeployIfNotExists和Modify效果的 Azure 策略来实现上述一些资源的部署。 它们遵循策略驱动的治理设计原则。
有关详细信息，请参阅采用策略驱动的防护措施。
Azure 登陆区域概念体系结构的内置原型
概念体系结构包括应用程序工作负载（例如 corp 和 online）的示例登陆区域原型。 这些原型可能适用于你的组织并满足要求。 可以更改这些原型或创建新原型。 你的决定取决于组织的需求和要求。
提示
若要查看 Azure 登陆区域加速器中的登陆区域原型，请参阅 Azure 登陆区域加速器中的管理组。
你还可能想在资源层次结构的其他位置创建更改。 为组织实现 Azure 登陆区域规划层次结构时，请遵循设计领域中的准则。
概念体系结构中的以下登陆区域原型示例可帮助你了解其目的和预期用途：
| 登陆区域原型（管理组） | 目的或用途 |
|---|---|
| 公司 | 企业登陆区域的专用管理组。 此组适用于需要通过连接订阅中的中心与企业网络建立连接或混合连接的工作负载。 |
| 联机 | 联机登陆区域的专用管理组。 此组适用于可能需要直接 Internet 入站/出站连接的工作负载，或可能不需要虚拟网络的工作负载。 |
| 沙盒 | 仅用于组织进行测试和探索的订阅的专用管理组。 这些订阅将安全地与公司登陆区域和联机登陆区域断开连接。 沙盒还分配有限制性较小的策略集，支持测试、探索和配置 Azure 服务。 |
可能需要定制的方案
如前所述，我们在 Azure 登陆区域概念体系结构中提供了常见的登陆区域原型。 他们是 corp 和 online。 这些原型不是固定的，也不是应用程序工作负载唯一允许的登陆区域原型。 你可能需要根据需求和要求定制登陆区域原型。
在定制登陆区域原型之前，了解概念并可视化我们建议自定义的层次结构区域非常重要。 下图显示了 Azure 登陆区域概念体系结构的默认层次结构。
突出显示了层次结构的两个区域。 一个位于“登陆区域”下方，另一个位于“平台”下方。
定制应用程序登陆区域原型
请注意“登陆区域”管理组下方以蓝色突出显示的区域。 它是层次结构中最常见和最安全的位置，可添加更多原型以满足新的或更多要求，而这些要求无法通过使用现有层次结构作为更多策略分配添加到现有原型中。
例如，你要托管一组需要满足支付卡行业 (PCI) 合规性要求的应用程序工作负载。 但是，并非整个资产中的所有工作负载都要满足这项新要求。
有一种简单而安全的方法可以满足这项新要求。 在层次结构中的“登陆区域”管理组下创建一个名为 PCI 的新管理组。 可为新的 PCI 管理组分配更多策略，例如 PCI v3.2.1:2018 的 Microsoft Defender for Cloud 法规遵从性策略计划。 此操作将构建一个新原型。
现在，可将新的或现有的 Azure 订阅放入新的 PCI 管理组，使其继承所需的策略并构成新原型。
另一个示例是 Microsoft Cloud for Sovereignty，它为机密计算添加了管理组，并符合在受管制行业中使用的一致。 Microsoft云主权 为公有云采用提供适当的主权控制的工具、指导和防护措施。
提示
需要知道在与 RBAC 和 Azure Policy 相关的管理组之间移动 Azure 订阅时要考虑什么以及会发生什么。 有关详细信息，请参阅将现有 Azure 环境转换到 Azure 登陆区域概念体系结构。
定制平台登陆区域原型
你还可能想要定制“平台”管理组下方以橙色突出显示的区域。 此区域中的区域称为平台登陆区域。
例如，你可能有一个专门的 SOC 团队，他们需要自己的原型来托管其工作负载。 这些工作负载需要满足不同于“管理”管理组的 Azure Policy 和 RBAC 分配要求。
在层次结构中的“平台”管理组下创建一个新的“安全”管理组。 可为其分配所需的 Azure Policy 和 RBAC 分配。
现在，可将新的或现有的 Azure 订阅放入新的“安全”管理组，使其继承所需的策略并构成新原型。
定制的 Azure 登陆区域层次结构示例
下图显示了定制的 Azure 登陆区域层次结构。 它使用上图中的示例。
考虑的要点
在思考如何在层次结构中定制 Azure 登陆区域原型的实现时，请考虑以下几点：
并非一定要定制层次结构。 我们提供的默认原型和层次结构适用于大多数方案。
不要在原型中重新创建组织层次结构、团队或部门。
始终尝试在现有原型和层次结构上进行构建以满足新要求。
仅在真正有必要时才创建新原型。
例如，PCI 之类的新合规性要求仅适用于一部分应用程序工作负载，而不需要应用于所有工作负载。
仅在上图中突出显示的区域中创建新原型。
避免层次结构深度超过四层，以避免操作变得复杂和不必要的排除工作。 在层次结构中水平扩展而不是垂直扩展原型。
不要为开发、测试和生产等环境创建原型。
如果来自棕色环境或正在寻找在登陆区域管理组中托管订阅的方法，并采用“仅审核”强制模式的策略，请查看 方案：通过复制登陆区域管理组来转换环境