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