什么是 Azure 管理组?What are Azure management groups?

如果你的组织有多个订阅,则可能需要一种方法来高效地管理这些订阅的访问权限、策略和符合性。If your organization has many subscriptions, you may need a way to efficiently manage access, policies, and compliance for those subscriptions. Azure 管理组提供订阅上的作用域级别。Azure management groups provide a level of scope above subscriptions. 可将订阅组织到名为“管理组”的容器中,并将管理条件应用到管理组。You organize subscriptions into containers called "management groups" and apply your governance conditions to the management groups. 管理组中的所有订阅都将自动继承应用于管理组的条件。All subscriptions within a management group automatically inherit the conditions applied to the management group. 不管使用什么类型的订阅,管理组都能提供大规模的企业级管理。Management groups give you enterprise-grade management at a large scale no matter what type of subscriptions you might have. 单个管理组中的所有订阅都必须信任同一个 Azure Active Directory 租户。All subscriptions within a single management group must trust the same Azure Active Directory tenant.

例如,可将策略应用到限制创建虚拟机 (VM) 的区域的管理组。For example, you can apply policies to a management group that limits the regions available for virtual machine (VM) creation. 此策略将应用到该管理组下面的所有管理组、订阅和资源,只允许在该区域中创建 VM。This policy would be applied to all management groups, subscriptions, and resources under that management group by only allowing VMs to be created in that region.

管理组和订阅的层次结构Hierarchy of management groups and subscriptions

可以生成管理组和订阅的灵活层次结构,以便将资源组织成用于统一策略和访问管理的层次结构。You can build a flexible structure of management groups and subscriptions to organize your resources into a hierarchy for unified policy and access management. 下图显示了使用管理组创建用于调控的层次结构的示例。The following diagram shows an example of creating a hierarchy for governance using management groups.

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

同时包含管理组和订阅的根管理组的图。Diagram of a root management group holding both management groups and subscriptions. 有些子管理组包含管理组,有些包含订阅,而有些两者均包含。Some child management groups hold management groups, some hold subscriptions, and some hold both. 示例层次结构中的一个示例是四个级别的管理组(其子级别是所有订阅)。One of the examples in the sample hierarchy is four levels of management groups with the child level being all subscriptions.

例如,可以创建应用一个策略的层次结构,该策略将 VM 位置限制到名为“生产”的组中的“美国西部”区域。You can create a hierarchy that applies a policy, for example, which limits VM locations to the US West Region in the group called "Production". 此策略将继承到作为该管理组后代的所有企业协议 (EA) 订阅,并将应用于这些订阅下的所有 VM。This policy will inherit onto all the Enterprise Agreement (EA) subscriptions that are descendants of that management group and will apply to all VMs under those subscriptions. 此安全策略不能由资源或订阅所有者更改,因此增强了治理效果。This security policy cannot be altered by the resource or subscription owner allowing for improved governance.

使用管理组的另一个场景是向用户提供对多个订阅的访问权限。Another scenario where you would use management groups is to provide user access to multiple subscriptions. 通过移动该管理组下的多个订阅,可对该管理组创建一个 Azure 角色分配,该分配将这种访问权限继承到所有订阅。By moving multiple subscriptions under that management group, you can create one Azure role assignment on the management group, which will inherit that access to all the subscriptions. 管理组的一个分配就能让用户访问所需的一切内容,而无需基于不同订阅编写 Azure RBAC 的脚本。One assignment on the management group can enable users to have access to everything they need instead of scripting Azure RBAC over different subscriptions.

关于管理组的重要事实Important facts about management groups

  • 在单个目录中可以支持 10,000 个管理组。10,000 management groups can be supported in a single directory.
  • 一个管理组树最多可支持六个级别的深度。A management group tree can support up to six levels of depth.
    • 此限制不包括根级别或订阅级别。This limit doesn't include the Root level or the subscription level.
  • 每个管理组和订阅只能支持一个父级。Each management group and subscription can only support one parent.
  • 每个管理组可以有多个子级。Each management group can have many children.
  • 所有订阅和管理组都在每个目录中的单个层次结构内。All subscriptions and management groups are within a single hierarchy in each directory. 请参阅关于根管理组的重要事实See Important facts about the Root management group.

