委任された管理と分離された環境の概要

  • [アーティクル]

Microsoft Entra のシングルテナント アーキテクチャは、委任された管理の機能を備えており、多くの場合、環境を分離するのに十分です。 この記事の他のセクションで詳しく説明しているように、Microsoft ではこれを行うための多くのツールを提供しています。 ただし、シングル テナントで達成できる範囲を超える程度の分離が組織で必要になる場合があります。

特定のアーキテクチャについて説明する前に、次の点を理解しておくことが重要です。

  • 一般的なシングル テナントの動作。

  • Microsoft Entra ID の管理単位のしくみ。

  • Azure リソースと Microsoft Entra テナント間の関係。

  • 分離が必要となる一般的な要件。

セキュリティ境界としての Microsoft Entra テナント

Microsoft Entra テナントは、組織が使用するアプリケーションとリソースに ID とアクセス管理 (IAM) 機能を提供します。

ID とは、リソースへのアクセスの認証と承認を受けられるディレクトリ オブジェクトです。 ID オブジェクトには、人間に与えられる ID と人間以外に与えられる ID があります。 人間に与えられる ID と人間以外に与えられる ID を区別するために、人間に与えられる ID を ID、人間以外に与えられる ID をワークロード ID と呼びます。 人間以外のエンティティには、アプリケーション オブジェクト、サービス プリンシパル、マネージド ID、デバイスがあります。 この用語は業界全体で一貫していませんが、通常、ワークロード ID は、一部のシステムでソフトウェア エンティティを認証するために必要になるものです。

人間に与えられる ID と人間以外に与えられる ID を区別するために、IT 業界全体でその 2 つを区別するさまざまな用語が登場しています。

  • ID - ID は、人間が認証に使用する Active Directory (AD) と Microsoft Entra オブジェクトを記述することから始まりました。 この一連の記事では、ID は人間を表すオブジェクトを指すものとします。

  • ワークロード ID - Microsoft Entra ID では、ワークロード ID はアプリケーション、サービス プリンシパル、マネージド ID です。 ワークロード ID は、他のサービスとリソースの認証とアクセスに使用されます。

ワークロード ID の詳細については、「ワークロード ID とは」を参照してください。

Microsoft Entra テナントは、管理者の管理下にある ID セキュリティ境界です。 このセキュリティ境界内では、サブスクリプション、管理グループ、リソース グループの管理を委任して、Azure リソースの管理制御をセグメント化できます。 これらのグループ化は、テナント全体のポリシーと設定の構成に依存しますが、相互に直接やり取りを行うことはありません。 そして、これらの設定と構成は、Microsoft Entra グローバル管理者の管理下にあります。

Microsoft Entra ID は、ID を表すオブジェクトにアプリケーションと Azure リソースへのアクセス権を付与するために使用されます。 その意味では、Microsoft Entra ID を信頼する Azure リソースとアプリケーションの両方が、Microsoft Entra ID で管理できるリソースです。 次の図では、Microsoft Entra テナント境界に、Microsoft Entra ID オブジェクトと構成ツールが示されています。 ディレクトリの下には、ID とアクセスの管理に ID オブジェクトを使用するリソースがあります。 ベスト プラクティスに従って、IAM の適切な動作をテストするためのテスト環境を使用して環境が設定されています。

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

Microsoft Entra ID を使用するアプリにアクセスする

ID に、さまざまな種類のアプリケーションへのアクセス権を付与することができます。 たとえば、次のようになります。

  • Exchange Online、Microsoft Teams、SharePoint Online などの Microsoft 生産性サービス

  • Azure Sentinel、Microsoft Intune、Microsoft 365 Defender ATP などの Microsoft IT サービス

  • Azure DevOps や Microsoft Graph API などの Microsoft Developer ツール

  • Salesforce や ServiceNow などの SaaS ソリューション

  • Microsoft Entra アプリケーション プロキシなどのハイブリッド アクセス機能と統合されたオンプレミス アプリケーション

  • カスタムの自社開発アプリケーション

