条件付きアクセス: クラウド アプリ、アクション、認証コンテキスト

クラウド アプリ、操作、認証コンテキストは、Azure AD 条件付きアクセス ポリシーの重要なシグナルです。 管理者は、条件付きアクセス ポリシーを使用して、特定のアプリケーション、アクション、認証コンテキストにコントロールを割り当てることができます。

  • 管理者は、組み込みの Microsoft アプリケーションおよび Azure AD 統合アプリケーション (ギャラリー、ギャラリー以外、アプリケーション プロキシ経由で公開されたアプリケーションなど) を含むアプリケーションの一覧から選択できます。
  • 管理者は、クラウド アプリケーションではなく、セキュリティ情報の登録デバイスの登録または参加などのユーザー操作に基づいてポリシーを定義することを選択できます。これにより、条件付きアクセスで、これらの操作に関する制御を適用できます。
  • 管理者は、認証コンテキストを使用して、アプリケーション内に追加のセキュリティ レイヤーを提供できます。

条件付きアクセス ポリシーを定義し、クラウド アプリを指定する

Microsoft クラウド アプリケーション

既存の Microsoft クラウド アプリケーションの多くは、選択できるアプリケーションの一覧に含まれています。

管理者は、次の Microsoft のクラウド アプリに条件付きアクセス ポリシーを割り当てることができます。 Office 365 や Microsoft Azure Management などの一部のアプリには、複数の関連する子アプリやサービスが含まれています。 アプリは継続的に追加されるため、次の一覧はすべてを網羅したものではなく、変更されることがあります。

  • Office 365
  • Azure Analysis Services
  • Azure DevOps
  • Azure Data Explorer
  • Azure Event Hubs
  • Azure Service Bus
  • Azure SQL Database と Azure Synapse Analytics
  • Common Data Service
  • Microsoft Application Insights Analytics
  • Microsoft Azure Information Protection
  • Microsoft Azure Management
  • Microsoft Azure Subscription Management
  • Microsoft Defender for Cloud Apps
  • Microsoft Commerce Tools Access Control Portal
  • Microsoft Commerce Tools Authentication Service
  • Microsoft フォーム
  • Microsoft Intune
  • Microsoft Intune Enrollment
  • Microsoft Planner
  • Microsoft Power Apps
  • Microsoft Power Automate
  • Microsoft Search in Bing
  • Microsoft StaffHub
  • Microsoft Stream
  • Microsoft Teams
  • Exchange Online
  • SharePoint
  • Yammer
  • Office Delve
  • Office Sway
  • Outlook Groups
  • Power BI サービス
  • Project Online
  • Skype for Business Online
  • 仮想プライベート ネットワーク (VPN)
  • Windows Defender ATP

重要

条件付きアクセスで使用できるアプリケーションは、オンボードと検証のプロセスを経ています。 この一覧にすべての 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 クラウド アプリの影響を受けるのは、次の主要なアプリケーションです。

  • Exchange Online
  • Microsoft 365 Search サービス
  • Microsoft フォーム
  • Microsoft Planner (ProjectWorkManagement)
  • Microsoft Stream
  • Microsoft Teams
  • Microsoft To-Do
  • Microsoft Flow
  • Microsoft Office 365 ポータル
  • Microsoft Office クライアント アプリケーション
  • Microsoft To-Do Web アプリ
  • Microsoft Whiteboard サービス
  • Office Delve
  • Office Online
  • OneDrive
  • Power Apps
  • Power Automate
  • セキュリティ & コンプライアンス ポータル
  • SharePoint Online
  • Skype for Business Online
  • Skype および Teams Tenant Admin API
  • Sway
  • Yammer

含まれているすべてのサービスの完全な一覧については、「Office 365 アプリ スイートの条件付きアクセスに含まれるアプリ」の記事を参照してください。

Microsoft Azure の管理

条件付きアクセス ポリシーが Microsoft Azure Management アプリケーションを対象としている場合、条件付きアクセス ポリシー アプリ ピッカー内では、ポータルに密接にバインドされた一連のサービスのアプリケーション 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 Database
  • SQL Managed Instance
  • Azure Synapse
  • Visual Studio サブスクリプション管理者ポータル
  • Microsoft IoT Central

Note

Microsoft Azure Management アプリケーションは、Azure Resource Manager API を呼び出す Azure PowerShell に適用されます。 Microsoft Graph API を呼び出す Azure AD PowerShell には適用されません。

Microsoft Azure 管理のサンプル ポリシーを設定する方法の詳細については、「条件付きアクセス: Azure 管理に MFA を必須にする」を参照してください

ヒント

Azure Government の場合、Azure Government Cloud Management API アプリケーションを対象にする必要があります。

他のアプリケーション

管理者は、Azure AD に登録された任意のアプリケーションを条件付きアクセス ポリシーに追加できます。 これらのアプリケーションには次が含まれます。

注意

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

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

すべてのクラウド アプリ

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

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

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

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

    • ネイティブ クライアントの場合:
      • Azure AD Graph: email、offline_access、openid、profile、User.read
      • MS Graph: User.read、People.read、UserProfile.read
    • 機密/認証されたクライアントの場合:
      • Azure AD Graph: email、offline_access、openid、profile、User.read、User.read.all、User.readbasic.all
      • MS Graph: User.read、User.read.all、User.read.All People.read、People.read.all、GroupMember.Read.All、Member.Read.Hidden、UserProfile.read

ユーザー操作

ユーザー操作とは、ユーザーが実行できるタスクです。 現在、条件付きアクセスでは 2 つのユーザー操作がサポートされています。

  • セキュリティに関する情報の登録: このユーザー操作により、統合された登録が有効になったユーザーが自分のセキュリティに関する情報を登録しようとすると、条件付きアクセス ポリシーが適用されます。 詳細情報については、「統合されたセキュリティ情報の登録」を参照してください。

  • デバイスの登録または参加: このユーザー操作により、管理者は、ユーザーがデバイスを Azure AD に登録するか、または参加させたときに条件付きアクセス ポリシーを適用できます。 これにより、現在存在するテナント全体のポリシーではなく、デバイスを登録するか参加させるための多要素認証をきめ細かく構成できます。 このユーザー操作には、次の 3 つの重要な考慮事項があります。

    • Require multifactor authentication は、このユーザー操作で使用できる唯一のアクセス制御であり、それ以外はすべて無効になっています。 この制限により、Azure AD デバイス登録に依存している、あるいは Azure AD デバイス登録に適用されないアクセス制御との競合を防ぐことができます。
    • Client appsFilters for devicesDevice state の各条件は、条件付きアクセス ポリシーの適用を Azure AD デバイス登録に依存しているため、このユーザー操作では使用できません。
    • このユーザー操作によって条件付きアクセスポリシーを有効にした場合、 [Azure Active Directory]>[デバイス]>[デバイス設定] - Devices to be Azure AD joined or Azure AD registered require Multifactor Authentication[いいえ] に設定する必要があります。 そうしないと、このユーザー操作での条件付きアクセス ポリシーが適切に適用されません。 このデバイス設定に関するより詳細な情報は、「デバイス設定の構成」に記載されています。

認証コンテキスト

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

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

認証コンテキストの構成

認証コンテキストは、Azure portal の [Azure Active Directory]>[セキュリティ]>[条件付きアクセス]>[認証コンテキスト] の下で管理されます。

Azure portal で認証コンテキストを管理する

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

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

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

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

ポリシーへの条件付きアクセス認証コンテキストの追加

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

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

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

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

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

次のステップ