每个目录的根管理组Root management group for each directory

为每个目录指定了一个称为“根”管理组的顶级管理组。Each directory is given a single top-level management group called the "Root" management group. 此根管理组内置在层次结构中,包含其所有下级管理组和订阅。This root management group is built into the hierarchy to have all management groups and subscriptions fold up to it. 此根管理组允许在目录级别应用全局策略和 Azure 角色分配。This root management group allows for global policies and Azure role assignments to be applied at the directory level. 一开始的时候,Azure AD 全局管理员需要提升自身权限才能成为此根组的用户访问管理员角色。The Azure AD Global Administrator needs to elevate themselves to the User Access Administrator role of this root group initially. 提升访问权限后,管理员可将任何 Azure 角色分配给其他目录用户或组,以便管理层次结构。After elevating access, the administrator can assign any Azure role to other directory users or groups to manage the hierarchy. 作为管理员,你可以将自己的帐户分配为根管理组的所有者。As administrator, you can assign your own account as owner of the root management group.

关于根管理组的重要事实Important facts about the Root management group

  • 默认情况下,根管理组的显示名称是“租户根组”。By default, the root management group's display name is Tenant root group. ID 是 Azure Active Directory ID。The ID is the Azure Active Directory ID.
  • 若要更改显示名称,必须在根管理组中为帐户分配“所有者”或“参与者”角色。To change the display name, your account must be assigned the Owner or Contributor role on the root management group. 请参阅更改管理组名称,了解如何更新管理组的名称。See Change the name of a management group to update the name of a management group.
  • 无法像操作其他管理组一样移动或删除根管理组。The root management group can't be moved or deleted, unlike other management groups.
  • 所有订阅和管理组归并到目录中的一个根管理组下。All subscriptions and management groups fold up to the one root management group within the directory.
    • 目录中的所有资源归并到根管理组进行全局管理。All resources in the directory fold up to the root management group for global management.
    • 新订阅在创建时自动默认为根管理组。New subscriptions are automatically defaulted to the root management group when created.
  • 所有 Azure 客户都可查看根管理组,但并非所有客户都具有管理该根管理组的权限。All Azure customers can see the root management group, but not all customers have access to manage that root management group.
    • 有权访问订阅的每个人都可看到订阅位于层次结构中的位置的上下文。Everyone who has access to a subscription can see the context of where that subscription is in the hierarchy.
    • 未对任何人授予对根管理组的默认访问权限。No one is given default access to the root management group. 只有 Azure AD 全局管理员可将自身提升为拥有访问权限的角色。Azure AD Global Administrators are the only users that can elevate themselves to gain access. 拥有根管理组的访问权限后,全局管理员便可向要管理的其他用户分配任何 Azure 角色Once they have access to the root management group, the global administrators can assign any Azure role to other users to manage
      色。it.
  • 在 SDK 中,根管理组(即“租户根”)作为一个管理组进行操作。In SDK, the root management group, or 'Tenant Root', operates as a management group.

重要

对根管理组进行的任何用户访问权限分配或策略分配都适用于在目录中的所有资源。Any assignment of user access or policy assignment on the root management group applies to all resources within the directory. 因此,所有客户都应评估在此作用域中定义项目的需求。Because of this, all customers should evaluate the need to have items defined on this scope. 仅在此范围内,用户访问权限和策略分配应为“必须具有”User access and policy assignments should be "Must Have" only at this
scope.

管理组的初始设置Initial setup of management groups

任何用户都需在开始使用管理组时进行初始设置。When any user starts using management groups, there's an initial setup process that happens. 第一步是在目录中创建根管理组。The first step is the root management group is created in the directory. 创建此组后,目录中存在的所有现有订阅都成为根管理组的子级。Once this group is created, all existing subscriptions that exist in the directory are made children of the root management group. 执行此过程是为了确保一个目录中只有一个管理组层次结构。The reason for this process is to make sure there's only one management group hierarchy within a directory. 目录中的单个层次结构可让管理客户应用目录内其他客户无法绕开的全局访问权限和策略。The single hierarchy within the directory allows administrative customers to apply global access and policies that other customers within the directory can't bypass. 在根上分配的任何内容都将应用于整个层次结构,其中包括该 Azure AD 租户中的所有管理组、订阅、资源组和资源。Anything assigned on the root will apply to the entire hierarchy, which includes all management groups, subscriptions, resource groups, and resources within that Azure AD Tenant.

