次の方法で共有

シングル テナントでのリソースの分離

  • [アーティクル]

多くの分離シナリオは、シングル テナント内で実現できます。 可能であれば、組織に最適な生産性とコラボレーション エクスペリエンスを提供するために、管理をシングル テナント内で個別の環境に委任することをお勧めします。

結果

リソースの分離 - Microsoft Entra ディレクトリ ロール、セキュリティ グループ、条件付きアクセス ポリシー、Azure リソース グループ、Azure 管理グループ、管理単位 (AU)、その他の制御を使用して、特定のユーザー、グループ、およびサービス プリンシパルに対してリソース アクセスを制限できます。 リソースは別個の管理者によって管理することができ、別個のユーザー、アクセス許可、アクセス要件をもつことができます。

一連のリソースで固有のテナント全体の設定が必要な場合、またはテナント メンバーによる未承認アクセスに対するリスク許容度が最小限である場合、または構成の変更によって重大な影響が発生する可能性がある場合は、マルチ テナント間での分離を実現する必要があります。

構成の分離 - アプリケーションなどのリソースが、認証方法やネームド ロケーションなどのテナント全体の構成への依存関係をもっている場合があります。 リソースを分離するときには、これらの依存関係を考慮する必要があります。 全体管理者は、リソースに影響を与えるリソース設定およびテナント全体の設定を構成できます。

一連のリソースで固有のテナント全体の設定が必要な場合、またはテナントの設定を別のエンティティによって管理する必要がある場合は、マルチ テナントで分離を実現する必要があります。

管理の分離 - Microsoft Entra ID の委任された管理を使用すると、アプリケーションと API、ユーザーとグループ、リソース グループ、条件付きアクセス ポリシーなどのリソースの管理を分離できます。

全体管理者は、信頼できるリソースを検出して、そのリソースへの完全なアクセスを取得できます。 監査とアラートを設定して、リソースが認証されている場合に管理者がリソースを変更するとそれを知ることができます。

Microsoft Entra ID で管理単位 (AU) を使用して、ある程度の管理の分離を提供することもできます。 管理単位では、ロールのアクセス許可が、組織の任意の定義部分に限定されます。 たとえば、管理単位を使用して、ヘルプデスク管理者のロールを地域のサポート スペシャリストに委任できます。そうすれば、そのスペシャリストが自分のサポートするリージョンのユーザーのみを管理できます。

管理単位を示す図。

管理単位を使用して、ユーザー、グループ、デバイス オブジェクトを分離できます。 これらの単位の割り当ては、動的メンバーシップ ルールによって管理できます。

Privileged Identity Management (PIM) を使用して、高い特権ロールの要求を承認するのに最適な組織内のユーザーを定義できます。 たとえば、管理者は、テナント全体の変更を行うために全体管理者のアクセス権を必要とすることがあります。

Note

PIM を使用するには、一人一人に Microsoft Entra ID P2 ライセンスが必要です。

全体管理者に対し、特定のリソースの管理を禁止する必要がある場合は、別の全体管理者がいる別のテナントに、そのリソースを分離する必要があります。 これはバックアップで特に重要になる場合があります。この例については、「マルチユーザー承認ガイダンス」を参照してください。

一般的な使用法

シングル テナントで複数の環境を利用する最も一般的な用途の 1 つは、運用リソースを非運用リソースから分離することです。 シングル テナント内で、開発チームとアプリケーション所有者は、テスト アプリ、テスト ユーザーとグループ、およびそれらのオブジェクトのテスト ポリシーを備えた別の環境を作成し管理することができます。同様に、Azure リソースと信頼されたアプリの非運用インスタンスを作成できます。

次の図は、非運用環境と運用環境を示しています。

Microsoft Entra テナント境界を示す図。

この図では、非運用の Azure リソース、および、同等の非運用ディレクトリ オブジェクトをもつ非運用インスタンスの Microsoft Entra 統合アプリケーションがあります。 この例では、ディレクトリ内の非運用リソースをテスト目的で使用します。

Note

シングル Microsoft Entra テナントに複数の Microsoft 365 環境を含めることはできません。 ただし、シングル Microsoft Entra テナントに複数の Dynamics 365 環境を含めることはできます。

シングル テナント内での分離のもう 1 つのシナリオは、階層化された管理の場所、子会社、または実装の分離です (「エンタープライズ アクセス モデル」による)。

Azure RBAC ロールの割り当てにより、スコープを設定した Azure リソースの管理が可能になります。 同様に、Microsoft Entra ID では、条件付きアクセス、ユーザーとグループのフィルター処理、管理単位の割り当て、アプリケーションの割り当てなどの複数の機能を使用して、Microsoft Entra ID 信頼アプリケーションをきめ細かく管理できます。

Microsoft 365 サービスの完全な分離 (組織レベルの構成のステージングを含む) を確実に行う必要がある場合は、マルチ テナントの分離を選択する必要があります。

シングル テナントでのスコープを設定した管理

Azure リソースのスコープを設定した管理

Azure RBAC を使用すると、きめ細かいスコープと領域を使用して管理モデルを設計できます。 次の例の管理階層について考えてみます。

Note

組織の個々の要件、制約、目標に基づいて管理階層を定義する方法は複数あります。 詳細については、Azure リソースを整理する方法に関する「クラウド導入フレームワークガイダンス」を参照してください。

シングル テナントでのリソースの分離を示す図。

  • 管理グループ - 他の管理グループに影響を与えないように、特定の管理グループにロールを割り当てることができます。 上記のシナリオでは、人事チームは、リソースがすべての HR サブスクリプションにデプロイされている領域を監査する Azure Policy を定義できます。

  • サブスクリプション - 特定のサブスクリプションにロールを割り当てて、他のリソース グループに影響を与えないようにすることができます。 上記の例では、人事チームは、他の HR サブスクリプションや他のチームのサブスクリプションを読み取ることなく、福利厚生サブスクリプションの読み取りロールを割り当てることができます。

  • リソース グループ - ロールを特定のリソース グループに割り当てて、他のリソース グループに影響を与えないようにすることができます。 上の例では、福利厚生エンジニアリング チームは共同作成者ロールをテスト リーダーに割り当てて、彼らがテスト DB とテスト Web アプリを管理したり、リソースを追加したりできるようにします。

  • 個々のリソース - ロールを特定のリソースに割り当てて、他のリソースに影響を与えないようにすることができます。 上の例では、福利厚生エンジニアリング チームは、テスト Web アプリや運用リソースに干渉することなく、Azure Cosmos DB データベースのテスト インスタンスのみについての Cosmos DB アカウント読み取りロールをデータ アナリストに割り当てることができます。

詳細については、「Azure 組み込みロール」と「Azure ロールベースのアクセス制御 (Azure RBAC) とは」を参照してください。

これは階層構造であるため、上のほうの階層にあるほど、下位レベルに対するスコープ、可視性、影響が大きくなります。 最上位レベルのスコープは、Microsoft Entra テナント境界内のすべての Azure リソースに影響します。 これは、アクセス許可を複数のレベルで適用できることも意味しています。 このことによって発生するリスクは、階層の上位のロールを割り当てると、階層の下位では意図したよりも多くのアクセスが提供される可能性があるということです。 Microsoft Entra (正式には CloudKnox) は、リスクの軽減に役立つ可視性と修復を提供する Microsoft 製品です。 一部の詳細を次に示します。

  • ルート管理グループでは、すべてのサブスクリプションとリソースに適用される Azure ポリシーと RBAC ロールの割り当てを定義します。

  • グローバル管理者は、すべてのサブスクリプションと管理グループについてアクセスを昇格させることができます。

最上位レベルのスコープはどちらも厳密に監視する必要があります。 ネットワークなど、リソース分離の他のディメンションを計画することが重要です。 Azure ネットワークに関する一般的なガイダンスについては、「ネットワーク セキュリティに関する Azure のベスト プラクティス」を参照してください。 サービスとしてのインフラストラクチャ (IaaS) ワークロードには、ID とリソースの分離の両方を全体的な設計と戦略の一部とする必要がある特別なシナリオがあります。

「Azure ランディング ゾーンの概念アーキテクチャ」に従って、機密性の高いリソースやテスト リソースを分離することを検討してください。 たとえば、ID サブスクリプションは別個の管理グループに割り当てる必要があり、開発目的のすべてのサブスクリプションは "サンドボックス" 管理グループに分離することが考えられます。 詳細については、「エンタープライズ スケールのドキュメント」を参照してください。 シングル テナント内でのテスト目的の分離については、「参照アーキテクチャの管理グループ階層」でも考慮しています。

Microsoft Entra ID 信頼アプリケーションのスコープ管理

次のセクションでは、Microsoft Entra ID 信頼アプリケーションのスコープ管理のパターンについて概説します。

Microsoft Entra ID では、カスタム アプリと SaaS アプリの複数のインスタンスの構成がサポートされていますが、独立したユーザー割り当てがある同じディレクトリに対して、ほとんどの Microsoft サービスはサポートされていません。 上記の例には、旅行アプリの実稼働バージョンとテスト バージョンの両方が含まれています。 企業テナントに対して運用前バージョンをデプロイして、アプリ固有の構成とポリシーの分離を実現できます。これにより、ワークロード所有者は会社の資格情報を使用してテストを実行できます。 テスト ユーザーやテスト グループなどの非運用ディレクトリ オブジェクトは、それらのオブジェクトの個別の所有権をもつ非運用アプリケーションに関連付けられます。

Microsoft Entra テナント境界内のすべての信頼アプリケーションに影響を与えるテナント全体の側面は次のとおりです。

  • グローバル管理者は、テナント全体の設定をすべて管理できます。

  • ユーザー管理者、アプリケーション管理者、条件付きアクセス管理者など、他のディレクトリ ロールでは、そのロールのスコープ内でテナント全体の構成を管理できます。

許可される認証方法、ハイブリッド構成、B2B コラボレーション許可ドメインの一覧、ネームド ロケーションなどの構成設定はテナント全体にわたるものです。

Note

Microsoft Graph API のアクセス許可と同意のアクセス許可を、管理単位のグループまたはメンバーにスコープすることはできません。 これらのアクセス許可はディレクトリ レベルで割り当てられます。リソースレベルのスコープを許可できるのはリソース固有の同意のみです (現在、Microsoft Teams チャットのアクセス許可に制限されています)

重要

Office 365、Microsoft Dynamics、Microsoft Exchange などの Microsoft SaaS サービスのライフサイクルは、Microsoft Entra テナントにバインドされます。 その結果、これらのサービスの複数のインスタンスでは、必ず複数の Microsoft Entra テナントが必要になります。 特定の管理スコープ機能の詳細については、個々のサービスのドキュメントを参照してください。

次のステップ