継続的アクセス評価 (CAE) でゼロトラストを強化する

By Mirko Peters · 2026-08-11

ポッドキャストへようこそ。今回も、ID セキュリティ アーキテクチャを掘り下げていきます。Microsoft Entra ID で、新しく強固な条件付きアクセス ポリシーを展開したのに、侵害されたユーザーやポリシー外のデバイスが、その後also 8 時間も平然と作業を続けている――そんな経験がある方は少なくないはずです。ID 管理者は、この歯がゆい現実に毎日直面しています。Microsoft 365 の認証の仕組みにおける本当のポイントは、セキュリティ境界の強さはトークンの強さに等しい、ということです。ポリシーが自ら適用されるわけではありません。適用するのはトークンです。

Automatically translated with AI from the original post. Read the English original

ポッドキャストへようこそ。今回も、ID セキュリティ アーキテクチャを掘り下げていきます。Microsoft Entra ID で、新しく強固な条件付きアクセス ポリシーを展開したのに、侵害されたユーザーやポリシー外のデバイスが、その後も 8 時間ほど平然と作業を続けている――そんな経験がある方は少なくないはずです。ID 管理者は、この歯がゆい現実に毎日直面しています。Microsoft 365 の認証の仕組みにおける本当のポイントは、セキュリティ境界の強さはトークンの強さに等しい、ということです。ポリシーが自ら適用されるわけではありません。適用するのはトークンです。

この包括的なブログ記事では、先日のポッドキャストでの議論を掘り下げ、継続的アクセス評価 (CAE) がどのようにゲームを変えるのかを解説します。静的なトークンから離れ、リアルタイムでイベント駆動の失効に移行することで、組織の露出期間を大幅に短縮できます。トークンが内部でどのように流れるのか、その基本的な仕組みを押さえるには、関連エピソードの Modern Authentication and Token Lifecycle in Microsoft 365 もぜひお聴きください。

TL;DR (重要なポイント)

• ポリシーが自ら適用されるわけではなく、適用するのはトークンです。 条件付きアクセスは、トークンの発行時または更新時に評価されます。既存のトークンは、強制的に再評価させるまで、以前の信頼状態を保持し続けます。
• MSAL は リフレッシュ トークン を使って アクセス トークン を静かに入れ替えます。一方 CAE は、リスクやコンテキストが変化した際に、トークンを途中で無効化できます。
• 変更を「今すぐ確実に」反映させるには、トークンのライフサイクルを対象にする必要があります (サインイン頻度、リフレッシュ トークンの取り消し、CAE、セッション制御)。

平易な概念モデル

継続的アクセス評価がなぜこれほど大きな変化をもたらすのかを理解するには、まず最新の認証に関わる要素を見ておく必要があります。最新の認証アーキテクチャを、会員制クラブに例えてみましょう。

• アクセス トークン (AT): 短期間 (通常約 1 時間) 有効な来場者バッジです。特定の部屋への入室を許可します。
• リフレッシュ トークン (RT): 長期間 (数日から数週間) 有効なリストバンドです。毎回セキュリティ チェックを受けなくても、フロントデスクで新しい来場者バッジを発行してもらえます。
• MSAL: 裏側で、リフレッシュ トークンを新しいアクセス トークンに、完全に静かに交換する内部の担当者です。
• 条件付きアクセス (CA): AT/RT の発行時 (および CAE のイベント発生時) に、資格情報とコンテキストを厳密に確認する、門番となるポリシー エンジンです。
• CAE（Continuous Access Evaluation）：リスクが高まった場合、デバイスが非準拠になった場合、ユーザーの場所が不適切に変化した場合、またはユーザーアカウントが無効化された場合に、セッション中にAzure ADがアクセス権を能動的に取り消せるようにする、最新のプロトコルのアップグレードです。

新しいポリシーが今日適用されなかった理由

セキュリティ ポリシーの更新後に最もよくあるヘルプデスクの問い合わせの一つが、「特定の国をブロックしたはずなのに、ユーザー X が管理されていないネットワークからファイルをダウンロードし続けている！」というものです。なぜこうなるのでしょうか。その答えはトークンのキャッシュにあります。

