トークン保護の展開ガイド - Web アプリ (プレビュー)

このガイドでは、Azure Resource Manager (ARM) にアクセスする Web (ブラウザー ベース) アプリケーションで使用されるサインイン セッション トークンのトークン保護をデプロイして適用するために必要な手順について説明します。

トークン保護とサポートされているプラットフォームの概要については、「Microsoft Entra 条件付きアクセスのToken Protectionを参照してください。 このデプロイ ガイドを使用する前に、概要ドキュメントを確認してください。

前提条件

この機能を使用するには、Microsoft Entra ID P1 ライセンスが必要です。 要件に適したライセンスを見つけるには、Microsoft Entra ID の一般的に利用可能な機能を比較する を参照してください。

サポートされているアプリケーション、リソース、ブラウザー

アプリケーション

• Azure portal
• Microsoft Intune 管理センター
• Microsoft Entra 管理センター
• Microsoft エンゲージ センター
• Microsoft Engage Hub

上記の Web アプリケーションのみがサポートされています。 ポリシーが適用されると 、ARM にアクセスする他の Web アプリケーションへの ユーザーのアクセスがブロックされます。 ARM にアクセスするが サポートされていない 上位の Web アプリケーションには、次のものが含まれますが、これらに限定されません。

• Microsoft 365 セキュリティおよびコンプライアンス センター
• Microsoft AppSource
• Azure Data Factory
• AZURE AI Studio アプリ
• Azure Synapse Studio
• Microsoft Power BI
• Microsoft 開発者ポータル
• Azure OpenAI Studio
• Power Platform 管理センター

サポートされているリソース

• Windows Azure Service Management API リソースとして条件付きアクセスで構成されたAzure Resource Manager (ARM)。

サポートされているプラットフォームとブラウザー

¹ 一部のデバイス登録の種類はサポートされていません。 サポートされていないデバイス登録の種類の一覧を参照してください。

Windowsと macOS で ARM のトークン保護を有効にする

アプリ、ブラウザー、またはデバイスの非互換性が原因でユーザーが中断する可能性を最小限に抑えるには、次の推奨事項に従います。

• ユーザーのパイロット グループから開始し、時間の経過と共に拡張します。
• 適用する前に、 レポート専用モード でトークン保護の条件付きアクセス ポリシーを作成します。
• 対話型サインイン ログと非対話型サインイン ログの両方をキャプチャします。
• 通常のアプリケーション使用を十分にカバーする長さまでこれらのログを分析します。 ユーザーの影響を分析して理解するための手順については、次のセクションで説明します。
• 信頼できる既知のユーザーをユーザー グループに追加し、ポリシーを適用します。

このプロセスは、トークン保護の適用に対するユーザーの準備状況を評価するのに役立ちます。

手順 1: エンド ユーザー デバイスを構成する

各デバイスで、手動またはグループ ポリシーまたは Intune を使用して、以下を完了します。

Windows

1. デバイスがビルド 26100.8246/26200.8246 以降Windows 11実行されていることを確認します。

2. 次のレジストリ値を設定して、このプレビューを有効にします。

   [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\BrowserCore]
   "EnablePlatformAuth"=dword:00000001
   

3. Microsoft Single Sign-On ブラウザー拡張機能をインストールします。

   • Google Chrome:Chrome Web ストアからシングル サインオンMicrosoftインストールし、[Chrome に追加] を選択し>拡張機能を追加して、ツール バーに表示されたことを確認します。
   • Microsoft Edge: edge://extensionsに移動し、[他のストアからの拡張機能を許可する] をオンにして、Microsoft シングル サインオン拡張機能をインストールして、有効になっていることを確認します。

macOS

1. Microsoft ポータル サイトをインストールするか、MDM ソリューションを使用して展開します。 ポータル サイトは、Microsoft Entra サインインの認証ブローカーとして機能します。
2. 次のいずれかのオプションを使用して、ハードウェアベースの登録を有効にします。
   • オプション A:Microsoft Enterprise SSO プラグインを有効にします。
   • オプション B:macOS 用のプラットフォーム SSO を構成します。 プラットフォーム SSO では、既定でハードウェアベースのストレージが使用され、追加のフラグ構成は必要ありません。 セットアップ手順については、Microsoft Intune の macOS デバイスの Configure Platform SSO に関するページを参照してください。
3. 前のWindowsセクションで説明したように、Microsoft Edge または Google Chrome に Microsoft シングル サインオン ブラウザー拡張機能をインストールします。

手順 1 の後に想定される内容

デバイスが前提条件と構成を満たすと、サポートされているアプリケーションとブラウザーからの認証要求がブラウザー内で完全に完了しなくなります。代わりにプラットフォーム認証ブローカーによって処理されます。 この動作により、これらのアプリケーションは、 プライマリ更新トークン (PRT) などのデバイス バインドサインイン セッション トークンを使用し、トークン保護の条件付きアクセス ポリシーを満たすことができます。

次の計画を立てる。

• 変更を有効にするには、少なくとも 24 時間かかります。 ブローカー ベースの認証への切り替えは、レジストリ値、拡張機能、またはプラットフォーム SSO プロファイルが適用された直後ではありません。 このウィンドウが通過するか、レポートのみのデータに準備が正確に表示されないまで、手順 2 に進む必要はありません。
• ほとんどの場合、切り替えは自動的に行われます。 通常、ユーザーは何も行いません。変更が反映されている間、既存のブラウザー セッションは引き続き機能します。
• 一部のユーザーには、簡単なサインイン ダイアログが表示されます。 プレビュー期間中、Azure ポータルにアクセスしているユーザーに、"サインインしています..."新しいウィンドウが開いています。 新しいウィンドウは表示されません。ユーザーアクションは必要ありません。サインインは単独で完了します。 必要に応じて、この動作をパイロット グループに事前に伝えて、障害として報告されないようにします。

手順 2: レポート専用モードで条件付きアクセス ポリシーを作成する

手順 1 を完了してから 24 時間待つと、引き続きレポート専用モードでポリシーを設定し、適用の準備を確認できます。

