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 サブスクリプションの追加に関する記事を参照してください。

Diagram of a single Microsoft Entra tenant with Azure landing zones deployed.

前の図では、管理グループ、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 テナントが最適です。 マルチテナント モデルに移行すると、境界が作成され、ユーザーの摩擦、管理オーバーヘッドが発生し、攻撃対象領域が増加する可能性があるため、セキュリティ リスクが発生し、製品のシナリオと制限が複雑になる可能性があります。 次に例をいくつか示します。

組織は、企業の Microsoft Entra テナント モデルから逸脱する理由を明確にし、余分なオーバーヘッドと複雑さが要件を満たすために正当化されることを確認する必要があります。 これらのインスタンスの例については、シナリオに関するこちらの記事にあります。

グローバル管理者 (グローバル 管理) ロールも懸念事項です。 全体管理者ロールは、Microsoft Entra テナントで使用できる最高レベルのアクセス許可を提供します。 Azure では、すべての全体管理者が、Microsoft Entra テナントにリンクされている任意の Azure サブスクリプションの制御を引き受けることができます。 詳細については、「Azure のすべてのサブスクリプションと管理グループを管理する目的でアクセス権限を昇格させる」を参照してください。

重要

Microsoft Entra Privileged Identity Management を使って、Microsoft Entra ID と Azure 内でこのロールとその他の特権ロールを保護することをお勧めします。

ID チームと Azure チームは、多くの場合、異なるチーム、部門、組織構造に属しているため、社内チームと部門にまたがるこのロールの所有権が課題となる可能性があります。

Azure を運用するチームは Azure サービスを担当し、管理するサービスのセキュリティを確保したいと考えています。 その環境にアクセスする権限を持つロールをそのチーム外の個人が持っている場合、セキュリティは弱くなります。 詳細については、「必要なクラウドの職務の概要」を参照してください。

Microsoft Entra ID には、技術的なレベルでこの問題を軽減するのに役立つコントロールが用意されていますが、この問題は人とプロセスに関するディスカッションでもあります。 詳細については、「推奨事項」を参照してください。

重要

複数の Microsoft Entra テナントは、ほとんどのお客様に推奨されないアプローチです。 1 つの Microsoft Entra テナント (通常は企業の Microsoft Entra テナント) は、必要な分離要件を満たすことができるので、ほとんどのお客様に推奨されます。

詳細については、以下を参照してください:

次のステップ