大規模な教育機関向けのマルチテナント アーキテクチャを設計する
小規模な教育機関には、シングルテナント アーキテクチャをお勧めします。 ただし、100 万人を超えるユーザーを持つ組織の場合は、Azure サブスクリプションやクォータなどのパフォーマンスの問題やテナントの制限、サービスの制限と制限Microsoft Entra軽減するためのマルチテナント アーキテクチャをお勧めします。
デザインの原則
マルチテナント アーキテクチャを設計するときは、コストを削減し、効率とセキュリティを向上させるために、次の設計原則を検討してください。
コストを削減する
オンプレミスインフラストラクチャと複数の ID プロバイダーへの依存を減らします。
ユーザーがセルフサービスを使用して自分のアカウントのロックを解除したり、パスワードをリセットしたりできます (たとえば、セルフサービス パスワード リセットMicrosoft Entra)。
効率の向上
管理上の問題を最小限に抑えるために、テナント全体のアーキテクチャ、構成、およびプロセスを標準化します。
ユーザーがテナント間を移動する必要性を最小限に抑える
セキュリティを強化する
学生データのセキュリティを確保することに重点を置きます。
最小特権の原則に従います。必要なタスクを実行し、Just In Time (JIT) アクセスを実装するために必要な特権のみを付与します。
エンタイトルメント管理または B2B コラボレーションMicrosoft Entra介してのみ外部ユーザーのアクセスを有効にします。
Just Enough Access (JEA) を使用して特定のユーザーに特定のタスクの管理を委任して、ジョブを実行します。
複数のテナントの一般的な理由
100 万人未満のユーザーを持つ組織では、他の条件で複数のテナントが必要であることを示していない限り、1 つのテナントを作成することを強くお勧めします。 100 万以上のユーザー オブジェクトを持つ組織の場合は、リージョンアプローチを使用して複数のテナントを使用することをお勧めします。
個別のテナントを作成すると、EDU 環境に次の効果があります。
管理上の分離
重要なリソースに影響を与える管理セキュリティまたは運用エラーの影響を制限する可能性があります。
侵害された管理者またはユーザー アカウントの影響を制限する可能性があります。
使用状況レポートと監査ログは、テナント内に含まれています。
リソースの分離
学生のプライバシー。 学生ユーザー オブジェクトは、オブジェクトが存在するテナント内でのみ検出できます。
リソースの分離。 別のテナント内のリソースは、他のテナントのユーザーと管理者によって検出または列挙することはできません。
オブジェクト フットプリント。 Microsoft Graph やその他の管理インターフェイスを介してMicrosoft Entra IDやその他の Microsoft Online サービスに書き込むアプリケーションは、ローカル テナント内のリソースにのみ影響する可能性があります。
クォータ。 テナント全体の Azure クォータと制限 の消費量は、他のテナントの使用量とは別です。
構成の分離
異なる構成要件を持つリソースと信頼アプリケーションに対応できる、テナント全体の設定の個別のセットを提供します。
Office 365などの Microsoft Online サービスの新しいセットを有効にします。
ユーザー数が 100 万人を超えるだけでなく、次の考慮事項によって複数のテナントが発生する可能性があります。
管理上の考慮事項
お客様は、市民権の国、居住国、クリアランス レベルなどの基準に基づいて環境を管理できるユーザーを制限する規制の下で運用します。
特定のローカル リージョンで ID を作成する必要がある学生データのプライバシーなどのコンプライアンス要件があります。
リソースに関する考慮事項
たとえば、研究開発のために、規制上またはビジネス上重要な理由から、既存の管理者による検出、列挙、または引き継ぎから保護する必要があるリソースがあります。
MS Graph などの API を使用してユーザーのデータを大規模に変更できるカスタム アプリケーションの開発サイクル (Directory.ReadWrite.All が付与されているアプリケーションなど)
構成に関する考慮事項
- 許可された認証の種類、デバイス管理ポリシー、セルフサービス機能、外部 ID の ID 証明など、既存のテナント全体のセキュリティまたはコラボレーション体制と競合する要件を持つリソース。
マルチテナント アプローチを決定する
このセクションでは、米国全体で100の学校に200万人の学生を持つ美術学校という架空の大学を考えてみましょう。 これらの学校には、合計 130,000 人の教師と 30,000 人の正社員とスタッフがいます。
複数のテナントをデプロイする場合は、次のようなリージョンアプローチをお勧めします。
まず、各リージョンに 100 万人未満のユーザーが含まれる地理的リージョンで、学生と教師のコミュニティを分割します。
リージョンごとにMicrosoft Entra テナントを作成します。
対応するリージョンのスタッフ、教師、学生をプロビジョニングして、コラボレーション エクスペリエンスを最適化します。
リージョンを使用する理由
テナント間を移動するユーザーの数を最小限に抑えるには、リージョンアプローチをお勧めします。 各学校レベル (たとえば、小学校、中学校、高校) のテナントを作成した場合は、各学年の終わりにユーザーを移行する必要があります。 代わりに、ユーザーが同じリージョンに残っている場合は、属性が変更されてもテナント間で移動する必要はありません。
リージョン アプローチのその他の利点は次のとおりです。
各リージョン内の最適なコラボレーション
他のテナントからのゲスト オブジェクトの最小数が必要です
テナントのユーザー数が 100 万人を超えると、管理エクスペリエンスとツールが時間の経過と同時に低下する傾向があります。 同様に、ユーザー 選択ウィンドウの使用などの一部のエンド ユーザー エクスペリエンスは、面倒で信頼性の低い状態になります。
説得力のある理由なしに複数のテナントをデプロイすることを選択する小規模な組織では、管理オーバーヘッドとユーザー移行の数が不必要に増加します。 これを行うには、テナント間でのコラボレーション エクスペリエンスを確保するための手順も必要になります。
Microsoft Entra B2B コラボレーションを使用してテナント間で共同作業を行う
B2B コラボレーションMicrosoft Entra、ユーザーは 1 つの資格情報セットを使用して複数のテナントにサインインできます。 教育機関の場合、B2B コラボレーションの利点は次のとおりです。
複数のテナントを管理する一元管理チーム
リージョン間の教師コラボレーション
保護者が自分の資格情報を使用してオンボーディングする
請負業者や研究者などの外部パートナーシップ
B2B コラボレーションでは、あるテナント (ホーム テナント) で作成されたユーザー アカウントがゲスト ユーザーとして別のテナント (リソース テナント) に招待され、ユーザーはホーム テナントの資格情報を使用してサインインできます。 管理者は、B2B コラボレーションを使用して、外部ユーザーが既存のソーシャル アカウントまたはエンタープライズ アカウントでサインインできるように、Facebook、Microsoft アカウント、Google、エンタープライズ ID プロバイダーなどの ID プロバイダーとのフェデレーションを設定することもできます。
メンバーとゲスト
Microsoft Entra テナント内のユーザーは、UserType プロパティに基づくメンバーまたはゲストのいずれかです。 既定では、メンバー ユーザーはテナントにネイティブなユーザーです。 既定では、Microsoft Entra B2B コラボレーション ユーザーが UserType = Guest を持つユーザーとして追加されます。 ゲストには、ディレクトリとアプリケーションでの アクセス許可が制限 されています。 たとえば、ゲスト ユーザーは、自分のプロファイル情報を超えてテナントから情報を参照することはできません。 ただし、ゲスト ユーザーは、ユーザー プリンシパル名 (UPN) または objectId を指定することで、別のユーザーに関する情報を取得できます。 ゲスト ユーザーは、ゲスト ユーザーの アクセス許可が制限されている 設定に関係なく、グループ メンバーシップを含む、所属するグループのプロパティを読み取ることもできます。
場合によっては、リソース テナントがゲストの代わりにホーム テナントのユーザーをメンバーとして扱いたい場合があります。 その場合は、Microsoft Entra B2B Invite Manager API を使用して、ホーム テナントからリソース テナントにメンバーとしてユーザーを追加または招待できます。 詳細については、「Microsoft Entra B2B コラボレーション ユーザーのプロパティ」を参照してください。
複数のテナントの一元管理
Microsoft Entra B2B を使用して外部 ID をオンボードする。 その後、外部 ID に特権ロールを割り当てて、Microsoft Entraテナントを一元化された IT チームのメンバーとして管理できます。 また、Microsoft Entra B2B を使用して、地域レベルまたは地区レベルの管理者などの他のスタッフ メンバーのゲスト アカウントを作成することもできます。
ただし、Exchange 管理者や SharePoint 管理者など、サービス固有のロールには、テナントにネイティブなローカル アカウントが必要です。
次のロールを B2B アカウントに割り当てることができます
アプリケーション管理者
アプリケーション開発者
認証管理者
B2C IEF キーセット管理者
B2C IEF ポリシー管理者
クラウド アプリケーション B2C IEF ポリシー管理者
クラウド デバイス B2C IEF ポリシー管理者
条件付きアクセス管理者
デバイス管理者
デバイス参加
デバイス ユーザー
ディレクトリ リーダー
ディレクトリ製作者
ディレクトリ同期アカウント
ユーザー フロー管理者の外部 ID
ユーザー フロー属性管理者の外部 ID
外部 ID プロバイダー
グループ管理者
ゲスト招待者
ヘルプデスク管理者
ハイブリッド ID 管理者
Intune サービス管理者
ライセンス管理者
パスワード管理者
特権認証管理者
特権ロール管理者
レポート閲覧者
制限付きゲスト ユーザー
セキュリティ管理者
セキュリティ閲覧者
ユーザー アカウント管理者
Workplace Device Join
Microsoft Entra IDのカスタム管理者ロールは、独自のカスタム ロールを作成および整理できるように、組み込みロールの基になるアクセス許可を表示します。 この方法では、必要なときにいつでも、組み込みのロールよりもきめ細かい方法でアクセスを許可できます。
複数のテナント間で委任して使用できる管理ロールに対する管理のしくみを示す例を次に示します。
Susie のネイティブ アカウントはリージョン 1 テナントにあり、Microsoft Entra B2B を使用して、リージョン 2 とリージョン 3 のテナントの中央 IT チームに認証管理者としてアカウントを追加します。
複数のテナント間でのアプリの使用
マルチテナント環境でのアプリの管理に関連する問題を軽減するには、 マルチテナント アプリの作成を検討する必要があります。 また、複数の IdP 接続をサポートする SaaS アプリを確認する必要もあります。 複数の IDP 接続をサポートする SaaS アプリでは、各テナントで個々の接続を構成する必要があります。 複数の IDP 接続をサポートしていない SaaS アプリでは、独立したインスタンスが必要になる場合があります。 詳細については、「方法: マルチテナント アプリケーション パターンを使用して任意のMicrosoft Entra ユーザーにサインインする」を参照してください。
注: ライセンス モデルは、SaaS アプリによって異なる場合があります。 マルチテナント環境で複数のサブスクリプションが必要かどうかを判断するには、ベンダーとチェックします。
テナントごとの管理
サービス固有のロールには、テナントごとの管理が必要です。 サービス固有のロールには、テナントにネイティブなローカル アカウントが必要です。 各テナントに一元化された IT チームを配置するだけでなく、Exchange、SharePoint、Teams などのワークロードを管理するには、各テナントにリージョン IT チームが必要です。
次のロールでは、各テナントにネイティブなアカウントが必要です
Azure DevOps 管理者
Azure Information Protection 管理者
課金管理者
CRM サービス管理者
コンプライアンス管理者
コンプライアンス データ管理者
カスタマー ロックボックス アクセス承認者
Desktop Analytics管理者
Exchange 管理者
Insights 管理者
Insights ビジネス リーダー
Kaizala 管理者
Lync サービス管理者
メッセージ センターのプライバシー閲覧者
メッセージ センター リーダー
プリンター管理者
プリンター技術者
検索管理者
検索エディター
セキュリティ オペレーター
サービス サポート管理者
SharePoint 管理者
Teams 通信管理者
Teams 通信サポート エンジニア
Teams 通信サポート スペシャリスト
Teams サービス管理者
各テナントの一意の管理者
各リージョンにネイティブな IT チームがある場合は、それらのローカル管理者のいずれかが Teams 管理を管理できます。 次の例では、Charles はリージョン 1 テナントに存在し、Teams サービス管理者の役割を持っています。 Alice と Ichiro はそれぞれリージョン 2 と 3 に存在し、それらのリージョンで同じ役割を果たします。 各ローカル管理者は、自分のリージョンにネイティブな 1 つのアカウントを持っています。
テナント間でのロールの管理
各リージョンにローカルの管理者プールがない場合は、Teams サービス管理者ロールを 1 人のユーザーのみに割り当てることができます。 このシナリオでは、次に示すように、中央 IT チームの Bob が、各テナントに Bob のローカル アカウントを作成することで、3 つのテナントすべてで Teams サービス管理者として機能させることができます。
テナント内の管理者ロールの委任
管理単位 (AU) を使用して、ユーザーとグループMicrosoft Entra論理的にグループ化する必要があります。 管理単位を使用して管理範囲を制限することは、異なる地域、地区、または学校で構成される教育機関で役立ちます。
たとえば、架空の美術学校は、それぞれが複数の学校を含む 3 つの地域に広がっています。 各リージョンには、アクセスを制御し、ユーザーを管理し、それぞれの学校のポリシーを設定する IT 管理者のチームがあります。
たとえば、IT 管理者は次の操作を行うことができます。
リージョン 1 の各学校のユーザーに AU を作成し、その学校のすべてのユーザーを管理します。 (画像なし)
教師アカウントを管理するために、各学校の教師を含む AU を作成します。
各学校の学生を含む個別の AU を作成して、学生アカウントを管理します。
学校の教師に学生 AU のパスワード管理者ロールを割り当てて、教師が学生のパスワードをリセットできますが、他のユーザーのパスワードをリセットできないようにします。
管理単位にスコープを設定できるロールは次のとおりです。
認証管理者
グループ管理者
ヘルプデスク管理者
ライセンス管理者
パスワード管理者
ユーザー管理者
詳細については、「 スコープ付きロールを管理単位に割り当てる」を参照してください。
テナント間管理
設定は、各テナントで個別に構成されます。 可能であれば、テナントの作成の一部としてを構成し、これらの設定を見直す必要を最小限に抑えます。 一部の一般的なタスクは自動化できますが、テナント間管理ポータルは組み込まれています。
大規模なオブジェクトの管理
Microsoft Graph (MS Graph) と Microsoft Graph PowerShell を使用すると、ディレクトリ オブジェクトを大規模に管理できます。 また、テナント内のほとんどのポリシーと設定を管理するためにも使用できます。 ただし、次のパフォーマンスに関する考慮事項を理解する必要があります。
MS Graph では、ユーザー、グループ、メンバーシップの変更の作成をテナントあたり 1 時間あたり 72,000 に制限します。
MS Graph のパフォーマンスは、テナント内の読み取りアクションや書き込みアクションなどのユーザー主導のアクションによって影響を受ける可能性があります
MS Graph のパフォーマンスは、テナント内の他の競合する IT 管理者タスクによって影響を受ける可能性があります
PowerShell、SDS、Microsoft Entra Connect、およびカスタム プロビジョニング ソリューションは、MS Graph を介してさまざまなレートでオブジェクトとメンバーシップを追加します
次の手順
「Microsoft Entra テナントの概要」を確認していない場合は、次を参照してください。