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

ターゲット リソース (以前のクラウド アプリ、アクション、認証コンテキスト) は、条件付きアクセス ポリシーの重要なシグナルです。 条件付きアクセス ポリシーを使用すると、管理者は特定のアプリケーション、サービス、アクション、または認証コンテキストに制御を割り当てることができます。

• 管理者は、組み込みの Microsoft アプリケーションと、Microsoft Entra 統合アプリケーション (ギャラリー、ギャラリー以外、アプリケーション プロキシ を介して発行されたアプリケーションなど) を含むアプリケーションまたはサービスの一覧から選択できます。
• 管理者は、セキュリティ情報の登録やデバイスの登録または参加などのユーザー アクションに基づいてポリシーを定義し、条件付きアクセスがそれらのアクションを制御できるようにします。
• 管理者は、グローバル セキュリティで保護されたアクセスからの トラフィック転送プロファイルを 対象にして、機能を強化できます。
• 管理者は 、認証コンテキスト を使用して、アプリケーションでセキュリティの追加レイヤーを提供できます。

条件付きアクセス ポリシーとターゲット リソース パネルのスクリーンショット。

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

管理者は、サービス プリンシパルがテナントに表示される場合、Microsoft Graphを除き、条件付きアクセス ポリシーを Microsoft クラウド アプリに割り当てることができます。 Microsoft Graphはアンブレラ リソースとして機能します。 対象ユーザー レポートを使用して、基になるサービスを確認し、ポリシー内のそれらのサービスを対象とします。 Microsoft 365/Office 365 や Windows Azure Service Management API複数の関連する子アプリまたはサービスが含まれています。 新しい Microsoft クラウド アプリケーションが作成されると、テナントにサービス プリンシパルが作成されるとすぐに、アプリ ピッカーの一覧に表示されます。

Office 365

Microsoft 365は、Exchange、SharePoint、Microsoft Teamsなどのクラウドベースの生産性とコラボレーション サービスを提供します。 条件付きアクセスでは、アプリケーションのMicrosoft 365 スイートが "Office 365" の下に表示されます。 Microsoft 365クラウド サービスは、スムーズでコラボレーションのエクスペリエンスを確保するために深く統合されています。 Microsoft Teamsなどの一部のアプリは、SharePointや Exchange など、他のアプリに依存するため、この統合によってポリシーの作成時に混乱が生じる可能性があります。

条件付きアクセスでのOffice 365 アプリのグループ化により、これらのサービスを一度にすべて対象にできます。 個々のクラウド アプリをターゲットにするのではなく、Microsoft 365グループ化を使用して、サービスの依存関係の問題を回避することをお勧めします。

このアプリケーション グループをターゲットにすると、整合性のないポリシーや依存関係のために発生する可能性のある問題を回避するのに役立ちます。 たとえば、Exchange Online アプリは、メール、予定表、連絡先情報などの従来のExchange Online データに関連付けられています。 関連するメタデータは、検索などのさまざまなリソースを通して公開される可能性があります。 すべてのメタデータが意図したとおりに保護されるようにするには、管理者はMicrosoft 365 アプリにポリシーを割り当てる必要があります。

管理者は、条件付きアクセス ポリシーから、Microsoft 365 スイート全体または特定のMicrosoft 365 クラウド アプリを除外できます。

含まれるすべてのサービスの完全な一覧は、アプリ スイートの条件付きアクセスに含まれる記事 Apps Microsoft 365で確認できます。

Windows Azure Service Management API

Windows Azure Service Management API アプリケーションを対象にすると、ポータルに密接にバインドされた一連のサービスに発行されたトークンに対してポリシーが適用されます。 このグループ化には、次のアプリケーション ID が含まれます。

• Azure Resource Manager
• Azure ポータル。Microsoft Entra管理センターと Microsoft Engage Center も対象となります
• Azure Data Lake
• Application Insights API
• Log Analytics API（ログアナリティクス API）

ポリシーはAzure管理ポータルと API に適用されるため、Azure API に依存するすべてのサービスまたはクライアントが間接的に影響を受ける可能性があります。 例えば次が挙げられます。

