什么是 Azure 管理组？

如果你的组织有多个 Azure 订阅，则可能需要一种方法来高效地管理这些订阅的访问权限、策略和合规性。 管理组提供高于订阅级别的治理范围。 将订阅组织到管理组中时，所应用的治理规则会通过继承机制级联到所有关联的订阅。

无论你拥有哪种类型的订阅，管理组都能为你提供大规模的企业级管理。 但是，单个管理组中的所有订阅都必须信任同一个 Microsoft Entra 租户。

例如，你可以将某项策略应用于某个管理组，以限制可用于创建虚拟机 (VM) 的区域。 此策略会应用于所有嵌套的管理组、订阅和资源，从而允许在经过授权的区域中创建虚拟机。

管理组和订阅的层次结构

可以生成管理组和订阅的灵活层次结构，以便将资源组织成用于统一策略和访问管理的层次结构。 下图显示了使用管理组创建用于治理的层次结构的示例。

例如，可以创建应用策略的层次结构，以将虚拟机位置限制为名为 Corp 的管理组中的“中国东部”区域。此策略会继承作为该管理组后代的所有企业协议 (EA) 订阅，并应用于这些订阅下的所有虚拟机。 资源或订阅所有者无法更改此安全策略，以便改进治理。

使用管理组的另一个场景是向用户提供对多个订阅的访问权限。 通过将多个订阅移到同一管理组下，即可在该管理组上创建一个 Azure 角色分配。 该角色继承对该所有订阅的访问权限。 在管理组上进行一次分配，就能使用户获得所需的一切访问权限，而无需针对不同订阅编写 Azure 基于角色的访问控制 (RBAC) 脚本。

场景比较

*：将策略应用于某个范围时，强制措施将应用于范围中的所有成员。 例如，在资源组上，它仅适用于其下的资源。

**：标记可以跨范围应用，并单独添加到资源。 Azure Policy 具有有助于管理标记的内置策略。

：Azure 标记可用作 Azure Policy 中的条件，以将策略应用于某些资源。 Azure 标签有一定的限制。

关于管理组的重要事实

• 单个目录可以支持 10,000 个管理组。

• 一个管理组树最多可支持六个级别的深度。

  此限制不包括根级别或订阅级别。

• 每个管理组和订阅只能支持一个父项。

• 每个管理组可以有多个子级。

• 所有订阅和管理组都在每个目录中的单个层次结构内。 有关详细信息，请参阅本文后面的有关根管理组的重要事实。

每个目录的根管理组

每个目录都有一个名为根管理组的顶级管理组。 根管理组内置于层级结构中，使所有管理组和订阅都归属于它。

根管理组允许在目录级别应用全局策略和 Azure 角色分配。 最初，提升访问权限以管理所有 Azure 订阅和管理组，从而获得该根组的用户访问管理员角色。 租户管理员提升访问权限后，管理员可将任何 Azure 角色分配给其他目录用户或组，以便管理层次结构。 作为管理员，你可以将自己的帐户分配为根管理组的所有者。

关于根管理组的重要信息

• 默认情况下，根管理组的显示名称为“租户根组”，它作为管理组自我运行。 此 ID 与 Microsoft Entra 租户 ID 的值相同。
• 若要更改显示名称，账户必须在根管理组中具有“所有者”或“参与者”角色。 有关详细信息，请参阅更改管理组的名称。
• 无法像操作其他管理组一样移动或删除根管理组。
• 所有订阅和管理组归并到目录中的一个根管理组中。
  • 目录中的所有资源归并到根管理组进行全局管理。
  • 新订阅在创建时自动默认为根管理组。
• 所有 Azure 客户都可查看根管理组，但并非所有客户都具有管理该根管理组的权限。
  • 有权访问订阅的每个人都可看到订阅位于层次结构中的位置的上下文。
  • 没有人对根管理组具有默认访问权限。 Microsoft Entra 全局管理员是唯一可以提升自身权限以获取访问权限的用户。 拥有根管理组的访问权限后，他们可以向其他用户分配任何 Azure 角色来管理该组。

管理组的初始设置

任何用户都需在开始使用管理组时进行初始设置。 第一步是在目录中创建根管理组。 目录中的所有现有订阅随后都会成为根管理组的子项。

执行此过程是为了确保一个目录中只有一个管理组层次结构。 目录中的单个层次结构可让管理客户应用目录内其他客户无法绕开的全局访问权限和策略。

根上分配的任何内容都适用于整个层次结构。 也就是说，它适用于该 Microsoft Entra 租户中的所有管理组、订阅、资源组和资源。

管理组访问权限

Azure 管理组支持使用 Azure RBAC 来访问所有资源和定义角色。 层次结构中存在的子资源会继承这些权限。 可将任何 Azure 角色分配到管理组，该角色会继承资源的层次结构。

例如，可以将 Azure 角色“虚拟机参与者”分配给管理组。 此角色对管理组本身不具有任何操作权限，但其权限会继承到该管理组下的所有虚拟机。

下图列出了管理组的角色和支持的操作。

*：这些角色允许用户仅对管理组范围执行指定的操作。

**：将订阅或管理组移入根管理组或将其移出根管理组，无需根管理组上的角色分配。

迁移订阅和管理组

移动订阅和管理组时，需要应用不同的角色分配。 若要移动子订阅或管理组，需要以下权限：

