你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

什么是 Azure 管理组?

如果你的组织有多个 Azure 订阅,则可能需要一种方法来高效地管理这些订阅的访问权限、策略和符合性。 管理组提供了订阅上方的治理范围。 你将订阅组织到管理组中,你应用的治理条件会按继承关系级联到所有相关的订阅。

无论你可能具有什么类型的订阅,管理组都将提供大规模企业级管理。 但是,某一个管理组中的所有订阅都必须信任同一个 Azure Active Directory (Azure AD) 租户。

例如,可将策略应用到限制创建虚拟机 (VM) 的区域的管理组。 此策略将应用于所有嵌套的管理组、订阅和资源,并且只允许在经过授权的区域中创建 VM。

管理组和订阅的层次结构

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

示例管理组层次结构的图。

同时包含管理组和订阅的根管理组的图。 有些子管理组包含管理组,有些包含订阅,而有些两者均包含。 示例层次结构中的一个示例是四个级别的管理组,其中子级别为所有订阅。

例如,可以创建应用策略的层次结构,用它将 VM 位置限为名为“Corp”的管理组中的“美国西部”区域。 此策略将继承作为该管理组后代的所有企业协议 (EA) 订阅,并将应用于这些订阅下的所有 VM。 此安全策略不能由资源或订阅所有者更改,因此增强了治理效果。

注意

Microsoft 客户协议 (MCA) 订阅的成本管理功能当前不支持管理组。

使用管理组的另一个场景是向用户提供对多个订阅的访问权限。 通过移动该管理组下的多个订阅,可对该管理组创建一个 Azure 角色分配,该分配将这种访问权限继承到所有订阅。 管理组的一个分配就能让用户访问所需的一切内容,而无需基于不同订阅编写 Azure RBAC 的脚本。

关于管理组的重要事实

  • 在单个目录中可以支持 10,000 个管理组。
  • 一个管理组树最多可支持六个级别的深度。
    • 此限制不包括根级别或订阅级别。
  • 每个管理组和订阅只能支持一个父级。
  • 每个管理组可以有多个子级。
  • 所有订阅和管理组都在每个目录中的单个层次结构内。 请参阅关于根管理组的重要事实

每个目录的根管理组

为每个目录指定了一个称为根管理组的顶级管理组。 此根管理组内置在层次结构中,包含其所有下级管理组和订阅。 此根管理组允许在目录级别应用全局策略和 Azure 角色分配。 一开始的时候,Azure AD 全局管理员需要提升自身权限才能成为此根组的用户访问管理员角色。 提升访问权限后,管理员可将任何 Azure 角色分配给其他目录用户或组,以便管理层次结构。 作为管理员,你可以将自己的帐户分配为根管理组的所有者。

关于根管理组的重要事实

  • 默认情况下,根管理组的显示名称为“租户根组”,它作为管理组自我运行。 ID 值与 Azure Active Directory (Azure AD) 租户 ID 相同。
  • 若要更改显示名称,必须在根管理组中为帐户分配“所有者”或“参与者”角色。 请参阅更改管理组名称,了解如何更新管理组的名称。
  • 无法像操作其他管理组一样移动或删除根管理组。
  • 所有订阅和管理组归并到目录中的一个根管理组中。
    • 目录中的所有资源归并到根管理组进行全局管理。
    • 新订阅在创建时自动默认为根管理组。
  • 所有 Azure 客户都可查看根管理组,但并非所有客户都具有管理该根管理组的权限。
    • 有权访问订阅的每个人都可看到订阅位于层次结构中的位置的上下文。
    • 未对任何人授予对根管理组的默认访问权限。 只有 Azure AD 全局管理员可将自身提升为拥有访问权限的角色。 拥有根管理组的访问权限后,全局管理员便可向要管理它的其他用户分配任何 Azure 角色。

重要

对根管理组进行的任何用户访问权限或策略分配都适用于在目录中的所有资源。 因此,所有客户都应评估在此作用域中定义项目的需求。 用户访问权限和策略分配应仅在此作用域内“必须拥有”。

