Azure 管理グループとは

組織に多くの Azure サブスクリプションがある場合は、これらのサブスクリプションのアクセス、ポリシー、およびコンプライアンスを効率的に管理する方法が必要になることがあります。 管理グループのガバナンス範囲は、サブスクリプションを上回ります。 サブスクリプションを管理グループにまとめると、適用するガバナンス条件は関連付けられているすべてのサブスクリプションへの継承によりカスケード表示されます。

管理グループを使うと、サブスクリプションの種類に関係なく、エンタープライズ レベルの管理を大規模に行うことができます。 ただし、単一の管理グループ内のすべてのサブスクリプションは、同じ Microsoft Entra テナントを信頼する必要があります。

たとえば、仮想マシン (VM) の作成に使用できるリージョンを制限するポリシーを、管理グループに適用できます。 このポリシーは、入れ子になったすべての管理グループ、サブスクリプション、リソースに適用され、承認されたリージョンのみで VM の作成を許可します。

管理グループとサブスクリプションの階層

管理グループとサブスクリプションの柔軟な構造を作成し、リソースを階層に整理して、統一されたポリシーとアクセス管理を適用できます。 次の図は、管理グループを使用して管理のための階層を作成する例を示しています。

管理グループとサブスクリプションの両方を包含しているルート管理グループの図。 一部の子管理グループは管理グループを包含し、一部はサブスクリプション、一部はその両方を包含しています。 サンプル階層の例の 1 つは、すべてサブスクリプションを子レベルで持つ、4 つのレベルの管理グループです。

ポリシーを適用する階層を作成できます。たとえば、"Corp" という管理グループの VM の場所を米国西部リージョンに制限できます。このポリシーは、その管理グループの子孫であるすべての Enterprise Agreement (EA) サブスクリプションに継承され、それらのサブスクリプションの下にあるすべての VM に適用されます。 リソースまたはサブスクリプションの所有者は、ガバナンスを向上させるために、このセキュリティ ポリシーを変更することはできません。

Note

現在、管理グループは、Microsoft 顧客契約 (MCA) サブスクリプションの Cost Management 機能ではサポートされていません。

管理グループを使用するもう 1 つのシナリオは、ユーザーに複数のサブスクリプションへのアクセスを提供する場合です。 管理グループの下に複数のサブスクリプションを移動することで、管理グループに 1 つの Azure ロールの割り当てを作成できます。 ロールは、そのアクセス権をすべてのサブスクリプションに継承します。 さまざまなサブスクリプションに Azure RBAC を割り当てるスクリプトを作成することなく、管理グループへ 1 つ割り当てるだけで、ユーザーは必要なものすべてにアクセスできます。

管理グループに関する重要な事実

• 1 つのディレクトリで 10,000 の管理グループをサポートできます。

• 管理グループのツリーは、最大 6 レベルの深さをサポートできます。

  この制限には、ルート レベルまたはサブスクリプション レベルは含まれません。

• 各管理グループとサブスクリプションでは、1 つの親のみをサポートできます。

• 各管理グループには、多数の子を含めることができます。

• すべてのサブスクリプションと管理グループは、各ディレクトリの 1 つの階層内に存在します。 詳細については、この記事で後述する、「ルート管理グループに関する重要な事実」をご覧ください。

各ディレクトリのルート管理グループ

各ディレクトリには、"ルート" 管理グループと呼ばれる 1 つの最上位管理グループがあります。 このルート管理グループは階層に組み込まれており、すべての管理グループとサブスクリプションはルート管理グループにまとめられます。

ルート管理グループは、ディレクトリ レベルで、グローバル ポリシーと Azure ロールの割り当てを適用できます。 最初に、Microsoft Entra のグローバル管理者は、自分自身を昇格させる必要があり、このルート グループのユーザー アクセス管理者ロールに追加します。 アクセス権の昇格後、管理者は、任意の Azure ロールを他のディレクトリ ユーザーまたはグループに割り当てて階層を管理することができます。 管理者の場合は、自分のアカウントをルート管理グループの所有者として割り当てることができます。

ルート管理グループに関する重要な事実

• 既定で、ルート管理グループの表示名は Tenant root group であり、それ自体が管理グループとして機能します。 この ID は、Microsoft Entra テナント ID と同じ値です。
• 表示名を変更するには、自分のアカウントにルート管理グループの所有者または共同作成者ロールを持たせる必要があります。 詳細については、「管理グループの名前を変更する」をご覧ください。
• 他の管理グループと異なり、ルート管理グループを移動または削除することはできません。
• すべてのサブスクリプションと管理グループは、ディレクトリ内の 1 つのルート管理グループにまとめられます。
  • ディレクトリ内のすべてのリソースは、グローバル管理用のルート管理グループにまとめられます。
  • 既定では、新しいサブスクリプションはその作成時に自動的にルート管理グループに設定されます。