Microsoft Entra ID を使用するアプリケーションでは、信頼されたMicrosoft Entra テナントでディレクトリ オブジェクトを構成し、管理する必要があります。 ディレクトリ オブジェクトの例としては、アプリケーションの登録、サービス プリンシパル、グループ、スキーマ属性拡張機能などがあります。

Azure リソースへのアクセス

Microsoft Entra テナントのユーザー、グループ、サービス プリンシパル オブジェクト (ワークロード ID) には、Azure ロール ベースのアクセス制御 (RBAC) と Azure 属性ベースのアクセス制御 (ABAC) を使用してロールが付与されます。

  • Azure RBAC を使用すると、セキュリティ プリンシパル、ロール定義、スコープによって決定されるロールに基づいてアクセスを提供できます。

  • Azure ABAC は、Azure RBAC を基盤としたものであり、特定のアクションのコンテキストにおける属性に基づいたロールの割り当て条件を追加することにより構築されます。 ロールの割り当て条件は、ロールの割り当てに追加することによってさらにきめ細かなアクセス制御を可能にするもう 1 つの確認のしくみです。

Azure リソース、リソース グループ、サブスクリプション、管理グループには、これらの割り当てられた RBAC ロールを使用してアクセスします。 たとえば、次の図では、ロールベースのアクセス制御を使用した Microsoft Entra ID での管理機能の分布を示しています。

Microsoft Entra のロールの階層を示す図。

マネージド ID をサポートする Azure リソースを使用すると、リソースで Microsoft Entra テナント境界内の他のリソースに対する認証、アクセス権の付与、ロールの割り当てを行うことができます。

サインインに Microsoft Entra ID を使用するアプリケーションでは、実装の一環としてコンピューティングやストレージなどの Azure リソースを使用することもできます。 たとえば、Azure で実行され、Microsoft Entra ID を信頼して認証を行うカスタム アプリケーションでは、ディレクトリ オブジェクトと Azure リソースが使用されます。

最後に、Microsoft Entra テナント内のすべての Azure リソースは、テナント全体の Azure クォータと制限に影響します。

ディレクトリ オブジェクトへのアクセス

前の図に示すように、ID、リソース、およびそれらのリレーションシップは、Microsoft Entra テナント内ではディレクトリ オブジェクトとして表されます。 ディレクトリ オブジェクトの例としては、ユーザー、グループ、サービス プリンシパル、アプリの登録などがあります。

Microsoft Entra テナント境界内に一連のディレクトリ オブジェクトがあると、次の機能が生まれます。

  • 表示 : ID では、アクセス許可に基づいて、リソース、ユーザー、グループ、アクセス使用状況レポート、監査ログを検出または列挙できます。 たとえば、ディレクトリのあるメンバーは、Microsoft Entra ID の既定のユーザー アクセス許可ごとにディレクトリ内のユーザーを検出できます。

  • アプリケーションはオブジェクトに影響を与える可能性があります。 アプリケーションは、ビジネス ロジックの一部として Microsoft Graph を介してディレクトリ オブジェクトを操作できます。 一般的な例としては、ユーザー属性の読み取り/設定、ユーザーの予定表の更新、ユーザーに代わってメールを送信するなどがあります。 アプリケーションがテナントに影響を与えることを許可するには、同意が必要です。 管理者はすべてのユーザーについて同意できます。 詳細については、「Microsoft ID プラットフォーム エンドポイントでのアクセス許可と同意」を参照してください。

注意

アプリケーションのアクセス許可を使用する場合は注意が必要です。 たとえば、Exchange Online では、アプリケーションのアクセス許可を特定のメールボックスとアクセス許可にスコープ設定する必要があります。

  • 調整とサービスの制限。 リソースのランタイム動作によって、過剰使用やサービスの低下を防ぐために調整をトリガーする可能性があります。 調整は、アプリケーション、テナント、またはサービス レベル全体で行うことができます。 調整が発生する最も一般的なケースは、テナント内またはテナント間でアプリケーションに大量の要求がある場合です。 同様に、アプリケーションのランタイム動作に影響を与える可能性のある Microsoft Entra サービスの制限と制約があります。

ロール管理の管理単位