• Azure CLI
• Azure Data Factory ポータル
• Azure Event Hubs
• Azure PowerShell
• Azure Service Bus
• Azure SQL Database
• Azure Synapse
• クラシック デプロイ モデル API
• Microsoft 365管理センター
• Microsoft IoT Central
• マルチテナント管理のMicrosoft Defender
• SQL Managed Instance
• Visual Studio サブスクリプション管理者ポータル

Microsoft 管理ポータル

条件付きアクセス ポリシーが Microsoft 管理ポータル クラウド アプリを対象とする場合、ポリシーは、Microsoft 管理ポータルに関連付けられている特定の基になるリソース アプリケーション ID に対して発行されたトークンに適用されます。 アプリのグループ化には、これらのポータルが呼び出したり依存したりするバックエンド サービスは含まれません。 管理ポータルのサービスの依存関係を特定するには、サインイン ログで条件付きアクセス対象ユーザーレポートを使用します

次のアプリケーションは、Microsoft 管理ポータルで構成されます。

• Exchange Admin Center アプリ ID: 497effe9-df71-4043-a8bb-14cf78c4b63b
• Azure ポータル アプリ ID: c44b4083-3bb0-49c1-b47d-974e53cbdf3c
• Microsoft Office 365 Portal アプリ ID: 00000006-0000-0ff1-ce00-00000000000
• Microsoft 365 Security and Compliance Center (Protection Center) アプリ ID: 80ccca67-54bd-44ab-8625-4b79c4dc7775

管理ポータルのグループ化は、主に、条件付きアクセス ポリシー (MFA の適用など) を使用して 1 つ以上の管理ポータルを対象とする簡単な方法を含むシナリオを対象としています。 このグループ化は、Microsoft が 管理する管理者向けの MFA で利用され、ポリシーの作成を効率化します。

このオプションは、基になるアプリケーション ID に関連付けられているすべてのバックエンド サービスの一括除外メカニズムとして機能するものではありません。

その他のアプリケーション

管理者は、登録Microsoft Entraアプリケーションを条件付きアクセス ポリシーに追加できます。 これらのアプリケーションには次が含まれることがあります。

• Microsoft Entra アプリケーション プロキシ
• ギャラリーから追加されたアプリケーション
• ギャラリーにないカスタム アプリケーション
• アプリ配信コントローラーとネットワーク経由で公開されるレガシ アプリケーション
• パスワードに基づくシングル サインオンを使用するアプリケーション

一部のアプリケーションは、ピッカーにまったく表示されません。 これらのアプリケーションを条件付きアクセス ポリシーに含める唯一の方法は、すべてのリソース (以前の "すべてのクラウド アプリ") を含めるか、>を使用して不足しているサービス プリンシパルを追加することです。 New-MgServicePrincipal PowerShell コマンドレットを使用するか、Microsoft Graph API を使用します。

さまざまなクライアントの種類の条件付きアクセス

条件付きアクセスは、クライアントが ID トークンを要求する機密クライアントである場合を除き、クライアントではなくリソースに適用されます。

• パブリック クライアント
  • パブリック クライアントとは、デスクトップ上のMicrosoft Outlookなどのデバイスや、Microsoft Teamsなどのモバイル アプリでローカルに実行されるクライアントです。
  • 条件付きアクセス ポリシーは、パブリック クライアント自体には適用されませんが、要求するリソースに基づいています。
• 機密クライアント
  • 条件付きアクセスは、クライアントによって要求されたリソース、および ID トークンを要求した場合の機密クライアント自体に適用されます。
  • たとえば、Outlook Web がスコープ Mail.Read および Files.Read のトークンを要求する場合、条件付きアクセスは Exchange とSharePointのポリシーを適用します。 さらに、Outlook Web が ID トークンを要求した場合、条件付きアクセスは Outlook Web のポリシーも適用します。

Microsoft Entra 管理センターでこれらのクライアントの種類に対するサインイン ログを表示するには、次の手順に従います。

