你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
本文介绍了云平台团队如何实施防护措施来管理 Azure 登陆区域中的应用程序环境。 它还介绍了如何将各种应用程序开发环境与其框架保持一致。 创建适当的环境的关键方面是将订阅放置在适当的管理组中。
奠定基础
开发团队需要能够快速迭代，云治理和平台团队需要大规模管理组织风险、合规性和安全性。 可以通过关注两个关键 的 Azure 登陆区域设计原则（策略驱动的治理和订阅民主化）来正确管理应用程序环境。 这些原则提供基本防护措施，并描述如何将控件委托给应用程序团队。 应用程序团队使用 Azure Well-Architected 框架指南 来设计其工作负荷。 他们部署和管理自己的登陆区域资源，平台团队通过分配 Azure 策略来控制资源。
为 半治理 资源提供沙盒资源非常重要，因此应用程序团队可以试验技术和功能。
当应用程序所有者使用 订阅出售或其他订阅 创建过程时，他们必须知道如何为多个开发环境请求订阅。
本文介绍 Azure 登陆区域，包括管理组、策略和共享平台体系结构，以及工作负荷或应用程序登陆区域。
注释
本文中的指南仅适用于工作负荷或应用程序的降落区域。 有关 Azure 登陆区域平台本身的测试和环境隔离，请参阅 Azure 登陆区域的测试方法，其中描述了 Canary 方法。
在实践中，可以使用任意数量和类型的分阶段环境。 本文引用了以下分阶段环境。
| 环境 | DESCRIPTION | 管理组 |
|---|---|---|
| 沙盒 | 用于快速创新原型的环境，但不适用于生产绑定配置。 | 沙盒管理组 |
| 发展 | 用于生成潜在发布候选项的环境 | 典型管理组，例如 公司 或 在线 |
| 测试 | 用于执行测试的环境，包括单元测试、用户验收测试和质量保证测试 | 典型管理组，例如 公司 或 在线 |
| 生产 | 用于向客户提供价值的环境 | 典型管理组，例如 公司 或 在线 |
有关详细信息，请参阅视频 处理应用程序工作负荷的开发、测试和生产环境 以及 在 Azure 中应使用多少个订阅？
环境、订阅和管理组
作为本部分的先决条件，请参阅 资源组织设计区域。
采用 Azure 登陆区域做法时，必须正确组织订阅。 理想情况下，每个应用程序环境都应有自己的订阅。 此方法提供使环境保持隔离的安全和策略控制。 它包含对一个环境的潜在问题。
不同的订阅在典型类型级别具有相同的策略。 如果需要，应用程序所有者可以分配特定于订阅的策略，以强制实施特定于应用程序和环境的行为。
某些应用程序体系结构要求服务在环境之间共享。 如果是这种情况，则可以对多个环境使用单个订阅。 我们建议工作负荷所有者与云平台团队协作，以确定是否需要多个环境的单个订阅。
在以下的情况下，对多个应用程序环境使用单个订阅：
环境不能在各自的订阅中隔离。
环境中分配了相同的团队，负责功能角色，例如网络管理员。
这些环境可以使用相同的策略。
如果应用程序或服务工作负荷需要位于单个订阅中，并且需要对应用于每个环境的策略进行更改，则可以：
在登陆区域管理组下创建新的 原型对齐 管理组。 有关详细信息，请参阅本文中的 管理组层次结构 。
将沙盒订阅用于开发活动。 沙盒具有限制较少的策略集。
使用在订阅级别应用的策略，而不是管理组级别。 可以在策略定义中添加标记，以帮助筛选策略并将其应用于正确的环境。 还可以将策略分配给特定资源组或将其排除在特定的资源组中。
可以在订阅创建过程中分配策略，作为 订阅售货的一部分。
对于为帮助控制成本而实现的策略，请在所需的订阅级别应用策略定义。 或者，可以让登陆区域所有者负责成本，从而提供真正的自主性。 有关详细信息，请参阅 平台自动化和 DevOps。
警告
与管理组级别的策略和控制不同，具有提升订阅权限的个人可以更改基于订阅的策略和标记。 具有适当角色的管理员可以通过排除策略、修改策略或更改资源上的标记来绕过这些控制。
因此，不应在以安全为中心的策略的定义中应用标记。 此外，不要将以下操作的权限设置为始终激活：
Microsoft.Authorization/policyAssignments/*Microsoft.Authorization/policyDefinitions/*Microsoft.Authorization/policyExemptions/*Microsoft.Authorization/policySetDefinitions/*
可以使用 Privileged Identity Management（PIM）来控制这些操作。
管理组层次结构
避免复杂的管理组层次结构。 它们可能需要频繁的修改、无法有效扩展，并且缺乏价值。 为避免这些潜在问题，Azure 登陆区域管理组与工作负荷原型保持一致。 有关详细信息，请参阅 管理组和订阅组织。
原型对齐 意味着仅针对特定工作负荷原型创建管理组。 例如，在概念体系结构中，登陆区域管理组具有公司和在线子管理组。 这些子管理组与所持有的工作负荷的不同原型模式相一致。 子管理组侧重于混合连接（VPN/Azure ExpressRoute）要求，例如仅限内部与面向公众的应用程序和服务。
不包括沙盒环境，各种应用程序环境应使用相同的原型进行部署。 即使环境分布在多个订阅中，它们也会根据管理组原型和需求被纳入同一个管理组（企业 或 在线）。
可以将 沙盒订阅 用于非结构化开发，例如个人实验室或没有原型的工作负荷。 应用程序或服务工作负荷团队使用沙盒管理组测试各种 Azure 服务，以确定最适合其要求的内容。 在确定服务后，他们可以为团队配置着陆区（在着陆区管理组层次结构中与工作负荷原型正确对齐的管理组中）。
沙盒环境可用于特定应用程序，或者工作负荷团队可以使用它们进行试验。
有关详细信息，请参见:
基于环境的管理组挑战
原型中的环境的管理组可以增加管理开销，并提供最小的价值。
登陆区域管理组应具有通用策略，用于为公司组和联机子管理组实施防护措施。 Corp 和 Online 具有独特的策略，这些策略强制实施与面向公众和专用的工作负载相关的公司准则。
许多组织为工作负荷软件开发生命周期（SDLC）环境创建单独的管理组来分配环境策略和控制。 实际上，此方法为工作负荷团队带来的挑战比它解决的要多。 SDLC 环境不应具有不同的策略，因此不建议单独管理组。
应用程序所有者可以更改工作负荷的拓扑或资源配置，使其与它通过升级的多个 SDLC 环境中的策略保持一致。 此方法会增加风险。 特定于每个环境的规则可能会导致开发人员和质量保证团队的开发体验不佳。 如果应用程序有一组在某个环境中运行的防护策略，而在后期的升级周期中适用于另一组策略，则可能会出现问题。 如果控件发生更改，可能需要调整应用程序。
若要防止此额外工作，请在 SDLC 环境中在整个代码提升过程中创建一致的策略。 不应为每个环境创建策略，而是为所有开发环境（不包括沙盒环境）提供一致的集。
例如，假设组织定义了一个策略，该策略要求使用特定的防火墙规则来配置存储帐户，以防止来自公用网络的入口。 相反，存储帐户使用 Azure 登陆区域网络内的专用终结点进行通信。 如果开发环境没有此类策略，则测试工作负荷找不到允许公共访问的存储帐户的错误配置。 测试部署在开发环境中运行，并对其进行迭代。 将解决方案提升到具有存储帐户策略的另一个环境时，部署会因为强制执行的策略而失败。
因此，应用程序开发团队必须在已经投入大量精力后重新修改他们的部署和架构。 此示例演示了不同环境中的不同策略如何创建问题。
注释
以下公式演示了为什么每个环境或工作负荷的单独管理组无法很好地缩放： N 工作负荷 x Z 管理组 = 总管理组。
如果一个组织有 30 个工作负荷，每个工作负荷都需要一个管理组和一个子管理组来用于开发、测试和生产环境，那么该组织将会剩下：
N = 工作负荷/应用数 = 30
Z = 工作负荷和环境的管理组数 （1 个用于工作负荷 + 3 的环境） = 4
N （30） x Z （4） = 120 个管理组总数
应用程序所有者可能需要策略以不同的方式应用于多个环境。 例如，应用程序所有者可能需要对生产环境进行备份配置，但对于其他环境则不需要备份配置。
某些策略可以作为管理组级别的审核策略启用。 应用程序团队确定如何实现控件。 此方法不会阻止部署，但它会创建感知，并使应用程序团队能够管理其独特的需求。 然后，他们可以创建子级策略，或将这些要求合并到基础结构即代码（IaC）部署模块中。
在此共同责任模型中，平台团队审核实践，应用程序团队管理实现。 此模型可以提高部署的灵活性。
平台作员必须与每个应用程序或服务工作负荷团队（登陆区域所有者）合作，以了解其要求。 平台作员可以根据应用程序要求和计划提供订阅。 平台作员还可以决定为各种类型的工作负荷指定 生产线 ，以便他们可以根据应用程序或服务工作负荷团队的常见要求生成订阅创建过程和工具。
方案：基于虚拟机（VM）的工作负荷
Azure 登陆区域中的早期工作负荷通常由 Azure VM 组成。 可以在 Azure 中部署这些工作负荷，或者从现有数据中心迁移这些工作负荷。
无需将 VM 部署到单个订阅中的多个环境，可以：
为每个应用程序环境建立订阅，并将其全部置于同一原型管理组中。
为相应订阅中的每个应用程序环境部署虚拟网络。 可以根据应用程序环境的大小确定虚拟网络大小。
将虚拟机部署到相应的订阅。 如果适用，VM 可以为每个环境使用不同的 SKU 和不同的可用性配置。
各种应用程序环境资源受不同的访问控制保护。 因此，当应用程序开发人员设置部署管道时，每个管道的标识可以限制为环境。 此配置有助于保护环境免受意外部署。
场景：Azure 应用服务
使用应用服务的环境订阅的工作负载可能会带来挑战。 对于应用程序开发人员， 应用服务最佳做法 是使用 部署槽 位来帮助管理 Web 应用的更改和更新。
但是，此功能只能与应用服务计划中的应用一起使用，该应用只能存在于单个订阅中。 如果平台作员要求应用程序所有者对开发、测试和生产环境使用单独的订阅，则应用程序部署生命周期可能更难管理。
对于此示例，最佳选项是应用程序或服务工作负荷的单个订阅。 应用程序所有者可以在资源组级别将 Azure 基于角色的访问控制 （RBAC）与 PIM 配合使用，以提高安全性。