委任された管理と分離された環境の概要
Microsoft Entra のシングルテナント アーキテクチャは、委任された管理の機能を備えており、多くの場合、環境を分離するのに十分です。 組織では、単一のテナントでは不可能なレベルの分離が必要になる場合があります。
この記事では、次の点を理解することが重要です。
- 単一テナントの操作と機能
- Microsoft Entra ID の管理単位 (AU)
- Azure リソースと Microsoft Entra テナント間の関係
- 分離を推進する要件
セキュリティ境界としての Microsoft Entra テナント
Microsoft Entra テナントは、組織のアプリケーションとリソースに ID とアクセス管理 (IAM) 機能を提供します。
ID とは、リソースへのアクセスを認証、承認されたディレクトリ オブジェクトです。 人間と人間以外に与えられる ID の ID オブジェクトがあります。 これらを区別するために、人間に与えられる ID を ID、人間以外に与えられる ID をワークロード ID と呼びます。 人間以外のエンティティには、アプリケーション オブジェクト、サービス プリンシパル、マネージド ID、デバイスがあります。 一般的に、ワークロード ID は、ソフトウェア エンティティがシステムで認証を行うために使用されます。
- ID - 人間を表すオブジェクト
- ワークロード ID - ワークロード ID はアプリケーション、サービス プリンシパル、マネージド ID です。
- ワークロード ID は、他のサービスやリソースを認証し、アクセスします。
詳細については、ワークロード ID の概要を参照してください。
Microsoft Entra テナントは、管理者が制御する ID セキュリティ境界です。 このセキュリティ境界内では、サブスクリプション、管理グループ、リソース グループの管理を委任して、Azure リソースの管理制御をセグメント化できます。 これらのグループは、ポリシーと設定のテナント全体の構成に依存します。
Microsoft Entra ID は、アプリケーションや Azure リソースへのアクセスをオブジェクトに許可します。 Microsoft Entra ID を信頼する Azure リソースやアプリケーションは、Microsoft Entra ID で管理できます。 ベスト プラクティスに従い、テスト環境で環境を設定します。
Microsoft Entra ID を使用するアプリにアクセスする
アプリケーションへのアクセス権を ID に付与します。
- Exchange Online、Microsoft Teams、SharePoint Online などの Microsoft 生産性サービス
- Azure Sentinel、Microsoft Intune、Microsoft Defender Advanced Threat Protection (ATP) などの Microsoft IT サービス
- Azure DevOps や Microsoft Graph API などの Microsoft 開発者ツール
- Salesforce や ServiceNow などの SaaS ソリューション
- Microsoft Entra アプリケーション プロキシなどのハイブリッド アクセス機能と統合されたオンプレミス アプリケーション
- カスタム開発アプリケーション
Microsoft Entra ID を使用するアプリケーションでは、信頼された Microsoft Entra テナントでディレクトリ オブジェクトを構成し、管理する必要があります。 ディレクトリ オブジェクトの例としては、アプリケーションの登録、サービス プリンシパル、グループ、スキーマ属性拡張機能などがあります。
Azure リソースへのアクセス
Microsoft Entra テナントのユーザー、グループ、サービス プリンシパル オブジェクト (ワークロード ID) にロールを付与します。 詳細については、Azure ロールベースのアクセス制御 (RBAC) と Azure 属性ベースのアクセス制御 (ABAC) を参照してください。
Azure RBAC を使用すると、セキュリティ プリンシパル、ロール定義、スコープによって決定されるロールに基づいてアクセスを提供できます。 Azure ABAC では、アクションの属性に基づいてロールの割り当て条件が追加されます。 より詳細なアクセス制御を行う場合は、ロールの割り当て条件を追加します。 RBAC ロールが割り当てられた Azure リソース、リソース グループ、サブスクリプション、管理グループにアクセスします。
マネージド 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 プラットフォームでのアクセス許可と同意」を参照してください。
調整とサービスの制限: リソースのランタイム動作によって、過剰使用やサービスの低下を防ぐために調整をトリガーする可能性があります。 調整は、アプリケーション、テナント、またはサービス レベル全体で行うことができます。 一般的に、調整は、テナント内またはテナント間でアプリケーションに大量の要求がある場合に発生します。 同様に、アプリケーションのランタイム動作に影響を与える可能性のある Microsoft Entra サービスの制限と制約があります。
Note
アプリケーションのアクセス許可は慎重に行う必要があります。 たとえば、Exchange Online では、アプリケーションのアクセス許可をメールボックスとアクセス許可にスコープ設定します。
ロール管理の管理単位
管理単位では、ロールのアクセス許可が、組織の任意の部分に限定されます。 管理単位を使用して、ヘルプデスク管理者のロールを地域のサポート スペシャリストに委任できます。そうすれば、そのスペシャリストが自分のサポートするリージョンのユーザーを管理できます。 管理単位は、他の Microsoft Entra リソースのコンテナーとして使用できる Microsoft Entra リソースです。 管理単位に含めることができるのは、以下のとおりです。
- ユーザー
- グループ
- デバイス
次の図では、AU が組織構造に基づいて Microsoft Entra テナントをセグメント化しています。 この方法は、部署またはグループが専用の IT サポート スタッフを割り当てる場合に便利です。 AU を使用して、管理単位に限定された特権アクセス許可を提供します。
詳細については、「Microsoft Entra ID の管理単位」を参照してください。
リソースの分離を行う一般的な理由
特殊なアクセス要件を持つリソースなど、セキュリティ上の理由からリソースのグループを他のリソースから分離することがあります。 このアクションは AU の適切なユース ケースです。 ユーザーやセキュリティ プリンシパルのリソース アクセス、ロールを決定します。 リソースを分離する理由:
- 開発者チームは、反復を安全に行えることが必要です。 ただし、Microsoft Entra ID への書き込みがあるアプリの開発とテストは、書き込み操作によって Microsoft Entra テナントに影響を与える場合があります。
- SharePoint サイト、OneDrive、Microsoft Teams など、Office 365 コンテンツを変更する可能性がある新しいアプリケーション
- MS Graph または類似の API を大規模に使用した、ユーザーのデータを変更する可能性のあるカスタム アプリケーション。 たとえば、Directory.ReadWrite.All が付与されているアプリケーションです。
- 大量のオブジェクト セットを更新する DevOps スクリプト
- Microsoft Entra 統合アプリの開発者は、テスト用にユーザー オブジェクトを作成できることが必要です。 ユーザー オブジェクトは、運用環境のリソースにアクセスできません。
- 他のリソースに影響を与える可能性がある非運用の Azure リソースとアプリケーション。 たとえば、新しい SaaS アプリでは、運用インスタンスとユーザー オブジェクトからの分離が必要です。
- 検出、列挙、または管理者によく引き継ぎから保護されるシークレット リソース
テナントの構成
Microsoft Entra ID の構成設定は、対象を絞った管理アクション、またはテナント全体の管理アクションを通じて、Microsoft Entra テナント内のリソースに影響を与える可能性があります。
- 外部 ID: 管理者は、テナントでプロビジョニングする外部 ID を識別して制御します。
- テナントで外部 ID を許可するかどうか
- どのドメインから外部 ID を追加するか
- ユーザーが他のテナントからユーザーを招待できるかどうか
- 名前付きの場所: 管理者は、次の目的で名前付きの場所を作成します。
- 場所からのサインインをブロックする
- 多要素認証などの条件付きアクセス ポリシーをトリガーする
- セキュリティ要件をバイパスする
- セルフサービス オプション: 管理者は、セルフサービス パスワード リセットを設定し、テナント レベルで Microsoft 365 グループを作成します。
グローバル ポリシーでオーバーライドしない場合は、一部のテナント全体の構成をスコープ設定できます。
- テナント構成では、外部 ID が許可されます。 リソース管理者は、これらの ID をアクセスから除外できます。
- テナント構成では、個人デバイスの登録が許可されます。 リソース管理者は、アクセスからデバイスを除外できます。
- 名前付きの場所が構成されます。 リソース管理者は、アクセスを許可または除外するポリシーを構成できます。
構成の分離を行う一般的な理由
管理者によって制御される構成は、リソースに影響します。 テナント全体にわたる構成の中には、リソースに非適用にしたり部分的に適用したりするようポリシーをスコープ設定できるものもありますが、できない構成もあります。 リソースに固有の構成がある場合は、そのリソースを別のテナントに分離します。 以下に例を示します。
- テナント全体のセキュリティまたはコラボレーション体制と競合する要件があるリソース
- 許可される認証の種類、デバイス管理ポリシー、セルフサービス、外部 ID の ID 証明など
- 環境全体に認定をスコープ設定するコンプライアンス要件
- このアクションには、すべてのリソースと Microsoft Entra テナントが含まれます (特に、要件が他の組織リソースと競合しているか、他の組織リソースを除外している場合)
- 運用ポリシーまたは機密性の高いリソース ポリシーと競合する外部ユーザー アクセス要件
- Microsoft Entra テナントでホストされている、複数の国やリージョンにまたがる組織と企業。
- たとえば、国やリージョン、または企業の子会社で使用されている設定やライセンスなど
テナント管理
特権ロールをもつ Microsoft Entra テナントの ID には、前のセクションで説明した構成タスクを実行するための可視性とアクセス許可があります。 管理には、ユーザー、グループ、デバイスなどの ID オブジェクトの所有権が含まれます。 また、認証、承認などのテナント全体の構成のスコープ実装も含まれます。
ディレクトリ オブジェクトの管理
管理者は、ID オブジェクトがリソースにどのようにアクセスするか、またどのような状況でアクセスするかを管理します。 また、権限に基づいてディレクトリ オブジェクトを無効化、削除、変更します。 ID オブジェクトには、次のものがあります。
- 組織 ID (次のようなもの) は、ユーザー オブジェクトによって表されます。
- 管理者
- 組織のユーザー
- 組織の開発者
- サービス アカウント
- テスト ユーザー
- 外部 ID は、組織外のユーザーを表します。
- アカウント付きでプロビジョニングされている組織環境のパートナー、サプライヤー、またはベンダー
- Azure B2B コラボレーションを介してプロビジョニングされているパートナー、サプライヤー、またはベンダー
- グループは、オブジェクトによって表されます。
- セキュリティ グループ
- Microsoft 365 グループ
- 動的グループ
- 管理単位
- デバイスは、オブジェクトによって表されます。
- Microsoft Entra ハイブリッド参加済みデバイス。 オンプレミスから同期されたオンプレミス コンピューター。
- Microsoft Entra 参加済みデバイス
- 従業員が職場のアプリケーションにアクセスするために使用する Microsoft Entra 登録済みモバイル デバイス
- Microsoft Entra に登録済みの下位レベルのデバイス (レガシ)。 たとえば、Windows 2012 R2 などです。
- ワークロード ID
- マネージド ID
- サービス プリンシパル
- アプリケーション
ハイブリッド環境では、ID は通常 Microsoft Entra Connect を使用してオンプレミスの環境から同期されます。
ID サービスの管理
特定のアクセス許可をもつ管理者は、リソース グループ、セキュリティ グループ、またはアプリケーションに対して、テナント全体のポリシーをどのように実装するかを管理します。 リソース管理を検討する際は、リソースをグループ化するか分離するかを決める次の理由を考慮してください。
- グローバル管理者は、テナントにリンクされている Azure サブスクリプションを制御します。
- 認証管理者ロールが割り当てられた ID は、管理者以外のユーザーに、多要素認証または Fast IDentity Online (FIDO) 認証のための再登録を要求します。
- 条件付きアクセス管理者は、組織所有のデバイスからユーザーがアプリにサインインするための条件付きアクセス ポリシーを作成します。 これらの管理者は、構成をスコープ指定します。 たとえば、テナントで外部 ID が許可されている場合は、リソースへのアクセスを除外できます。
- クラウド アプリケーション管理者は、アプリケーションのアクセス許可への同意をユーザーを代行して行います。
管理の分離を行う一般的な理由
環境とそのリソースはだれが管理すべきでしょうか。 ある環境の管理者は、別の環境にアクセスできない場合があります。
- 重要なリソースに影響を与えるセキュリティ上のエラーと運用エラーのリスクを軽減するために、テナント全体の管理責任を分離する場合
- 環境を管理できる人を制約する規制が、市民権、居住地、クリアランス レベルなどの条件に基づいている場合
セキュリティと運用面の考慮事項
Microsoft Entra テナントとそのリソース間の相互依存関係を考えると、侵害やエラーのセキュリティ リスクと運用上のリスクを理解することは重要です。 同期されたアカウントをもつフェデレーション環境で運用している場合、オンプレミスの侵害によって Microsoft Entra ID の侵害が発生するおそれがあります。
- ID の侵害: アクセス権を提供する管理者に十分な特権がある場合、テナントの境界では、ID に任意のロールが割り当てられます。 非特権 ID が侵害された場合の影響は大部分は封じ込めることができますが、管理者が侵害された場合は広範囲に及ぶ問題が発生する可能性があります。 たとえば、高度な特権を持つアカウントが侵害された場合、Azure リソースが侵害された状態になる可能性があります。 ID 侵害や不適切なアクターのリスクを軽減するには、階層化された管理を実装し、Microsoft Entra 管理者ロールについて最小特権の原則に従うようにします。 テスト アカウントとテスト サービス プリンシパルがテスト アプリケーション外のリソースにアクセスしないようにする条件付きアクセス ポリシーを作成してください。 特権アクセス戦略の詳細については、「特権アクセス: 戦略」を参照してください。
- フェデレーション環境の侵害
- 信頼リソースの侵害: Microsoft Entra テナントのコンポーネントが侵害された場合、テナントとリソースのレベルでのアクセス許可に基づいて、信頼リソースに影響が及ぶおそれがあります。 リソースの特権によって、侵害されたコンポーネントの影響が決まります。 書き込み操作を実行するために統合されたリソースは、テナント全体に影響する可能性があります。 ゼロ トラストに関するガイダンスに従うことで、侵害の影響を制限できます。
- アプリケーション開発: アプリケーション開発ライフサイクルの初期段階では、Microsoft Entra ID への書き込み特権がある場合にリスクがあります。 バグにより、意図せず Microsoft Entra オブジェクトに書き込みが行われて変更される可能性があります。 詳細については、Microsoft ID プラットフォームのベスト プラクティスを参照してください。
- 操作エラー: 不適切なアクター、またはテナント管理者やリソース所有者による運用エラーが、セキュリティ インシデントの原因となる場合があります。 これらのリスクは、どのようなアーキテクチャでも発生します。 職務の分離、階層化された管理、最小限の特権の原則と次のベスト プラクティスを使用してください。 別のテナントは使用しないでください。
ゼロ トラスト原則
セキュアな設計に導くため、Microsoft Entra ID の設計戦略にゼロ トラスト原則を組み込んでください。 ゼロ トラストを使用してプロアクティブなセキュリティを採用することができます。