查看所有订阅时遇到问题Trouble seeing all subscriptions

2018 年 6 月 25 日之前的预览版中较早开始使用管理组的一些目录可能会遇到问题,即并非所有订阅都在该层次结构中。A few directories that started using management groups early in the preview before June 25 2018 could see an issue where not all the subscriptions were within the hierarchy. 将所有订阅都纳入到该层次结构中的过程是在角色或策略分配已针对目录中的根管理组执行后实施的。The process to have all subscriptions in the hierarchy was put in place after a role or policy assignment was done on the root management group in the directory.

如何解决问题How to resolve the issue

有两个选项可用于解决此问题。There are two options you can do to resolve this issue.

  • 删除根管理组的所有角色和策略分配Remove all Role and Policy assignments from the root management group
    • 如果删除根管理组的所有策略和角色分配,服务会在下一个隔夜周期将所有订阅回填到层次结构中。By removing any policy and role assignments from the root management group, the service backfills all subscriptions into the hierarchy the next overnight cycle. 执行此过程后,所有租户订阅都不存在意外的访问权限授予或策略分配情况。This process is so there's no accidental access given or policy assignment to all of the tenants subscriptions.
    • 在不影响服务的情况下执行此过程的最佳方法是在根管理组的下一个级别应用角色或策略分配。The best way to do this process without impacting your services is to apply the role or policy assignments one level below the Root management group. 然后可以从根范围删除所有分配。Then you can remove all assignments from the root scope.
  • 直接调用 API 以开始回填过程Call the API directly to start the backfill process
    • 目录中的任何客户都可以调用 TenantBackfillStatusRequest 或 StartTenantBackfillRequest API 。Any customer in the directory can call the TenantBackfillStatusRequest or StartTenantBackfillRequest APIs. 调用 StartTenantBackfillRequest API 时,它会启动将所有订阅移到层次结构中的初始设置过程。When the StartTenantBackfillRequest API is called, it kicks off the initial setup process of moving all the subscriptions into the hierarchy. 此过程还会开始强制所有新订阅成为根管理组的子级。This process also starts the enforcement of all new subscription to be a child of the root management group. 无需更改根级别上的任何分配即可完成此过程。This process can be done without changing any assignments on the root level. 通过调用该 API,可使根上的任何策略或访问权限分配应用到所有订阅。By calling the API, you're saying it's okay that any policy or access assignment on the root can be applied to all subscriptions.

如果对此回填过程有疑问,请联系:managementgroups@microsoft.comIf you have questions on this backfill process, contact: managementgroups@microsoft.com

访问管理组Management group access

Azure 管理组支持使用 Azure 基于角色的访问控制 (Azure RBAC) 来访问所有资源和定义角色。Azure management groups support Azure role-based access control (Azure RBAC) for all resource accesses and role definitions. 层次结构中的子资源继承这些权限。These permissions are inherited to child resources that exist in the hierarchy. 可将任何 Azure 角色分配到管理组,该角色将继承资源的层次结构。Any Azure role can be assigned to a management group that will inherit down the hierarchy to the resources. 例如,可以向管理组分配 Azure 角色 VM 参与者。For example, the Azure role VM contributor can be assigned to a management group. 此角色不对管理组执行任何操作,但将继承该管理组下的所有 VM。This role has no action on the management group, but will inherit to all VMs under that management group.

下图列出了管理组的角色和支持的操作。The following chart shows the list of roles and the supported actions on management groups.

Azure 角色名称Azure Role Name 创建Create 重命名Rename 移动**Move** 删除Delete 分配访问权限Assign Access 分配策略Assign Policy 读取Read
“所有者”Owner XX XX XX XX XX XX XX
参与者Contributor XX XX XX XX XX
MG 参与者*MG Contributor* XX XX XX XX XX
读取器Reader XX
MG 读者*MG Reader* XX
资源策略参与者Resource Policy Contributor XX
用户访问管理员User Access Administrator XX XX

*:MG 参与者和 MG 读者只允许用户在管理组范围执行这些操作。*: MG Contributor and MG Reader only allow users to do those actions on the management group scope.
**:将订阅或管理组移入/移出层次结构不一定需要根管理组上的角色分配。**: Role Assignments on the Root management group aren't required to move a subscription or management group to and from it. 请参阅使用管理组管理资源了解有关将项目移到层次结构中的详细信息。See Manage your resources with management groups for details on moving items within the hierarchy.

Azure 自定义角色定义和分配Azure custom role definition and assignment

对管理组的 Azure 自定义角色支持目前处于预览状态,并且存在一些限制Azure custom role support for management groups is currently in preview with some limitations. 可以在角色定义的可分配范围中定义管理组范围。You can define the management group scope in the Role Definition's assignable scope. 然后即可在该管理组及其下的任何管理组、订阅、资源组或资源中分配 Azure 自定义角色。That Azure custom role will then be available for assignment on that management group and any management group, subscription, resource group, or resource under it. 此自定义角色会继承层次结构,就像任何内置角色一样。This custom role will inherit down the hierarchy like any built-in role.

示例定义Example definition

在包括管理组后,定义和创建自定义角色的操作不变。Defining and creating a custom role doesn't change with the inclusion of management groups. 使用完整路径来定义管理组 /providers/Microsoft.Management/managementgroups/{groupId}。Use the full path to define the management group /providers/Microsoft.Management/managementgroups/{groupId}.

使用管理组的 ID,而不是管理组的显示名称。Use the management group's ID and not the management group's display name. 发生此常见错误是因为在创建管理组时二者都是自定义字段。This common error happens since both are custom-defined fields when creating a management group.

...
{
  "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"
  ]
}
...

中断角色定义和分配层次结构路径的问题Issues with breaking the role definition and assignment hierarchy path

角色定义是可分配的范围,处于管理组层次结构中的任意位置。Role definitions are assignable scope anywhere within the management group hierarchy. 角色定义可以在父管理组中定义,而实际的角色分配存在于子订阅中。A role definition can be defined on a parent management group while the actual role assignment exists on the child subscription. 由于两个项之间存在某种关系,因此尝试将分配与其定义分离时,将收到错误。Since there's a relationship between the two items, you'll receive an error when trying to separate the assignment from its definition.

例如,让我们看看某个视觉对象的层次结构的一小部分。For example, let's look at a small section of a hierarchy for a visual.

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

该图重点介绍了具有子 IT 和营销管理组的根管理组。The diagram focuses on the root management group with child I T and Marketing management groups. IT 管理组具有一个名为“生产”的子管理组,而营销管理组则具有两个免费试用版子订阅。The I T management group has a single child management group named Production while the Marketing management group has two Free Trial child subscriptions.

假设在营销管理组上定义了一个自定义角色。Let's say there's a custom role defined on the Marketing management group. 然后,在两个免费的试用版订阅上分配了该自定义角色。That custom role is then assigned on the two free trial subscriptions.

如果我们尝试移动这些将要成为生产管理组子项的订阅之一,则会断开从订阅角色分配到营销管理组角色定义的路径。If we try to move one of those subscriptions to be a child of the Production management group, this move would break the path from subscription role assignment to the Marketing management group role definition. 在这种情况下,会出现一条错误,指出系统不允许该移动,因为它会破坏此关系。In this scenario, you'll receive an error saying the move isn't allowed since it will break this relationship.

若要修复此情况下的问题,可以使用多个不同的选项:There are a couple different options to fix this scenario:

  • 在将订阅移到新的父 MG 之前,从订阅中删除角色分配。Remove the role assignment from the subscription before moving the subscription to a new parent MG.
  • 将订阅添加到角色定义的可分配范围。Add the subscription to the Role Definition's assignable scope.
  • 在角色定义中更改可分配范围。Change the assignable scope within the role definition. 在上面的示例中,可以将可分配范围从“营销”更新为“根管理组”,这样,层次结构的两个分支就都可以访问定义。In the above example, you can update the assignable scopes from Marketing to Root Management Group so that the definition can be reached by both branches of the hierarchy.
  • 创建另一个将在其他分支中定义的自定义角色。Create an additional Custom Role that will be defined in the other branch. 此新角色会要求也可在订阅上更改角色分配。This new role will require the role assignment to be changed on the subscription also.

限制Limitations