1. 少なくとも条件付きアクセス管理者としてMicrosoft Entra 管理センターにサインインします。
2. Entra ID>Conditional Access>Policies に移動し、[新しいポリシー] を選択して名前を付けます。
3. [ 割り当て>ユーザー] に、パイロット ユーザーまたはテスト ユーザーを含めます。 組織の緊急アクセスや重大なアカウントは含めないでください。
4. [ターゲット リソース>リソース (旧称クラウド アプリ)) >リソースの選択>サービス管理 API Windows Azure選択します。
5. [条件>Device プラットフォームで、[構成] を [はい] に設定し、Windows、macOS、またはその両方を含めます。
6. [ 条件>Client アプリで、[ 構成] を[はい ] に設定し、 ブラウザーを含めます。 このプレビューでは、 モバイル アプリとデスクトップ クライアント を選択しないようにしてください。
7. [ アクセス制御>Session] で、[ サインイン セッションにトークン保護を要求する] を選択し、[選択] を 選択します。
8. [ポリシーの有効化] を [レポートのみ] に設定し、[作成] を選択します。

手順 3: ログとメトリックを使用した適用の準備状況を確認する

レポートのみのポリシーが設定され、実行されたら、Policy の影響を確認し、サインイン ログを分析し、Log Analytics を使用してinvestigate して適用の準備状況を確認する必要があります。

サインイン ログ

管理センターでトークン保護関連のサインイン イベントを表示するには:

1. Microsoft Entra 管理センターに、少なくとも条件付きアクセス管理者としてサインインします。
2. Entra ID>に移動し、モニタリングとヘルス>のサインイン ログを参照します。
3. トークン保護 - サインイン セッション状態コード列をビューに追加して、関連するサインイン イベントをすばやく表示します。 また、Azure Resource Manager リソースにフィルター処理し、[クライアント アプリ] を [ブラウザー] に設定して、このプレビューに関連するサインイン要求を分離します。
4. 調査中のサインイン イベントを選択します。
5. ポリシーの状態に応じて、[ 条件付きアクセス ] タブと [ レポート専用 ] タブを確認し、トークン保護ポリシーを選択します。
6. [ セッション制御] で、ポリシー要件が満たされているかどうかを確認します。
7. [ 基本情報 ] タブを選択し、[ トークン保護 - サインイン セッション ] フィールドで詳細を確認します。

サインイン ログには、要求がデバイス バインド トークンを使用するかどうかを示す tokenProtectionStatusDetails プロパティが含まれます。

"tokenProtectionStatusDetails": {
  "signInSessionStatus": "bound | unbound",
  "signInSessionStatusCode": <code>
}

サインイン セッションの状態コード

要求が 非連結 として表示される理由を理解したり、ポリシーを適用できるユーザーを特定したりするには、次の状態コードを参照してください。

自己修復可能なユーザーを識別する (macOS のみ)

macOS では、コード 1003 と 1004 は、1 回限りデバイス登録のアップグレードによって自己修復できます。

ユーザー アクションに準拠している要求またはアップグレード可能な要求を特定するには、次の条件をフィルター処理します。

• signInSessionStatus == bound、または
• signInSessionStatus == unbound 1003または1004のsignInSessionStatusCode。

非対話型サインインのサンプル Microsoft Graph クエリ:

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=(
  signInEventTypes/any(t: t eq 'nonInteractiveUser')
  and resourceDisplayName eq 'Azure Resource Manager'
  and (tokenProtectionStatusDetails/signInSessionStatusCode eq 1003
    or tokenProtectionStatusDetails/signInSessionStatusCode eq 1004
    or tokenProtectionStatusDetails/signInSessionStatus eq 'bound'))

これらのユーザーにトークン保護が適用されると、もう一度サインインするように求めるメッセージが表示され、認証が完了したらリソースにアクセスできます。

Log Analytics

また、Log Analyticsを使用して、トークン保護の強制エラーが原因でブロックされた要求に対して対話型および非対話型のサインイン ログに対してクエリを実行することもできます。 これらのクエリはサンプルのみであり、変更される可能性があります。 Azure Resource Manager リソースをフィルター処理し、準備メトリックを追加して、ハード ブロックと自己修復可能なブロックを区別できるようにします。

アプリケーション別の要求

次のサンプル クエリでは、過去 7 日間の非対話型サインイン ログを検索し、アプリケーションによる ARM へのブロックされた要求と許可された要求を強調表示し、ユーザーが自己修復できるブロックにフラグを設定します。 SigninLogsを入れ替えて、対話型ブラウザーのサインインを確認します。

// Select the log to query (SigninLogs or AADNonInteractiveUserSignInLogs)
// SigninLogs
AADNonInteractiveUserSignInLogs
// Adjust the time range below
| where TimeGenerated > ago(7d)
| project Id, ConditionalAccessPolicies, Status, UserPrincipalName, AppDisplayName,
    ResourceDisplayName, TokenProtectionStatusDetails
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName == "Azure Resource Manager"
// Add UserPrincipalName if you want to filter to a specific user
// | where UserPrincipalName == "<user_principal_name>"
| mv-expand todynamic(ConditionalAccessPolicies)
| where ConditionalAccessPolicies["enforcedSessionControls"] contains '["Binding"]'
    or ConditionalAccessPolicies["enforcedSessionControls"] contains '["SignInTokenProtection"]'
| where ConditionalAccessPolicies.result != "reportOnlyNotApplied"
    and ConditionalAccessPolicies.result != "notApplied"
| extend SessionNotSatisfyResult = ConditionalAccessPolicies["sessionControlsNotSatisfied"]
| extend Result = case(
    SessionNotSatisfyResult contains 'SignInTokenProtection'
        or SessionNotSatisfyResult contains 'Binding', 'Block', 'Allow')
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails)
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"])
| extend IsSelfRemediable = Result == "Block"
    and (bindingStatusCode == "1003" or bindingStatusCode == "1004")
| summarize by Id, UserPrincipalName, AppDisplayName, Result, IsSelfRemediable
| summarize Requests = count(),
    Users = dcount(UserPrincipalName),
    Allow = countif(Result == "Allow"),
    Block = countif(Result == "Block"),
    BlockSelfRemediable = countif(IsSelfRemediable == true),
    BlockedUsers = dcountif(UserPrincipalName, Result == "Block"),
    BlockedUsersSelfRemediable = dcountif(UserPrincipalName, IsSelfRemediable == true)
    by AppDisplayName
| extend PctAllowed = round(100.0 * Allow / (Allow + Block), 2)
| extend PctEnforceable = round(100.0 * (Allow + BlockSelfRemediable) / (Allow + Block), 2)
| project AppDisplayName, Requests, Users, Allow, Block,
    BlockSelfRemediable, BlockedUsers, BlockedUsersSelfRemediable,
    PctAllowed, PctEnforceable
| sort by Requests desc

ユーザーによる要求

次のクエリでは、過去 7 日間の非対話型サインイン ログを調べます。このログでは、同じ自己修復可能で強制可能なメトリックを使用して、ユーザーによる ARM へのブロックされた要求と許可された要求が強調表示されています。

// Per-user query for the Azure portal -> ARM web app scenario
// SigninLogs
AADNonInteractiveUserSignInLogs
// Adjust the time range below
| where TimeGenerated > ago(7d)
| project Id, ConditionalAccessPolicies, UserPrincipalName, AppDisplayName,
    ResourceDisplayName, TokenProtectionStatusDetails
| where ConditionalAccessPolicies != "[]"
| where ResourceDisplayName == "Azure Resource Manager"
// Add UserPrincipalName if you want to filter to a specific user
// | where UserPrincipalName == "<user_principal_name>"
| mv-expand todynamic(ConditionalAccessPolicies)
| where ConditionalAccessPolicies["enforcedSessionControls"] contains '["Binding"]'
    or ConditionalAccessPolicies["enforcedSessionControls"] contains '["SignInTokenProtection"]'
| where ConditionalAccessPolicies.result != "reportOnlyNotApplied"
    and ConditionalAccessPolicies.result != "notApplied"
| extend SessionNotSatisfyResult = ConditionalAccessPolicies.sessionControlsNotSatisfied
| extend Result = case(
    SessionNotSatisfyResult contains 'SignInTokenProtection'
        or SessionNotSatisfyResult contains 'Binding', 'Block', 'Allow')
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails)
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"])
| extend IsSelfRemediable = Result == "Block"
    and (bindingStatusCode == "1003" or bindingStatusCode == "1004")
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName, Result, IsSelfRemediable
| summarize Requests = count(),
    Allow = countif(Result == "Allow"),
    Block = countif(Result == "Block"),
    BlockSelfRemediable = countif(IsSelfRemediable == true)
    by UserPrincipalName, AppDisplayName, ResourceDisplayName
| extend PctAllowed = round(100.0 * Allow / (Allow + Block), 2)
| extend PctEnforceable = round(100.0 * (Allow + BlockSelfRemediable) / (Allow + Block), 2)
| project UserPrincipalName, AppDisplayName, ResourceDisplayName,
    Requests, Allow, Block, BlockSelfRemediable,
    PctAllowed, PctEnforceable
| sort by UserPrincipalName asc

手順 4: ポリシーを適用する

サインイン ログ データを確認し、対象のユーザーとデバイスの準備ができていることを確認したら、[ ポリシーの有効化] トグルを [レポートのみ] から [オン] に移動します。

関連するコンテンツ

• Microsoft Entra 条件付きアクセスでのトークン保護
• トークン保護の展開ガイド - Windows
• トークン保護の展開ガイド - Apple プラットフォーム
• プライマリ更新トークンとは