Microsoft Entra 条件付きアクセス: トークン保護 (プレビュー)

トークン保護 (業界ではトークンのバインドと呼ばれることがあります) では、トークンが目的のデバイスからのみ使用可能であることを確実にすることで、トークンの盗難を使用した攻撃を減らそうとします。 攻撃者がトークンを盗むことができる場合、ハイジャックまたはリプレイによって、トークンの有効期限が切れるか、トークンが取り消されるまで、被害者になりすます可能性があります。 トークンの盗難は比較的まれなイベントと考えられますが、その被害が大きくなる可能性があります。

トークン保護により、トークンとトークンが発行されるデバイス (クライアント シークレット) との間に暗号化で保護された結び付きが生じます。 クライアント シークレットがないと、バインドされたトークンは役に立ちません。 ユーザーが Microsoft Entra ID で Windows 10 以降のデバイスを登録すると、そのプライマリ ID が デバイスにバインドされます。 つまり、ポリシーによって、バインドされたサインイン セッション (または更新) トークン (プライマリ更新トークン (PRT) と呼ばれる) のみが、リソースへのアクセスを要求するときにアプリケーションによって使用されることを保証できます。

要件

この機能を使用するには、Microsoft Entra ID P2 ライセンスが必要です。 要件に適したライセンスを見つけるには、Microsoft Entra のプランと価格を参照してください。

次のデバイスとアプリケーションは、トークン保護の条件付きアクセス ポリシーが適用されているリソースへのアクセスをサポートしています。

サポート対象デバイス:

• Microsoft Entra 参加済み、Microsoft Entra ハイブリッド参加済み、または Microsoft Entra 登録済みの Windows 10 以降のデバイス。 サポートされていないデバイスの種類については 、既知の制限事項に 関するセクションを参照してください。
• ハイブリッド Microsoft Entra 参加済みの Windows Server 2019 以降。

サポートされているアプリケーション:

• OneDrive 同期クライアント バージョン 22.217 以降
• Teams ネイティブ クライアント バージョン 1.6.00.1331 以降
• Power BI Desktop バージョン 2.117.841.0 (2023 年 5 月) 以降
• Exchange PowerShell モジュール バージョン 3.7.0 以降
• Microsoft Graph PowerShell バージョン 2.0.0 以降、EnableLoginByWAM オプションを使用する場合
• "Windows 認証ブローカー" サインイン オプションを使用する場合の Visual Studio 2022 以降
• Windows アプリ バージョン 2.0.379.0 以降

既知の制限事項

• Office 永続クライアントはサポートされていません。
• 次のアプリケーションは、保護されたトークン フローを使用したサインインをサポートしていません。Exchange と SharePoint にアクセスすると、ユーザーはブロックされます。
  • SharePoint にアクセスする PowerShell モジュール
  • Excel 用の PowerQuery 拡張機能
  • Exchange または SharePoint にアクセスする、Visual Studio Code の拡張機能
• 次の Windows クライアント デバイスはサポートされていません。
  • Surface ハブ
  • Windows ベースの Microsoft Teams Rooms (MTR) システム
• ホーム テナントでトークン保護デバイスの登録要件を満たす外部ユーザーがサポートされています。 ただし、これらの要件を満たしていないユーザーには、根本原因を示す明確でないエラー メッセージが表示されます。
• 次の方法を使用して Microsoft Entra ID に登録されているデバイスはサポートされていません。
  • Microsoft Entra が Azure Virtual Desktop セッション ホストに参加しました。
  • 一括登録を使用して展開された Windows デバイス。
  • Windows 365 によってデプロイされたクラウド PCが Microsoft Entra に参加しています。
  • Microsoft Entra に参加している Power Automate でホストされているマシン グループ。
  • 自己展開モードを使用して展開された Windows Autopilot デバイス。
  • Microsoft Entra ID 認証が有効になっている仮想マシン (VM) 拡張機能を使用して Azure にデプロイされた Windows 仮想マシン。
• ユーザーが登録中に新しいサインインを実行しない場合、24H2 より前の Windows バージョンの 新しい Microsoft Entra 登録済みデバイスがブロックされる可能性があります。 ブロックされた場合、ユーザーはデバイスを再登録する必要があります。

前述のサポートされていない登録の種類が原因で影響を受けるデバイスを特定するには、サインイン ログで tokenProtectionStatusDetails 属性を調べます。 サポートされていないデバイス登録の種類のためにブロックされるトークン要求は、 signInSessionStatusCode 値 1003 で識別できます。

新しいオンボードの中断を防ぐために、前に説明した展開カテゴリに該当するすべてのデバイスを除外するデバイス フィルター条件を追加することで、トークン保護の条件付きアクセス ポリシーを変更できます。 たとえば、次を除外します。

