Microsoft Entra ID のシングル テナントでの安全なリソースの分離
多くの分離シナリオがシングル テナントで実現できます。 可能であれば、最高の生産性とコラボレーション エクスペリエンスを得るために、管理をシングル テナント内の個別の環境に委任することをお勧めします。
結果
リソースの分離 - ユーザー、グループ、およびサービス プリンシパルに対しリソース アクセスを制限するには、Microsoft Entra ディレクトリ ロール、セキュリティ グループ、条件付きアクセス ポリシー、Azure リソース グループ、Azure 管理グループ、管理単位 (AU)、その他の制御を使用します。 個別の管理者がリソースを管理できるようにします。 個別のユーザー、アクセス許可、およびアクセス要件を使用します。
次の場合は、複数のテナントで分離を行います。
- テナント全体の設定を必要とするリソース セット
- テナント メンバーによる未承認のアクセスに対するリスク許容度が最小限
- 構成の変更によって望ましくない影響が発生する
構成の分離 - アプリケーションなどのリソースが、認証方法やネームド ロケーションなどのテナント全体の構成への依存関係をもっている場合があります。 リソースを分離するときには、依存関係を考慮してください。 全体管理者は、リソースに影響を与えるリソース設定およびテナント全体の設定を構成できます。
一連のリソースで固有のテナント全体の設定が必要な場合、または別のエンティティがテナントの設定を管理している場合は、マルチ テナントで分離を行ってください。
管理の分離 - Microsoft Entra ID の委任された管理を使用して、アプリケーションおよび API、ユーザーおよびグループ、リソース グループ、条件付きアクセス ポリシーなどのリソースの管理を分離します。
全体管理者は、信頼できるリソースを検出して、そのリソースへのアクセス権を取得できます。 リソースに対する認証された管理者の変更の監査とアラートを設定してください。
Microsoft Entra ID で管理単位 (AU) を使用して管理の分離を行ってください。 管理単位では、ロールのアクセス許可が、組織の定義した部分に制限されます。 ヘルプデスク管理者ロールを地域のサポート スペシャリストに委任するには、AU を使用します。 すると、サポート スペシャリストはサポートしているリージョン内のユーザーを管理できます。
ユーザー、グループ、およびデバイス オブジェクトを分離するには、AU を使用します。 動的メンバーシップ グループのルールを使用して、ユニットを割り当ててください。
Privileged Identity Management (PIM) を使用して、より高い特権ロールの要求を承認するユーザーを選択してください。 たとえば、ユーザーの認証方法を変更するために認証管理者アクセスを必要とする管理者を選択します。
Note
PIM を使用するには、ユーザーごとに Microsoft Entra ID P2 ライセンスが必要です。
認証管理者がリソースを管理できないようにするには、別の認証管理者により、別のテナントにリソースを分離します。 バックアップにはこの方法を使用してください。 例については、マルチユーザー承認ガイダンスをご覧ください。
一般的な使用法
シングル テナントでの複数の環境の一般的な用法は、実稼働リソースを非実稼働リソースから分離することです。 テナントで、開発チームとアプリケーション所有者は、テスト アプリ、テスト ユーザーおよびグループ、それらのオブジェクトのテスト ポリシーを備えた別の環境を作成して管理します。 同様に、チームは Azure リソースと信頼されたアプリの非実稼働インスタンスを作成します。
非実稼働 Azure リソース、および、同等の非実稼働ディレクトリ オブジェクトを持つ Microsoft Entra 統合アプリケーションの非実稼働インスタンスを使用してください。 ディレクトリ内の非実稼働リソースはテスト用です。
Note
Microsoft Entra テナントに複数の Microsoft 365 環境を作成しないでください。 ただし、Microsoft Entra テナントに複数の Dynamics 365 環境は作成できます。
シングル テナントで分離するもう 1 つのシナリオは、場所、子会社、または階層化された管理での分離です。 「エンタープライズ アクセス モデル」をご覧ください。
Azure リソースのスコープ管理には、Azure ロールベースのアクセス制御 (Azure RBAC) の割り当てを使用します。 同様に、複数の機能を使用してアプリケーションを信頼する Microsoft Entra ID の Microsoft Entra ID 管理を有効にします。 例としては、条件付きアクセス、ユーザーとグループのフィルター処理、管理単位の割り当て、アプリケーションの割り当てなどがあります。
Microsoft 365 サービスの分離 (組織レベルの構成のステージングを含む) を行うには、マルチ テナントの分離を選択します。
Azure リソースのスコープを設定した管理
Azure RBAC を使用して、細分化されたスコープと表面領域を持つ管理モデルを設計します。 次の例の管理階層について考えてみます。
Note
組織の要件、制約、目標に基づいて管理階層を定義できます。 詳細については、Azure リソースの整理に関する「クラウド導入フレームワーク ガイダンス」をご覧ください。
- 管理グループ - 他の管理グループに影響を与えないように、特定の管理グループにロールを割り当てます。 上記のシナリオでは、HR チームは、Azure Policy を定義して、リソースがすべての HR サブスクリプションにデプロイされている領域を監査できます。
- サブスクリプション - 特定のサブスクリプションにロールを割り当てて、他のリソース グループに影響を与えないようにします。 上記の例では、HR チームは、他の HR サブスクリプションや他のチームのサブスクリプションを読み取ることなく、福利厚生サブスクリプションの閲覧者ロールを割り当てることができます。
- リソース グループ - ロールを特定のリソース グループに割り当てて、他のリソース グループに影響を与えないようにすることができます。 福利厚生エンジニアリング チームは共同作成者ロールを誰かに割り当てて、テスト データベースやテスト Web アプリを管理したり、リソースを追加したりできるようにします。
- 個々のリソース - ロールを特定のリソースに割り当てて、他のリソースに影響を与えないようにすることができます。 福利厚生エンジニアリング チームは、データ アナリストに、Azure Cosmos DB データベースのテスト インスタンスの Cosmos DB アカウント閲覧者ロールを割り当てます。 この作業は、テスト Web アプリや運用リソースに干渉しません。
詳細については、「Azure の組み込みロール」と「Azure RBAC とは何か」をご覧ください。
構造は階層型です。 したがって、階層が高いほど、スコープ、可視性、および下位レベルへの影響が広くなります。 最上位レベルのスコープは、Microsoft Entra テナント境界内の Azure リソースに影響します。 複数のレベルでアクセス許可を適用できます。 このアクションにより、リスクが生じます。 階層の上位のロールを割り当てると、階層の下位では意図したよりも多くのアクセスが提供される可能性があります。 Microsoft Entra では、リスクの軽減に役立つ可視性と修復が提供されます。
- ルート管理グループでは、サブスクリプションとリソースに適用される Azure ポリシーと RBAC ロールの割り当てを定義します。
- グローバル管理者は、サブスクリプションと管理グループについてアクセス権を昇格させることができます。
最上位レベルのスコープを監視します。 ネットワークなど、リソース分離の他のディメンションを計画することが重要です。 Azure ネットワークに関するガイダンスについては、「ネットワーク セキュリティに関する Azure のベスト プラクティス」をご覧ください。 サービスとしてのインフラストラクチャ (IaaS) ワークロードには、ID とリソースの分離を設計と戦略の一部とする必要があるシナリオがあります。
「Azure ランディング ゾーンの概念アーキテクチャ」に従って、機密性の高いリソースやテスト リソースを分離することを検討してください。 たとえば、分離された管理グループに ID サブスクリプションを割り当てます。 サンドボックス管理グループでの開発用の個別のサブスクリプション。 詳細については、「エンタープライズ スケールのドキュメント」をご覧ください。 テナント内でのテスト目的の分離については、「参照アーキテクチャの管理グループ階層」で考慮されています。
Microsoft Entra ID 信頼アプリケーションのスコープ管理
次のセクションでは、Microsoft Entra ID 信頼アプリケーションのスコープ管理のパターンについて概説します。
Microsoft Entra ID では、カスタム アプリと SaaS アプリの複数のインスタンスの構成がサポートされていますが、独立したユーザー割り当てがある同じディレクトリに対して、ほとんどの Microsoft サービスはサポートされていません。 上記の例には、旅行アプリの実稼働バージョンとテスト バージョンの両方が含まれています。 アプリ固有の構成とポリシーの分離を実現するには、企業テナントに対して実稼働前バージョンをデプロイします。 このアクションにより、ワークロード所有者は会社の資格情報を使用してテストを実行できます。 テスト ユーザーやテスト グループなどの非実稼働ディレクトリ オブジェクトは、それらのオブジェクトの個別の所有権を持つ非実稼働アプリケーションに関連付けられます。
Microsoft Entra テナント境界内の信頼アプリケーションに影響を与えるテナント全体の側面は次のとおりです。
- グローバル管理者は、テナント全体の設定をすべて管理します
- ユーザー管理者、アプリケーション管理者、条件付きアクセス管理者など、他のディレクトリ ロールでは、そのロールのスコープ内でテナント全体の構成を管理します。
認証方法、ハイブリッド構成、B2B Collaboration、ドメインの許可リスト、ネームド ロケーションなどの構成設定はテナント全体にわたるものです。
Note
Microsoft Graph API のアクセス許可と同意のアクセス許可を 1 グループまたは AU メンバーにスコープすることはできません。 これらのアクセス許可は、ディレクトリ レベルで割り当てられます。 リソース レベルのスコープを許可できるのはリソース固有の同意のみで、現在は、Microsoft Teams チャットのアクセス許可に制限されています。
重要
Office 365、Microsoft Dynamics、Microsoft Exchange などの Microsoft SaaS サービスのライフサイクルは、Microsoft Entra テナントにバインドされます。 その結果、これらのサービスの複数のインスタンスでは、複数の Microsoft Entra テナントが必要になります。