• ユーザーは有効な AT をすでに保持しています。そのトークンが自然に期限切れになるまでは、再評価は行われません。
• 変更前に発行されたRTは、以下の時点まで引き続き問題なく機能します：
  • 通常の静かな更新の際に、RT が再度提示された場合、または
  • セッションとリフレッシュ トークンを明示的に 取り消した 場合、または
  • CAE が強制的な再確認をトリガーした場合です。
• Microsoft Teams、Outlook、OneDrive などのモバイル アプリやデスクトップ アプリは、トークンを積極的に キャッシュし、静かに更新 します。その結果、この「古いポリシー」の有効期間が知らず知らずのうちに延びてしまいます。

制御手段 (優先順位順)

1. 対応するリソース プロバイダー (Exchange Online、SharePoint Online、Microsoft Graph、Teams) で CAE を有効にします。
   • 効果: ポリシーやリスクの変更により、セッションの途中でも トークンを即座に無効化 できます。
2. サインイン頻度を設定します (アプリごとの CA の セッション 制御から構成します)。
   • 標準的な生産性アプリでは 8～12 時間、機密性の高い管理ポータルでは 1～4 時間。
3. コンテキストが変わったら再認証を要求する。
   • 適用する CA 条件: サインインのリスク ≥ 中、ユーザーのリスク ≥ 高、デバイスの準拠が必要、または ハイブリッド/AADJ のみ。
4. 管理されていないセッションやリスクのあるセッションには、Conditional Access App Control（Microsoft Defender for Cloud Apps のセッションプロキシ）を使用します。
   • レガシー トークンを段階的に廃止するまでの間、ダウンロード/印刷/同期なしのような厳格なポリシーを適用し、影響範囲を抑えます。
5. 展開中やセキュリティ インシデントの発生時には、必要に応じてトークンを取り消す。
   • 限定的なアプローチ: 影響を受ける特定のユーザーやグループの更新トークンを無効化する。
   • 広範なアプローチ: 緊急時の態勢調整として、サインアウトを強制し、テナント全体でトークンを取り消す。
6. 最新の認証セッション設定。
   • 多くの最新ワークロードでは非推奨となったレガシー トークンの有効期間ポリシーよりも、常に CA のセッションコントロールを優先してください。

すぐに使えるポリシー（最小限でも効果的なもの）

1. ユーザーのリスクが「高」の場合にブロック

• 割り当て: すべてのユーザー（緊急アクセス用アカウント 2 つを除く）+ すべてのクラウド アプリ
• 条件: ユーザーのリスク = 高
• アクセス制御: ブロック
• セッション: CAE を有効にする（テナントの設定）

1. サインインのリスクに基づくステップアップ

• 割り当て: すべてのユーザー。アプリ: Exchange、SharePoint、管理ポータル
• 条件: サインインのリスク ≥ 中
• アクセス制御: 多要素認証（MFA）の必須化、準拠デバイスの必須化（特に管理ポータル向け）

1. 管理者向けのサインインの頻度を短くする

• 割り当て: ディレクトリ ロール = 特権
• セッション: サインインの頻度 = 1～4 時間、永続的なブラウザー セッション = なし

1. 管理されていないデバイスを封じ込める

• 割り当て: すべてのユーザー。アプリ: SharePoint、OneDrive、Teams
• デバイス フィルター: 管理されていない
• セッション: Conditional Access App Control を使用する（ダウンロード/印刷をブロック）

運用プレイブック

プレイブック A — "新しい CA ルールを今すぐ定着させる"

• 対象範囲: "Sensitive-Apps-Users" という名前のグループ
• 手順:
  1. 対象アプリケーションのサインインの頻度を設定し、調整します。
  2. 対象のセキュリティ グループの更新トークンを無効化します。
  3. 本日、追加のプロンプトが表示される理由をユーザーに案内します。
  4. SignInLogs で新しい CA のチャレンジを監視し、ヘルプデスクのチケット数にも注意します。

プレイブック B — "リスクの急増や侵害の封じ込め"

• トリガー: 重大度の高い ID アラート（リスクのあるユーザー、ありえない移動、Defender for Identity による横方向の移動など）
• アクション（Azure Logic Apps で自動化）:
  1. ユーザーの侵害を確認（ユーザーのリスク = 高に設定）。
  2. 更新トークンを取り消す + サインイン セッションを取り消す。
  3. ユーザーを 72 時間、App Control ポリシーに切り替える。
  4. パスワードのリセットとデバイスの正常性チェックを必須にする。
  5. Teams のアダプティブ カードで SOC とユーザーのマネージャーに通知する。

