1. Azure身份治理全景

在Azure中做权限治理，第一件必须搞清楚的事不是“怎么分配角色”，而是“权限到底作用在什么边界上”。很多团队在项目初期把用户直接加到订阅的“所有者”角色，短期看似方便，等到资源变多、人员流动、合规审计时才发现无法收拾。根源往往在于没有分清四个核心对象：租户（Tenant）、Entra ID、管理组（Management Group）和订阅（Subscription）。它们不是并列关系，而是一条从身份到资源的层层嵌套链。

一、租户与Entra ID：身份的唯一权威源

租户是Azure AD（现称Microsoft Entra ID）中的一个独立目录实例，它拥有全球唯一的租户ID（GUID）和默认域名，例如 contoso.onmicrosoft.com。一个组织通常只拥有一个租户，租户就是这家组织在云上的“身份户口本”。Entra ID则是这个租户里承载用户、组、服务主体、应用注册、设备等身份对象的技术服务。可以这样理解：租户是边界，Entra ID是边界内的身份系统。

关键点在于：Entra ID中的身份对象是全局的，但它们的权限作用范围由后续的资源层级决定。一个用户被创建在租户里，并不意味着他能访问任何订阅；他能否访问、以什么角色访问，取决于订阅、管理组或资源上是否给他分配了RBAC角色。因此，身份治理的第一条原则是：身份在Entra ID中集中管理，权限在资源层级上按需授予。

二、管理组：订阅之上的治理容器

当组织拥有多个订阅时，逐个订阅分配权限会迅速失控。管理组就是为解决这个问题而设计的容器，它可以包含订阅、其他管理组，形成一棵最多六层深的层级树（不含根管理组）。根管理组由系统自动创建，所有订阅和管理组最终都挂在它下面。

管理组本身不承载资源，它只承载策略（Azure Policy）和访问控制（RBAC）。例如，把“禁止创建公网IP”的策略分配到“生产”管理组，其下所有订阅自动继承；把“安全审计员”角色分配给某用户到“生产”管理组，该用户就能读取其下所有订阅的资源，而无需逐订阅授权。这就是管理组的核心价值：一次定义，向下继承。

三、订阅：资源与计费的边界

订阅是资源部署、计费和安全隔离的实际单元。每个订阅只能属于一个管理组，但可以包含任意数量的资源组和资源。订阅有三个关键属性：

• 资源边界：所有资源必须属于某个订阅，跨订阅访问需要显式授权。
• 计费边界：账单、配额、成本管理都以订阅为单位。
• RBAC作用域：角色分配可以作用在订阅、资源组或单个资源上。

订阅与管理组的关系是“多对一”：多个订阅可以挂到同一个管理组下，但一个订阅在某一时刻只能属于一个管理组。这个约束决定了治理树的结构必须提前规划，不能随意挂载。

四、四层关系全景与继承逻辑

把上述对象串起来，就得到Azure身份治理的完整作用链：租户 → Entra ID身份 → 管理组 → 订阅 → 资源组 → 资源。权限和策略从上层向下层继承，下层可以追加更细粒度的授权，但不能“取消”上层继承来的允许权限（除非使用拒绝分配，但拒绝分配本身也有其适用限制）。

下面这张图展示了企业身份与资源边界的实际结构，包含一个租户、两个管理组分支、三个订阅以及身份对象如何通过角色分配作用到不同层级。

五、继承与作用域：权限到底在哪里生效

理解这张图后，可以推导出三条实用规则：

1. 角色分配的作用域决定权限范围。在管理组上分配“读者”，用户能读取该管理组下所有订阅的资源；在订阅上分配“参与者”，用户只能操作该订阅内的资源。
2. 策略继承不可逆。上层管理组分配的“拒绝”策略会强制作用于下层，下层无法覆盖。因此生产管理组通常先挂“禁止公网IP”“强制标签”等策略，再挂订阅。
3. 订阅只能属于一个管理组。如果规划时把订阅挂错分支，迁移管理组需要重新评估策略和角色继承，成本较高。

六、一个可参考的治理结构示例

假设某企业有生产、非生产两套环境，共三个订阅。推荐结构如下：