📚 课程目录第2章 Azure企业级租户与订阅治理设计

2. Azure企业级租户与订阅治理设计

当企业从单订阅试验走向生产环境时，最先暴露的问题往往不是技术能力不足，而是治理结构缺失：资源散落在多个订阅中、权限靠个人账号直接授予、合规要求无法统一落地。Azure的企业级治理并非某个单独服务，而是由Azure AD租户、管理组、订阅、资源组、RBAC角色、Azure Policy六层对象共同构成的层级体系。理解它们之间的包含与继承关系，是设计多订阅治理框架的前提。

一、租户：治理的信任边界

Azure AD租户（现称Microsoft Entra ID租户）是身份与信任的最终边界。一个租户内所有用户、组、服务主体共享同一套身份目录，跨租户访问必须通过B2B协作或跨租户同步显式建立。企业规划时通常面临两种选择：

单租户模式：全集团共用一个租户，管理简单、策略统一，适合大多数企业；
多租户模式：按业务集团、合规区域或并购实体拆分租户，隔离性强，但跨租户治理成本显著上升。

对于绝大多数企业，推荐单一生产租户 + 独立沙箱租户的组合：生产租户承载全部正式业务，沙箱租户用于试验新功能、验证策略变更，避免试验性操作污染生产目录。租户一旦创建，其默认域名（如 contoso.onmicrosoft.com）不可更改，因此命名应在创建前确定，例如采用 contoso-prod 与 contoso-sandbox 的区分方式。

二、管理组与订阅层级：策略与权限的继承骨架

管理组（Management Group）是订阅之上的容器，最多支持六层嵌套。它的核心价值在于：在管理组上分配的RBAC角色和Azure Policy会被其下所有订阅、资源组、资源继承。这意味着企业不必在每个订阅重复配置，只需在合适的层级定义一次。

一个典型的多订阅企业治理框架可按“根管理组 → 业务线 → 环境 → 订阅”组织。例如：

Tenant Root Group
├── Platform（平台）
│   ├── Identity（标识订阅）
│   ├── Connectivity（网络枢纽订阅）
│   └── Management（日志与监控订阅）
├── Landing Zones（业务着陆区）
│   ├── Prod
│   │   ├── Sub-Finance-Prod
│   │   └── Sub-Retail-Prod
│   └── NonProd
│       ├── Sub-Finance-Dev
│       └── Sub-Retail-Test
└── Sandbox（沙箱）
    └── Sub-Experiment-01

这种结构的判断依据是：平台订阅与业务订阅的合规要求不同。平台层需要允许网络对等、DNS等特殊操作，而业务层应严格限制公网暴露。若把两者混在同一管理组下，策略将难以差异化。因此建议在根管理组下先按“平台/业务/沙箱”三分，再在业务线下按环境细分。

订阅本身是计费、配额与安全边界。设计时应遵循“一订阅一用途”原则，避免把生产与非生产资源混在同一订阅。订阅数量并非越多越好：每个订阅都有默认配额（如vCPU、公共IP数量），过度拆分会导致配额碎片化和管理开销上升。经验上，单个业务系统的生产环境使用1个订阅，非生产环境可合并到1个共享订阅，但需通过资源组和标签区分。

三、RBAC角色分配：最小权限的落地方式

RBAC的核心原则是在尽可能高的层级分配角色，在尽可能低的层级授予权限。具体做法是：

在管理组层级，为平台团队分配Contributor或自定义角色，使其能管理所有订阅的基础资源；
在订阅层级，为业务团队分配Reader或Resource Policy Contributor，使其能查看资源但不能修改网络与安全配置；
在资源组层级，为应用团队分配Contributor，限定其只能操作本应用资源；
对需要临时提权的场景，使用PIM（Privileged Identity Management）按需激活，而非永久授予Owner。

需要特别注意的是，Owner角色包含管理权限分配的能力，不应作为日常运维角色。生产环境中，Owner应仅保留给订阅级紧急恢复账号，并通过PIM审批流程控制激活时长（例如最长4小时）。

四、Azure Policy与合规基线

Azure Policy用于定义并强制执行资源属性规则，其效果（Effect）决定了不合规资源的处理方式：Deny阻止创建、Audit仅记录、Append自动补充属性、DeployIfNotExists自动部署缺失配置。企业合规基线通常从以下三类策略入手：

位置限制：只允许在指定区域（如China East 2、China North 3）创建资源，满足数据驻留要求；
标签强制：要求所有资源必须携带CostCenter、Environment、Owner标签，否则拒绝创建；
安全基线：禁止公网IP、强制存储账户启用HTTPS、要求虚拟机启用磁盘加密。

策略分配时，建议先在沙箱管理组以Audit模式运行，观察合规报告，确认不会误伤正常业务后，再切换到Deny并推广到生产管理组。Azure Policy的内置计划（Initiative）如Azure Security Benchmark可直接分配，也可复制后裁剪，避免一次性引入过多规则导致业务中断。

实战建议：治理框架不是一次性设计完成的。建议按“先结构、后策略、再细化”的顺序推进：第一步建立管理组与订阅层级，第二步在管理组上分配基础RBAC与审计策略，第三步根据合规报告逐步收紧为拒绝策略。每次策略变更前，先在沙箱租户验证，再通过管理组继承推广到生产环境。

五、治理框架的验证与迭代

框架落地后，可通过以下方式验证其有效性：在业务订阅中尝试创建不符合位置策略的资源，应被Deny拒绝；以业务团队成员身份登录，应只能看到被授权的资源组；在Azure Policy的合规仪表板中，应能看到各管理组的合规率与不合规资源清单。若发现某订阅长期存在大量不合规资源，说明策略分配层级或效果设置需要调整，而非简单追加更多规则。

最终，一个可运行的企业治理框架应达到三个状态：权限可继承、策略可继承、合规可度量。租户提供信任边界，管理组提供继承骨架，订阅提供隔离与计费单元，RBAC控制“谁能做什么”，Azure Policy控制“能做成什么样”。五者协同，才能支撑生产环境在多订阅规模下的安全与合规运行。