Azure ランディング ゾーンと複数の Microsoft Entra テナント
Azure ランディング ゾーンは、管理グループに基づいて構築されています。 組織がセキュリティとコンプライアンスのニーズを満たすために必要なガバナンス コントロールを提供するために、Azure ポリシーが割り当てられ、サブスクリプションが管理グループに配置されます。
ヒント
Azure ランディング ゾーンと Azure Policy を使用して組織のセキュリティ、コンプライアンス、および規制のニーズを実現する方法については、「Azure ランディング ゾーンでのセキュリティ コントロールのマッピング」を参照してください。
これらのリソースは、1 つの Microsoft Entra テナント内にデプロイされます。 管理グループと、Azure Policy などのその他のほとんどの Azure リソースでは、1 つの Microsoft Entra テナント内での操作のみがサポートされます。 Azure サブスクリプションは、コントロール プレーン操作に関して Azure Resource Manager (ARM) に対してユーザー、サービス、デバイスを認証する Microsoft Entra テナント、データ プレーン操作に関して一部の Azure サービス (Azure Storage など) に依存しています。
複数のサブスクリプションが同じ Microsoft Entra テナントに依存することができます。 各サブスクリプションは、1 つの Microsoft Entra テナントにのみ依存できます。 詳細については、テナントへの既存の Azure サブスクリプションの追加に関する記事を参照してください。
前の図では、管理グループ、Azure Policy、Azure サブスクリプションが Azure ランディング ゾーンの概念アーキテクチャに従って、1 つの Microsoft Entra テナント内にデプロイされています。
このアプローチは、要件に基づいてほとんどの組織に推奨されます。 このアプローチにより、組織は可能な限り最高のコラボレーション エクスペリエンスを実現し、1 つの Microsoft Entra テナント内でユーザーとリソースを制御、管理、分離できます。
組織では、多くのシナリオで複数の Microsoft Entra テナントを使用する必要がある場合があります。 これらの各テナントに Azure ランディング ゾーンのデプロイをデプロイして管理する方法と、複数の Microsoft Entra テナントを処理するための考慮事項と推奨事項を確認してください。
Note
この記事では、Microsoft 365 やその他の Microsoft Cloud オファリング (Dynamics 365や Power Platform など) ではなく、Azure に焦点を当てています。
テナントのプラットフォーム上に構築されたアプリケーションではなく、プラットフォームに焦点を当てています。 複数の Microsoft Entra テナントとアプリケーション アーキテクチャの詳細については、以下を参照してください。
1 つの Microsoft Entra テナントで十分な理由
複数の Microsoft Entra テナントが必要になる理由もいくつかありますが、通常は 1 つの Microsoft Entra テナントで十分である理由を理解することが重要です。 これは、すべての組織の既定の出発点である必要があります。
既存の企業の Microsoft Entra テナントを Azure サブスクリプションに使用して、プラットフォーム全体で最高の生産性とコラボレーション エクスペリエンスを実現します。
開発チームとアプリケーション所有者は、1 つのテナント内で、Azure リソースと信頼できるアプリの非運用インスタンス、テスト アプリ、テスト ユーザーとグループ、およびそれらのオブジェクトのテスト ポリシーを作成するための最小限の特権ロールを持つことができます。 1 つのテナントで管理を委任する方法の詳細については、「シングル テナントでのリソースの分離」を参照してください。
企業の Microsoft Entra テナントを使用しても満たされない要件がある場合にのみ、追加の Microsoft Entra テナントを作成します。
Microsoft 365 では、企業の Microsoft Entra テナントは、通常、組織で最初にプロビジョニングされるテナントです。 このテナントは、企業アプリケーションへのアクセスと Microsoft 365 サービスに使用されます。 これは組織内のコラボレーションをサポートします。 この既存のテナントから開始する理由は、既にプロビジョニング、管理、セキュリティ保護されているためです。 ID の定義済みのライフサイクルが既に確立されている可能性があります。 このコースを使用すると、新しいアプリ、リソース、サブスクリプションを簡単にオンボードできます。 成熟し理解された環境であり、確立されたプロセス、手順、コントロールがあります。
複数の Microsoft Entra テナントの複雑さ
新しい Microsoft Entra テナントを作成する場合、ID のプロビジョニング、管理、セキュリティ保護、管理に追加の作業が必要になります。 また、必要なポリシーと手順も確立しなければなりません。 コラボレーションには 1 つの Microsoft Entra テナントが最適です。 マルチテナント モデルに移行すると、境界が作成され、ユーザーの摩擦、管理オーバーヘッドが発生し、攻撃対象領域が増加する可能性があるため、セキュリティ リスクが発生し、製品のシナリオと制限が複雑になる可能性があります。 次に例をいくつか示します。
- 各テナントのユーザーと管理者の複数の ID - Microsoft Entra B2B を使用していない場合、ユーザーは複数の資格情報のセットを管理する必要があります。 詳細については、「マルチテナントの Azure ランディング ゾーン シナリオに関する考慮事項と推奨事項」を参照してください。
- 複数の Microsoft Entra テナントのサポートにおける Azure サービスの制限 - バインド先のテナントに所属する ID のみをサポートする Azure ワークロード。 詳細については、Azure 製品とサービスの Microsoft Entra との統合に関するページを参照してください。
- Microsoft Entra テナントの一元的な構成または管理がない - 複数のセキュリティ ポリシー、管理ポリシー、構成、ポータル、API、JML (入社、異動、退職) プロセス。
- Microsoft Entra ID P1 または P2 ライセンスの課金とライセンスの複雑さ、ライセンス重複の潜在的な要件 - 詳細については、「マルチテナントの Azure ランディング ゾーン シナリオに関する考慮事項と推奨事項」を参照してください。
組織は、企業の Microsoft Entra テナント モデルから逸脱する理由を明確にし、余分なオーバーヘッドと複雑さが要件を満たすために正当化されることを確認する必要があります。 これらのインスタンスの例については、シナリオに関するこちらの記事にあります。
重要
Microsoft Entra ID および Azure 内の特権ロールを保護するには、Microsoft Entra Privileged Identity Management を使用します。
ID チームと Azure チームが別々のチーム、部門、組織構造に所属していることが多いため、複数の社内のチームや部門にまたがる特権ロールの所有が問題になる可能性があります。
Azure を運用するチームは Azure サービスを担当し、管理するサービスのセキュリティを確保したいと考えています。 その環境にアクセスする権限を持つロールをそのチーム外の個人が持っている場合、セキュリティは弱くなります。 詳細については、「必要なクラウドの職務の概要」を参照してください。
Microsoft Entra ID には、技術的なレベルでこの問題を軽減するのに役立つコントロールが用意されていますが、この問題は人とプロセスに関するディスカッションでもあります。 詳細については、「推奨事項」を参照してください。
重要
複数の Microsoft Entra テナントは、ほとんどのお客様に推奨されないアプローチです。 1 つの Microsoft Entra テナント (通常は企業の Microsoft Entra テナント) は、必要な分離要件を満たすことができるので、ほとんどのお客様に推奨されます。
詳細については、以下を参照してください: