ゲートキーパーからウォッチャーへ：認証前と認証後のセキュリティをつなぐ

By Mirko Peters · 2026-08-11

ポッドキャストと関連する技術解説へようこそお帰りなさい！ユーザーが正常にサインインした直後に ID セキュリティ戦略の死角を感じたことがあるなら、あなただけではありません…

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

ポッドキャストと関連する技術解説へようこそお帰りなさい！ユーザーが正常にサインインした直後に ID セキュリティ戦略の死角を感じたことがあるなら、あなただけではありません。長年、多くの組織は攻撃者を締め出すために認証前の制御に大きく依存してきました。玄関を、セキュリティの最後の砦とみなしてきたのです。しかし、攻撃者が有効なトークンや盗まれた資格情報を使ってその玄関をすり抜けたら、どうなるでしょうか。この問いこそ、最近のエピソード Conditional Access with Defender for Identity Signals の中心テーマでした。この投稿では、それらの考え方をさらに掘り下げ、認証前のゲートキーパーと認証後のウォッチャーを組み合わせて、真に回復力のある ID アーキテクチャを構築する方法を解説します。

中心となる考え方（TL;DR）

最新の ID 保護を正しく理解するには、各ツールをリアルタイムで連携する専門的な役割として捉える必要があります。

• Conditional Access (CA) は入口の用心棒です。誰がアクセスしようとしているか、どこからアクセスしているか、デバイスの状態はどうかに基づいて、認証前の判断を行うのに非常に優れています。
• Defender for Identity (DfI) は防犯カメラと館内の警備を組み合わせたものです。認証後の動作、横方向の移動、内部の異常の監視に優れています。
• 真の回復力は、認証後のリスクが認証前の制限を自動的かつ動的に強めるときにのみ実現します。しかも、それはセッションの最中に起こります。

メンタルモデル

環境内でこれらのコンポーネントがどのように相互作用するか、メンタルモデルを整理しましょう。

• ゲートキーパー (CA)：誰がサインインしているか、どこからか、デバイスの状態、サインイン時のリスクを評価し、即座にセッション制御を適用します。
• ウォッチャー (DfI + M365 Defender)：横方向の移動、通常と異なるリソースへのアクセスパターン、Kerberoasting、NTLM の悪用、想定外の権限昇格を探索します。
• フィードバック ループ：ウォッチャーが不審な動作を検出すると、ユーザー リスクまたはセッション リスクのスコアが上がります。これによりゲートキーパーは、MFA の要求を強化する、アクセスを完全にブロックする、またはアクティブなセッションを制限するなど、制御をただちに厳しくします。

統合のブループリント（有効化する順序）

これらのシステムを相互に連携させるには、体系的な展開が必要です。以下のブループリントに従ってください。

1. リスクを考慮した CA（基本構成）
   • Entra ID Protection で、ユーザー リスクとサインイン リスクの評価を有効にします。
   • CA ポリシーを作成します。
     • ユーザー リスクが「高」の場合はブロックします（ヘルプデスクの業務フローが対応していれば、パスワードの変更を要求することもできます）。
     • サインイン リスクが「中」以上の場合は MFA を要求します。
     • 中から高の機密性を持つアプリでは準拠デバイスを必須とします。管理されていないエンドポイントはデバイス フィルターを使って、制限付きのセッション制御に直接振り分けます。
2. ウォッチャーからゲートキーパーへ連携させる
   • DfI がMicrosoft 365 Defender および Sentinel（SIEM/SOAR として使用している場合）にアラートを継続的に送信していることを確認します。
   • 重大度の高い DfI アラートに対して、ユーザーに対する「侵害されたものとして確認」のアクションを自動化します。これにより Entra ID Protection でユーザーのリスク = 高が設定され、CA ポリシーが即座に反応するようになります。
   • 自動化の流れ：M365 Defender のインシデント → Logic Apps または Power Automate → Graph Security/Identity Protection API（/riskDetections、/riskyUsers:confirmCompromised）→ 任意でサインアウトの強制。
   • サポートされているすべてのアプリ（Exchange、SharePoint、Graph）で Continuous Access Evaluation (CAE) を有効にし、ポリシーの変更が既存のライブ トークンに実際に反映されるようにします。
3. 封じ込めのためのセッション制御
   • 管理されていないセッションや危険なセッションに対しては、CA から直接 Defender for Cloud Apps（セッション プロキシ）を展開します。
     • CA → Conditional Access App Control を使用（まず監視を行い、その後、ダウンロード、コピー＆ペースト、印刷、同期などのデータ流出をブロックします）。
   • これと合わせて、機密性の高いすべてのアプリケーションに対して、MDE のデバイスリスク → Intune のコンプライアンス、そして CA の「準拠しているデバイスを必須にする」を設定します。
4. 特権ID のガードレール
   • PIMではジャストインタイムアクセスを強制してください。特権の昇格を許可する前に、MFA + 準拠デバイスとリスクのあるユーザー状態でないことを必須にします。
   • ユーザーリスクが低以上の場合は特権ロールをブロックする条件付きアクセスポリシーを実装してください(リスクが低でもです)。管理ロールを引き受ける前に、すぐにトリアージを行わせるためです。

「もしこうなら、そうする」: DfIのシグナルを条件付きアクセスのアクションに対応付ける

Defender for Identityの特定の検出シグナルを、自動化された条件付きアクセスと対応アクションに対応付けることで、受動的な監視と能動的な防御の間のギャップを埋めることができます:

まずはこれらを監査/監視モードで1～2週間実行し、アラートの種類ごとに信頼度が高まった段階で、対応を強制モードへ切り替えてください。

サンプルポリシー(実用的で最小構成)

これらの戦略を本番環境で運用するために、設定すべき基本的な4つのポリシーを紹介します。

1. ユーザーリスクが高の場合はブロック
   • 割り当て: すべてのユーザー(緊急アクセス用アカウントを除く)、すべてのクラウドアプリ
   • 条件: ユーザーリスク = 高
   • アクセス制御: アクセスをブロック
2. サインインリスクに基づくステップアップ認証
   • 割り当て: すべてのユーザー、重要度の高いアプリ(管理ポータル、Exchange、SharePoint、Entra 管理センター)
   • 条件: サインインリスク ≥ 中
   • アクセス制御: MFAを必須にする + 準拠デバイス(または管理対象デバイス)を必須にする
3. 非管理対象デバイスのセッションを制限
   • 割り当て: すべてのユーザー、SharePoint/OneDrive/Teams
   • デバイスの状態: 準拠/ハイブリッド参加済みは除外、非管理対象は適用
   • セッション: 条件付きアクセス App Control を使用(ダウンロードをブロック)
4. 特権昇格のガード
   • 割り当て: ディレクトリ ロール = 特権管理者ロール
   • 条件: ユーザーリスク ≥ 低 または サインインリスク ≥ 中
   • アクセス制御: MFAを必須にする + 準拠デバイスを必須にする。リスクが高以上の場合はブロック

自動化プレイブック(すぐに設定可能)

自動化は、封じ込めまでの平均時間(MTTC)を短縮する秘訣です。今日からすぐに構築できる2つのプレイブックを紹介します。

プレイブックA: DfIの高重大度アラート → ID の封じ込め

• トリガー: IdentityThreatHigh のタグが付いたM365 Defenderのインシデント
• アクション:
  1. Graph API – ユーザーの侵害を確認(ユーザーリスクを高に設定)
  2. Entra ID – 更新トークンを直ちに取り消す
  3. Intune/MDE – デバイスを隔離(主要な単一デバイスが関連付けられている場合)
  4. ServiceNow/JSM – タイムラインと収集した成果物を含むインシデントチケットを作成
  5. Teamsのアダプティブ カードで SOC とユーザーの管理者に通知し、誤検知に備えてワンクリックで元に戻せるボタンを付ける

プレイブックB: SharePointへの異常なアクセスの急増

• トリガー: Defenderのアラート「通常と異なるファイルのダウンロード」
• アクション:
  1. Microsoft Entra拡張属性を使い、ユーザーに UnderInvestigation のタグを付ける
  2. ユーザーを、ダウンロードと印刷をブロックするApp Controlへ誘導する条件付きアクセス ポリシーに移行する
  3. 影響を受けたSharePointサイトに対してeDiscoveryの保留を開始する(任意。コンプライアンス要件に応じて)
  4. SOCが手動で延長しない限り、72時間後に封じ込めを自動的に期限切れにする

ハンティングと役立つクエリ

積極的なハンティングにより、攻撃者が悪用する前に脆弱性を発見できます。M365 Defenderの高度なハンティングで、次のクエリを使用してください:

ユーザーの30日間のベースラインと比べた、SharePointサイトへのアクセスの急増:

let lookback=30d;
let recent=1h;
let baseline = CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(recent))
    | where Application == "SharePoint" and ActionType == "FileAccessed"
    | summarize uniqSites=dcount(SiteUrl) by AccountUpn;
CloudAppEvents
| where Timestamp >= ago(recent)
| where Application == "SharePoint" and ActionType in ("FileDownloaded","FileAccessed")
| summarize curSites=dcount(SiteUrl), dls=sumif(1, ActionType=="FileDownloaded") by AccountUpn
| join kind=leftouter baseline on AccountUpn
| where curSites > 3 * coalesce(uniqSites,1) or dls > 500

後続のDfIアラートと密接に関連するサインインリスクの急増:

let riskySignIns = IdentityLogonEvents
| where RiskLevelDuringSignIn in ("medium","high")
| project AccountUpn, Timestamp, RiskLevelDuringSignIn;
let dfiAlerts = IdentityDirectoryEvents
| where EventType startswith "DefenderForIdentity"
| project AccountUpn, DfiTime=Timestamp, AlertType=EventType;
riskySignIns
| join kind=inner dfiAlerts on AccountUpn
| where DfiTime between (Timestamp .. Timestamp + 4h)

効果を証明する指標

経営陣に報告する際は、リスクが実際に減少したことを示す指標が必要です。次の主要業績評価指標（KPI）を追跡してください。

• アイデンティティインシデントの平均封じ込め時間（MTTC）（アラート生成から CA による適用までの時間）↓
• 攻撃者の滞留時間（最初の不審な操作から修復完了までの時間）↓
• ブロックされたリスクのあるセッション（ポリシーが発動したイベント）↑ と同時に 誤検知率 ↓
• リスクのあるユーザーの未処理期間（24 時間を超えて未解決のケース）↓
• トークン失効の遅延時間（秒単位で測定）↓
• リスクに起因する特権昇格の失敗（被害が発生する前に早期に検出されたもの）↑ のあと、時間の経過とともに正常化
• ID、デバイス、アプリにわたる Secure Score ↑ と同時に、ヘルプデスクへの問い合わせ件数が増えないこと

30/60/90 日の展開戦略

すべてを一晩で変更しようとしないでください。次の段階的なタイムラインを使用します。

0〜30 日（基盤づくり）

• Entra の ユーザーとサインインのリスク設定を有効にし、CA の基本ポリシーを監査モードで展開したうえで、適用モードに移行します。
• Defender for Identity を M365 Defender にオンボードし、アラートと主要なエンティティのマッピングを検証します。
• サポートされるアプリで Continuous Access Evaluation（CAE）を有効にし、MDE のデバイスリスクと Intune のコンプライアンスを統合します。

31〜60 日（フィードバックと封じ込め）

• Logic Apps で プレイブック A と B を構築し、ドライランの状態で十分にテストします。
• 2〜3 つの共同作業を行うビジネスチームを対象に、管理されていないセッションに対する App Control をパイロット導入します。
• PIM の昇格ガードレールポリシーを実装します。

61〜90 日（適用と測定）

• 信頼度の高いアラートについて、自動化されたプレイブックを完全な 適用（enforce）モードに切り替えます。
• 上記の指標を追跡するアイデンティティセキュリティのワークブックを（Sentinel または Power BI で）構築します。
• 四半期ごとにパープルチームの演習を実施し、実際の攻撃を想定したシナリオで、MTTC、トークン失効の速度、CA ポリシーの切り替えを検証します。

よくある落とし穴と、より安全な既定値

導入時に注意すべき典型的なミスは次のとおりです。

• 落とし穴: CA のサインインリスクだけに依存する → 対策: ユーザーリスクと認証後の DfI アラートにも対応します。
• 落とし穴: CAE を構成していないため、古いトークンが侵害されたセッションを維持し続ける → 対策: CAE を有効にし、トークンの失効を自動化されたプレイブックに直接組み込みます。
• 落とし穴: 組織全体でファイルのダウンロードを広範囲にブロックし、ユーザーの反発を招く → 対策: App Controlは、セッションが管理されていない、またはリスクがある場合にのみ選択的に適用します。
• 落とし穴: 積極的な自動侵害対応ワークフローにより、アラートが大量発生し誤検知が増える → 対策: 自動化の実行条件として複数シグナルによる検証を設けます（例: DfI の高重大度アラート + 通常より多いダウンロード量 + 業務時間外のアクセス）。
• 落とし穴: 自動化されたリスクポリシーによって緊急時用の「ブレークグラス」アカウントが誤ってロックアウトされる → 対策: 監視を厳重に行う2 つのブレークグラスアカウントを除外し、資格情報を四半期ごとにローテーションします。

これらの変更を組織全体に伝えるために、次の既製のスニペットを使用してください。

経営陣向けの CAB 用一文:

ログイン後のユーザーの挙動を、アクセス制御の判断に連携させることに成功しました。アカウントが普段と異なる動きを見せた場合は、セッションの途中でセキュリティ上の追加認証を求めるか、アクセスをブロックします。通常の日常業務を遅らせることなく、攻撃者が潜伏できる時間を大幅に短縮できます。

管理者向けの変更メモ:

• 新しい条件付きアクセスポリシーにより、通常と異なるリスクが検出された場合に、追加の MFA による認証の要求やアクセスのブロックが行われることがあります。テレメトリに基づいて、有効な認証トークンをセッションの途中で失効させることができるようになりました。ブレークグラスアカウントは引き続き明示的に除外されます。影響分析については、Identity Resilience のワークブックを確認してください。

オーナー向けの Teams 通知カード（自動送信）:

• 「お客様のアカウントから通常と異なるファイル操作が検出されました。一時的な保護措置（管理されていないデバイスでのダウンロードの無効化など）を適用しています。ご本人による操作である場合は、確認をクリックしてください。心当たりがない場合は、直ちに報告をクリックしてください。」