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