条件付きアクセス: ターゲット リソース

  • [アーティクル]

ターゲット リソース (以前のクラウド アプリ、操作、認証コンテキスト) は、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 サービスの依存関係を持つサービスまたはクライアントは、間接的に影響を受ける可能性があります。 次に例を示します。

  • クラシック デプロイ モデル API
  • Azure PowerShell
  • Azure CLI
  • Azure DevOps
  • Azure Data Factory ポータル
  • Azure Event Hubs
  • Azure Service Bus
  • Azure SQL データベース
  • SQL Managed Instance
  • Azure Synapse
  • Visual Studio サブスクリプション管理者ポータル
  • Microsoft IoT Central

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 に登録された任意のアプリケーションを条件付きアクセス ポリシーに追加できます。 これらのアプリケーションには次が含まれることがあります。

注意

条件付きアクセス ポリシーでは、サービスにアクセスするための要件が設定されるため、クライアント (パブリック/ネイティブ) アプリケーションにそれを適用することはできません。 つまり、ポリシーはクライアント (パブリックまたはネイティブ) アプリケーションに直接設定されませんが、クライアントがサービスを呼び出すときに適用されます。 たとえば、SharePoint サービスで設定したポリシーは、SharePoint を呼び出すすべてのクライアントに適用されます。 Exchange で設定されたポリシーは、Outlook クライアントを使用して電子メールにアクセスしようとしたときに適用されます。 このため、クラウド アプリの選択で、クライアント (パブリック/ネイティブ) アプリケーションを選択できず、テナントに登録されているクライアント (パブリック/ネイティブ) アプリケーションのアプリケーション設定で、[条件付きアクセス] オプションを選択できません。

一部のアプリケーションは、ピッカーにまったく表示されません。 これらのアプリケーションを条件付きアクセス ポリシーに含める唯一の方法は、[すべてのクラウド アプリ] を含めることです。

すべてのクラウド アプリ

条件付きアクセス ポリシーを [すべてのクラウド アプリ] に適用すると、Web サイトとサービスに発行されたすべてのトークンに対してポリシーが適用されます。 このオプションには、Microsoft Entra ID などの条件付きアクセス ポリシーで個別に対象にできないアプリケーションが含まれます。

場合によっては、[すべてのクラウド アプリ] ポリシーが誤ってユーザー アクセスをブロックする可能性があります。 これらのケースはポリシーの適用から除外され、次のものが含まれます。

  • 目的のセキュリティ体制を実現するために必要なサービス。 たとえば、デバイス登録呼び出しは、[すべてのクラウド アプリ] を対象とする準拠デバイス ポリシーから除外されます。

  • ポリシーから除外されたアプリケーションで一般的に使用されるユーザー プロファイル、グループ メンバーシップ、リレーションシップ情報にアクセスするための Azure AD Graph と Microsoft Graph の呼び出し。 除外されたスコープを以下に示します。 アプリでこれらのアクセス許可を使用するには、引き続き同意が必要です。

    • ネイティブ クライアントの場合:
      • Azure AD Graph: email、offline_access、openid、profile、User.Read
      • Microsoft Graph: email、offline_access、openid、profile、User.Read、People.Read
    • 機密/認証されたクライアントの場合:
      • Azure AD Graph: email、offline_access、openid、profile、User.Read、User.Read.All、and 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

ユーザー操作

ユーザー操作とは、ユーザーが実行するタスクです。 現在、条件付きアクセスでは 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]>[デバイス]>[概要]>[デバイス設定] - Devices to be Microsoft Entra joined or Microsoft Entra registered require multifactor authentication を [いいえ] に設定する必要があります。 そうしないと、このユーザー操作での条件付きアクセス ポリシーが適切に適用されません。 このデバイス設定に関するより詳細な情報は、「デバイス設定の構成」に記載されています。

トラフィック転送プロファイル