1. Microsoft Entra管理センターに少なくとも Reports 閲覧者としてサインインします。
2. Entra IDに移動し、モニタリングとヘルスのサインイン ログを参照します。
3. [クライアント資格情報の種類] のフィルターを追加します。
4. サインインで使用されるクライアント資格情報に基づいてログの特定のセットを表示するように、フィルターを調整します。

詳細については、 パブリック クライアント アプリケーションと機密クライアント アプリケーションに関する記事を参照してください。

すべてのリソースの条件付きアクセス

リソースを除外せずに すべてのリソース (以前は "すべてのクラウド アプリ") に 条件付きアクセス ポリシーを適用すると、 グローバル セキュリティで保護されたアクセス トラフィック転送プロファイルを含む、Web サイトやサービスからのすべてのトークン要求に対してポリシーが適用されます。 このオプションには、Windows Azure Active Directory (00000002-0000-0000-c0000-00000000000) など、条件付きアクセス ポリシーで個別に対象にできないアプリケーションが含まれます。

すべてのリソース ポリシーにリソースの除外がある場合の従来の条件付きアクセスの動作

アプリがポリシーから除外されている場合、誤ってユーザー アクセスをブロックしないようにするために、特定の低い特権スコープが 以前に ポリシーの適用から除外されていました。 これらのスコープは、基になる Graph API の呼び出し、例えば、Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) や Microsoft Graph (00000003-0000-0000-c000-000000000000) へのアクセスを可能にし、認証の一部としてアプリケーションで一般的に使用されるユーザープロファイルおよびグループメンバーシップ情報にアクセスする許可を与えました。 たとえば、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: 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 (リソース: Windows Azure Active Directory、ID: 00000002-0000-0000-c000-0000000000000) にマップされるようになりました。

1 つ以上のリソース除外を持つすべてのリソースを対象とする条件付きアクセス ポリシー、または AD Graph Azure明示的にターゲットとするポリシーは、クライアント アプリケーションがこれらのスコープのみを要求するユーザー サインイン フローで適用されます。 アプリケーションが上記の範囲を超えて追加のスコープを要求した場合の動作に変更はありません。

ユーザー エクスペリエンス

クライアント アプリケーションが上記のスコープのみを要求するユーザー サインイン フローでは、ユーザーは条件付きアクセスチャレンジ (MFA やデバイス コンプライアンスなど) を受け取る可能性があります。 正確な課題は、すべてのリソース (リソースの除外ありまたは除外なし) を対象とするポリシーまたは AD Graph を明示的にターゲットとするポリシー Azure構成されているアクセス制御によって異なります。

次の例では、テナントに条件付きアクセス ポリシーがあり、次の詳細が含まれています。

• すべてのユーザーとすべてのリソースを対象とする
• 機密クライアント アプリケーションとExchange Onlineのリソース除外
• MFA が許可コントロールとして構成されている

シナリオの例

次の例に示すように、クライアント アプリケーションが前に示した範囲を超えるスコープを要求した場合の動作に変更はありません。

シナリオの例

ほとんどのアプリケーションは、前述のスコープを超えてスコープを要求し、アプリケーションがポリシーから明示的に除外されていない限り、既に条件付きアクセスの適用の対象となります。 このような場合、動作に変更はありません。

条件付きアクセスチャレンジを処理できるように、以前に一覧表示されたスコープのみを要求するように意図的に設計され、条件付きアクセスチャレンジを処理するように設計されていないカスタム アプリケーションは、更新が必要になる場合があります。 実装の詳細については、 Microsoft 条件付きアクセス開発者向けガイダンス を参照してください。

低い特権スコープの適用の変更の影響を受けるアプリケーションを特定する方法

アプリケーションは、前述のスコープのうち 1 つ以上のみを要求するように事前に承認できます。 影響を受けるアプリケーションを特定するには、次のオプションを使用します。