管理単位では、ロールのアクセス許可が、組織の任意の定義部分に限定されます。 たとえば、管理単位を使用して、ヘルプデスク管理者のロールを地域のサポート スペシャリストに委任できます。そうすれば、そのスペシャリストが自分のサポートするリージョンのユーザーのみを管理できます。 管理単位は、他の Microsoft Entra リソースのコンテナーとして使用できる Microsoft Entra リソースです。 管理単位に含めることができるのは、次のもののみです。

  • ユーザー

  • グループ

  • デバイス

次の図では、管理単位を使用して、ビジネス構造または組織の構造に基づいて Microsoft Entra テナントをさらにセグメント化しています。 これは、さまざまな部署やグループに専用の IT サポート スタッフがいる場合に便利です。 管理単位は、指定された管理単位に限定された特権アクセス許可を提供するために使用できます。

Microsoft Entra 管理単位を示す図。

管理単位の詳細については、「Microsoft Entra ID の管理単位」を参照してください。

リソースの分離を行う一般的な理由

場合によっては、リソースのグループを、セキュリティやその他の理由で他のリソースから分離する必要があります (リソースに固有のアクセス要件があるなど)。 このようなユース ケースでは、管理単位の使用が適しています。 どのユーザーとセキュリティ プリンシパルに、どのロールで、リソースへのアクセス権を付与するか、決定する必要があります。 リソースを分離する理由には次のものがあります。

  • 開発者チームには、アプリのソフトウェア開発ライフサイクル中に、安全に反復処理できる柔軟性が必要です。 ただし、Microsoft Entra ID への書き込みがあるアプリの開発とテストは、書き込み操作によって Microsoft Entra テナントに影響を与える可能性があります。 以下に、この例をいくつか示します。

    • SharePoint サイト、OneDrive、MS Teams など、Office 365 コンテンツを変更する可能性がある新しいアプリケーション。

    • MS Graph または類似の API を大規模に使用してユーザーのデータを変更する可能性のあるカスタム アプリケーション (たとえば、Directory.ReadWrite.All が付与されているアプリケーション)。

    • デプロイ ライフサイクルの一部として大規模なオブジェクト セットを更新する DevOps スクリプト。

    • Microsoft Entra 統合アプリの開発者は、テスト用にユーザー オブジェクトを作成できる必要があり、それらのユーザー オブジェクトは運用環境のリソースにアクセスできてはいけません。

  • 他のリソースに影響を与える可能性がある非運用の Azure リソースとアプリケーション。 たとえば、SaaS アプリケーションの新しいベータ 版を、アプリケーションおよび運用ユーザー オブジェクトの運用インスタンスから分離する必要がある場合があります。

  • 規制上またはビジネス上の重要な理由から、検出、列挙、または既存の管理者からの引き継ぎから保護する必要があるシークレット リソースなども該当します。

テナントの構成

Microsoft Entra ID の構成設定は、対象を絞った管理アクション、またはテナント全体の管理アクションを通じて、Microsoft Entra テナント内のすべてのリソースに影響を与える可能性があります。 テナント全体の設定の例を次に示します。

  • 外部 ID: 管理者は、テナントでプロビジョニングできる外部 ID を識別して制御します。

    • テナントで外部 ID を許可するかどうか。

    • 追加できるドメインの外部 ID。

    • ユーザーが他のテナントからユーザーを招待できるかどうか。

  • ネームド ロケーション: 管理者は、ネームド ロケーションを作成できます。これは、次の操作に使用できます。

    • 特定の場所からのサインインをブロックする。

    • MFA などの条件付きアクセス ポリシーをトリガーする。

    • セキュリティ要件をバイパスする

  • セルフサービス オプション: 管理者は、セルフサービスパスワード リセットなどのセルフサービス オプションを設定し、テナント レベルで Microsoft 365 グループを作成します。

