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