管理者向けのコマンドとエンドポイント（コピー/貼り付け用）

• Microsoft Graph（推奨）:
  • セッションの取り消し（ユーザー）: POST /users/{id}/revokeSignInSessions
  • すべての更新トークンの無効化（ユーザー）: POST /users/{id}/invalidateAllRefreshTokens
  • 侵害されたリスクのあるユーザーの確認: POST /identityProtection/riskyUsers/{id}/confirmCompromised
  • 誤検知の解除: POST /identityProtection/riskyUsers/{id}/dismiss
• PowerShell（Entra / AzureAD）
  • （レガシー）: Revoke-AzureADUserAllRefreshToken -ObjectId <UserId>
  • MSGraph PowerShell: Invoke-MgGraphRequest -Method POST -Uri "/users/$id/revokeSignInSessions"

ヒント: 今後の自動化に備えて、常にMicrosoft Graphを優先してください。UPN のリストを受け取り、組み込みのバックオフ ロジックを使ってこれらの呼び出しをループする Runbook を作成しましょう。

調査と監視（KQL）

条件付きアクセスの変更後も古いトークンを使い続けていたのは誰か？

サイレントな RT の急増（スクリプトによるリフレッシュトークンの悪用の可能性）

重要な指標

• 適用までの時間（ポリシー変更 → 最初の CA チャレンジ）↓
• トークン失効までの遅延（操作 → ユーザーへの強制再認証）↓
• ブロックされたリスクの高いセッション（週単位）↑ かつ 誤検知 ↓
• ユーザー 1,000 人あたりのヘルプデスク認証チケット数は変更後も安定したまま
• リスクの急増と相関する CAE の無効化（セッション中のリアルタイムな反応を実証）
• 特権サインインの頻度遵守率（古いセッションが残らないことを確認）↑

30/60/90 日の実行計画

0～30 日目 – 基盤整備

• CAE を有効にし、サポート対象のアプリケーションを文書化します。
• ユーザー リスクのブロックとサインイン リスクに基づくステップアップ認証の CA ポリシーを実装します。
• 生産性向上アプリには サインイン頻度を 8～12 時間、管理ツールには 1～4 時間に設定します。
• 管理されていないエンドポイントに対して App Control をパイロット導入します。

31～60 日目 – トークンの管理強化

• セキュリティ グループ単位で リフレッシュトークンを一括無効化する Graph の Runbook を作成します。
• Playbook B を Microsoft Defender のアラートに直接接続します（リスクの高いユーザー → 自動的なトークン失効と封じ込め）。
• 永続的なセッションを減らし、従来のトークン有効期間ポリシーを無効にします。

61～90 日目 – ゼロトラストのチューニング

• CAE の適用範囲を拡大し、セッション中の追加認証プロンプトが意図どおりスムーズに動作することを確認します。
• PIM のガードレールを追加します（ユーザーまたはサインインのリスクが低～中以上の場合は昇格をブロック）。
• 上記の指標を使用して Identity Session Health ブックを構築します。
• パープルチーム演習を実施し、トークン失効の速度と CA の適用の仕組みを検証します。

よくある落とし穴（より安全なデフォルト設定）

• ポリシーだけに頼る → 常にトークンを管理します（CAE + 失効 + サインイン頻度）。
• テナント全体で単一のサインイン頻度 → 管理者向けのワークロードと一般のワーカー向けアプリでポリシーを分けます。
• 正午にテナント全体で失効 → グループとタイムゾーンごとに段階的に展開し、大規模な業務停止を避けます。
• モバイルのバックグラウンド更新を無視 → 追加のプロンプトが表示されることを想定し、モバイル ユーザーに変更を事前に周知します。
• 緊急アクセス アカウントの除外がない → 常に監視され、十分にテストされた2 つの緊急アクセス アカウントを維持します。

CAB 向けの一言要約（経営層向け）

ポリシーをトークンのライフサイクルに直接結び付けました。Continuous Access Evaluation と対象を絞った失効により、リスクやポリシーの変更が即座に有効になり、日常業務を止めることなく露出の時間を短縮できます。