# ==============================
# Inventory of apps whose delegated consent grants include ONLY
# the OIDC scopes + specific directory scopes listed below.
#
# Enhancements incorporated:
#  - Supported both PowerShell 5.1 and 7.x
#  - Add user sign-in count (last 7 days) per app
#
# Output:
#  - ServicePrincipalObjectId (oauth2PermissionGrants.clientId = SP object id)
#  - AppId
#  - AppDisplayName
#  - AppOwnerOrganizationId (for classification)
#  - Scopes (union of delegated scopes granted)
#  - UserSigninsLast7Days (Successful + Failed)
# ==============================

$TenantId = Read-Host "Enter your Microsoft Entra tenant ID (GUID)"

$BaselineScopes = @(
  "openid", "profile", "email", "offline_access",
  "User.Read", "User.Read.All", "User.ReadBasic.All",
  "People.Read", "People.Read.All",
  "GroupMember.Read.All", "Member.Read.Hidden"
)

Disconnect-MgGraph -ErrorAction SilentlyContinue

Connect-MgGraph -TenantId $TenantId -Scopes @(
  "DelegatedPermissionGrant.Read.All",
  "Directory.Read.All",
  "Reports.Read.All"
)

# ------------------------------
# Pull oauth2PermissionGrants (paging)
# ------------------------------
$uri = "https://graph.microsoft.com/beta/oauth2PermissionGrants?`$select=clientId,scope,consentType"
$grants = @()
while ($uri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $uri
  $grants += $resp.value
  $uri = $resp.'@odata.nextLink'
}

# ------------------------------
# Build baseline-only candidate set (Jun: HashSet per clientId)
# ------------------------------
$scopesByClient = @{}  # key: clientId (SP objectId), value: HashSet[string] (case-insensitive)

foreach ($g in $grants) {
  $cid = $g.clientId.ToString().Trim()
  if (-not $cid) { continue }

  if (-not $scopesByClient.ContainsKey($cid)) {
    $scopesByClient[$cid] = [System.Collections.Generic.HashSet[string]]::new(
      [System.StringComparer]::OrdinalIgnoreCase
    )
  }

  foreach ($s in ($g.scope -split '\s+')) {
    if ($s -and $s.Trim().Length -gt 0) {
      [void]$scopesByClient[$cid].Add($s.Trim())
    }
  }
}

$candidates = foreach ($cid in $scopesByClient.Keys) {
  $scopes = $scopesByClient[$cid]
  if ($scopes.Count -le 0) { continue }

  $outside = $scopes | Where-Object { $_ -notin $BaselineScopes }
  if ($outside.Count -eq 0) {
    [PSCustomObject]@{
      ServicePrincipalObjectId = $cid
      Scopes = ($scopes -join ' ')
    }
  }
}

# ------------------------------
# Pull per-app sign-in summary for last 7 days (Graph REST via Invoke-MgGraphRequest)
# Endpoint: GET /beta/reports/getAzureADApplicationSignInSummary(period='D7')
# In this API output, 'id' corresponds to the appId (clientId)
# ------------------------------
$signInSummary = @()
$signInUri = "https://graph.microsoft.com/beta/reports/getAzureADApplicationSignInSummary(period='D7')"

while ($signInUri) {
  $resp = Invoke-MgGraphRequest -Method GET -Uri $signInUri

  if ($resp -and $resp.value) {
    $signInSummary += $resp.value
  }

  # Paging (if present)
  $signInUri = $resp.'@odata.nextLink'
}

# appId -> total sign-ins (7d)
$signInCountByAppId = @{}
foreach ($s in $signInSummary) {
  $appId = $s.id
  if (-not $appId) { continue }

  # PS5.1-safe null handling
  $success = 0
  $failed  = 0
  if ($null -ne $s.successfulSignInCount) { $success = [int]$s.successfulSignInCount }
  if ($null -ne $s.failedSignInCount)     { $failed  = [int]$s.failedSignInCount }

  $signInCountByAppId[$appId] = $success + $failed
}

$resultsTenantOwned = @()
$resultsNotTenantOwned = @()