• 正在移动的子订阅或管理组
  • Microsoft.management/managementgroups/write
  • Microsoft.management/managementgroups/subscriptions/write（仅适用于订阅）
  • Microsoft.Authorization/roleAssignments/write
  • Microsoft.Authorization/roleAssignments/delete
  • Microsoft.Management/register/action
• 目标父级管理组
  • Microsoft.management/managementgroups/write
• 当前的父级管理组
  • Microsoft.management/managementgroups/write

有关在层次结构中移动项目的详细信息，请参阅使用管理组管理资源。

Azure 自定义角色定义和分配

可以在 Azure 自定义角色定义中将管理组定义为可分配范围。 可在该管理组及其下的任何管理组、订阅、资源组或资源中分配 Azure 自定义角色。 自定义角色会继承层次结构，就像任何内置角色一样。

有关自定义角色和管理组的限制的信息，请参阅本文后面的限制。

示例定义

在包括管理组后，定义和创建自定义角色的操作不变。 使用完整路径定义管理组：/providers/Microsoft.Management/managementgroups/{_groupId_}。

使用管理组的 ID，而不是管理组的显示名称。 发生此常见错误是因为在创建管理组时二者都是自定义字段。

...
{
  "Name": "MG Test Custom Role",
  "Id": "id",
  "IsCustom": true,
  "Description": "This role provides members understand custom roles.",
  "Actions": [
    "Microsoft.Management/managementGroups/delete",
    "Microsoft.Management/managementGroups/read",
    "Microsoft.Management/managementGroups/write",
    "Microsoft.Management/managementGroups/subscriptions/delete",
    "Microsoft.Management/managementGroups/subscriptions/write",
    "Microsoft.resources/subscriptions/read",
    "Microsoft.Authorization/policyAssignments/*",
    "Microsoft.Authorization/policyDefinitions/*",
    "Microsoft.Authorization/policySetDefinitions/*",
    "Microsoft.PolicyInsights/*",
    "Microsoft.Authorization/roleAssignments/*",
    "Microsoft.Authorization/roledefinitions/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
        "/providers/microsoft.management/managementGroups/ContosoCorporate"
  ]
}
...

破坏角色定义和分配层次结构路径的问题

角色定义是在管理组层次结构中的任何位置都可分配的范围。 角色定义可以定义在父管理组中，而实际的角色分配则存在于子订阅中。 由于两个项之间存在某种关系，因此尝试将分配与其定义分离时，会看到错误。

例如，请考虑层次结构的一个小部分的以下示例。

假设在沙盒管理组上定义了一个自定义角色。 然后，该自定义角色会分配到两个沙盒订阅上。

如果尝试将其中一个订阅移动到 Corp 管理组的子级，则会断开从订阅角色分配到沙盒管理组角色定义的路径。 在这种情况下，会收到一条错误，指出系统不允许该移动，因为它会破坏此关系。

若要修复此方案，可以使用以下选项：

• 在将订阅移到新的父管理组之前，从订阅中删除角色分配。
• 将订阅添加到角色定义的可分配范围。
• 在角色定义中更改可分配范围。 在此示例中，你可以将可分配范围从“沙盒管理组”更新为“根管理组”，这样，层次结构的两个分支就都可以访问定义。
• 另外创建一个在其他分支中定义的自定义角色。 采用此新角色时，还需要您更改订阅的角色。

限制

在管理组上使用自定义角色存在限制：

• 在新角色的可分配范围中，只能定义一个管理组。 设置此限制是为了减少出现角色定义和角色分配不关联的情况的次数。 将进行了角色分配的订阅或管理组移到另一个没有该角色定义的父项时，会出现这种情况。
• 无法在管理组范围内分配具有 DataActions 的自定义角色。 有关详细信息，请参阅自定义角色限制。
• Azure 资源管理器不验证管理组是否存在于角色定义的可分配范围中。 即使存在拼写错误或者管理组 ID 不正确，仍会创建角色定义。

移动管理组和订阅

若要将管理组或订阅移动为另一个管理组的子项，需要：

• 管理组写入权限，以及对子订阅或子管理组的角色分配写入权限。
  • 内置角色示例：所有者
• 目标父管理组中的管理组写入访问权限。
  • 内置角色示例：所有者、参与者、管理组参与者
• 现有父管理组中的管理组写入访问权限。
  • 内置角色示例：所有者、参与者、管理组参与者

存在例外：如果目标或现有父管理组是根管理组，则权限要求不适用。 由于根管理组是所有新管理组和订阅的默认登陆点，因此不需其上的权限即可移动项。

如果订阅上的“所有者”角色继承自当前管理组，则你的移动目标会受限。 你只能将订阅移动到另一个你在其中具有“所有者”角色的管理组。 你不能将订阅移动到你在其中仅具有“参与者”角色的管理组，因为你会失去该订阅的所有权。 如果你已被直接分配了订阅的“所有者”角色，则可将它移到你在其中具有参与者角色的任何管理组。

使用活动日志审核管理组

Azure Monitor 活动日志支持管理组。 可查询发生在与其他 Azure 资源位于相同中心位置的管理组上的所有事件。 例如，可以看到对特定管理组所做的所有角色分配或策略分配更改。

如果要在 Azure 门户之外针对管理组进行查询，管理组的目标作用域如下："/providers/Microsoft.Management/managementGroups/{management-group-id}"

相关内容

若要了解有关管理组的详细信息，请参阅：

• 创建管理组来组织 Azure 资源
• 更改、删除或管理管理组
• 保护资源层次结构