• Microsoft Entra に参加しているクラウド PC では、 systemLabels -eq "CloudPC" and trustType -eq "AzureAD"を使用できます。
• Microsoft Entra に参加している Azure Virtual Desktops では、 systemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD"を使用できます。
• Microsoft Entra に参加している Power Automate でホストされているマシン グループは、 systemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD"使用できます。
• 自己展開モードを使用して展開された Windows Autopilot デバイスでは、enrollmentProfileName プロパティを使用できます。 たとえば、Autopilot 自己展開モード デバイスの登録プロファイルを Intune で "Autopilot 自己展開プロファイル" として作成した場合は、"enrollmentProfileName -eq "Autopilot 自己展開プロファイル" を使用できます。
• Microsoft Entra に参加している Azure の Windows 仮想マシンでは、 profileType -eq "SecureVM" and trustType -eq "AzureAD"を使用できます。

デプロイ

ユーザーにとって、登録済みデバイスと互換アプリケーションで互換性のあるクライアント プラットフォームを使用する場合、トークン保護を適用する条件付きアクセス ポリシーの展開は非表示にする必要があります。

アプリまたはデバイスの非互換性によるユーザーの作業の中断の可能性を最小限に抑えるために、次のことを強くお勧めします。

• ユーザーのパイロット グループから開始し、随時拡張します。
• トークン保護の適用に移行する前に 、レポート専用モード で条件付きアクセス ポリシーを作成します。
• 対話型と非対話型の両方のサインイン ログをキャプチャします。
• 通常のアプリケーションの用途をカバーするのに十分な期間にわたって、これらのログを分析します。
• 既知の適切なユーザーを適用ポリシーに追加します。

このプロセスは、トークン保護の適用についてユーザーのクライアントとアプリの互換性を評価するのに役立ちます。

条件付きアクセス ポリシーを作成する

特権アクセス セキュリティ レベルで説明されているような特殊なロールを実行するユーザーは、この機能のターゲットとして考えられます。 小さなサブセットでのパイロット運用から開始することをお勧めします。

次の手順は、Windows デバイス上の Exchange Online と SharePoint Online のトークン保護を要求する条件付きアクセス ポリシーを作成するのに役立ちます。

1. Microsoft Entra 管理センターに、少なくとも条件付きアクセス管理者としてサインインします。
2. Entra ID>Conditional Access>Policies に移動します。
3. [ 新しいポリシー] を選択します。
4. ポリシーに名前を付けます。 ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。
5. [ 割り当て] で、[ ユーザーまたはワークロード ID] を選択します。
   1. [ 含める] で、このポリシーをテストしているユーザーまたはグループを選択します。
   2. [除外] で、[ユーザーとグループ] を選択し、組織の緊急アクセスまたはブレイクグラスアカウントを選択します。
6. [ターゲット リソース] で>リソース (旧称クラウド アプリ)>含める>リソースを選択

   1. [ 選択] で、プレビューでサポートされている次のアプリケーションを選択します。

      1. Office 365 Exchange Online
      2. Office 365 SharePoint Online
      3. 環境内に Windows アプリを展開した場合は、次を含めます。
         1. Azure Virtual Desktop
         2. Windows 365
         3. Windows クラウド ログイン

      警告

      条件付きアクセス ポリシーは、これらのアプリケーションに対してのみ構成する必要があります。 Office 365 アプリケーション グループを選択すると、意図しないエラーが発生する可能性があります。 この変更は、条件付きアクセス ポリシーで Office 365 アプリケーション グループを選択する必要がある一般的な規則の例外です。

   2. 選択を選択します。

7. 条件:
   1. [デバイス プラットフォーム] の下:
      1. [ 構成] を [はい] に設定します。
      2. Include>デバイス プラットフォームを選択します>Windows。
      3. [ 完了] を選択します。
   2. [ クライアント アプリ] の下:

      1. [ 構成] を [はい] に設定します。

         警告

         クライアント アプリの条件を構成しないか、ブラウザーを選択したままにすると、MSAL.jsを使用するアプリケーション (Teams Web など) がブロックされる可能性があります。

      2. [先進認証クライアント] で、[ モバイル アプリとデスクトップ クライアント] のみを選択します。 その他の項目はオフのままにします。

      3. [ 完了] を選択します。

8. [ アクセス制御>Session] で、[ サインイン セッションにトークン保護が必要] を選択し、[選択] を 選択します。
9. 設定を確認し 、[ポリシーの有効化] を [レポートのみ] に設定します。
10. [ 作成] を選択して作成し、ポリシーを有効にします。

管理者は、 ポリシーの影響モードまたはレポート専用モードを使用してポリシー設定を評価した後、[ ポリシーの有効化] トグルを [レポートのみ] から [オン] に移動できます。

ログをキャプチャして分析する

