複数の Microsoft Entra テナントのシナリオ
組織が複数の Microsoft Entra テナントを必要とする理由、または調査した方がよい理由はいくつかあります。 最も一般的なシナリオは、次のとおりです。
- 合併と買収
- 規制または国/地域のコンプライアンス要件
- 部署または組織の分離と自律性の要件
- Azure から SaaS アプリケーションを提供する独立系ソフトウェア ベンダー (ISV)
- テナント レベルのテスト/Microsoft 365 のテスト
- グラスルーツ/シャドウ IT/スタートアップ
合併と買収
組織が時間の経過とともに成長するにつれて、他の企業や組織を買収することがあります。 これらの買収先では、Microsoft 365 (Exchange Online、SharePoint、OneDrive、Teams)、Dynamics 365、Microsoft Azure などのサービスをホストして提供する既存の Microsoft Entra テナントが既に確立されている可能性があります。
通常、買収の場合、2 つの Microsoft Entra テナントは 1 つの Microsoft Entra テナントに統合されます。 この統合により、管理オーバーヘッドが削減され、コラボレーション エクスペリエンスが向上し、他の企業や組織に単一のブランド ID が提供されます。
重要
カスタム ドメイン名 (例: contoso.com) は、一度に 1 つの Microsoft Entra テナントにのみ関連付けることができます。 そのため、合併または買収のシナリオが発生した際は、1 つのカスタム ドメイン名をすべての ID で使用できるため、テナントの統合をお勧めします。
2 つの Microsoft Entra テナントを 1 つに統合することは複雑であるため、テナントが長期間または無期限に放置され、分離されたままになる可能性があります。
このシナリオは、他の組織が将来その会社を買収する可能性があるため、組織または企業が分離したままにしておきたい場合にも発生する可能性があります。 組織が Microsoft Entra テナントを分離したままにして、統合しなければ、将来的に 1 つのエンティティの合併または買収が行われた場合の作業は少なくなります。
規制または国/地域のコンプライアンス要件
一部の組織には、厳格な規制または国/地域のコンプライアンス コントロールとフレームワーク (UK Official、Sarbanes Oxley (SOX)、NIST など) があります。 組織は、これらのフレームワークに対応し、準拠するために複数の Microsoft Entra テナントを作成する場合があります。
世界中にオフィスやユーザーが所在する、データ所在地の規制が厳しい組織も、複数の Microsoft Entra テナントを作成する場合があります。 ただし、この特定の要件は、通常、Microsoft 365 Multi-Geo などの機能を使って、1 つの Microsoft Entra テナント内で対処されます。
もう 1 つのシナリオは、組織が Azure Government (米国政府) または Azure China (21Vianet が運営) を必要とする場合です。 これらの国内の Azure クラウド インスタンスには、独自の Microsoft Entra テナントが必要です。 その Microsoft Entra テナントは、その国の Azure クラウド インスタンス専用であり、その Azure クラウド インスタンス内の Azure サブスクリプション ID およびアクセス管理サービスに使われます。
ヒント
Azure 国内/地域クラウドの ID シナリオの詳細については、次をご覧ください。
前のシナリオと同様に、準拠すべき規制または国/地域のコンプライアンス フレームワークが組織にある場合に、既定のアプローチとして複数の Microsoft Entra テナントが必要ない場合があります。 ほとんどの組織は、Privileged Identity Management や管理単位などの機能を使用して、1 つの Microsoft Entra テナント内でフレームワークに準拠できます。
部署または組織の分離と自律性の要件
組織によっては、複数の部署にまたがる複雑な内部構造を持つ場合や、組織の各部分間で高度な分離と自律性が必要になる場合があります。
このシナリオが発生し、「シングル テナントでのリソースの分離」のツールとガイダンスでは必要なレベルの分離を提供できない場合、複数の Microsoft Entra テナントのデプロイ、管理、操作が必要になる場合があります。
このようなシナリオでは、これらの複数のテナントのデプロイ、管理、運用を担当する一元化された機能が存在しないことがより一般的です。 代わりに、独立した部署または組織の一部に完全に引き継がれ、実行と管理が行われます。 一元化されたアーキテクチャ、戦略、または CCoE スタイル チームは、別の Microsoft Entra テナントで構成する必要があるベスト プラクティスに関するガイダンスと推奨事項を引き続き提供する場合があります。
警告
運用上の役割と責任がある組織では、組織の Microsoft Entra テナントを運用するチーム間で課題が発生します。 Azure では、2 つのチーム間で明確な RACI を作成し合意することを優先させる必要があります。 このアクションにより、両方のチームが作業し、組織にサービスを提供し、タイムリーにビジネスに価値を提供できるようになります。
一部の組織には、Azure を使用するクラウド インフラストラクチャと開発チームが存在します。 これらの組織は、サービス プリンシパルの作成またはグループの作成と管理を行うために、企業の Microsoft Entra テナントを制御する ID チームに依存しています。 合意した RACI がない場合、多くの場合、チーム間のプロセスと理解が不足し、チームや組織全体の間での摩擦につながります。 複数の Microsoft Entra テナントがこの課題を克服する唯一の方法であると考えている組織もあります。
ただし、複数の Microsoft Entra テナントによってエンド ユーザーに課題が生じ、複数のテナントのセキュリティ保護、管理、運用の複雑さが増し、ライセンス コストが増加する可能性があります。 Microsoft Entra ID P1 または P2 などのライセンスは、複数の Microsoft Entra テナントにまたがりません。 場合によっては、Microsoft Entra B2B を使うと、一部の機能やサービスのライセンスの重複が軽減されることがあります。 デプロイで Microsoft Entra B2B を使う予定の場合は、各機能と Microsoft Entra B2B の適格性に関するサービスのライセンス条項とサポート可能性を確認してください。
このような状況の組織は、回避策として複数の Microsoft Entra テナントを作成するのではなく、1 つの Microsoft Entra テナントでチームが共同作業できるように運用上の課題を解決する必要があります。
Azure から SaaS アプリケーションを提供する独立系ソフトウェア ベンダー (ISV)
SaaS (サービスとしてのソフトウェア) 製品を顧客に提供する ISV は、Azure を使用するために複数の Microsoft Entra テナントを持つことでメリットが得られる場合があります。
ISV の場合、メール、ファイル共有、内部アプリケーションなどの通常のビジネス アクティビティに対し、Azure の使用を含めて企業の Microsoft Entra テナントと分離していることがあります。 また、エンド カスタマーに提供する SaaS アプリケーションを Azure サブスクリプションがホストおよび配信する別の Microsoft Entra テナントがある場合もあります。 このアプローチは、ユーザーとその顧客をセキュリティ インシデントから保護するため、一般的で理にかなっています。
詳細については、「Azure ランディング ゾーンに関する独立系ソフトウェア ベンダー (ISV) の考慮事項」を参照してください。
テナント レベルのテスト/Microsoft 365 のテスト
Microsoft Cloud の製品、サービス、オファリングの一部のアクティビティと機能は、別の Microsoft Entra テナントでのみテストできます。 いくつかの例を次に示します。
- Microsoft 365 – Exchange Online、SharePoint、Teams
- Microsoft Entra ID - Microsoft Entra Connect、Microsoft Entra ID Protection のリスク レベル、SaaS アプリケーション
- Microsoft Graph API を使用し、運用環境に影響を与え、変更を加えることができるテスト スクリプト
前のシナリオのようなテストを実行する場合は、別の Microsoft Entra テナントが唯一の選択肢です。
ただし、別の Microsoft Entra テナントは、環境 (Dev/Test など) に関係なく、ワークロードを含む Azure サブスクリプションをホストするためのものではありません。 それどころか、Dev/Test 環境であっても、通常の "運用" Microsoft Entra テナントに含める必要があります。
ヒント
Azure ランディング ゾーンと、Azure ランディング ゾーン環境内の Azure ワークロードまたはリソースのテストを処理する方法については、次を参照してください。
グラスルーツ/シャドウ IT/スタートアップ
チームが迅速にイノベーションを起こしたい場合は、可能な限り迅速に移行できるように、別の Microsoft Entra テナントを作成できます。 意図的または意図的でないかに関わらず、イノベーションを起こすために、Azure 環境にアクセスするための中央/プラットフォーム チームのプロセスとガイダンスを回避する可能性があります。
このシナリオは、独自の Microsoft Entra テナントを設定して、企業やサービスの実行、ホスト、運用を行うスタートアップにおいて一般的です。 一般的に想定されることですが、スタートアップが買収されると、この追加の Microsoft Entra テナントは、買収した組織の IT チームが今後どうするかを決定する、意思決定ポイントとなります。
このシナリオをナビゲートする方法の詳細については、この記事の「合併と買収」および「Azure から SaaS アプリケーションを提供する独立系ソフトウェア ベンダー (ISV)」セクションを参照してください。
重要
組織の企業またはプライマリ Microsoft Entra テナントに属する 1 つまたは複数の Azure サンドボックス サブスクリプションへのアクセス権をチームに付与するために、簡単にアクセスできる効率的なプロセスを、プラットフォーム チームに用意することを強くお勧めします。 このプロセスは、シャドウ IT シナリオの発生を防ぎ、関係者の将来的な課題を回避します。
サンドボックスの詳細については、リソースの編成の設計領域内の管理グループのガイダンスを参照してください。
まとめ
シナリオで詳しく説明したように、組織で複数の Microsoft Entra テナントが必要になる理由はいくつかあります。 ただし、これらのシナリオの要件を満たすために複数のテナントを作成すると、複数のテナントを維持するための複雑さと運用タスクが追加され、ライセンス要件のためのコストが追加される可能性があります。 詳細については、「マルチテナントの Azure ランディング ゾーン シナリオに関する考慮事項と推奨事項」を参照してください。