ゼロトラストにおける継続的検証 - リスクベース認証と行動分析

ゼロトラストセキュリティの核心は「決して信頼せず、常に検証する」という原則ですが、従来の認証モデルでは「ログイン時に一度だけ検証し、その後はセッションが有効な限りアクセスを許可する」という静的なアプローチが一般的でした。しかし、このアプローチでは認証後に発生するリスクの変化に対応できません。ゼロトラストでは、セッション中も継続的にリスクを評価し、状況に応じて動的にアクセス制御を行う「継続的検証」が求められます。

本記事では、継続的検証について以下の内容を解説します。

• 継続的検証（Continuous Verification）の概念と必要性
• リスクベース認証（Risk-Based Authentication）の仕組み
• UEBA（User and Entity Behavior Analytics）による異常検知
• セッション中のリスク再評価と自動対応の実装
• Microsoft Entra ID ProtectionとMicrosoft Defender for Identityの活用

この記事を読むことで、一度の認証で終わらない継続的検証の仕組みを理解し、リスクベースの動的アクセス制御を設計できるようになります。

前提知識

本記事を理解するために、以下の知識があることを前提としています。

• ゼロトラストの基本原則を把握している
• 条件付きアクセスポリシーの基本を理解している
• 認証・認可の基本概念を知っている

ゼロトラストの基本原則についてはゼロトラストセキュリティ入門 - 基本原則と7つの柱を理解するを、条件付きアクセスについては条件付きアクセスポリシーの設計と実装を先に読むことをお勧めします。

期待される学習成果

本記事を読み終えると、以下のことができるようになります。

1. 継続的検証の必要性とゼロトラストにおける役割を説明できる
2. リスクベース認証の仕組みとリスクシグナルの種類を理解できる
3. UEBAによる行動分析と異常検知の原理を説明できる
4. セッション中のリスク再評価と自動対応の設計ができる
5. Microsoft Entra ID Protectionの基本的な構成を理解できる

継続的検証とは

継続的検証（Continuous Verification）とは、ユーザーやデバイスの信頼性を初回認証時だけでなく、セッション全体を通じて継続的に評価し、リスクレベルの変化に応じてアクセス制御を動的に調整する仕組みです。

従来の静的認証モデルの限界

従来の認証モデルでは、ユーザーが一度正常にログインすれば、セッションの有効期限が切れるまでそのアクセス権限が維持されます。

flowchart LR
    subgraph traditional["従来の静的認証モデル"]
        login["ログイン<br/>（一度だけ検証）"]
        session["セッション継続<br/>（検証なし）"]
        access["リソースアクセス<br/>（自由に許可）"]
    end
    
    login -->|"認証成功"| session
    session -->|"セッション有効"| access
    access -->|"セッション終了まで"| session

この静的なモデルには、以下の重大な問題があります。

継続的検証のアプローチ

継続的検証では、セッション中も定期的にリスクを評価し、状況の変化に応じてアクセス制御を調整します。

flowchart TB
    subgraph continuous["継続的検証モデル"]
        direction TB
        login["初回認証"]
        
        subgraph evaluation["継続的評価ループ"]
            collect["シグナル収集"]
            analyze["リスク分析"]
            decide["アクセス判断"]
        end
        
        actions["対応アクション"]
    end
    
    login --> collect
    collect --> analyze
    analyze --> decide
    decide -->|"リスク低"| collect
    decide -->|"リスク中"| actions
    decide -->|"リスク高"| actions
    actions -->|"再認証要求<br/>セッション終了<br/>権限制限"| collect

継続的検証の主要な要素は以下の通りです。

1. リアルタイムシグナル収集: ユーザー行動、デバイス状態、ネットワーク環境など
2. リスク分析エンジン: 収集したシグナルを分析しリスクスコアを算出
3. 動的ポリシー適用: リスクレベルに応じたアクセス制御の実行
4. 自動対応: 高リスク検知時の自動的な対処

リスクベース認証

リスクベース認証（Risk-Based Authentication: RBA）は、認証要求のコンテキストを分析し、リスクレベルに応じて認証要件を動的に調整する仕組みです。

リスクシグナルの種類

リスクベース認証では、様々なシグナルを組み合わせてリスクを評価します。

flowchart TB
    subgraph signals["リスクシグナルの分類"]
        direction TB
        
        subgraph user["ユーザーシグナル"]
            behavior["行動パターン"]
            history["認証履歴"]
            role["役割・権限"]
        end
        
        subgraph device["デバイスシグナル"]
            compliance["コンプライアンス状態"]
            health["デバイス正常性"]
            managed["管理状態"]
        end
        
        subgraph network["ネットワークシグナル"]
            location["地理的位置"]
            ip["IPアドレス評価"]
            connection["接続タイプ"]
        end
        
        subgraph context["コンテキストシグナル"]
            time["アクセス時刻"]
            app["対象アプリ"]
            data["データ機密度"]
        end
    end
    
    signals --> engine["リスク評価エンジン"]
    engine --> score["リスクスコア算出"]