Global Secure Access のトラフィック転送プロファイルを使用すると、管理者は、Microsoft Entra Internet Access および Microsoft Entra Private Access 経由でトラフィックをルーティングする方法を定義および制御できます。 トラフィック転送プロファイルは、デバイスとリモート ネットワークに割り当てることができます。 これらのトラフィック プロファイルに条件付きアクセス ポリシーを適用する方法の例については、 Microsoft 365 トラフィック プロファイルに条件付きアクセス ポリシーを適用する方法 の記事を参照してください。

これらのプロファイルの詳細については、Global Secure Access のトラフィック転送プロファイルに関する記事を参照してください。

認証コンテキスト

認証コンテキストを使用すると、アプリケーションのデータとアクションをさらにセキュリティで保護することができます。 これらのアプリケーションには、独自のカスタム アプリケーション、カスタム基幹業務 (LOB) アプリケーション、SharePoint のようなアプリケーション、Microsoft Defender for Cloud Apps によって保護されるアプリケーションが該当します。

たとえば、組織は、ランチ メニューや秘密の BBQ ソース レシピなどのファイルを SharePoint サイト内に保持することがあります。 すべてのユーザーがランチ メニュー サイトにアクセスできるとしても、秘密の BBQ ソース レシピにアクセスできるユーザーは、管理対象デバイスからアクセスして、特定の利用規約に同意する必要があります。

認証コンテキストはユーザーまたはワークロード ID で動作しますが、同じ条件付きアクセス ポリシーでは機能しません。

認証コンテキストの構成

認証コンテキストは、[保護]>[条件付きアクセス]>[認証コンテキスト] で管理されます。

認証コンテキストの管理を示すスクリーンショット。

新しい認証コンテキスト定義を作成するには、[新しい認証コンテキスト] を選択します。 組織の認証コンテキスト定義 c1-c99 は、合計 99 に制限されています。 次の属性を構成します。

  • [表示名] は、Microsoft Entra ID と認証コンテキストを使用するアプリケーション間で認証コンテキストを識別するために使用される名前です。 必要な認証コンテキストの数を減らすために、信頼されたデバイスのようなリソース間で使用できる名前を使用することをお勧めします。 セットを小さくすると、リダイレクトの回数が制限され、エンドツーエンドのユーザー エクスペリエンスが向上します。
  • [説明] には、管理者が使用するポリシーと、リソースに認証コンテキストを適用するポリシーに関する詳細情報が記載されています。
  • [アプリに発行] チェックボックスをオンにすると、認証コンテキストがアプリに対して公開され、割り当て可能になります。 オフにした場合、認証コンテキストはダウンストリーム リソースに使用できなくなります。
  • [ID] は読み取り専用で、トークンとアプリで要求固有の認証コンテキスト定義に使用されます。 トラブルシューティングと開発のユースケースをここに示します。

条件付きアクセス ポリシーに追加する

管理者は、 [割り当て]>[クラウド アプリまたはアクション] で [このポリシーが適用される対象を選択する] メニューから [認証コンテキスト] を選択することによって、条件付きアクセス ポリシーで、公開されている認証コンテキストを選択できます。

ポリシーへの条件付きアクセス認証コンテキストの追加方法を示すスクリーンショット

認証コンテキストを削除する

認証コンテキストを削除する場合は、それをまだ使用しているアプリケーションがないことを確認します。 そうでないと、アプリ データへのアクセスは保護されなくなります。 この前提条件を確認するには、認証コンテキストの条件付きアクセス ポリシーが適用されている場合のサインイン ログを確認します。

認証コンテキストを削除するには、条件付きアクセス ポリシーが割り当てられていないこと、およびアプリに発行されていないことが必要です。 この要件によって、まだ使用中の認証コンテキストが誤って削除されるのを回避できます。

認証コンテキストを含むリソースをタグ付けする

アプリケーションでの認証コンテキストの使用の詳細については、次の記事を参照してください。

次のステップ