使用 Azure 管理组来组织资源Organize your resources with 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.

例如,可将策略应用到限制创建虚拟机 (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.

管理组层次结构树的示例

创建层次结构以便可以应用策略,例如,将 VM 位置限制到“生产”组中的“美国西部区域”。Create a hierarchy so you can apply a policy, for example, limit VM locations to US West Region on the group "Production". 此策略将继承到该管理组下的两个 EA 订阅,并应用到这些订阅下的所有 VM。This policy will inherit onto both EA subscriptions under 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 multi subscriptions. 通过移动该管理组下的多个订阅,可对该管理组创建一个基于角色的访问控制 (RBAC) 分配,该分配将这种访问权限继承到所有订阅。By moving multiple subscriptions under that management group, you can create one role-based access control (RBAC) assignment on the management group, which will inherit that access to all the subscriptions. 管理组的一个分配就能让用户访问所需的一切内容,而无需基于多个订阅编写 RBAC 分配的脚本。One assignment on the management group can enable users to have access to everything they need instead of scripting 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. 此根管理组允许在目录级别应用全局策略和 RBAC 分配。This Root management group allows for global policies and RBAC assignments to be applied at the directory level. Azure AD 全局管理员最初需要提升自身的权限才能成为此根组的所有者。The Azure AD Global Administrator needs to elevate themselves to be the owner of this root group initially. 当管理员成为组的所有者后,可将任何 RBAC 角色分配给其他目录用户或组来管理层次结构。Once the administrator is the owner of the group, they can assign any RBAC role to other directory users or groups to manage the hierarchy.

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

  • 默认情况下,已提供根管理组的名称和 ID。The root management group's name and ID are given by default. 随时可以更新此显示名称,以便在 Azure 门户中显示其他名称。The display name can be updated at any time to show different within the Azure portal.
    • 该名称将为“租户根组”。The name will be "Tenant root group".
    • ID 将为 Azure Active Directory ID。The ID will be the Azure Active Directory ID.
  • 无法像操作其他管理组一样移动或删除根管理组。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. 拥有访问权限后,目录管理员可向要管理的其他用户分配任何 RBAC 角色。Once they have access, the directory administrators can assign any RBAC role to other users to manage.

Important

对根管理组进行的任何用户访问权限分配或策略分配都适用于在目录中的所有资源。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 all the subscriptions aren't within the hierarchy. 将所有订阅都纳入到该层次结构中的过程是在角色或策略分配已针对目录中的根管理组执行后实施的。The processes 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.

  1. 删除根管理组的所有角色和策略分配Remove all Role and Policy assignments from the root management group
    1. 通过删除根管理组的所有策略和角色分配,服务会在下一个隔夜周期将所有订阅回填到层次结构中。By removing any policy and role assignments from the root management group, the service will backfill 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.
    2. 在不影响服务的情况下执行此过程的最佳方法是在根管理组的下一个级别应用角色或策略分配。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.
  2. 直接调用 API 以开始回填过程Call the API directly to start the backfill process
    1. 目录中的任何客户都可以调用 TenantBackfillStatusRequestStartTenantBackfillRequest 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.

如果对此回填过程有疑问,请联系: https://www.azure.cn/support/contact/If you have questions on this backfill process, contact: https://www.azure.cn/support/contact/

访问管理组Management group access

Azure 管理组支持使用 Azure 基于角色的访问控制 (RBAC) 来访问所有资源访问和定义角色。Azure management groups support Azure Role-Based Access Control (RBAC) for all resource accesses and role definitions. 层次结构中的子资源继承这些权限。These permissions are inherited to child resources that exist in the hierarchy. 可将任何内置 RBAC 角色分配到管理组,该角色将继承资源的层次结构。Any built-in RBAC role can be assigned to a management group that will inherit down the hierarchy to the resources. 例如,可以向管理组分配 RBAC 角色 VM 参与者。For example, the RBAC 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.

RBAC 角色名称RBAC Role Name 创建Create 重命名Rename 移动**Move** DeleteDelete 分配访问权限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

*: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.

自定义 RBAC 角色定义和分配Custom RBAC Role Definition and Assignment

管理组当前不支持自定义 RBAC 角色。Custom RBAC roles aren't supported on management groups at this time. 请访问管理组反馈论坛,查看此项的状态。See the management group feedback forum to view the status of this item.

使用活动日志审核管理组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: