【実務・中級編】 ZTNA環境におけるEDR(Endpoint Detection and Response)データのリアルタイム連携 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

かつて、我々エンジニアの平穏を守っていた「境界防御」という名の城壁は、今や見る影もなく崩れ去りました。社内LANにいれば安全、VPNを潜り抜ければ信頼される——そんな牧歌的な時代は、高度化したランサムウェアや巧妙なサプライチェーン攻撃によって終わりを告げたのです。

現在、我々が構築すべきは「何も信頼しない」ことを前提としたゼロトラストネットワークアクセス（ZTNA）です。しかし、単に認証を強化するだけでは不十分です。真のゼロトラストの醍醐味、そして最も泥臭くもエキサイティングな領域は、「エンドポイントの健全性（EDRシグナル）を、いかにリアルタイムでネットワーク制御に叩き込むか」という一点に集約されます。

今日は、CrowdStrikeやMicrosoft DefenderといったEDRが吐き出す「悲鳴」をZTNAがいかに聞き取り、瞬時にアクセス権を剥奪するのか。その裏側にあるAPI設計と通信フローの真髄を、現場の視点から解説します。

—

1. 境界型防御の限界と「動的ポリシー」へのパラダイムシフト

従来のVPN環境では、一度トンネルが開通してしまえば、その中を通るパケットは（IDS/IPSで多少検閲されるとはいえ）基本的に「許可されたもの」として扱われてきました。もし、接続後のPCがマルウェアに感染し、C2サーバとの通信を始めたとしても、VPNゲートウェイはそれを止める術を持っていません。

ここで登場するのが、ZTNAのポリシー決定ポイント（PDP）とポリシー執行ポイント（PEP）です。
重要なのは、アクセスの可否を「ログイン時の一回きり」で判断しないこと。EDRが検知した「不穏な挙動」をトリガーに、リアルタイムで信頼スコアを書き換え、アクティブなセッションを強制遮断する。これこそが、現代のインフラエンジニアに求められる設計思想です。

2. アーキテクチャ：シグナルはどのように伝播するか

EDRとZTNAの連携は、主に「Shared Signals and Events (SSE)」や「Continuous Access Evaluation Profile (CAEP)」といった、RFCでも議論が進んでいる標準化技術の考え方に基づいています。

典型的な通信フローを整理してみましょう。

1. インシデント発生: ユーザーのPC上でEDR（CrowdStrike等）が不審なプロセスを検知。
2. シグナル送出: EDRのクラウドコンソールから、ZTNAのコントローラーへAPI（Webhook）経由で「このデバイスは危険だ（Risk Score: High）」という通知が飛ぶ。
3. ポリシー再評価: ZTNAコントローラーは、当該デバイスの現在のセッションを特定。
4. 即時遮断: ZTNAのゲートウェイ（PEP）に対し、該当トークンの無効化、または通信のドロップを命令する。

シーケンス図：EDR連携による動的アクセス制限

sequenceDiagram
    participant Endpoint as ユーザーPC (EDR Agent)
    participant EDR as EDR Cloud (CrowdStrike/Defender)
    participant ZTNA as ZTNA Controller (Policy Engine)
    participant GW as ZTNA Gateway (PEP)
    participant App as 社内重要資産

    Endpoint->>App: ZTNA経由で業務継続中
    Note over Endpoint: マルウェアが不審な挙動を開始
    Endpoint-->>EDR: 脅威検知シグナル送信
    EDR->>ZTNA: Webhook: Device Risk High (DeviceID: A-123)
    ZTNA->>ZTNA: ポリシー再評価 (Risk > Threshold = Deny)
    ZTNA->>GW: セッション強制切断・IPブロック命令
    GW--x App: 以降の通信を全て遮断
    Endpoint->>GW: アクセス拒否 (403 Forbidden / Connection Reset)

3. 実践：API連携のペイロードと設計

では、実際にEDRからどのようなデータが届き、それをどう処理すべきか。ここでは、汎用的なWebhookレシーバーのロジックを想定して解説します。

EDRから送出されるJSONペイロード（例）

多くのEDR製品は、以下のような構造のJSONをポストしてきます。ここで重要なのは device_id と assessment_score です。

{
  "event_type": "endpoint_risk_updated",
  "timestamp": "2023-10-27T10:15:00Z",
  "data": {
    "device_id": "WS-PRO-999888",
    "user_principal_name": "tanaka@example.com",
    "assessment_score": 85,
    "risk_level": "High",
    "threat_details": "Ransomware-like file activity detected"
  }
}

ZTNAコントローラー側の処理（Python例）

このシグナルを受け取り、ZTNAのAPIを叩いてセッションを殺すための擬似コードです。実際の現場では、APIのレートリミットやリトライ処理、ログの永続化が欠かせません。

import requests
import json

def handle_edr_webhook(request):
    """
    EDRからのリスク通知を受け取り、ZTNAのアクセス権を動的に剥奪する
    """
    payload = request.get_json()
    device_id = payload['data']['device_id']
    risk_level = payload['data']['risk_level']

    # リスクレベルがHighの場合、即座にアクションを実行
    if risk_level == "High":
        print(f"[ALERT] High risk detected for device: {device_id}. Revoking access...")
        
        # ZTNA管理APIの認証情報（実際は環境変数等から取得）
        ZTNA_API_ENDPOINT = "https://ztna-controller.internal/api/v1/sessions/revoke"
        HEADERS = {
            "Authorization": "Bearer YOUR_ADMIN_TOKEN",
            "Content-Type": "application/json"
        }
        
        # 対象デバイスに紐づくアクティブセッションを全て無効化するリクエスト
        data = {
            "filter": {
                "device_id": device_id
            },
            "reason": "Security posture degraded: EDR signal received"
        }
        
        response = requests.post(ZTNA_API_ENDPOINT, headers=HEADERS, data=json.dumps(data))
        
        if response.status_code == 200:
            print(f"[SUCCESS] Access revoked for {device_id}")
        else:
            print(f"[ERROR] Failed to revoke access: {response.text}")

    return "OK", 200

4. 現場で直面する「泥臭い」課題とTips

仕様書には書かれていない、私が現場で何度も痛い目を見たポイントを共有します。

① APIのタイムラグと「レースコンディション」

EDRが検知してからZTNAが遮断するまでには、数秒〜数十秒のタイムラグが生じます。この「魔の時間」に、攻撃者は横展開（ラテラルムーブメント）を完了させてしまうかもしれません。

  • 対策: ZTNA側で、特定の高リスクアプリ（DBサーバ等）への通信には、常に「再認証」や「追加のコンテキスト確認」を走らせる設定を併用してください。

② ポリシーの「フラッピング」問題

デバイスのスコアが境界線（例：スコア50で遮断）付近で変動すると、接続と遮断が繰り返される「フラッピング」が発生します。ユーザーは仕事にならず、ヘルプデスクの電話が鳴り止みません。

  • 対策: スコアの判定には「ヒステリシス（遊び）」を持たせるか、一度遮断したら管理者による手動復帰、あるいは一定時間の「冷却期間」を設ける設計にすべきです。

③ 証明書とデバイスIDの紐付け

APIで送られてくる device_id が、ZTNA側で認識している ID と一致しないことがよくあります。

  • 対策: 導入初期に、EDRの管理エージェントが持つ一意な識別子（UUID等）と、ZTNAクライアントが使用するデバイス証明書のシリアル番号をマッピングするデータベースを整備しておくことが、運用の成否を分けます。

5. 終わりに：パケットに「信頼」を乗せないために

ZTNAとEDRのリアルタイム連携は、決して「魔法」ではありません。それは、地道なAPIの繋ぎ込みと、徹底した例外処理、そして「何が起きたら止めるか」という明確なセキュリティポリシーの結晶です。

我々エンジニアの仕事は、単にネットワークを繋ぐことではなく、「正当な理由がない通信を一刻も早く止める」仕組みを、美しく、かつ堅牢に実装することにあります。

もし、あなたの環境でまだVPNが「繋ぎっぱなし」になっているなら、まずはEDRのAPIリファレンスを開くところから始めてみてください。パケットの挙動を追いかけ、システム同士を対話させる。その先にこそ、真のゼロトラストが待っています。

次回の記事では、この連携をさらに深化させ、SIEM（SplunkやSentinel）を介したより高度な相関分析と自動応答について深掘りします。それでは、また現場でお会いしましょう。

スポンサーリンク

コメント

タイトルとURLをコピーしました