管理组的初始设置

任何用户都需在开始使用管理组时进行初始设置。 第一步是在目录中创建根管理组。 创建此组后,目录中存在的所有现有订阅都成为根管理组的子级。 执行此过程是为了确保一个目录中只有一个管理组层次结构。 目录中的单个层次结构可让管理客户应用目录内其他客户无法绕开的全局访问权限和策略。 在根上分配的任何内容都将应用于整个层次结构,其中包括该 Azure AD 租户中的所有管理组、订阅、资源组和资源。

访问管理组

Azure 管理组支持使用 Azure 基于角色的访问控制 (Azure RBAC) 来访问所有资源和定义角色。 层次结构中的子资源继承这些权限。 可将任何 Azure 角色分配到管理组,该角色将继承资源的层次结构。 例如,可以向管理组分配 Azure 角色 VM 参与者。 此角色不会对管理组执行任何操作,但将继承该管理组下的所有 VM。

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

Azure 角色名称 创建 重命名 移动** 删除 分配访问权限 分配策略 读取
“所有者” X X X X X X X
参与者 X X X X X
MG 参与者* X X X X X
读取器 X
MG 读取者* X
资源策略参与者 X
用户访问管理员 X X

*:“管理组参与者”和“管理组读取者”角色只允许用户在管理组范围执行这些操作。

**:将订阅或管理组移入/移出层次结构不一定需要根管理组上的角色分配。

请参阅使用管理组管理资源了解有关将项目移到层次结构中的详细信息。

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/managementgroup/write",
    "Microsoft.Management/managementgroup/subscriptions/delete",
    "Microsoft.Management/managementgroup/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 和 Online 的子管理组,而沙盒管理组有两个子订阅。

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

如果我们尝试移动这些将要成为 Corp 管理组子项的订阅之一,则会断开从订阅角色分配到沙盒管理组角色定义的路径。 在这种情况下,会出现一条错误,指出系统不允许该移动,因为它会破坏此关系。

若要修复此情况下的问题,可以使用多个不同的选项:

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

限制

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

  • 在新角色的可分配范围中,只能定义一个管理组。 设置此限制是为了减少出现角色定义和角色分配不关联的情况的次数。 将进行了角色分配的订阅或管理组移到另一个没有该角色定义的父项时,会出现此情况。
  • 不能在管理组自定义角色中定义资源提供程序数据平面操作。 存在此限制是因为,在更新数据平面资源提供程序时存在延迟问题。 我们会解决此延迟问题,并会在角色定义中禁用这些操作以降低风险。
  • Azure 资源管理器不验证管理组是否存在于角色定义的可分配范围中。 即使存在拼写错误或者列出的管理组 ID 不正确,仍会创建角色定义。

移动管理组和订阅

若要将管理组或订阅移动为另一个管理组的子项,三项规则的计算结果都需要为 true。

如果执行移动操作,你需要:

  • 在子订阅或管理组上的管理组写入权限和角色分配写入权限。
    • 内置角色示例:所有者
  • 目标父管理组中的管理组写入访问权限。
    • 内置角色示例:所有者参与者管理组参与者
  • 现有父管理组中的管理组写入访问权限。
    • 内置角色示例:所有者参与者管理组参与者

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

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

重要

Azure 资源管理器可以将管理组层次结构详细信息缓存最多 30 分钟。 因此,移动管理组可能不会立即反映在 Azure 门户中。

使用活动日志审核管理组

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

与所选管理组相关的活动日志和操作的屏幕截图。

如果要在 Azure 门户外针对管理组进行查询,管理组的目标范围将如下所示:“/providers/Microsoft.Management/managementGroups/{management-group-id}”。

注意

使用 Azure 资源管理器 REST API,可以在管理组上启用诊断设置,以将相关的 Azure 活动日志条目发送到 Log Analytics 工作区、Azure 存储或 Azure 事件中心。 有关详细信息,请参阅管理组诊断设置 - 创建或更新

后续步骤

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