• すべての Azure ユーザーはルート管理グループを表示できますが、すべてのユーザーがルート管理グループを管理するアクセス権を持つわけではありません。
  • サブスクリプションへのアクセス権を持つすべてのユーザーは、階層内にそのサブスクリプションが存在するコンテキストを参照できます。
  • 既定では、ルート管理グループには誰もアクセスできません。 Microsoft Entra 全体管理者は、自分自身を昇格させてアクセス権を取得できる唯一のユーザーです。 全体管理者がルート管理グループへのアクセス権を取得すると、他のユーザーが管理できるように任意の Azure ロールを割り当てることができます。

重要

ルート管理グループでのユーザーのアクセス権またはポリシーは、ディレクトリ内のすべてのリソースに適用されます。 このアクセス レベルのため、すべてのお客様は、このスコープに項目を定義する必要性を評価する必要があります。 ユーザー アクセスやポリシーの割り当ては、このスコープのみで "必須" でなければなりません。

管理グループの初期セットアップ

ユーザーが管理グループの使用を開始する際には、初期セットアップ プロセスが発生します。 最初の手順は、ディレクトリでのルート管理グループの作成です。 ディレクトリに存在する既存のサブスクリプションはすべて、ルート管理グループの子になります。

このプロセスが実行される理由は、ディレクトリ内に管理グループ階層が 1 つだけ存在するようにするためです。 ディレクトリ内に 1 つの階層が存在することにより、ディレクトリ内の他のユーザーがバイパスできないグローバル アクセス権とポリシーを管理ユーザーが適用できるようになります。

ルートに割り当てられているものはすべて、階層全体に適用されます。 つまり、Microsoft Entra テナント内のすべての管理グループ、サブスクリプション、リソース グループ、およびリソースに適用されます。

管理グループ アクセス

Azure 管理グループでは、すべてのリソース アクセスとロール定義に対して Azure RBAC がサポートされます。 階層内に存在する子リソースは、これらのアクセス許可を継承します。 管理グループには任意の Azure ロールを割り当てることができます。ロールは階層を継承し、各リソースに割り当てられます。

たとえば、Azure ロール VM 共同作成者を管理グループに割り当てることができます。 このロールには、管理グループに対するアクションはありませんが、その管理グループに属するすべての VM に継承されます。

次の図に、管理グループのロールとサポートされているアクションの一覧を示します。

Azure ロール名	作成	[名前の変更]	移動**	削除	アクセス権を割り当てる	ポリシーを割り当てる	Read
所有者	X	X	X	X	X	X	X
Contributor	X	X	X	X			x
管理グループ共同作成者	x	X	X	X			X
Reader							x
管理グループ閲覧者							x
リソース ポリシー共同作成者						X
User Access Administrator					X	x

*: これらのロールを使用すると、ユーザーは指定されたアクションを管理グループ スコープに対してのみ実行できます。

**: ルート管理グループに対するロールの割り当ては、それとの間でのサブスクリプションまたは管理グループの移動に必要ありません。

階層内の項目の移動についての詳細は、「管理グループを使用してリソースを管理する」をご覧ください。

Azure カスタム ロールの定義と割り当て

管理グループは、Azure カスタム ロール定義で割り当て可能なスコープとして定義できます。 これで、その Azure カスタム ロールを、当該の管理グループと、その下にあるすべての管理グループ、サブスクリプション、リソース グループ、またはリソースに割り当てることができるようになります。 組み込みロールと同様、このカスタム ロールも階層に沿って継承されます。

カスタム ロールと管理グループに関する制限事項については、この記事で後述する「制限事項」をご覧ください。

定義の例

カスタム ロールの定義と作成は、管理グループを追加しても変化することはありません。 完全なパスを使用して、管理グループ /providers/Microsoft.Management/managementgroups/{_groupId_} を定義します。

管理グループの表示名ではなく、管理グループの ID を使用してください。 どちらも管理グループを作成する際にカスタムで定義されるフィールドであるため、この一般的なエラーが発生します。

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

ロールの定義を割り当ての階層パスから切り離すことによって生じる問題

ロールの定義は、管理グループの階層の範囲内であれば、どこでも割り当てることができます。 ロールは親管理グループに対して定義できますが、実際のロールの割り当てが存在するのは子のサブスクリプションです。 この 2 つの項目間には関係があるため、割り当てをその定義から切り離そうとするとエラーが発生します。

たとえば、次の例のような階層の小さなセクションを考えてみましょう。

この図は、子 landing zone および sandbox 管理グループを持つルート管理グループに焦点を当てています。 landing zone 管理グループには Corp と Online という名前の 2 つの子管理グループがあり、sandbox 管理グループには 2 つの子サブスクリプションがあります。

sandbox 管理グループでカスタム ロールが定義されているとします。 そのカスタム ロールは 2 つの sandbox サブスクリプションに割り当てられています。

そのいずれかのサブスクリプションを Corp 管理グループの子に移動しようとすると、サブスクリプションに対するロールの割り当てから sandbox 管理グループに対するロールの定義へのパスが断ち切られてしまいます。 このシナリオでは、その関係が壊れるため移動は許可されないという内容のエラーが発生します。

このシナリオを解決するには、次のオプションがあります。

• サブスクリプションからロールの割り当てを削除した後で、サブスクリプションを新しい親管理グループに移動します。
• "ロールの定義" の割り当て可能なスコープにサブスクリプションを追加します。
• ロールの定義内の割り当て可能なスコープを変更します。 この例では、階層の両方のブランチが定義に到達できるように、sandbox 管理グループからルート管理グループに割り当て可能なスコープを更新できます。
• もう一方の分岐の中で定義するカスタム ロールを新たに作成します。 この新しいロールでは、サブスクリプションのロールを変更する必要もあります。

制限事項

管理グループでカスタム ロールを使用するには、次の制限があります。

• 新しいロールの割り当て可能なスコープに定義できる管理グループは 1 つだけです。 この制限は、ロールの定義とロールの割り当てが切り離される状況の発生回数を減らすために設けられています。 この種の状況は、ロールを割り当てたサブスクリプションまたは管理グループが、そのロールの定義が存在しない別の親に移動されると発生します。
• DataActions が含まれるカスタム ロールを管理グループのスコープで割り当てることはできません。 詳細については、「カスタム ロールの制限事項」を参照してください。
• ロールの定義の割り当て可能なスコープに管理グループが存在するかどうかは、Azure Resource Manager では確認されません。 入力ミスや間違った管理グループ ID が記載されていても、ロールの定義は作成されます。

管理グループとサブスクリプションの移動

管理グループまたはサブスクリプションを別の管理グループの子に移動するには、次のものが必要です。

• 子のサブスクリプションまたは管理グループでの、管理グループの書き込みアクセス許可とロールの割り当ての書き込みアクセス許可。
  • 組み込みロールの例: 所有者
• 移動先の親管理グループに対する、管理グループの書き込みアクセス権限。
  • 組み込みロールの例: 所有者、共同作成者、管理グループ共同作成者
• 既存の親管理グループに対する、管理グループの書き込みアクセス権限。
  • 組み込みロールの例: 所有者、共同作成者、管理グループ共同作成者

次の例外があります: ターゲットまたは既存の親管理グループがルート管理グループである場合、このアクセス許可の要件は適用されません。 すべての新しい管理グループとサブスクリプションは既定でルート管理グループに追加されるため、項目を移動するためにこのグループに対するアクセス許可は不要です。

サブスクリプションの所有者ロールが現在の管理グループから継承される場合、移動先は制限されます。 サブスクリプションは、所有者ロールを持つ別の管理グループにのみ移動できます。 サブスクリプションの所有者ではなくなってしまうため、ご自分が共同作成者でしかない管理グループにサブスクリプションを移動できません。 サブスクリプションの所有者ロールに直接割り当てられている場合は、共同作成者のロールを持っている任意の管理グループに移動できます。

重要

Azure Resource Manager では、管理グループの階層の詳細が最大 30 分間キャッシュされます。 その結果、Azure portal で管理グループを移動したことがすぐには表示されない場合があります。

アクティビティ ログを使用して管理グループを監査する

管理グループは、Azure Monitor アクティビティ ログ内でサポートされます。 他の Azure リソースと同じ一元的な場所で、管理グループに発生するすべてのイベントのクエリを実行できます。 たとえば、特定の管理グループに対して行われた、ロールの割り当てまたはポリシーの割り当ての変更を、すべて確認できます。

Azure portal の外部にある管理グループに対してクエリを実行する場合、管理グループのターゲット スコープは "/providers/Microsoft.Management/managementGroups/{management-group-id}" のようになります。

Note

Azure Resource Manager REST API を使用することで、管理グループの診断設定を有効にして、関連する Azure アクティビティ ログ エントリを Log Analytics ワークスペース、Azure Storage、または Azure Event Hubs に送信できます。 詳細については、管理グループの診断設定 - 作成または更新についての記事をご覧ください。

関連するコンテンツ

管理グループについて詳しくは、以下をご覧ください。

• 管理グループを作成して Azure リソースを整理する
• 管理グループを変更、削除、または管理する
• リソース階層の保護