組織では多くの場合、合併と買収、規制要件、または管理上の境界により、複数のテナントを管理する必要があります。 どのようなシナリオであっても、Microsoft Entra は、テナント間でアカウントをプロビジョニングし、シームレスなコラボレーションを促進するための柔軟ですぐに使用可能なソリューションを提供します。 Microsoft Entra は次の 3 つのモデルに対応しており、組織の進化するニーズに適応できます。
- ハブ アンド スポーク
- メッシュ型
- Just-In-Time
ハブ アンド スポーク
ハブ アンド スポーク トポロジには、次の 2 つの一般的なパターンがあります。
オプション 1 (アプリケーション ハブ): このオプションでは、一般的に使用されるアプリケーションを、組織全体のユーザーがアクセスできる中央ハブ テナントに統合できます。
オプション 2 (ユーザー ハブ): 一方、オプション 2 では、すべてのユーザーを 1 つのテナント内で一元管理し、リソースが管理されるスポーク テナントにユーザーをプロビジョニングします。
実際のシナリオをいくつか調べ、それらがこれらの各モデルとどのように一致するかを見てみましょう。
合併と買収 (アプリケーション ハブ)
合併と買収では、すぐにコラボレーション可能にする機能がとても重要であり、それにより、IT で複雑な意思決定が行われている間も企業間で連携して機能することができます。 たとえば、新しく買収された会社の従業員が、社内ヘルプ デスクアプリ チケット システムなどのアプリケーションやベネフィット アプリケーションにすぐにアクセスする必要がある場合、テナント間同期が非常に重要です。 この同期プロセスにより、買収された企業のユーザーを初日からアプリケーション ハブにプロビジョニングし、SaaS アプリ、オンプレミスのアプリケーション、その他のクラウド リソースへのアクセスを許可できます。 ターゲット テナント内で、管理者はアクセス パッケージを設定して、ビジネス クリティカルなデータを含む Salesforce や Amazon Web Services などの追加アプリケーションへの時間制限付きアクセスを許可できます。 次の図は、最近買収したテナント (左側) とそのユーザーを示しています。ユーザーは、親会社のテナントにプロビジョニングされ、必要なリソースへのアクセスが許可されます。
コラボレーションとリソースのテナントを分離する (ユーザー ハブ)
組織が Azure の使用を拡大するにつれて、多くの場合、重要な Azure リソースを管理するための専用テナントが作成されます。 一方、ユーザー プロビジョニングは中央のハブ テナントに依存します。 このモデルにより、ハブ テナントの管理者は中央のセキュリティとガバナンスのポリシーを確立できるようになり、開発チームでは必要な Azure リソースをデプロイするための自律性と機敏性が向上します。 テナント間同期では、管理者がユーザーのサブセットをスポーク テナントにプロビジョニングし、それらのユーザーのライフサイクルを管理できるようにすることで、このトポロジがサポートされます。
メッシュ型
単一のテナント内でユーザーを一元管理している企業もあれば、アプリケーション、HR システム、Active Directory ドメインが各テナントに統合された分散構造を採用している企業もあります。 テナント間同期では、各テナントにプロビジョニングするユーザーを柔軟に選択できます。
ポートフォリオ企業内でのコラボレーション (部分メッシュ)
このシナリオでは、各テナントは、同一の親組織内の異なる企業を表しています。 各テナントの管理者は、ターゲット テナントにプロビジョニングするユーザーのサブセットを選択します。 このソリューションは、ユーザーが重要なリソースにアクセスする必要がある場合にコラボレーションを促進しながら、各テナントが個別に動作するための柔軟性を提供します。
テナント間同期は一方向です。 内部メンバー ユーザーは、外部ユーザーとして複数のテナントに同期できます。 トポロジが双方向で同期が行われていることを示している場合、それは各方向の個別のユーザー セットであり、各矢印は個別の構成です。
事業単位間でのコラボレーション (フルメッシュ)
このシナリオでは、組織は事業単位ごとに異なるテナントを指定します。 事業単位は、特に Microsoft Teams を使用して密接に連携します。 その結果、各テナントは、組織内の 4 つのテナント全体ですべてのユーザーをプロビジョニングすることを選択しました。 新しいユーザーが入社したり退職したりすると、プロビジョニング サービスによってユーザーの作成と削除が行われます。 組織では、4 つのテナントすべてを含むマルチテナント組織も構成されています。 ユーザーが Teams でコラボレーションを行う必要があるときは、会社全体でユーザーを簡単に見つけて、それらのユーザーとのチャットや会議を開始できます。
Just-In-Time
これまで説明したシナリオは組織内のコラボレーションを対象としていますが、組織間のコラボレーションが不可欠な場合もあります。 これは、合弁事業や独立した法人の組織の場合に該当する可能性があります。 接続された組織とエンタイトルメント管理を採用すると、接続された組織間でリソースにアクセスするためのポリシーを定義し、ユーザーが必要なリソースへのアクセスを要求可能にできます。
合弁事業
複数年にわたる合弁事業に従事する別個の組織である Contoso と Litware について考えてみましょう。 両社は、緊密にコラボレーションを行う必要があります。 Contoso の管理者は、Litware ユーザーが必要とするリソースを含むアクセス パッケージを定義しています。 Litware の新入社員が Contoso のリソースにアクセスする必要がある場合、このアクセス パッケージへのアクセスを要求できます。 承認されると、その社員が必要なリソースを使用してプロビジョニングされます。 アクセスは、時間制限が設けられたり、Contoso のガバナンス要件に準拠するために定期的に見直されたりする場合があります。
次の図は、2 つの組織が、接続された組織とエンタイトルメント管理を使用して Just-In-Time でコラボレーションを行う方法を示しています。
サポートされるシナリオ
テナント間同期では、ソース テナントに内部ユーザーをインポートし、ターゲット テナントで外部ユーザーをプロビジョニングできます。
| ソース テナントの資格情報 | ソース テナントの userType | ターゲット テナントの資格情報 | ターゲット テナントの userType | サポートされるシナリオ |
|---|---|---|---|---|
| 内部 | メンバー | 外部 | メンバー | あり |
| 内部 | メンバー | 外部 | ゲスト | あり |
| 内部 | ゲスト | 外部 | メンバー | あり |
| 内部 | ゲスト | 外部 | ゲスト | あり |
| 内部 | メンバー | 内部 | メンバー | いいえ |
| 内部 | メンバー | 内部 | ゲスト | いいえ |
| 内部 | ゲスト | 内部 | メンバー | いいえ |
| 内部 | ゲスト | 内部 | ゲスト | いいえ |
| 外部 | メンバー | 外部 | メンバー | いいえ |
| 外部 | メンバー | 外部 | ゲスト | いいえ |
| 外部 | ゲスト | 外部 | メンバー | いいえ |
| 外部 | ゲスト | 外部 | ゲスト | いいえ |