主要なリスクシグナルの詳細は以下の通りです。

ユーザー関連シグナル

デバイス関連シグナル

ネットワーク関連シグナル

リスクレベルに応じた認証要件

リスク評価の結果に基づき、認証要件を動的に調整します。

flowchart LR
    subgraph risk["リスクレベル"]
        low["低リスク"]
        medium["中リスク"]
        high["高リスク"]
    end
    
    subgraph action["認証アクション"]
        allow["アクセス許可"]
        mfa["MFA要求"]
        restrict["制限付きアクセス"]
        block["ブロック"]
        reset["パスワードリセット強制"]
    end
    
    low -->|"既知デバイス<br/>通常の場所"| allow
    medium -->|"新しいデバイス<br/>珍しい場所"| mfa
    medium -->|"機密データ<br/>アクセス"| restrict
    high -->|"漏洩資格情報<br/>不審な行動"| block
    high -->|"確認後"| reset

典型的なリスクレベルと対応アクションの例を示します。

低リスク時の対応

• 条件: 登録済みデバイス、通常の場所、通常のアクセス時間
• アクション: パスワードのみでアクセス許可、またはシームレスSSO

中リスク時の対応

• 条件: 新しいデバイス、通常と異なる場所、機密リソースへのアクセス
• アクション: 追加のMFA要求、制限付きアクセス（読み取り専用など）

高リスク時の対応

• 条件: 漏洩した資格情報、あり得ない移動、マルウェア検出
• アクション: アクセスブロック、セッション無効化、パスワードリセット強制

UEBA（User and Entity Behavior Analytics）

UEBA（User and Entity Behavior Analytics）は、ユーザーおよびエンティティ（デバイス、アプリケーション、サービスアカウントなど）の行動を分析し、異常を検知するセキュリティ技術です。

UEBAの基本原理

UEBAは、機械学習とデータ分析を活用して、以下のプロセスでセキュリティ脅威を検知します。

flowchart TB
    subgraph ueba["UEBA分析プロセス"]
        direction TB
        
        subgraph collect["データ収集"]
            logs["ログデータ"]
            network["ネットワークトラフィック"]
            endpoint["エンドポイントデータ"]
            cloud["クラウドアクティビティ"]
        end
        
        subgraph baseline["ベースライン構築"]
            profile["ユーザー/エンティティ<br/>プロファイル作成"]
            pattern["行動パターン学習"]
            peer["ピアグループ分析"]
        end
        
        subgraph detect["異常検知"]
            compare["ベースラインとの比較"]
            score["リスクスコア算出"]
            alert["アラート生成"]
        end
    end
    
    collect --> baseline
    baseline --> detect
    detect -->|"継続的な学習"| baseline

ベースライン構築

UEBAは、各ユーザーやエンティティの「通常の行動」を学習してベースラインを構築します。ベースラインには以下の要素が含まれます。

• 時間的パターン: 通常のログイン時間、作業時間帯
• 地理的パターン: よくアクセスする場所、使用するIPレンジ
• アクセスパターン: 頻繁に利用するアプリケーション、リソース
• データ操作パターン: 通常のダウンロード量、ファイルアクセス頻度
• ピアグループとの比較: 同じ役割・部門のユーザーとの行動比較

UEBAで検知できる異常

UEBAは、以下のような異常行動を検知できます。

アカウント侵害の兆候

内部脅威の兆候

ラテラルムーブメントの兆候

リスクスコアリング

UEBAは、検知した異常を評価してリスクスコアを算出します。

flowchart TB
    subgraph scoring["リスクスコアリングの要素"]
        direction TB
        
        anomaly["異常の重大度"]
        frequency["発生頻度"]
        context["コンテキスト"]
        asset["対象資産の重要度"]
        history["過去のインシデント"]
    end
    
    scoring --> calculate["スコア計算"]
    
    calculate --> low["0-39: 低リスク<br/>監視継続"]
    calculate --> medium["40-69: 中リスク<br/>調査推奨"]
    calculate --> high["70-100: 高リスク<br/>即時対応"]

スコアリングの考慮要素は以下の通りです。

• 異常の重大度: 検知された異常がセキュリティにどの程度影響するか
• 発生頻度: 同様の異常が繰り返し発生しているか
• コンテキスト: 異常が発生した状況（時間、場所、関連イベント）
• 対象資産の重要度: アクセス対象のシステムやデータの機密性
• 過去の履歴: ユーザーやエンティティの過去のリスクイベント

