使用 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. 單一管理群組中的所有訂用帳戶都必須信任相同的 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.

管理群組階層樹狀結構範例

您可以建立套用原則的階層,例如將名為「生產」群組中的 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". 此原則將會繼承管理群組底下的所有 Enterprise 合約 (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. 將多個訂用帳戶移至該管理群組底下,讓您能在管理群組上建立角色型存取控制 (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 the User Access Administrator role of this root group initially. 提高存取權限後,管理員即可將任何 RBAC 角色指派給其他目錄使用者或群組,以管理階層。After elevating access, the administrator can assign any RBAC 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. 識別碼則是 Azure Active Directory 識別碼。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. 一旦全域管理員擁有根管理群組存取權之後,就可以將任何 RBAC 角色指派給其他使用者以進行Once they have access to the root management group, the global administrators can assign any RBAC 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 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.
    • 要在不影響您服務的情況下進行此流程,最好的方法是將角色或原則指派套用至比根管理群組低一階的層級。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
    • 目錄中的所有客戶都可以呼叫 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.

若您對於此回填流程有任何問題,請連絡:managementgroups@microsoft.comIf you have questions on this backfill process, contact: managementgroups@microsoft.com

管理群組存取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 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** 刪除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.

自訂 RBAC 角色定義和指派Custom RBAC role definition and assignment

管理群組的自訂 RBAC 角色支援目前為預覽版,但有一些 限制Custom RBAC 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. 接著,該自訂 RBAC 角色即可在該管理群組,以及任何管理群組、訂用帳戶、資源群組或其下的資源上指派。That custom RBAC 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 does not 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}.

使用管理群組的識別碼,而不是管理群組的顯示名稱。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.

sub-tree

假設行銷管理群組上有定義的自訂角色。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 is moved to a different parent that doesn't have the role definition.
  • 不允許在管理群組自訂角色中定義 RBAC 資料平面動作。RBAC Data Plane actions can't be defined in management group custom roles. 有這項限制是因為 RBAC 動作更新資料平面資源提供者時會發生延遲問題。This restriction is in place as there's a latency issue with RBAC actions 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 Resource Manager 不會驗證角色定義的可指派範圍中是否存在管理群組。The Azure Resource Manager doesn't validate the management group's existence in the role definition's assignable scope. 如果有錯字或列出了不正確的管理群組識別碼,則仍會建立角色定義。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: