Azure 管理グループとは

[アーティクル]
04/20/2023

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

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

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

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

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

サンプル管理グループの階層の図。

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

注意

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

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

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

1 つのディレクトリでは、10,000 個の管理グループをサポートできます。
管理グループのツリーは、最大 6 レベルの深さをサポートできます。
- この制限には、ルートレベルまたはサブスクリプションレベルは含まれません。
各管理グループとサブスクリプションは、1 つの親のみをサポートできます。
各管理グループには、多数の子を含めることができます。
すべてのサブスクリプションと管理グループは、各ディレクトリの 1 つの階層内に存在します。「ルート管理グループに関する重要な事実」を参照してください。

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

各ディレクトリには、ルート管理グループと呼ばれる 1 つの最上位管理グループがあります。このルート管理グループは階層に組み込まれており、すべての管理グループとサブスクリプションはルート管理グループにまとめられます。ルート管理グループにより、グローバルポリシーと Azure ロールの割り当てをディレクトリレベルで適用できます。 Azure AD 全体管理者は自分自身を昇格させて、最初にこのルートグループのユーザーアクセス管理者ロールにする必要があります。アクセス権の昇格後、管理者は、任意の Azure ロールを他のディレクトリユーザーまたはグループに割り当てて階層を管理することができます。管理者の場合は、自分のアカウントをルート管理グループの所有者として割り当てることができます。

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

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

重要

ルート管理グループでのユーザーのアクセス権またはポリシーは、ディレクトリ内のすべてのリソースに適用されます。そのため、すべてのユーザーは、このスコープで定義されている項目を所有する必要性を評価する必要があります。ユーザーアクセスやポリシーの割り当ては、このスコープでのみ「必須」である必要があります。

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

ユーザーが管理グループの使用を開始する際には、初期セットアッププロセスが発生します。最初の手順として、ディレクトリでルート管理グループが作成されます。このグループが作成されると、ディレクトリ内に存在するすべての既存のサブスクリプションがルート管理グループの子になります。このプロセスが実行される理由は、ディレクトリ内に管理グループ階層が 1 つだけ存在するようにするためです。ディレクトリ内に 1 つの階層が存在することにより、ディレクトリ内の他のユーザーがバイパスできないグローバルアクセス権とポリシーを管理ユーザーが適用できるようになります。ルートに割り当てられている内容はすべて、階層全体に適用されます。これには、この Azure AD テナント内におけるすべての管理グループ、サブスクリプション、リソースグループ、リソースが含まれます。

管理グループアクセス

Azure 管理グループでは、すべてのリソースアクセスとロール定義について、Azure のロールベースのアクセス制御 (Azure RBAC) がサポートされます。これらのアクセス許可は、階層内に存在する子リソースに継承されます。管理グループには任意の Azure ロールを割り当てることができます。ロールは階層を継承し、各リソースに割り当てられます。たとえば、VM 共同作成者の Azure ロールは、管理グループに割り当てることができます。このロールには、管理グループに対するアクションはありませんが、その管理グループに属するすべての VM に継承されます。

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

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

*: [管理グループ共同作成者]、[管理グループ閲覧者] の各ロールを使用すると、ユーザーは管理グループスコープでのみこれらのアクションを実行できます。

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

階層内の項目の移動について詳しくは、「Manage your resources with management groups (管理グループを使用してリソースを管理する)」を参照してください。

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

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

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

実際に見た方がわかりやすいので、ある階層のごく一部分を例に見てみましょう。

サンプル管理グループの階層のサブセットの図。

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

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

このシナリオを解決するためには、いくつかの選択肢があります。

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

制限事項

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

新しいロールの割り当て可能なスコープに定義できる管理グループは 1 つだけです。この制限は、ロールの定義とロールの割り当てが切り離される状況の発生回数を減らすために設けられています。この状況は、ロールを割り当てたサブスクリプションまたは管理グループが、そのロールの定義が存在しない別の親に移動されると発生します。
管理グループのカスタムロールでリソースプロバイダーデータプレーンのアクションを定義することはできません。この制限は、データプレーンリソースプロバイダーを更新する際の待ち時間の問題があるために設けられています。この待ち時間の問題は現在対応中であり、これらのアクションは、リスクを軽減するためにロールの定義では無効にされる予定です。
ロールの定義の割り当て可能なスコープに管理グループが存在するかどうかは、Azure Resource Manager では確認されません。入力ミスや間違った管理グループ ID が記載されていても、ロールの定義は作成されます。

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

管理グループまたはサブスクリプションを別の管理グループの子に移動するには、3 つのルールが true として評価されなければなりません。

移動操作を行う際は、次のことが必要です。

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

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

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

重要

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

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

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

選択した管理グループに関連するアクティビティログと操作のスクリーンショット。

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

注意

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

次のステップ

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