セッション中のリスク再評価

継続的検証では、セッション確立後も定期的にリスクを再評価し、状況の変化に対応します。

トークン保護とセッション管理

モダンな認証システムでは、トークンを使用してセッションを管理します。継続的検証では、これらのトークンのライフサイクル管理が重要になります。

sequenceDiagram
    participant User as ユーザー
    participant App as アプリケーション
    participant IdP as IdP/PDP
    participant UEBA as UEBA/リスクエンジン
    
    User->>IdP: 1. 初回認証
    IdP->>UEBA: リスク評価要求
    UEBA-->>IdP: リスク: 低
    IdP-->>User: アクセストークン発行（有効期限: 1時間）
    
    User->>App: 2. リソースアクセス
    App->>IdP: トークン検証
    IdP-->>App: 有効
    App-->>User: アクセス許可
    
    Note over UEBA: 異常行動を検知
    
    User->>App: 3. リソースアクセス（30分後）
    App->>IdP: トークン検証
    IdP->>UEBA: リスク再評価
    UEBA-->>IdP: リスク: 高（異常検知）
    IdP-->>App: トークン無効化
    App-->>User: 再認証要求

Continuous Access Evaluation（CAE）

Microsoft Entra IDでは、Continuous Access Evaluation（CAE）という機能により、重要なイベント発生時にリアルタイムでセッションを再評価できます。

CAEで評価されるクリティカルイベント

CAEの有効化による効果

flowchart LR
    subgraph before["CAEなし"]
        direction TB
        b1["イベント発生"]
        b2["トークン有効期限まで待機<br/>（最大1時間）"]
        b3["アクセス継続"]
    end
    
    subgraph after["CAEあり"]
        direction TB
        a1["イベント発生"]
        a2["即時通知"]
        a3["リアルタイム対応"]
    end
    
    before --> problem["セキュリティギャップ"]
    after --> solution["リアルタイム保護"]

セッションライフタイム管理

継続的検証を効果的に実装するためには、適切なセッションライフタイム管理が必要です。

セッション管理のベストプラクティス

自動対応の実装

継続的検証で検知したリスクに対して、人手を介さず自動的に対応することで、脅威への対応時間を大幅に短縮できます。

リスクベースの自動対応フロー

flowchart TB
    subgraph detection["検知"]
        signal["リスクシグナル検知"]
        analyze["リスク分析"]
        score["リスクスコア算出"]
    end
    
    subgraph response["自動対応"]
        direction TB
        
        subgraph low["低リスク対応"]
            l1["追加ログ記録"]
            l2["監視強化"]
        end
        
        subgraph medium["中リスク対応"]
            m1["MFA要求"]
            m2["セッション制限"]
            m3["アラート生成"]
        end
        
        subgraph high["高リスク対応"]
            h1["セッション終了"]
            h2["アカウントロック"]
            h3["パスワードリセット強制"]
            h4["SOC通知"]
        end
    end
    
    signal --> analyze --> score
    score -->|"0-39"| low
    score -->|"40-69"| medium
    score -->|"70-100"| high

自動対応アクションの種類

認証関連のアクション

セッション関連のアクション

通知・エスカレーション

Microsoft Entra ID Protectionの活用

Microsoft Entra ID Protectionは、継続的検証を実現するためのMicrosoftのソリューションです。リスク検知、調査、修復のワークフローを自動化できます。

ID Protectionのアーキテクチャ

flowchart TB
    subgraph signals["シグナルソース"]
        entra["Microsoft Entra ID"]
        defender["Microsoft Defender"]
        external["外部脅威情報"]
    end
    
    subgraph idp["ID Protection"]
        detect["リスク検知エンジン"]
        
        subgraph risks["リスクの種類"]
            signin["サインインリスク"]
            user["ユーザーリスク"]
        end
        
        policy["リスクポリシー"]
    end
    
    subgraph response["対応"]
        ca["条件付きアクセス"]
        remediate["自動修復"]
        report["レポート・調査"]
    end
    
    signals --> detect
    detect --> risks
    risks --> policy
    policy --> response

リスク検知の種類

ID Protectionは、サインインリスクとユーザーリスクの2種類のリスクを検知します。

サインインリスク検知

サインインリスクは、特定のサインイン要求が正規のユーザーによるものではない可能性を示します。

ユーザーリスク検知

ユーザーリスクは、ユーザーのアカウント自体が侵害されている可能性を示します。

リスクポリシーの設定

ID Protectionでは、リスクレベルに応じた自動対応ポリシーを設定できます。

サインインリスクポリシーの設定例

1
2
3
4
5
6
7
8
9

# サインインリスクポリシー
ポリシー名: 中〜高リスクサインインにMFA要求
対象ユーザー: すべてのユーザー
除外: 緊急アクセスアカウント
サインインリスク: 中以上
制御: 
  - 多要素認証を要求
セッション:
  - サインイン頻度: 毎回

ユーザーリスクポリシーの設定例

1
2
3
4
5
6
7
8

# ユーザーリスクポリシー
ポリシー名: 高リスクユーザーにパスワードリセット強制
対象ユーザー: すべてのユーザー
除外: 緊急アクセスアカウント
ユーザーリスク: 高
制御:
  - 多要素認証を要求
  - パスワード変更を要求

条件付きアクセスとの統合

ID Protectionのリスクシグナルは、条件付きアクセスポリシーの条件として使用できます。これにより、より柔軟なリスクベースアクセス制御が可能になります。

flowchart LR
    subgraph conditions["条件付きアクセスの条件"]
        user["ユーザー/グループ"]
        app["クラウドアプリ"]
        device["デバイス状態"]
        location["場所"]
        signin["サインインリスク"]
        userrisk["ユーザーリスク"]
    end
    
    subgraph controls["アクセス制御"]
        grant["許可制御"]
        session["セッション制御"]
    end
    
    conditions --> evaluate["ポリシー評価"]
    evaluate --> controls

Microsoft Defender for Identityによる高度な検知

Microsoft Defender for Identityは、オンプレミスのActive Directory環境を監視し、高度な脅威を検知するソリューションです。クラウドとオンプレミスのハイブリッド環境における継続的検証に重要な役割を果たします。

Defender for Identityの検知カテゴリ

ハイブリッド環境での継続的検証

flowchart TB
    subgraph onprem["オンプレミス"]
        dc["ドメインコントローラー"]
        adfs["AD FS"]
        sensor["Defender for Identity<br/>センサー"]
    end
    
    subgraph cloud["クラウド"]
        entra["Microsoft Entra ID"]
        idp["ID Protection"]
        xdr["Microsoft Defender XDR"]
    end
    
    dc --> sensor
    adfs --> sensor
    sensor -->|"シグナル送信"| xdr
    entra --> idp
    idp --> xdr
    xdr -->|"統合ビュー"| soc["SOC/セキュリティチーム"]

継続的検証の設計ベストプラクティス

継続的検証を効果的に実装するためのベストプラクティスを紹介します。

段階的な導入アプローチ

flowchart LR
    subgraph phase1["フェーズ1: 可視化"]
        p1a["リスクシグナル収集開始"]
        p1b["ベースライン学習"]
        p1c["レポートモードで評価"]
    end
    
    subgraph phase2["フェーズ2: 検知強化"]
        p2a["リスクポリシー有効化"]
        p2b["アラート調整"]
        p2c["誤検知の削減"]
    end
    
    subgraph phase3["フェーズ3: 自動対応"]
        p3a["自動修復の有効化"]
        p3b["SOAR連携"]
        p3c["継続的改善"]
    end
    
    phase1 --> phase2 --> phase3

リスク許容度に応じた設定

組織のリスク許容度に応じて、継続的検証の厳格さを調整します。

モニタリングと継続的改善

継続的検証の効果を測定し、改善を続けることが重要です。

測定すべきKPI

まとめ

継続的検証は、ゼロトラストセキュリティを実現するための核心的な要素です。本記事で解説した重要なポイントを振り返ります。

1. 静的認証から継続的検証へ: 一度の認証で終わらず、セッション全体を通じてリスクを評価することで、認証後の脅威にも対応できます。

2. リスクベース認証: ユーザー、デバイス、ネットワーク、コンテキストの多様なシグナルを組み合わせてリスクを評価し、認証要件を動的に調整します。

3. UEBAによる行動分析: 機械学習を活用してベースラインを構築し、異常行動を検知することで、従来のルールベースでは検知できなかった脅威を発見できます。

4. 自動対応の重要性: 検知したリスクに自動的に対応することで、攻撃者に時間を与えず、被害を最小化できます。

5. Microsoft Entra ID ProtectionとDefender for Identity: Microsoftのソリューションを活用することで、クラウドとオンプレミスの両方で継続的検証を実現できます。

継続的検証は、「常に検証する」というゼロトラストの原則を具現化するものです。次の記事では、SIEM/SOARによるセキュリティ監視と自動対応について解説し、継続的検証で収集したログをどのように統合・分析し、組織全体のセキュリティ運用に活かすかを学びます。

参考リンク

• Microsoft Entra ID Protection の概要 | Microsoft Learn
• Microsoft Defender for Identity とは | Microsoft Learn
• Continuous Access Evaluation | Microsoft Learn
• NIST SP 800-207 Zero Trust Architecture
• Microsoft Zero Trust ドキュメント | Microsoft Learn