Azure 管理グループとは

組織に多数のサブスクリプションがある場合は、これらのサブスクリプションのアクセス、ポリシー、およびコンプライアンスを効率的に管理する方法が必要になることがあります。 Azure 管理グループの範囲は、サブスクリプションを上回ります。 "管理グループ" と呼ばれるコンテナーにサブスクリプションを整理して、管理グループに管理条件を適用できます。 管理グループ内のすべてのサブスクリプションは、管理グループに適用された条件を自動的に継承します。 管理グループを使うと、サブスクリプションの種類に関係なく、大きな規模でエンタープライズ レベルの管理を行うことができます。 単一の管理グループ内のすべてのサブスクリプションは、同じ Azure Active Directory テナントを信頼する必要があります。

たとえば、仮想マシン (VM) の作成に使えるリージョンを制限するポリシーを管理グループに適用できます。 そのリージョンでの VM の作成を許可するだけで、その管理グループの下にあるすべての管理グループ、サブスクリプション、リソースに、このポリシーが適用されます。

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

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

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

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

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

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

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

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

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

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

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

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

重要

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

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

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

サブスクリプションの表示の問題

2018 年 6 月 25 日より前のプレビューで初期に管理グループの使用を開始した数個のディレクトリでは、一部のサブスクリプションが階層内にないという問題が発生していました。 すべてのサブスクリプションを階層に含めるプロセスは、ディレクトリ内のルート管理グループに対してロールまたはポリシーの割り当てが行われた後に導入されました。

この問題を解決する方法

この問題を解決するためのオプションは 2 つあります。

  • ルート管理グループからすべてのロールとポリシーの割り当てを削除します
    • ルート管理グループからすべてのポリシーとロールの割り当てを削除することによって、次の夜間サイクルで、すべてのサブスクリプションがサービスにより階層にバックフィルされます。 このプロセスの目的は、テナントのサブスクリプションに誤ってアクセスやポリシーの割り当てが行われないようにすることです。
    • サービスに影響を与えずにこのプロセスを実行する最善の方法として、ルート管理グループの 1 つ下のレベルのロールまたはポリシー割り当てを適用します。 次に、ルート スコープからすべての割り当てを削除します。
  • API を直接呼び出して、バックフィル プロセスを開始します
    • ディレクトリ内の任意のユーザーは、TenantBackfillStatusRequest API または StartTenantBackfillRequest API を呼び出すことができます。 StartTenantBackfillRequest API が呼び出されると、すべてのサブスクリプションを階層に移動する初期セットアップ プロセスが開始されます。 このプロセスでは、すべての新しいサブスクリプションが強制的にルート管理グループの子になります。 このプロセスを実行するには、ルート レベルで割り当てを変更する必要があります。 この API を呼び出すことで、ルートに対するポリシーまたはアクセスの割り当てをすべてのサブスクリプションに適用できることを示します。

このバックフィル プロセスについて質問がある場合は、managementgroups@microsoft.com までお問い合わせください。

管理グループ アクセス

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

*:MG Contributor と MG Reader は、管理グループのスコープのみでのこれらのアクションの実行をユーザーに許可します。
**: ルート管理グループに対するロールの割り当ては、それとの間でのサブスクリプションまたは管理グループの移動に必要ありません。 階層内の項目の移動について詳しくは、「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 つの項目間には関係があるため、割り当てをその定義から切り離そうとするとエラーが発生します。

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

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

この図では、子の IT およびマーケティング管理グループを持つルート管理グループに焦点を当てています。 IT 管理グループには、運用環境という名前の子マネージメント管理グループが 1 つありますが、マーケティング管理グループには無料試用版の子サブスクリプションが 2 つあります。

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

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

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

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

制限事項

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

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

重要

AssignableScopes への管理グループの追加は、現在プレビューの段階です。 このプレビュー バージョンはサービス レベル アグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。

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

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

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

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

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

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

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

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

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

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

次のステップ

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