ポリシーへの影響 (プレビュー)、サインイン ログ、Log Analytics などの機能を使用して、トークン保護の適用前後の条件付きアクセスの適用を監視します。

サインイン ログ

Microsoft Entra サインイン ログを使って、レポート専用モードまたは有効モードのトークン保護適用ポリシーの結果を検証します。

1. Microsoft Entra 管理センターに、少なくとも条件付きアクセス管理者としてサインインします。
2. Entra ID>に移動し、モニタリングとヘルス>のサインイン ログを参照します。
3. 特定の要求を選択して、ポリシーが適用されているかどうかを判別します。
4. 状態に応じて [ 条件付きアクセス ] または [ レポートのみ] ウィンドウに移動し、トークン保護を必要とするポリシーの名前を選択します。
5. [ セッション制御] で、 ポリシー要件が満たされているかどうかを確認します。
6. 要求のバインド状態の詳細を確認するには、ウィンドウの [基本情報 ] を選択し、[ トークン保護 ] - [サインイン セッション] フィールドを参照してください。 使用できる値:
   1. Bound: 要求はバインドされたプロトコルを使用していました。 一部のサインインには複数の要求が含まれる場合があり、トークン保護ポリシーを満たすためにすべての要求をバインドする必要があります。 個々の要求がバインドされていると思われる場合でも、他の要求がバインドされていない場合、ポリシーへの準拠は保証されません。 サインインのすべての要求を表示するには、特定のユーザーのすべての要求をフィルター処理するか、corelationid で検索します。
   2. Unbound: 要求がバインドされたプロトコルを使用していませんでした。 要求がバインド解除されている場合に考えられる statusCodes は次のとおりです。
      1. 1002: Microsoft Entra ID デバイスの状態がないため、要求はバインド解除されています。
      2. 1003: Microsoft Entra ID デバイスの状態がトークン保護の条件付きアクセス ポリシー要件を満たしていないため、要求はバインドされていません。 このエラーは、デバイスの登録の種類がサポートされていないか、デバイスが新しいサインイン資格情報を使用して登録されていないことが原因である可能性があります。
      3. 1005: 要求は、他の未指定の理由で解除されています。
      4. 1006: OS バージョンがサポートされていないため、要求はバインドされていません。
      5. 1008: クライアントが Windows アカウント マネージャー (WAM) などのプラットフォーム ブローカーと統合されていないため、要求はバインドされていません。

ログ解析

また、Log Analytics を使用して、トークン保護の強制エラーが原因でブロックされた要求に対してサインイン ログ (対話型および非対話型) のクエリを実行することもできます。

過去 7 日間の非対話型サインイン ログを検索する Log Analytics クエリのサンプルを次に示します。アプリケーションによるブロック要求と許可された要求が強調表示されています。 これらのクエリは単なるサンプルであり、変更される場合があります。

//Per Apps query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, Status,UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | 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 'SignInTokenProtection', 'Block','Allow')
| summarize by Id,UserPrincipalName, AppDisplayName, Result 
| summarize Requests = count(), Users = dcount(UserPrincipalName), Block = countif(Result == "Block"), Allow = countif(Result == "Allow"), BlockedUsers = dcountif(UserPrincipalName, Result == "Block") by AppDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by Requests desc 

前のクエリの結果は、次のスクリーンショットのようになります。

次のクエリ例では、過去 7 日間の非対話型サインイン ログを調べます。[ユーザーによるブロック済み要求と許可された要求] が強調表示されています。

//Per users query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | 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 'SignInTokenProtection', 'Block','Allow')
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName,Result  
| summarize Requests = count(),Block = countif(Result == "Block"), Allow = countif(Result == "Allow") by UserPrincipalName, AppDisplayName,ResourceDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by UserPrincipalName asc   

次のクエリ例では、過去 7 日間の非対話型サインイン ログを調べます。Microsoft Entra ID デバイスの状態がトークン保護 CA ポリシー要件を満たしていないデバイスを使用しているユーザーが強調表示されています。

AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| where TokenProtectionStatusDetails!= "" 
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails) 
| extend bindingStatus = tostring(parsedBindingDetails["signInSessionStatus"]) 
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"]) 
| where bindingStatusCode == 1003 
| summarize count() by UserPrincipalName 

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

デバイスを登録または参加したユーザーは、トークン保護要件が有効になっているときに、トークン保護がサポートされているアプリケーションのサインイン体験に違いはありません。

デバイスを登録または登録していないユーザー、またはトークン保護要件が有効になっているときにサポートされていないアプリケーションを使用している場合は、認証後に次のスクリーンショットが表示されます。

トークン保護要件が有効になっているときにサポートされているアプリケーションを使用していないユーザーには、認証後に次のスクリーンショットが表示されます。

関連コンテンツ

プライマリ更新トークンとは