管理グループ
管理グループ を使用して、Azure サブスクリプションの整理と管理をします。 サブスクリプションの数が増えるにつれて、管理グループによる Azure 環境の構造化と、サブスクリプション管理の容易化が重要になります。 次のガイダンスを使用して、効果的な管理グループ階層を構築し、ベスト プラクティスに従ってサブスクリプションを整理します。
管理グループの設計に関する考慮事項
Microsoft Entra テナント内の管理グループの構造では、組織のマッピングがサポートされています。 組織でその Azure の大規模導入を計画する場合、管理グループの構造について十分に検討してください。
組織が特定のチームによって所有または運用されているサービスを分離する方法を決定します。
ビジネス要件、運用要件、規制要件、データ所在地、データ セキュリティ、データ主権コンプライアンスなどの理由で、個別に保持する必要がある特定の機能があるかどうかを判断します。
管理グループを使用すると、Azure Policy を介してポリシーとイニシアティブの割り当てを集約できます。
Azure のロールベースのアクセス制御 (RBAC)の認可は、管理グループの操作に対して有効にすると、デフォルトの認可をオーバーライドします。 既定では、icrosoft Entra テナント内の、サービス プリンシパルまたはサービス プリンシパルなどの任意のプリンシパルは、新しい管理グループを作成できます。 詳細については、「リソース階層を保護する方法」を参照してください。
また、次の要因についても検討してください。
管理グループのツリーでは、最大 6 レベルの深さまでサポートできます。 この制限には、テナント ルート レベルまたはサブスクリプション レベルは含まれません。
既定では、新しいサブスクリプションはすべてテナント ルート管理グループに配置されます。
詳細については、「管理グループ」を参照してください。
管理グループの推奨事項
できる限り、管理グループの階層は、3 ないし 4 レベル以下のある程度フラットなものにします。 この制限により、管理のオーバーヘッドと複雑さが軽減されます。
組織構造を深い入れ子になった管理グループ階層に複製しないでください。 管理グループは、ポリシーの割り当てと課金のために使用します。 このアプローチでは、Azure ランディング ゾーンの概念アーキテクチャで目的に合った管理グループを使用する必要します。 このアーキテクチャでは、同じ管理グループ レベルで同じ種類のセキュリティとコンプライアンスを必要とするワークロードに対して Azure ポリシーが提供されます。
ホストするワークロードの種類を表す管理グループをルート レベルの管理グループの下に作成します。 これらのグループは、ワークロードのセキュリティ、コンプライアンス、接続性、機能のニーズに基づきます。 このグループ化構造を使用すると、管理グループ レベルで一連の Azure ポリシーを適用できます。 このグループ化構造を、同じセキュリティ、コンプライアンス、接続性、および機能設定を必要とするすべてのワークロードに使用します。
リソース タグを使用して、管理グループ階層全体に対してクエリを実行し、水平方向に移動します。 Azure Policy を使用して、リソース タグを実装または追加できます。 これにより、複雑な管理グループ階層を使用しなくても、検索のニーズに合わせてリソースをグループ化できます。
運用環境に移動する前にリソースをすぐに試すことができるように、最上位のサンドボックス管理グループを作成します。 サンドボックスは、開発、テスト、運用の各環境から分離されています。
共通プラットフォーム ポリシーと Azure ロールの割り当てをサポートするには、ルート管理グループの下にプラットフォーム管理グループを作成します。 このグループ化構造では、Azure 基盤のサブスクリプションにさまざまなポリシーを確実に適用できます。 この方法では、共通リソースへの課金が、1 つの基盤サブスクリプション セットで集中管理されます。
ルート管理グループのスコープで Azure Policy の割り当ての数を制限します。 この制限により、下位レベルの管理グループで継承されるポリシーのデバッグが最小限に抑えられます。
ポリシーを使用して、管理グループまたはサブスクリプション スコープでコンプライアンス要件を適用し、ポリシー主導型のガバナンスを実現します。
テナントで管理グループを操作できるのは特権ユーザーのみであることを確認します。 管理グループ階層設定で Azure RBAC 承認を有効にして、ユーザー特権を絞り込みます。 既定では、すべてのユーザーがルート管理グループの下に独自の管理グループを作成できます。
新しいサブスクリプションの既定の専用管理グループを構成します。 このグループにより、ルート管理グループの下にどのサブスクリプションも移動しないようにします。 このグループは、ユーザーが Microsoft Developer Network (MSDN) または Visual Studio の特典とサブスクリプションを持っている場合に特に重要です。 この種類の管理グループの候補としては、サンドボックス管理グループがあります。 詳細については、「デフォルト管理グループの設定」を参照してください。
運用、テスト、および開発環境用の管理グループを作成しないでください。 必要に応じて、これらのグループを同じ管理グループ内の異なるサブスクリプションに分割します。 詳細については、以下を参照してください:
マルチリージョンデプロイには、標準の Azure ランディング ゾーン管理グループ構造を使用することをお勧めします。 異なる Azure リージョンをモデル化するためだけに管理グループを作成しないでください。 リージョンまたはマルチリージョンの使用状況に基づいて管理グループの構造を変更したり拡張したりしないでください。
データ所在地、データ セキュリティ、データ主権などの場所ベースの規制要件がある場合は、場所に基づいて管理グループ構造を作成する必要があります。 この構造は、さまざまなレベルで実装できます。 詳細については、「Azure ランディング ゾーン アーキテクチャの変更」を参照してください。
Azure ランディング ゾーン アクセラレータと ALZ-Bicep リポジトリ内の管理グループ
次の例では、管理グループの構造を示します。 この例の管理グループは、Azure ランディング ゾーン アクセラレータと ALZ-Bicep リポジトリの管理グループ モジュール 内にあります。
Note
managementGroups.bicep を編集することで、Azure ランディング ゾーン bicep モジュールで、管理グループ階層を変更できます。
| 管理グループ | 説明 |
|---|---|
| 中間ルート管理グループ | この管理グループは、テナント ルート グループの直下にあります。 組織は、ルート グループを使用する必要がないように、この管理グループにプレフィックスを付けます。 組織は、既存の Azure サブスクリプションを階層に移動できます。 このアプローチでは、将来のシナリオも設定されます。 この管理グループは、Azure ランディング ゾーン アクセラレータによって作成された他のすべての管理グループの親です。 |
| プラットフォーム | この管理グループには、管理、接続性、ID など、すべてのプラットフォームの子管理グループが含まれています。 |
| 管理 | この管理グループには、管理、監視、およびセキュリティのための専用のサブスクリプションが含まれています。 このサブスクリプションでは、関連付けられているソリューションや Azure Automation アカウントを含む Azure Monitor Logs ワークスペースがホストされます。 |
| 接続 | この管理グループには、接続性のための専用のサブスクリプションが含まれています。 このサブスクリプションでは、Azure Virtual WAN、Azure Firewall、Azure DNS Private Zones など、プラットフォームに必要な Azure ネットワーク リソースがホストされます。 さまざまなリソース グループを使用して、さまざまなリージョンにデプロイされている仮想ネットワーク、ファイアウォール インスタンス、仮想ネットワーク ゲートウェイなどのリソースを含めることができます。 一部の大規模なデプロイでは、接続リソースのサブスクリプション クォータ制限が適用される場合があります。 接続リソースの各リージョンに専用サブスクリプションを作成できます。 |
| ID | この管理グループには、ID のための専用のサブスクリプションが含まれています。 このサブスクリプションは、Active Directory Domain Services (AD DS) 仮想マシン (VM) または Microsoft Entra Domain Services のプレースホルダーです。 さまざまなリソース グループを使用して、さまざまなリージョンにデプロイされている仮想ネットワークや VM などのリソースを含めることができます。 また、このサブスクリプションでは、ランディング ゾーン内のワークロードに対して AuthN または AuthZ も有効になります。 ID サブスクリプション内のリソースを強化および管理するために、特定の Azure ポリシーが割り当てられます。 一部の大規模なデプロイでは、接続リソースのサブスクリプション クォータ制限が適用される場合があります。 接続リソースの各リージョンに専用サブスクリプションを作成できます。 |
| ランディング ゾーン | すべてのランディング ゾーンの子管理グループを含む親管理グループ。 ワークロードがセキュリティで保護され、準拠するように、ワークロードに依存しない Azure ポリシーが割り当てられます。 |
| オンライン | オンライン ランディング ゾーン用の専用管理グループです。 このグループは、直接的なインターネットの受信または送信接続を必要とする可能性があるワークロード、または仮想ネットワークを必要としない可能性があるワークロード用です。 |
| 企業 | 企業ランディング ゾーン用の専用管理グループです。 このグループは、接続サブスクリプションのハブ経由で企業ネットワークとの接続またはハイブリッド接続を必要とするワークロード用です。 |
| サンドボックス | サブスクリプション専用管理グループ 組織は、テストと探索にサンドボックスを使用します。 これらのサブスクリプションは、企業およびオンライン ランディング ゾーンから安全に分離されます。 また、サンドボックスには、Azure サービスのテスト、探索、構成を有効にするために割り当てられる、制限の少ない一連のポリシーもあります。 |
| 使用停止 | 取り消されるランディング ゾーンの専用管理グループ。 取り消されたランディング ゾーンは、この管理グループに移動され、30 日から 60 日後に Azure によって削除されます。 |
Note
多くの組織では、既定の Corp および Online 管理グループが理想的な始点となります。
一部の組織では、さらに管理グループを追加する必要があります。
管理グループ階層を変更する場合は、「要件を満たすように Azure ランディング ゾーン アーキテクチャを調整する」を参照してください。
Azure ランディング ゾーン アクセラレータのアクセス許可
Azure ランディング ゾーン アクセラレータ:
管理グループ操作、サブスクリプション管理操作、ロールの割り当てを実行するには、専用のサービス プリンシパル名 (SPN) が必要です。 SPN を使用すると、昇格された権利を持つユーザーの数が減り、最小特権ガイドラインに従うことになります。
SPN にルート レベルでのアクセス権を付与するには、ルート管理グループのスコープでユーザー アクセス管理者ロールが必要です。 SPN にアクセス権がある場合、ユーザー アクセス管理者ロールを安全に削除できます。 この方法により、SPN のみがユーザー アクセス 管理者ロールに接続されます。
ルート管理グループのスコープで、ルート管理グループ スコープで前述の SPN の共同作成者ロールが必要です。これにより、テナント レベルの操作が可能になります。 このアクセス許可レベルでは、その SPN を使用して、組織内の任意のサブスクリプションに対するリソースのデプロイと管理を確実に行うことができあます。
次のステップ
Azure の大規模な導入を計画している場合のサブスクリプションの使用方法について説明します。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示