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) 割り当てを 1 つ作成できます。これにより、すべてのサブスクリプションにそのアクセスが継承されます。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 を割り当てるスクリプトを作成しなくても、管理グループへ 1 つ割り当てることで、ユーザーは必要なものすべてにアクセスできます。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

  • 1 つのディレクトリでは、10,000 個の管理グループをサポートできます。10,000 management groups can be supported in a single directory.
  • 管理グループのツリーは、最大 6 レベルの深さをサポートできます。A management group tree can support up to six levels of depth.
    • この制限には、ルート レベルまたはサブスクリプション レベルは含まれません。This limit doesn't include the Root level or the subscription level.
  • 各管理グループとサブスクリプションは、1 つの親のみをサポートできます。Each management group and subscription can only support one parent.
  • 各管理グループには、多数の子を含めることができます。Each management group can have many children.
  • すべてのサブスクリプションと管理グループは、各ディレクトリの 1 つの階層内に存在します。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

各ディレクトリには、"ルート" 管理グループと呼ばれる 1 つの最上位管理グループがあります。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

  • 既定では、ルート管理グループの表示名は Tenant root 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. 名前を変更する手順については、「管理グループの名前を変更する」を参照してください。For the steps to change the name, see Change the name of a management group.
  • 他の管理グループと異なり、ルート管理グループを移動または削除することはできません。The root management group can't be moved or deleted, unlike other management groups.
  • すべてのサブスクリプションと管理グループは、ディレクトリ内の 1 つのルート管理グループにまとめられます。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 global administrators can assign any RBAC role to other users to manage.

重要

ルート管理グループでのユーザーのアクセス権またはポリシーの割り当ては、ディレクトリ内のすべてのリソースに適用されます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. このプロセスが実行される理由は、ディレクトリ内に管理グループ階層が 1 つだけ存在するようにするためです。The reason for this process is to make sure there's only one management group hierarchy within a directory. ディレクトリ内に 1 つの階層が存在することにより、ディレクトリ内の他のユーザーがバイパスできないグローバル アクセス権とポリシーを管理ユーザーが適用できるようになります。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

この問題を解決するためのオプションは 2 つあります。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. サービスに影響を与えずにこのプロセスを実行する最善の方法として、ルート管理グループの 1 つ下のレベルのロールまたはポリシー割り当てを適用します。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. ディレクトリ内の任意のユーザーは、TenantBackfillStatusRequest API または 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.com までお問い合わせください。If 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 built-in RBAC role can be assigned to a management group that will inherit down the hierarchy to the resources. たとえば、VM 共同作成者の RBAC ロールは、管理グループに割り当てることができます。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 CreateCreate 名前の変更Rename 移動**Move** 削除Delete アクセス権の割り当てAssign Access ポリシーの割り当てAssign Policy 読み取りRead
OwnerOwner XX XX XX XX XX XX XX
ContributorContributor XX XX XX XX XX
MG Contributor*MG Contributor* XX XX XX XX XX
ReaderReader XX
MG Reader*MG Reader* XX
リソース ポリシー共同作成者Resource Policy Contributor XX
User Access AdministratorUser Access Administrator XX

*: MG Contributor と MG Reader は、管理グループのスコープのみでのこれらのアクションの実行をユーザーに許可します。*: 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. 階層内の項目の移動について詳しくは、「Manage your resources with management groups (管理グループを使用してリソースを管理する)」を参照してください。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 portal の外部で管理グループに対するクエリを使用する場合、管理グループのターゲット スコープは、 "/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: