条件付きアクセス: ターゲット リソース
ターゲット リソース (以前のクラウド アプリ、操作、認証コンテキスト) は、Azure AD 条件付きアクセス ポリシーの重要なシグナルです。 管理者は、条件付きアクセス ポリシーを使用して、特定のアプリケーション、サービス、アクション、認証コンテキストにコントロールを割り当てることができます。
- 管理者は、組み込みの Microsoft アプリケーションおよび Microsoft Entra 統合アプリケーション (ギャラリー、ギャラリー以外、アプリケーション プロキシ経由で公開されたアプリケーションなど) を含むアプリケーションまたはサービスの一覧から選択できます。
- 管理者は、クラウド アプリケーションではなく、セキュリティ情報の登録やデバイスの登録または参加などのユーザー操作に基づいてポリシーを定義することを選択できます。これにより、条件付きアクセスで、これらの操作に関する制御を適用できます。
- 管理者は、Global Secure Access のトラフィック転送プロファイルをターゲットにして、機能を強化できます。
- 管理者は、認証コンテキストを使用して、アプリケーション内に追加のセキュリティ レイヤーを提供できます。
Microsoft クラウド アプリケーション
既存の Microsoft クラウド アプリケーションの多くは、選択できるアプリケーションの一覧に含まれています。
管理者は、これらの Microsoft クラウド アプリケーションに条件付きアクセス ポリシーを割り当てることができます。 Office 365 や Windows Azure Service Management API などの一部のアプリには、複数の関連する子アプリまたはサービスが含まれています。
重要
条件付きアクセスで使用できるアプリケーションは、オンボーディングと検証のプロセスを通過します。 これらのアプリケーションには、すべての Microsoft アプリが含まれているわけではありません。 多くのアプリケーションは、ポリシーを直接適用することが意図されていないバックエンド サービスです。 欠けているアプリケーションを探している場合は、特定のアプリケーション チームに問い合わせるか、または UserVoice で要求を発行することができます。
Office 365
Microsoft 365 では、Exchange、SharePoint、Microsoft Teams などのクラウドベースの生産性およびコラボレーション サービスが提供されます。 Microsoft 365 クラウド サービスは、スムーズに共同作業を行うために緊密に統合されています。 Microsoft Teams などの一部のアプリは SharePoint や Exchange などの他のアプリに依存しているため、この統合により、ポリシーの作成時に混乱が生じる可能性があります。
Office 365 スイートにより、これらのサービスを一度にすべてターゲットにすることができます。 サービスの依存関係に関する問題を回避するために、個々のクラウド アプリをターゲットにするのではなく、新しい Office 365 スイートを使用することをお勧めします。
このアプリケーション グループをターゲットにすると、整合性のないポリシーや依存関係のために発生する可能性のある問題を回避するのに役立ちます。 たとえば、Exchange Online アプリは、メール、予定表、連絡先情報などの従来の Exchange Online データに関連付けられています。 関連するメタデータは、検索などのさまざまなリソースを通して公開される可能性があります。 すべてのメタデータが意図したとおりに確実に保護されるようにするために、管理者は Office 365 アプリにポリシーを割り当てる必要があります。
管理者は、条件付きアクセスポリシーから Office 365 スイート全体、または特定の Office 365 クラウド アプリを除外できます。
含まれているすべてのサービスの完全な一覧については、「Office 365 アプリ スイートの条件付きアクセスに含まれるアプリ」の記事を参照してください。
Windows Azure Service Management API
Windows Azure Service Management API アプリケーションを対象にすると、ポータルに密接にバインドされている一連のサービスに発行されたトークンにポリシーが適用されます。 このグループ化には、次のアプリケーション ID が含まれます。
- Azure Resource Manager
- Azure portal。Microsoft Entra 管理センターも対象です
- Azure Data Lake
- Application Insights API
- Log Analytics API
ポリシーは Azure 管理ポータルと API に適用されるため、Azure API サービスの依存関係を持つサービスまたはクライアントは、間接的に影響を受ける可能性があります。 次に例を示します。
- Azure CLI
- Azure Data Factory ポータル
- Azure DevOps
- Azure Event Hubs
- Azure PowerShell
- Azure Service Bus
- Azure SQL データベース
- Azure Synapse
- クラシック デプロイ モデル API
- Microsoft 365 管理センター
- Microsoft IoT Central
- SQL Managed Instance
- Visual Studio サブスクリプション管理者ポータル
Note
Windows Azure Service Management API アプリケーションは、Azure Resource Manager API を呼び出す Azure PowerShell に適用されます。 Microsoft Graph API を呼び出す Microsoft Graph PowerShell には適用されません。
Windows Azure Service Management API のサンプル ポリシーを設定する方法の詳細については、「条件付きアクセス: Azure 管理に MFA を必須にする」を参照してください。
ヒント
Azure Government の場合、Azure Government Cloud Management API アプリケーションを対象にする必要があります。
Microsoft 管理ポータル
条件付きアクセス ポリシーが Microsoft 管理ポータル クラウド アプリを対象とする場合、ポリシーは、次の Microsoft 管理ポータルのアプリケーション ID に発行されたトークンに適用されます。
- Azure Portal
- Exchange 管理センター
- Microsoft 365 管理センター
- Microsoft 365 Defender ポータル
- Microsoft Entra 管理センター
- Microsoft Intune 管理センター
- Microsoft Purview コンプライアンス ポータル
- Microsoft Teams 管理センター
一覧に管理ポータルを継続的に追加しています。
Note
Microsoft 管理ポータル アプリは、一覧表示されている管理ポータルへの対話型サインインにのみ適用されます。 基になるリソースまたはサービス (Microsoft Graph や Azure Resource Manager API など) へのサインインは、このアプリケーションでカバーされません。 それらのリソースは、Windows Azure Service Management API アプリによって保護されます。 このグループ化により、お客様は、API と PowerShell に依存する自動化に影響を与えることなく、管理者向けの MFA 導入の取り組みを進めることができます。 準備ができたら、包括的な保護のために管理者が常に MFA を実行することを要求するポリシーを使用することを Microsoft はお勧めします。
他のアプリケーション
管理者は、Microsoft Entra に登録された任意のアプリケーションを条件付きアクセス ポリシーに追加できます。 これらのアプリケーションには次が含まれることがあります。
- Microsoft Entra アプリケーション プロキシを介して発行されたアプリケーション
- ギャラリーから追加されたアプリケーション
- ギャラリーにないカスタム アプリケーション
- アプリ配信コントローラーとネットワーク経由で公開されるレガシ アプリケーション
- パスワードに基づくシングル サインオンを使用するアプリケーション
Note
条件付きアクセス ポリシーでは、サービスにアクセスするための要件が設定されるため、クライアント (パブリック/ネイティブ) アプリケーションにそれを適用することはできません。 つまりポリシーは、クライアント (パブリック/ネイティブ) アプリケーションに直接設定されませんが、クライアントがサービスを呼び出すときに適用されます。 たとえば、SharePoint サービスで設定したポリシーは、SharePoint を呼び出すすべてのクライアントに適用されます。 Exchange で設定されたポリシーは、Outlook クライアントを使用して電子メールにアクセスしようとしたときに適用されます。 このため、アプリ ピッカーでクライアント (パブリック/ネイティブ) アプリケーションを選択できず、テナントに登録されているクライアント (パブリック/ネイティブ) アプリケーションのアプリケーション設定で [条件付きアクセス] オプションを選択できません。
一部のアプリケーションは、ピッカーにまったく表示されません。 これらのアプリケーションを条件付きアクセス ポリシーに含める唯一の方法は、[すべてのリソース] (以前の [すべてのクラウド アプリ]) を含めることです。
異なるクライアントの種類での条件付きアクセスについて
条件付きアクセスは、クライアントが ID トークンを要求する機密クライアントである場合を除き、クライアントではなくリソースに適用されます。
- パブリック クライアント
- パブリック クライアントとは、Microsoft Teams などのモバイル アプリや、デスクトップ上の Microsoft Outlook などのデバイスでローカルに実行されるものです。
- 条件付きアクセス ポリシーは、パブリック クライアント自体には適用されませんが、パブリック クライアントによって要求されたリソースに基づいて適用されます。
- 機密クライアント
- 条件付きアクセスは、クライアントによって要求されたリソース、および ID トークンを要求した場合の機密クライアント自体に適用されます。
- たとえば、Outlook Web がスコープ
Mail.ReadおよびFiles.Readのトークンを要求した場合、条件付きアクセスによって Exchange と SharePoint のポリシーが適用されます。 さらに、Outlook Web が ID トークンを要求した場合は、条件付きアクセスによって Outlook Web のポリシーも適用されます。
Microsoft Entra 管理センターからこれらのクライアントの種類のサインイン ログを表示するには、次の操作を実行します。
- Microsoft Entra 管理センターにレポート閲覧者以上でサインインします。
- [ID]>[監視と正常性]>[サインイン ログ] の順に参照します。
- [クライアント資格情報の種類] のフィルターを追加します。
- サインインで使用されるクライアント資格情報に基づいてログの特定のセットを表示するように、フィルターを調整します。
詳細については、パブリック クライアント アプリケーションと機密クライアント アプリケーション 記事を参照してください。
すべてのリソース
アプリの除外なしで、条件付きアクセス ポリシーを [すべてのリソース] (以前の [すべてのクラウド アプリ]) に適用すると、グローバル セキュア アクセスのトラフィック転送プロファイルを含め、Web サイトとサービスからのすべてのトークン要求に対してポリシーが適用されます。 このオプションには、Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) などの条件付きアクセス ポリシーで個別に対象にできないアプリケーションが含まれます。
重要
Microsoft は、「すべてのユーザーに多要素認証を要求する」で説明されているような、すべてのユーザーとすべてのリソース (アプリの除外なし) を対象とするベースライン多要素認証ポリシーを作成することをお勧めします。
すべてのリソース ポリシーにアプリの除外がある場合の条件付きアクセスの動作
ポリシーから除外されているアプリがある場合、誤ってユーザー アクセスをブロックしないように、特定の低い特権スコープがポリシーの適用から除外されます。 これらのスコープにより、認証の一部としてアプリケーションで一般的に使用されるユーザー プロファイルとグループ メンバーシップ情報にアクセスするために、Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) や Microsoft Graph (00000003-0000-0000-c000-000000000000) など、基になる Graph API を呼び出すことが許可されます。 たとえば、Outlook が Exchange のトークンを要求すると、現在のユーザーの基本的なアカウント情報を表示できるように User.Read スコープも要求されます。
ほとんどのアプリには同様の依存関係があるため、すべてのリソース ポリシーにアプリの除外がある場合には、これらの低い特権スコープが自動的に除外されます。 これらの低い特権スコープの除外では、基本的なユーザー プロファイルとグループ情報以外のデータ アクセスは許可されません。 除外されるスコープが以下に一覧表示されていますが、アプリはこれらのアクセス許可を使用するための同意を必要とします。
- ネイティブ クライアントとシングル ページ アプリケーション (SPA) は、次の低い特権スコープにアクセスできます。
- Azure AD Graph:
email、offline_access、openid、profile、User.Read - Microsoft Graph:
email、offline_access、openid、profile、User.Read、People.Read
- Azure AD Graph:
- 機密クライアントは、すべてのリソース ポリシーから除外されている場合、次の低い特権スコープにアクセスできます。
- Azure AD Graph:
email、offline_access、openid、profile、User.Read、User.Read.All、User.ReadBasic.All - Microsoft Graph:
email、offline_access、openid、profile、User.Read、User.Read.All、User.ReadBasic.All、People.Read、People.Read.All、GroupMember.Read.All、Member.Read.Hidden
- Azure AD Graph:
前述のスコープの詳細については、「Microsoft Graph のアクセス許可リファレンス」と「Microsoft アイデンティティ プラットフォーム におけるスコープとアクセス許可」を参照してください。
ディレクトリ情報の保護
推奨されるベースライン MFA ポリシー (アプリの除外なし) がビジネス上の理由で構成できず、組織のセキュリティポリシーがディレクトリ関連の低権限スコープ (User.Read、User.Read.All、User.ReadBasic.All、People.Read、People.Read.All、GroupMember.Read.All、Member.Read.Hidden) を含める必要がある場合は、代替策として、Windows Azure Active Directory (00000002-0000-0000-c000-0000-000000000000) を対象とする個別の条件付きアクセス ポリシーを作成します。 Windows Azure Active Directory (別称: Azure AD Graph) は、ユーザー、グループ、アプリケーションなどのディレクトリに格納されているデータを表すリソースです。 Windows Azure Active Directory リソースは、すべてのリソースに含まれますが、次の手順に従って条件付きアクセス ポリシーで個別に対象とすることができます。
- 属性定義管理者および属性割り当て管理者として Microsoft Entra 管理センターにサインインします。
- [保護]>[カスタム セキュリティ属性] の順に参照します。
- 新しい属性セットと属性定義を作成します。 詳細情報については、「Microsoft Entra ID でカスタム セキュリティ属性の定義を追加または非アクティブ化する」を参照してください。
- アイデンティティ>アプリケーション>エンタープライズ アプリケーションに移動します。
- [アプリケーションの種類] フィルターを削除し、00000002-0000-0000-c000-000000000000 で始まるアプリケーション ID を検索します。
- Windows Azure Active Directory>カスタムセキュリティ属性>割り当ての追加を選択します。
- ポリシーで使用する属性セットと属性値を選択します。
- [保護]>[条件付きアクセス]>[ポリシー] の順に参照します。
- 既存のポリシーを作成または変更します。
- [ターゲット リソース] で、>リソース (旧称、クラウド アプリ)>[含める] で、>[リソースの選択]>[フィルターの編集] を選択します。
- 前述の属性セットおよび定義を含むようにフィルターを調整します。
- ポリシーを保存します
グローバル セキュア アクセスを使用するすべてのインターネット リソース
[グローバル セキュア アクセスを使用するすべてのインターネット リソース] オプションを使用すると、管理者は Microsoft Entra Internet Access からインターネット アクセス トラフィック転送プロファイルをターゲットにすることができます。
これらのトラフィック転送プロファイルを使用すると、管理者は、Microsoft Entra Internet Access および Microsoft Entra Private Access 経由でトラフィックをルーティングする方法を定義および制御できます。 トラフィック転送プロファイルは、デバイスとリモート ネットワークに割り当てることができます。 これらのトラフィック プロファイルに条件付きアクセス ポリシーを適用する方法の例については、 Microsoft 365 トラフィック プロファイルに条件付きアクセス ポリシーを適用する方法 の記事を参照してください。
これらのプロファイルの詳細については、Global Secure Access のトラフィック転送プロファイルに関する記事を参照してください。
ユーザー操作
ユーザー操作とは、ユーザーが実行するタスクです。 現在、条件付きアクセスでは 2 つのユーザー操作がサポートされています。
- セキュリティに関する情報の登録: このユーザー操作により、統合された登録が有効になったユーザーが自分のセキュリティに関する情報を登録しようとすると、条件付きアクセス ポリシーが適用されます。 詳細情報については、「統合されたセキュリティ情報の登録」を参照してください。
Note
ユーザー アカウントが Microsoft 個人用アカウント (MSA) のゲストである場合に、セキュリティ情報の登録のためのユーザー アクションを対象とするポリシーを管理者が適用するとき、[多要素認証を要求する] コントロールを使用すると、MSA ユーザーはセキュリティ情報を組織に登録するよう要求されます。 Google など、別のプロバイダーからのゲスト ユーザーである場合、アクセスはブロックされます。
- デバイスの登録または参加: このユーザー操作により、管理者は、ユーザーがデバイスを Microsoft Entra ID に登録するか、または参加させたときに条件付きアクセス ポリシーを適用できます。 これにより、現在存在するテナント全体のポリシーではなく、デバイスを登録するか参加させるための多要素認証をきめ細かく構成できます。 このユーザー操作には、次の 3 つの重要な考慮事項があります。
Require multifactor authenticationは、このユーザー操作で使用できる唯一のアクセス制御であり、それ以外はすべて無効になっています。 この制限により、Microsoft Entra デバイス登録に依存している、あるいは Microsoft Entra デバイス登録に適用されないアクセス制御との競合を防ぐことができます。Client apps、Filters for devices、Device stateの各条件は、条件付きアクセス ポリシーの適用を Microsoft Entra デバイス登録に依存しているため、このユーザー操作では使用できません。
警告
条件付きアクセス ポリシーが [デバイスの登録または参加] のユーザー操作で構成されている場合は、[ID]>[デバイス]>[概要]>[デバイス設定] - Require Multifactor Authentication to register or join devices with Microsoft Entra を [いいえ] に設定する必要があります。 そうしないと、このユーザー操作による条件付きアクセス ポリシーが適切に適用されません。 このデバイス設定に関するより詳細な情報は、「デバイス設定の構成」に記載されています。
認証コンテキスト
認証コンテキストを使用すると、アプリケーションのデータとアクションをさらにセキュリティで保護することができます。 これらのアプリケーションには、独自のカスタム アプリケーション、カスタム基幹業務 (LOB) アプリケーション、SharePoint のようなアプリケーション、Microsoft Defender for Cloud Apps によって保護されるアプリケーションが該当します。
たとえば、組織は、ランチ メニューや秘密の BBQ ソース レシピなどのファイルを SharePoint サイト内に保持することがあります。 すべてのユーザーがランチ メニュー サイトにアクセスできるとしても、秘密の BBQ ソース レシピにアクセスできるユーザーは、管理対象デバイスからアクセスして、特定の利用規約に同意する必要があります。
認証コンテキストはユーザーまたはワークロード ID で動作しますが、同じ条件付きアクセス ポリシーでは機能しません。
認証コンテキストの構成
認証コンテキストは、[保護]>[条件付きアクセス]>[認証コンテキスト] で管理されます。
新しい認証コンテキスト定義を作成するには、[新しい認証コンテキスト] を選択します。 組織の認証コンテキスト定義 c1-c99 は、合計 99 に制限されています。 次の属性を構成します。
- [表示名] は、Microsoft Entra ID と認証コンテキストを使用するアプリケーション間で認証コンテキストを識別するために使用される名前です。 必要な認証コンテキストの数を減らすために、信頼されたデバイスのようなリソース間で使用できる名前を使用することをお勧めします。 セットを小さくすると、リダイレクトの回数が制限され、エンドツーエンドのユーザー エクスペリエンスが向上します。
- [説明] には、管理者が使用するポリシーと、リソースに認証コンテキストを適用するポリシーに関する詳細情報が記載されています。
- [アプリに発行] チェックボックスをオンにすると、認証コンテキストがアプリに対して公開され、割り当て可能になります。 オフにした場合、認証コンテキストはダウンストリーム リソースに使用できなくなります。
- [ID] は読み取り専用で、トークンとアプリで要求固有の認証コンテキスト定義に使用されます。 トラブルシューティングと開発のユースケースをここに示します。
条件付きアクセス ポリシーに追加する
管理者は、 [割り当て]>[クラウド アプリまたはアクション] で [このポリシーが適用される対象を選択する] メニューから [認証コンテキスト] を選択することによって、条件付きアクセス ポリシーで、公開されている認証コンテキストを選択できます。
認証コンテキストを削除する
認証コンテキストを削除する場合は、それをまだ使用しているアプリケーションがないことを確認します。 そうでないと、アプリ データへのアクセスは保護されなくなります。 この前提条件を確認するには、認証コンテキストの条件付きアクセス ポリシーが適用されている場合のサインイン ログを確認します。
認証コンテキストを削除するには、条件付きアクセス ポリシーが割り当てられていないこと、およびアプリに発行されていないことが必要です。 この要件によって、まだ使用中の認証コンテキストが誤って削除されるのを回避できます。
認証コンテキストを含むリソースをタグ付けする
アプリケーションでの認証コンテキストの使用の詳細については、次の記事を参照してください。
- 秘密度ラベルを使用して Microsoft Teams、Microsoft 365 グループ、SharePoint サイトのコンテンツを保護する
- Microsoft Defender for Cloud Apps
- カスタム アプリケーション
次のステップ
- 条件付きアクセス:条件
- Conditional Access common policies (条件付きアクセスの一般的なポリシー)
- クライアント アプリケーションの依存関係