マルチ テナントでのリソースの分離
1 つのテナント境界内で管理を委任してもニーズを満たさない、特定のシナリオがあります。 このセクションでは、マルチテナント アーキテクチャの作成が必要になる場合がある要件について説明します。 組織の中には、2 つ以上の Microsoft Entra テナントを使用しているマルチテナントの組織もあります。 この場合、テナント間で独自のコラボレーションを行ったり、独自の管理要件を設定したりすることが必要な場合があります。 マルチテナント アーキテクチャでは、管理のオーバーヘッドと複雑さが増すため、注意して使用する必要があります。 シングル テナントでニーズを満たすことができる場合は、そのアーキテクチャを使用することをお勧めします。 詳しくは、「マルチテナント ユーザー管理」をご覧ください。
個別のテナントによって新しい境界が作成されるため、前のセクションで説明したように、Microsoft Entra ディレクトリ ロール、ディレクトリ オブジェクト、条件付きアクセス ポリシー、Azure リソース グループ、Azure 管理グループ、およびその他のコントロールの分離された管理が行われます。
個別のテナントは、組織の IT 部門が、Intune、Microsoft Entra Connect、ハイブリッド認証構成などの Microsoft サービスでテナント全体の変更を検証しながら、組織のユーザーとリソースを保護するのに役立ちます。 これには、テナント全体に影響を与える可能性があり、運用テナント内のユーザーのサブセットにスコープを設定できないテスト サービス構成が含まれます。
MS Graph または類似の API を使用して、運用ユーザー オブジェクトのデータを変更する可能性があるカスタム アプリケーション (たとえば、Directory.ReadWrite.All または同様の広いスコープが付与されているアプリケーション) の開発中に、運用環境以外の環境を個別のテナントにデプロイすることが必要になる場合があります。
Note
複数のテナントへの Microsoft Entra Connect 同期。これは運用環境以外の環境を個別のテナントにデプロイするときに便利なことがあります。 詳細については、「Microsoft Entra Connect: サポートされるトポロジ」を参照してください。
結果
前述のようなシングル テナント アーキテクチャで実現した結果に加えて、組織は次に示すようにリソースとテナントの相互作用を完全に分離できます。
リソースの分離
可視性 - 分離したテナント内のリソースは、他のテナントのユーザーおよび管理者が検出または列挙することができません。 同様に、使用状況レポートと監査ログは新しいテナント境界内に含められます。 この可視性の分離により、組織では機密プロジェクトに必要なリソースを管理できます。
オブジェクト占有領域 - Microsoft Graph やその他の管理インターフェイスを介して Microsoft Entra ID や他の Microsoft Online サービスに書き込むアプリケーションは、個別のオブジェクト領域で動作できます。 これにより、開発チームはソフトウェア開発ライフサイクル中に他のテナントに影響を与えることなくテストを実行できます。
クォータ - テナント全体の Azure クォータと制限の使用量は、他のテナントの使用量とは別です。
構成の分離
新しいテナントには、そのテナント レベルで異なる構成を必要とする要件を持つ、リソースと信頼する側のアプリケーションに対応できる、個別のテナント全体の設定のセットが用意されています。 さらに、新しいテナントでは、Office 365 などの新しい Microsoft Online サービスのセットが提供されます。
管理上の分離
新しいテナント境界には、別個の Microsoft Entra ディレクトリ ロールのセットが含まれています。これにより、さまざまな管理者のセットを構成できます。
一般的な使用法
次の図は、複数のテナントでのリソース分離の一般的な使用方法を示しています。これは、シングル テナントの委任された管理で実現できるよりももっと多くの分離を必要とする、実稼働前環境または "サンドボックス" 環境です。
Contoso は、ContosoSandbox.com と呼ばれる実稼働前テナントを使用して企業テナント アーキテクチャを強化した組織です。 サンドボックス テナントは、Microsoft Graph を使用して Microsoft Entra ID と Microsoft 365 に書き込むエンタープライズ ソリューションの継続的な開発をサポートするために使用されます。 これらのソリューションは、企業テナントにデプロイされます。
サンドボックス テナントがオンラインになることで、開発中のアプリケーションが、テナント リソースを消費してクォータに影響を与えたり、調整したりすることで運用システムに直接または間接的に影響を与えないようにします。
開発者は、開発ライフサイクル中にサンドボックス テナントにアクセスする必要があります。このとき、運用環境で制限されている追加のアクセス許可を必要とするセルフサービス アクセスで行うことが理想的です。 これらの追加のアクセス許可の例としては、ユーザー アカウントの作成、削除、更新のほか、アプリケーションの登録、Azure リソースのプロビジョニングとプロビジョニング解除、ポリシーまたは環境の全体的な構成の変更などがあります。
この例では、Contoso は Microsoft Entra B2B Collaboration を使用して企業テナントからのユーザーをプロビジョニングし、複数の資格情報を管理せずにサンドボックス テナント内のアプリケーションのリソースを管理およびアクセスできるユーザーを有効にします。 この機能は、主に組織間コラボレーション シナリオを対象としています。 ただし、Contoso のような複数のテナントを持つ企業では、この機能を使用して、資格情報のライフサイクル管理が増えたりユーザー エクスペリエンスが複雑になったりすることを回避できます。
External Identities クロステナント アクセス設定を使用して、B2B コラボレーションを通じて他の Microsoft Entra 組織とコラボレーションを行う方法を管理します。 これらの設定によって、お客様のリソースに対して外部 Microsoft Entra 組織の受信アクセス ユーザーが持つレベルと、お客様のユーザーが外部組織に対して持つ送信アクセスのレベルの両方が決まります。 また、他の Microsoft Entra 組織からの多要素認証 (MFA) とデバイスの信頼性情報 (準拠している信頼性情報と Microsoft Entra ハイブリッド参加済みを使用した信頼性情報) を信頼できるようになります。 詳細と計画に関する考慮事項については、Microsoft Entra 外部 ID でのクロステナント アクセスに関するページを参照してください。
もう 1 つの方法として、Microsoft Entra Connect の機能を利用して、同じオンプレミスの Microsoft Entra 資格情報を複数のテナントに同期し、同じパスワードを維持しながらユーザー UPN ドメインで区別するという方法もあります。
マルチテナントのリソースの分離
新しいテナントでは、別個の管理者セットがあります。 組織は Microsoft Entra B2B コラボレーションを通じて企業 ID を使用することを選択できます。 同様に、組織では Azure リソースのテナント間の管理のために Azure Lighthouse を実装できるため、非運用の Azure サブスクリプションを、運用の Azure サブスクリプションの ID で管理できます。 Azure Lighthouse は、Microsoft Intune などの Azure 外部のサービスの管理には使用できません。 マネージド サービス プロバイダー (MSP) 向けの Microsoft 365 Lighthouse は、Microsoft 365 Business Premium、Microsoft 365 E3、またはWindows 365 Business を使っている中小規模企業 (SMB) の顧客向けに、デバイス、データ、ユーザーを大規模にセキュリティで保護して管理するための管理ポータルです。
これによりユーザーは、分離のベネフィットを享受しながら企業の資格情報を引き続き使用できます。
サンドボックス テナント内の Microsoft Entra B2B コラボレーションは、Azure B2B の許可/拒否リストを使用して、企業環境からの ID のみをオンボードできるように構成する必要があります。 B2B に許可する必要があるテナントの場合は、クロステナント多要素認証やデバイスの信頼用に、External Identities クロステナント アクセス設定を使用することを検討してください。
重要
外部 ID アクセスが有効になっているマルチテナント アーキテクチャでは、リソースの分離のみが提供されますが、ID の分離は有効化されません。 Microsoft Entra B2B コラボレーションと Azure Lighthouse を使用したリソース分離では、ID に関連するリスクは軽減されません。
サンドボックス環境で ID が企業環境と共有される場合、サンドボックス テナントには次のシナリオが適用されます。
企業テナント内のユーザー、デバイス、またはハイブリッド インフラストラクチャを侵害する悪意のあるアクターが、サンドボックス テナントに招待された場合、サンドボックス テナントのアプリとリソースにアクセスできる可能性があります。
企業テナントの操作エラー (ユーザー アカウントの削除や資格情報の失効など) によって、サンドボックス テナントへの招待されたユーザーのアクセスに影響が出る可能性があります。
非常に防御的なアプローチを必要とするビジネス クリティカルなリソースに対し、リスク分析を行い、複数のテナントによる ID 分離を検討する必要があります。 Azure Privileged Identity Management は、ビジネス クリティカルなテナントとリソースへのアクセスに対して追加のセキュリティを強制することで、リスクをいくらか軽減するのに役立ちます。
ディレクトリ オブジェクト
リソースの分離に使用するテナントには、プライマリ テナントと同じ種類のオブジェクト、Azure リソース、および信頼する側のアプリケーションが含まれている場合があります。 次のオブジェクトの種類をプロビジョニングする必要がある場合があります。
ユーザーとグループ: 次のようなソリューション エンジニアリング チームが必要とする ID。
サンドボックス環境管理者。
アプリケーションの技術所有者。
基幹業務アプリケーション開発者。
テスト エンド ユーザー アカウント。
これらの ID は、次の目的でプロビジョニングされる場合があります。
Microsoft Entra B2B コラボレーションを通じて企業アカウントを持つ従業員。
管理、緊急管理アクセス、またはその他の技術的な理由でローカル アカウントを必要とする従業員。
非運用のオンプレミス Active Directory を持っているかそれを必要とするお客様は、基になるリソースとアプリケーションによって必要な場合、自分のオンプレミス ID をサンドボックス テナントに同期することもできます。
デバイス: 非運用テナントでは、ソリューション エンジニアリング サイクルで必要な程度にデバイス数が減ります。
管理ワークステーション
開発、テスト、およびドキュメントに必要な非運用コンピューターとモバイル デバイス
アプリケーション
Microsoft Entra 統合アプリケーション: 次のためのアプリケーション オブジェクトとサービス プリンシパル:
運用環境にデプロイされているアプリケーションのテスト インスタンス (たとえば、Microsoft Entra ID や Microsoft オンライン サービス に書き込むアプリケーション)。
運用以外のテナントを管理および維持するためのインフラストラクチャ サービス。企業テナントで使用できるソリューションのサブセットである可能性があります。
Microsoft Online Services:
通常、運用環境で Microsoft Online Services を所有するチームは、それらのサービスの非運用インスタンスを所有しているチームである必要があります。
運用環境以外のテスト環境の管理者は、これらのサービスが特にテストされている場合を除き、Microsoft Online Services をプロビジョニングしないでください。 これにより、テスト環境での運用 SharePoint サイトの設定など、Microsoft サービスの不適切な使用を回避できます。
同様に、エンド ユーザーによって開始できる Microsoft Online サービス (アドホック サブスクリプションとも呼ばれます) のプロビジョニングはロックダウンする必要があります。 詳細については、「Microsoft Entra ID のセルフサービス サインアップについて」を参照してください。
一般に、グループベースのライセンスを使用して、テナントに対して重要でないライセンス機能をすべて無効にする必要があります。 これは、ライセンス機能を有効にすることの影響を知らないことがある開発者による構成ミスを回避するために、運用テナント内のライセンスを管理するのと同じチームが行う必要があります。
Azure リソース
信頼する側のアプリケーションによって必要なすべての Azure リソースもデプロイできます。 たとえば、データベース、仮想マシン、コンテナー、Azure Functions などです。 サンドボックス環境では、使用できるセキュリティ機能が少ない製品やサービスについて、低価格の SKU を使用するというコスト削減を検討する必要があります。
テストの終了後に変更が運用環境にレプリケートされる場合は、アクセス制御用の RBAC モデルを運用環境以外の環境で引き続き使用する必要があります。 これを行わないと、非運用環境のセキュリティ上の欠陥が運用テナントに反映されます。
複数のテナントを使用したリソースと ID の分離
分離の結果
リソースの分離だけでは要件を満たせない、限定的な状況があります。 マルチテナント アーキテクチャでのリソースと ID の両方の分離は、すべてのクロステナント コラボレーション機能を無効にし、個別の ID 境界を実質的に構築することによって行うことができます。 この方法は、運用エラーと、企業テナント内のユーザー ID、デバイス、またはハイブリッド インフラストラクチャの侵害に対する防御です。
分離の一般的な使用法
個別の ID 境界は、通常、顧客向けサービスなどのビジネス クリティカルなアプリケーションやリソースに使用されます。 このシナリオでは、Fabrikam は、従業員の ID 侵害が SaaS の顧客に影響を与えるリスクを回避するために、顧客向けの SaaS 製品用に個別のテナントを作成することを決定しました。 次の図に、このアーキテクチャを示します。
FabrikamSaaS テナントには、Fabrikam のビジネス モデルの一部として顧客に提供されるアプリケーションに使用される環境が含まれています。
ディレクトリ オブジェクトの分離
FabrikamSaas のディレクトリ オブジェクトは、次のようになります。
ユーザーとグループ: ソリューション IT チーム、カスタマー サポート スタッフ、またはその他の必要な担当者が必要とする ID が SaaS テナント内に作成されます。 分離を維持するために、ローカル アカウントのみが使用され、Microsoft Entra B2B コラボレーションは有効になっていません。
Azure AD B2C ディレクトリ オブジェクト: テナント環境が顧客によってアクセスされる場合、Azure AD B2C テナントとそれに関連付けられている ID オブジェクトが含まれている可能性があります。 これらのディレクトリを保持するサブスクリプションは、分離されたコンシューマー向け環境に適しています。
デバイス: このテナントでは含まれるデバイスの数が少なくなり、以下のような、顧客向けソリューションを実行するために必要なもののみとなります。
セキュリティで保護された管理ワークステーション。
サポート担当者のワークステーション (前述のように "待機中" のエンジニアが含まれる場合があります)。
アプリケーションの分離
Microsoft Entra 統合アプリケーション: 次のためのアプリケーション オブジェクトとサービス プリンシパル:
運用アプリケーション (マルチテナント アプリケーション定義など)。
顧客向けの環境を管理および維持するためのインフラストラクチャ サービス。
Azure リソース: 顧客向けの運用インスタンスの IaaS、PaaS、SaaS リソースをホストします。