ネットワークの「即死」を防ぐ：EDR連携による動的VLAN制御の深淵
ネットワークエンジニアにとって、金曜の夜に鳴り響く「端末がランサムウェアに感染した」というアラートほど心臓に悪いものはない。かつて我々は、慌ててデータセンターへ走り、該当するスイッチのポートを物理的に引き抜くか、管理画面で手動シャットダウンしていた。だが、ネットワークがSDN（Software Defined Networking）で抽象化された今、そんな泥臭い対応は過去の遺物だ。
今日は、EDRが「クロ」と判断した瞬間に、ネットワーク側で自動的に隔離VLANへ放り込む、インテリジェントな防御アーキテクチャについて語ろうと思う。
「封じ込め」の自動化：アーキテクチャの基本思想
この仕組みの心臓部は、EDRのAPIとネットワーク機器のAPI（あるいはコントローラー）を繋ぐ「オーケストレーション層」にある。
一般的なフローはこうだ：
1. 検知: EDRエージェントが不審なプロセスを検知し、Cloud/On-premiseの管理コンソールへ通知。
2. トリガー: 管理コンソールがWebhookやAPI経由で、予め用意されたスクリプト（Lambdaや自作のAPIサーバー）を起動。
3. 隔離: スクリプトがスイッチのAPIを叩き、該当端末のポートVLAN IDを「隔離用VLAN（Isolation VLAN）」へと書き換える。
ここで重要なのは、「いかにして論理的な切断を速やかに行うか」という点に尽きる。
通信フローとAPI設計のリアリティ
REST APIを用いた実装では、RFC 7231に準拠したステートレスな通信を意識する必要がある。特にスイッチの管理インターフェースを叩く際、認証エラーやタイムアウトでコケると隔離が不完全になる。
シーケンスの要点
- 認証:
Authorization: Bearer <token>を用いてセッションを維持。 - 冪等性: 隔離処理を複数回叩いても設定が壊れないよう、現在のVLAN IDを確認してから変更する
GET→PATCHのプロセスが定石だ。
実装例：Pythonによるスイッチ制御
例えば、一般的なエンタープライズ向けスイッチのAPIを想定した、ポートVLAN変更のスクリプト例を挙げる。
import requests
# スイッチの管理IPと隔離用VLAN ID
SWITCH_IP = "192.168.10.1"
ISOLATION_VLAN = 666
TARGET_PORT = "GigabitEthernet0/1"
def isolate_endpoint(port_id):
"""
EDRからの通知を受け取り、ポートのVLANを隔離用へ変更する
"""
url = f"https://{SWITCH_IP}/rest/v1/interfaces/{port_id}"
headers = {
"Content-Type": "application/json",
"Authorization": "Bearer YOUR_ACCESS_TOKEN"
}
# 実際には現在のVLANをGETで確認する工程を挟むのが安全
payload = {
"vlan": ISOLATION_VLAN,
"description": "Quarantined_by_EDR_AUTOMATION" # 後で追跡できるようメモを残す
}
response = requests.patch(url, json=payload, headers=headers)
if response.status_code == 200:
print(f"成功: {port_id} を隔離VLAN {ISOLATION_VLAN} に移動しました")
else:
# ここで例外処理や通知をしっかり書くのがプロの仕事
print(f"失敗: {response.status_code} - {response.text}")
# 実行
isolate_endpoint(TARGET_PORT)実務でハマる「落とし穴」
この仕組みを導入する際、現場で必ずと言っていいほど直面するトラブルが二つある。
1. 認証情報の期限切れ
Bearer トークンが数時間で無効になる設定の場合、APIコールが突如として 401 Unauthorized を返すようになる。スクリプト内にトークン更新（リフレッシュ）処理を組み込むか、APIキーの有効期限設定を慎重に行う必要がある。
2. MACアドレス学習のタイムラグ
VLANを切り替えた直後、スイッチのCAMテーブルが更新されず、古いVLANの情報を引きずることがある。
特に大規模なL2スイッチ環境では、設定変更後に clear mac address-table dynamic interface <port> を叩くコマンドをAPI経由で送るか、ARPキャッシュのフラッシュを考慮した設計にしないと、隔離したつもりが通信できてしまうという「悲劇」が起こりうる。
最後に：ネットワークを「生き物」として扱う
この動的セグメンテーションは、ゼロトラストの第一歩だ。しかし、自動化には常にリスクが伴う。誤検知によって重要なサーバーが隔離されれば、業務は一瞬で停止する。
だからこそ、設計段階で「隔離を解除する際の手順」まで自動化（または承認プロセス化）しておくことが重要だ。「いかに速く殺すか」だけでなく、「いかに速く復旧させるか」。この両輪が揃って初めて、真に信頼できるセキュリティ運用が完成する。
君たちがコードを書くとき、そのパケットがどのスイッチを通り、どのインターフェースに落ちるのか。その光景を頭の中でイメージしながら構築してほしい。現場の苦労を知るエンジニアなら、きっとできるはずだ。
コメント