# ------------------------------
# Filter to tenant-owned or external apps; enrich with appId/displayName + sign-in counts
# ------------------------------
foreach ($c in $candidates) {
  try {
    $spUri = "https://graph.microsoft.com/beta/servicePrincipals/$($c.ServicePrincipalObjectId)?`$select=id,appId,displayName,appOwnerOrganizationId"
    $sp = Invoke-MgGraphRequest -Method GET -Uri $spUri

    $signinCount7d = 0
    if ($sp.appId -and $signInCountByAppId.ContainsKey($sp.appId)) {
      $signinCount7d = $signInCountByAppId[$sp.appId]
    }

    $row = [PSCustomObject]@{
      ServicePrincipalObjectId = $c.ServicePrincipalObjectId
      AppId                   = $sp.appId
      AppDisplayName          = $sp.displayName
      AppOwnerOrganizationId  = $sp.appOwnerOrganizationId
      Scopes                  = $c.Scopes
      UserSigninsLast7Days    = $signinCount7d
    }

    if ($sp.appOwnerOrganizationId -eq $TenantId) {
      $resultsTenantOwned += $row
    }
    else {
      $resultsNotTenantOwned += $row
    }
  }
  catch {
    # Ignore non-enumerable / missing service principals
  }
}

# ------------------------------
# Output
# ------------------------------
'=== Tenant-owned apps whose delegated consent grants include ONLY baseline scopes + user sign-ins (last 7 days) ==='
$resultsTenantOwned |
  Sort-Object UserSigninsLast7Days -Descending |
  Format-Table -AutoSize

'=== External apps whose delegated consent grants include ONLY baseline scopes + user sign-ins (last 7 days) ==='
$resultsNotTenantOwned |
  Sort-Object UserSigninsLast7Days -Descending |
  Format-Table -AutoSize

ディレクトリ情報の保護

リソースを除外せずに推奨されるベースライン 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-00000000000) を対象とする別の条件付きアクセス ポリシーを作成します。 Windows Azure Active Directory (Azure AD Graph とも呼ばれます) は、ユーザー、グループ、アプリケーションなどのディレクトリに格納されているデータを表すリソースです。 Windows Azure Active Directory リソースは すべてのリソース に含まれますが、次の手順を使用して、条件付きアクセス ポリシーで個別に対象にすることができます。

1. Microsoft Entra管理センターにAttribute 定義管理者およびAttribute 割り当て管理者としてサインインします。
2. Entra IDカスタム セキュリティ属性を参照します。
3. 新しい属性セットと属性定義を作成します。 詳細については、「Microsoft Entra ID でカスタム セキュリティ属性定義を追加または非アクティブ化する方法に関するトピックを参照してください。
4. Entra IDエンタープライズアプリケーションに移動します。
5. [アプリケーションの種類] フィルターを削除し、00000002-0000-0000-c000-000000000000 で始まるアプリケーション ID を検索します。
6. Windows Azure Active Directory>Custom セキュリティ属性>割り当ての追加 を選択します。
7. ポリシーで使用する属性セットと属性値を選択します。
8. Entra IDConditional AccessPolicies に移動します。
9. 既存のポリシーを作成または変更します。
10. ターゲット リソースリソース (旧クラウド アプリ)含めるで、リソースの選択フィルターの編集を選択します。
11. 前述の属性セットおよび定義を含むようにフィルターを調整します。
12. [ アクセス制御許可] で、[ アクセス権の付与]、[ 認証強度が必要] の順に選択し、[ 多要素認証] を選択し、[選択] を 選択します。
13. 設定を確認し、 [ポリシーの有効化] を [レポート専用] に設定します。
14. [作成] を選択して、ポリシーを有効化します。

グローバル セキュア アクセスを使用するすべてのインターネット リソース

グローバル セキュア アクセス オプションを使用することで、管理者は インターネット アクセス トラフィック転送プロファイル をMicrosoft Entra Internet Accessから指定できます。

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

これらのプロファイルの詳細については、「グローバル セキュア アクセス トラフィック転送プロファイル」の記事を参照してください。

すべてのエージェント リソース (プレビュー)

条件付きアクセス ポリシーをすべてのエージェント リソースに適用すると、エージェント ID ブループリント プリンシパルとエージェント ID に対するすべてのトークン要求のポリシーが適用されます。

ユーザー操作

ユーザー操作とは、ユーザーが実行するタスクのことです。 条件付きアクセスでは、次の 2 つのユーザー アクションがサポートされます。

• セキュリティ情報の登録: このユーザー アクションにより、ユーザーがセキュリティ情報を登録しようとしたときに、条件付きアクセス ポリシーで規則が適用されます。 詳細については、「 統合されたセキュリティ情報の登録」を参照してください。

• デバイスの登録または参加: このユーザー アクションを使用すると、ユーザーがデバイスを Microsoft Entra ID に登録または参加させるときに、条件付きアクセス ポリシーを適用できます。 これにより、管理者は、テナント全体のポリシーよりも細かい粒度でデバイスを登録または参加するための多要素認証を構成できます。 このユーザー操作には、次の 3 つの重要な考慮事項があります。
  • と は、このユーザー アクションで使用できる唯一のアクセス制御であり、その他はすべて無効になっています。 この制限により、Microsoft Entraデバイスの登録に依存しているか、Microsoft Entraデバイス登録に適用できないアクセス制御との競合が回避されます。
    • これらのシナリオではデバイスが既に登録されている必要があるため、Windows Hello for Businessおよびデバイスに結びついたパスキーはサポートされていません。
  • Client apps、Filters for devices、および Device state の条件は、条件付きアクセス ポリシーを適用するためにデバイスMicrosoft Entra登録に依存しているため、このユーザー アクションでは使用できません。

認証コンテキスト

認証コンテキストは、アプリケーションのデータとアクションをセキュリティで保護します。 これらのアプリケーションには、カスタム アプリケーション、基幹業務 (LOB) アプリケーション、SharePoint、またはMicrosoft Defender for Cloud Appsで保護されたアプリケーションが含まれます。 また、ロールのアクティブ化中に条件付きアクセス ポリシーを適用するために、Microsoft Entra Privileged Identity Management (PIM) と共に使用することもできます。

たとえば、組織は、ランチ メニューや秘密のバーベキュー ソースレシピなどのSharePointサイトにファイルを格納する場合があります。 誰もがランチメニューサイトにアクセスするかもしれませんが、秘密のBBQソースレシピサイトにアクセスするユーザーは、マネージドデバイスを使用し、特定の利用規約に同意する必要があります。 同様に、PIM を使用して特権ロールをアクティブ化する管理者は、多要素認証を実行したり、準拠しているデバイスを使用したりする必要がある場合があります。

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

認証コンテキストの構成

Entra IDConditional AccessAuthentication コンテキストに移動して、認証コンテキストを管理します。

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

[ 新しい認証コンテキスト ] を選択して、認証コンテキスト定義を作成します。 組織は、最大 99 個の認証コンテキスト定義 (c1 から c99) を作成できます。 次の属性を構成します。

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

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

管理者は、 割り当てCloud アプリまたはアクション に移動し、[このポリシーが適用される内容の選択] メニューから [認証コンテキスト ] を選択することで、条件付きアクセス ポリシーで発行された認証コンテキスト を選択 できます。

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

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

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

認証コンテキストを削除するには、条件付きアクセス ポリシーが割り当てられていないか、アプリに発行されていないことを確認します。 これにより、認証コンテキストが誤って削除されるのを防ぐことができます。

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

認証コンテキストの使用の詳細については、次の記事を参照してください。

• 秘密度ラベルを使用して、Microsoft Teams、Microsoft 365 グループ、SharePoint サイトのコンテンツを保護します
• Microsoft Defender for Cloud Apps
• カスタム アプリケーション
• Privileged Identity Management - アクティブ化時に、条件付きアクセス認証コンテキストをMicrosoft Entraする必要があります

関連コンテンツ

• 条件付きアクセス: 条件 – ポリシーを調整する条件を構成する方法について説明します。
• 条件付きアクセスの一般的なポリシー – 一般的なポリシー テンプレートを調べてすぐに開始します。
• クライアント アプリケーションの依存関係 – 依存関係が条件付きアクセス ポリシーにどのように影響するかを理解します。