[Azure管理组]什么是Azure管理组？

如果您的组织有许多Azure订阅，您可能需要一种方法来有效地管理这些订阅的访问、策略和合规性。管理组在订阅之上提供了一个治理范围。当您将订阅组织到管理组中时，您应用的治理条件将通过继承级联到所有关联的订阅。

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

例如，您可以将策略应用于管理组，以限制可用于创建虚拟机（VM）的区域。此策略将应用于所有嵌套的管理组、订阅和资源，以允许仅在授权区域创建VM。

管理组和订阅的层次结构

您可以构建一个灵活的管理组和订阅结构，将资源组织到一个层次结构中，以进行统一的策略和访问管理。下图显示了使用管理组创建治理层次结构的示例。

示例管理组层次结构图。

包含管理组和订阅的根管理组的关系图。一些子管理组持有管理组，一些持有订阅，还有一些同时持有两者。示例层次结构中的一个示例是四个级别的管理组，所有订阅都在子级别。

您可以创建一个应用策略的层次结构，例如，将VM位置限制在名为Corp.的管理组中的美国西部地区。此策略将继承该管理组的所有子代企业协议（EA）订阅，并将应用于这些订阅下的所有VM。资源或订阅所有者不能更改此安全策略，以改进治理。

注：

Microsoft客户协议（MCA）订阅的成本管理功能目前不支持管理组。

使用管理组的另一种情况是为用户提供对多个订阅的访问权限。通过将多个订阅移动到一个管理组下，您可以在该管理组上创建一个Azure角色分配。该角色将继承对所有订阅的访问权限。管理组上的一个分配可以使用户能够访问他们需要的一切，而不是在不同的订阅上编写Azure基于角色的访问控制（RBAC）脚本。

关于管理团队的重要事实

• 一个目录可以支持10000个管理组。
• 管理组树最多可以支持六个深度级别。
• 此限制不包括根级别或订阅级别。
• 每个管理组和订阅只能支持一个父级。
• 每个管理小组可以有很多孩子。

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

每个目录的根管理组

每个目录都有一个名为根管理组的顶级管理组。根管理组内置于层次结构中，以便将所有管理组和订阅折叠到其中。

根管理组允许在目录级别应用全局策略和Azure角色分配。最初，Microsoft Entra全局管理员需要将自己提升为此根组的用户访问管理员角色。提升访问权限后，管理员可以将任何Azure角色分配给其他目录用户或组来管理层次结构。作为管理员，您可以将您的帐户指定为根管理组的所有者。

关于根管理组的重要事实

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

重要事项

对根管理组的用户访问权限或策略的任何分配都适用于目录中的所有资源。由于这种访问级别，所有客户都应该评估是否需要在此范围内定义项目。用户访问和策略分配应仅在此范围内“必须具有”。

管理组的初始设置

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

此过程的原因是确保目录中只有一个管理组层次结构。目录中的单一层次结构允许管理客户应用目录中其他客户无法绕过的全局访问和策略。

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

管理组访问权限

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

例如，您可以将Azure角色VM Contributor分配给管理组。此角色对管理组没有操作，但将继承给该管理组下的所有VM。

下图显示了管理组上的角色列表和支持的操作。

• *：这些角色仅允许用户在管理组范围内执行指定的操作。
• **：将订阅或管理组移入或移出根管理组不需要分配角色。

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

Azure自定义角色定义和分配

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

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

示例定义

定义和创建自定义角色不会随着管理组的加入而改变。使用完整路径定义管理组：/proviers/Microsoft。管理/管理组/{_groupId_}。

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

JSON

...
{
 "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和Online，而沙箱管理组则有两个子订阅。

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

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

要解决此情况，您有以下选项：

• 在将订阅移动到新的父管理组之前，请从订阅中删除角色分配。
• 将订阅添加到角色定义的可分配范围。
• 更改角色定义中的可分配范围。在此示例中，您可以将沙箱管理组的可分配范围更新到根管理组，以便层次结构的两个分支都可以达到定义。
• 创建在另一个分支中定义的另一个自定义角色。此新角色还要求您更改订阅上的角色。
   

局限性

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

• 您只能在新角色的可分配范围内定义一个管理组。此限制是为了减少角色定义和角色分配断开连接的情况的数量。当具有角色分配的订阅或管理组移动到没有角色定义的其他父级时，就会发生这种情况。
• 无法在管理组范围内分配具有DataActions的自定义角色。有关更多信息，请参阅自定义角色限制。
• Azure资源管理器不会验证管理组在角色定义的可分配范围内的存在。如果存在拼写错误或管理组ID不正确，仍会创建角色定义。
   

移动管理组和订阅

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

• 子订阅或管理组的管理组写入权限和角色分配写入权限。
  • 内置角色示例：所有者
• 目标父管理组上的管理组写入权限。
  • 内置角色示例：所有者、贡献者、管理组贡献者
• 对现有父管理组的管理组写入权限。
  • 内置角色示例：所有者、贡献者、管理组贡献者

有一个例外：如果目标或现有父管理组是根管理组，则权限要求不适用。因为根管理组是所有新管理组和订阅的默认登录点，所以移动项目不需要对其拥有权限。

如果订阅上的所有者角色是从当前管理组继承的，则您的移动目标将受到限制。您只能将订阅移动到您具有所有者角色的另一个管理组。您无法将订阅移动到您只是参与者的管理组，因为您将失去订阅的所有权。如果您被直接分配到订阅的所有者角色，则可以将其移动到您具有参与者角色的任何管理组。

重要事项

Azure资源管理器将管理组层次结构的详细信息缓存长达30分钟。因此，Azure门户可能不会立即显示您移动了管理组。

使用活动日志审核管理组

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

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

当您想查询Azure门户之外的管理组时，管理组的目标范围看起来像 "/providers/Microsoft.Management/managementGroups/{management-group-id}"

注：

通过使用Azure Resource Manager REST API，您可以在管理组上启用诊断设置，以将相关的Azure Monitor活动日志条目发送到日志分析工作区、Azure存储或Azure事件中心。有关详细信息，请参阅管理组诊断设置：创建或更新。

相关内容

要了解有关管理组的更多信息，请参阅：

• Create management groups to organize Azure resources
• Change, delete, or manage your management groups
• Protect your resource hierarchy