組織が複数の 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 テナントに統合されます。 この統合により、管理オーバーヘッドが削減され、コラボレーション エクスペリエンスが向上し、1 つのブランド ID が他の企業や組織に提供されます。
重要
カスタム ドメイン名 (contoso.comなど) は、一度に 1 つの Microsoft Entra テナントにのみ関連付けることができます。 そのため、合併または買収のシナリオが発生したときに、すべての ID で単一のカスタム ドメイン名を使用できるため、テナントの統合が推奨されます。
2 つの Microsoft Entra テナントを 1 つに統合する複雑さのため、テナントが単独のままになり、長期間または無期限に分離されたままになる場合があります。
このシナリオは、他の組織が将来会社を買収する可能性があるため、組織または企業が分離したままにしたい場合にも発生する可能性があります。 組織が Microsoft Entra テナントを分離し続け、それらを統合しない場合、1 つのエンティティの将来の合併または買収がある場合の作業は少なくなります。
規制または国/地域のコンプライアンス要件
一部の組織には、厳密な規制または国/地域のコンプライアンス管理とフレームワークがあります (例: UK Official、Sarbanes Oxley (SOX)、NIST)。 組織は、これらのフレームワークを満たし、準拠するために複数の Microsoft Entra テナントを作成する場合があります。
データ所在地の規制が厳しい世界中にオフィスやユーザーがいる組織によっては、複数の Microsoft Entra テナントも作成される場合があります。 ただし、この特定の要件は、通常、Microsoft 365 Multi-Geoなどの機能を使用して、単一の Microsoft Entra テナント内で対処されます。
もう 1 つのシナリオは、組織が Azure Government (米国政府)
ヒント
Azure 国内/リージョン クラウドの ID シナリオの詳細については、次を参照してください。
前のシナリオと同様に、組織に準拠する規制または国/地域のコンプライアンス フレームワークがある場合は、既定のアプローチとして複数の Microsoft Entra テナントを必要としない場合があります。 ほとんどの組織は、Privileged Identity Management や 管理単位などの機能を使用して、単一の Microsoft Entra テナント内のフレームワークに準拠できます。
部署または組織の分離と自律性の要件
組織によっては、複数の部署にまたがる複雑な内部構造がある場合や、組織の一部間で高度な分離と自律性が必要になる場合があります。
このシナリオが発生し、1 つのテナント でのリソース分離
このようなシナリオでは、これらの複数のテナントのデプロイ、管理、運用を担当する一元化された機能が存在しない方が一般的です。 代わりに、独立した部署または組織の一部に完全に引き継がれ、実行と管理が行われます。 一元化されたアーキテクチャ、戦略、または 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 テナントを分離している可能性があります。 また、Azure サブスクリプションがホストし、エンド カスタマーに提供する SaaS アプリケーションを配信する別の Microsoft Entra テナントがある場合もあります。 このアプローチは、セキュリティ インシデントからユーザーと顧客を保護するため、一般的で賢明です。
詳細については、Azure ランディング ゾーン
テナント レベルのテスト / 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 テナント 、環境 (開発/テストなど) に関係なく、ワークロードを含む Azure サブスクリプションをホストするための ではありません。 開発/テスト環境であっても、代わりに通常の "運用" Microsoft Entra テナントに含める必要があります。
ヒント
Azure ランディング ゾーンと Azure ランディング ゾーン環境内の Azure ワークロードまたはリソースのテストを処理する方法については、次を参照してください。
草の根 / シャドウIT / スタートアップ
チームが迅速にイノベーションを行いたい場合は、可能な限り迅速に移行できるように、個別の Microsoft Entra テナントを作成できます。 意図的または意図せずに、イノベーションを行うために Azure 環境にアクセスするための中央/プラットフォーム チームのプロセスとガイダンスを回避する可能性があります。
このシナリオは、スタートアップ企業がビジネスとサービスを実行、ホスト、運用するために独自の Microsoft Entra テナントを設定する場合に一般的です。 通常は想定されますが、スタートアップが取得されると、追加の Microsoft Entra テナントによって、取得する組織の IT チームが今後の処理を決定する決定ポイントが作成されます。
このシナリオをナビゲートする方法の詳細については、この記事の「合併と買収」のセクション および独立系ソフトウェア ベンダー (ISV) 提供する SaaS アプリケーションを Azure セクションで参照してください。
重要
プラットフォーム チームには、組織の企業またはプライマリ Microsoft Entra テナントに所属する Azure サンドボックス サブスクリプションまたはサブスクリプションへのアクセス権をチームに付与する、簡単にアクセスできる効率的なプロセスを用意することを強くお勧めします。 このプロセスにより、シャドウ IT シナリオが発生するのを防ぎ、関係するすべての関係者の将来の課題を防ぐことができます。
サンドボックスの詳細については、「管理グループのガイダンス」を参照してください。リソース組織の設計領域。
概要
シナリオで詳しく説明するように、組織で複数の Microsoft Entra テナントが必要になる理由はいくつかあります。 ただし、これらのシナリオの要件を満たすために複数のテナントを作成すると、複雑さと運用タスクが追加され、複数のテナントが維持され、ライセンス要件のコストが追加される可能性があります。 詳細については、「マルチテナント シナリオでの Azure ランディング ゾーンの考慮事項と推奨事項」を参照してください。