テナント全体の構成によっては、グローバル ポリシーによって上書きされない限り、実装の範囲を設定できます。 次に例を示します。

  • テナントで外部 ID が許可されるように構成されている場合でも、リソース管理者は、それらの ID がリソースにアクセスできないように設定できます。

  • テナントで個人デバイスの登録が許可されるように構成されている場合でも、リソース管理者は、それらのデバイスが特定のリソースにアクセスできないように設定できます。

  • ネームド ロケーションが構成されている場合、リソース管理者は、それらの場所からのアクセスを許可または除外するポリシーを構成できます。

構成の分離を行う一般的な理由

管理者によって制御される構成は、リソースに影響します。 テナント全体にわたる構成の中には、特定のリソースに非適用にしたり部分的に適用したりするようポリシーをスコープ設定できるものもありますが、できない構成もあります。 リソースに固有の構成ニーズがある場合は、そのリソースを別のテナントに分離します。 構成分離のシナリオの例を次に示します。

  • 既存のテナント全体のセキュリティまたはコラボレーション体制と競合する要件があるリソース。 (たとえば、許可される認証の種類、デバイス管理ポリシー、セルフサービス機能、外部 ID の ID 証明など)。

  • すべてのリソースと Microsoft Entra テナント自体を含む、環境全体に対して認定をスコープとするコンプライアンス要件。特に、その要件が他の組織のリソースと競合している場合、または他の組織のリソースを除外する必要がある場合。

  • 運用ポリシーまたは機密性の高いリソース ポリシーと競合する外部ユーザー アクセス要件。

  • シングル Microsoft Entra テナントでホストされている、複数の国やリージョンにまたがる組織、および企業。 たとえば、さまざまな国やリージョン、または企業の子会社でどのような設定やライセンスが使用されているか、などです。

テナントでの管理

特権ロールをもつ Microsoft Entra テナントの ID には、前のセクションで説明した構成タスクを実行するための可視性とアクセス許可があります。 管理には、ユーザー、グループ、デバイスなどの ID オブジェクトの管理と、認証、承認などのテナント全体の構成のスコープ実装の両方が含まれます。

ディレクトリ オブジェクトの管理

管理者は、ID オブジェクトがリソースにどのようにアクセスするか、またどのような状況でアクセスするかを管理します。 また、権限に基づいてディレクトリ オブジェクトを無効にしたり、削除したり、変更したりすることもできます。 ID オブジェクトには、次のものがあります。

  • 組織 ID (次のようなもの) は、ユーザー オブジェクトによって表されます。

    • 管理者

    • 組織のユーザー

    • 組織の開発者

    • サービス アカウント

    • テスト ユーザー

  • 外部 ID は、次のような組織外のユーザーを表します。

    • 組織環境にローカルのアカウントでプロビジョニングされているパートナー、サプライヤー、またはベンダー

    • Azure B2B コラボレーションを介してプロビジョニングされているパートナー、サプライヤー、またはベンダー

  • グループは、次のようなオブジェクトによって表されます。

  • デバイスは、次のようなオブジェクトによって表されます。

    • ハイブリッド Microsoft Entra 参加済みデバイス (オンプレミスの Active Directory から同期されたオンプレミス コンピューター)

    • Microsoft Entra 参加済みデバイス

    • 従業員が職場のアプリケーションにアクセスするために使用する Microsoft Entra 登録済みモバイル デバイス。

    • Microsoft Entra に登録済みの下位レベルのデバイス (レガシ)。 たとえば、Windows 2012 R2 などです。

  • ワークロード ID

    • マネージド ID

    • サービス プリンシパル

    • アプリケーション

ハイブリッド環境では、ID は通常 Microsoft Entra Connect を使用してオンプレミスの Active Directory 環境から同期されます。

ID サービスの管理

適切なアクセス許可をもつ管理者は、テナント全体のポリシーをどのように実装するかを、リソース グループ レベル、セキュリティ グループ レベル、またはアプリケーションのレベルで管理することもできます。 リソースの管理を検討する場合は、次の点に注意してください。 いずれも、リソースを一緒に保持する、あるいはリソースを分離する理由となりうる事項です。

  • グローバル管理者は、テナントにリンクされている任意の Azure サブスクリプションを制御できます。

  • 認証管理者ロールが割り当てられた ID は、管理者以外のユーザーに MFA または FIDO 認証の再登録を要求できます。

  • 条件付きアクセス管理者は、特定のアプリにサインインするユーザーに対して、組織所有のデバイスからのみサインインするように要求する条件付きアクセス ポリシーを作成できます。 また、構成のスコープを設定することもできます。 たとえば、テナントで外部 ID が許可されている場合でも、それらの ID をあるリソースへのアクセスから除外するようにできます。

  • クラウド アプリケーション管理者は、アプリケーションのアクセス許可への同意をすべてのユーザーを代行して行うことができます。

管理の分離を行う一般的な理由

環境とそのリソースを管理する権限は誰がもつべきでしょうか。 ある環境の管理者が別の環境へのアクセス権をもってはいけない場合があります。 たとえば、次のようになります。

  • 重要なリソースに影響を与えるセキュリティ上のエラーと運用エラーのリスクをさらに軽減するために、テナント全体の管理責任を分離する場合。

  • 環境を管理できる人を制約する規制が、市民権、居住地、クリアランス レベルなど、スタッフでは対応できない条件に基づいている場合。

セキュリティと運用面の考慮事項

Microsoft Entra テナントとそのリソース間の相互依存関係を考えると、侵害やエラーのセキュリティ リスクと運用上のリスクを理解することは重要です。 同期されたアカウントをもつフェデレーション環境で運用している場合、オンプレミスの侵害によって Microsoft Entra ID の侵害が発生するおそれがあります。

  • ID の侵害 - テナントの境界の内側で、アクセス権を提供する ID に十分な特権がある場合、任意の ID に任意のロールを割り当てることができます。 非特権 ID が侵害された場合の影響は大部分は封じ込めることができますが、管理者が侵害された場合は影響が広範囲に及ぶ可能性があります。 たとえば、Microsoft Entra グローバル管理者アカウントが侵害された場合、Azure リソースが侵害された状態となる可能性があります。 ID 侵害や不適切なアクターのリスクを軽減するには、階層化された管理を実装し、Microsoft Entra 管理者ロールについて最小特権の原則に確実に従うようにします。 同様に、テスト アカウントとテスト サービス プリンシパルがテスト アプリケーションの外部のリソースに明確にアクセスしないようにする条件付きアクセス ポリシーを作成してください。 特権アクセス戦略の詳細については、「特権アクセス: 戦略」を参照してください。

  • フェデレーション環境の侵害

  • 信頼リソースの侵害 - セキュリティ上の考慮事項は、人間の ID だけではありません。 Microsoft Entra テナントのコンポーネントが侵害された場合、テナントでのそのアクセス許可のレベルとリソースのレベルに基づいて、信頼リソースに影響が及ぶおそれがあります。 Microsoft Entra ID 信頼リソースのコンポーネントが侵害された場合の影響は、リソースの権限によって決まります。書き込み操作を行うためにディレクトリと緊密に連携しているリソースは、テナント全体に深刻な影響を与えるおそれがあります。 ゼロ トラストに関するガイダンスに従うことで、侵害の影響を制限できます。

  • アプリケーション開発 - Microsoft Entra ID への書き込み特権をもつアプリケーションの開発ライフサイクルの初期段階。バグが意図せずに Microsoft Entra オブジェクトに変更を書き込む可能性があり、リスクが生じます。 開発中に Microsoft ID プラットフォームのベスト プラクティスに従って、これらのリスクを軽減します。

  • 運用エラー - セキュリティ インシデントは、不適切なアクターだけでなく、テナント管理者またはリソース所有者による運用エラーが原因で発生する可能性があります。 これらのリスクは、どのようなアーキテクチャでも発生します。 職務の分離、階層化された管理、最小限の特権の原則に従い、ベスト プラクティスに従うことで、これらのリスクを軽減します。別のテナントの使用による軽減はその後で考慮します。

Microsoft Entra ID 設計戦略にゼロトラスト原則を組み込むことは、これらの考慮事項を軽減するよう設計を導くのに役立ちます。 詳細については、「ゼロトラストを使用したプロアクティブなセキュリティの受け入れ」を参照してください。

次のステップ