在管理组上使用自定义角色时存在限制。There are limitations that exist when using custom roles on management groups.

  • 在新角色的可分配范围中,只能定义一个管理组。You can only define one management group in the assignable scopes of a new role. 设置此限制是为了减少出现角色定义和角色分配不关联的情况的次数。This limitation is in place to reduce the number of situations where role definitions and role assignments are disconnected. 将进行了角色分配的订阅或管理组移到另一个没有该角色定义的父项时,会出现此情况。This situation happens when a subscription or management group with a role assignment moves to a different parent that doesn't have the role definition.
  • 不能在管理组自定义角色中定义资源提供程序数据平面操作。Resource provider data plane actions can't be defined in management group custom roles. 存在此限制是因为,在更新数据平面资源提供程序时存在延迟问题。This restriction is in place as there's a latency issue with updating the data plane resource providers. 我们会解决此延迟问题,并会在角色定义中禁用这些操作以降低风险。This latency issue is being worked on and these actions will be disabled from the role definition to reduce any risks.
  • Azure 资源管理器不验证管理组是否存在于角色定义的可分配范围中。The Azure Resource Manager doesn't validate the management group's existence in the role definition's assignable scope. 即使存在拼写错误或者列出的管理组 ID 不正确,仍会创建角色定义。If there's a typo or an incorrect management group ID listed, the role definition will still be created.

移动管理组和订阅Moving management groups and subscriptions

若要将管理组或订阅移动为另一个管理组的子项,三项规则的计算结果都需要为 true。To move a management group or subscription to be a child of another management group, three rules need to be evaluated as true.

如果执行移动操作,你需要:If you're doing the move action, you need:

  • 在子订阅或管理组上的管理组写入权限和角色分配写入权限。Management group write and Role Assignment write permissions on the child subscription or management group.
    • 内置角色示例:所有者Built-on role example Owner
  • 目标父管理组中的管理组写入访问权限。Management group write access on the target parent management group.
    • 内置角色示例: 所有者参与者管理组参与者Built-in role example: Owner , Contributor , Management Group Contributor
  • 现有父管理组中的管理组写入访问权限。Management group write access on the existing parent management group.
    • 内置角色示例: 所有者参与者管理组参与者Built-in role example: Owner , Contributor , Management Group Contributor

例外 :如果目标或现有父管理组不是根管理组,则权限要求不适用。Exception : If the target or the existing parent management group is the Root management group, the permissions requirements don't apply. 由于根管理组是所有新管理组和订阅的默认登陆点,因此不需在其上具有相关权限即可移动某个项。Since the Root management group is the default landing spot for all new management groups and subscriptions, you don't need permissions on it to move an item.

如果订阅上的“所有者”角色继承自当前管理组,你的移动目标会受限。If the Owner role on the subscription is inherited from the current management group, your move targets are limited. 只能将订阅移到你在其中拥有“所有者”角色的另一管理组。You can only move the subscription to another management group where you have the Owner role. 不能将它移到你在其中是参与者的管理组,因为你会失去订阅的所有权。You can't move it to a management group where you're a contributor because you would lose ownership of the subscription. 如果你是直接分配到订阅的“所有者”角色的(而不是从管理组继承的),则可将它移到你在其中是参与者的任何管理组。If you're directly assigned to the Owner role for the subscription (not inherited from the management group), you can move it to any management group where you're a contributor.

使用活动日志审核管理组Audit management groups using activity logs

Azure 活动日志支持管理组。Management groups are supported within Azure Activity Log. 可以搜索到与其他 Azure 资源相同的中心位置中的管理组发生的所有事件。You can search all events that happen to a management group in the same central location as other Azure resources. 例如,可以看到对特定管理组所做的所有角色分配或策略分配更改。For example, you can see all Role Assignments or Policy Assignment changes made to a particular management group.

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

如果要在 Azure 门户外针对管理组进行查询,管理组的目标范围将如下所示: "/providers/Microsoft.Management/managementGroups/{yourMgID}"When looking to query on Management Groups outside of the Azure portal, the target scope for management groups looks like "/providers/Microsoft.Management/managementGroups/{yourMgID}".

后续步骤Next steps

若要了解有关管理组的详细信息,请参阅:To learn more about management groups, see: