「境界」の先で眠る爆弾をどう裁くか？――NACによる動的隔離のリアル
ネットワークエンジニアとして現場を歩いていると、いつだって頭をよぎるのは「境界防御を突破された後の絶望」だ。どれほど強固なFWを配置しても、内側に入り込んだランサムウェアや、悪意ある挙動を示す端末は、社内LANという「信頼された領域」で静かに牙を研ぐ。
今日語るのは、教科書通りの「NAC（Network Access Control）」ではない。「検知即、隔離」を自動化し、感染端末を物理的に孤立させるネットワークの自律神経系の話だ。
なぜ「手動のLANケーブル抜き」ではダメなのか
深夜3時、SOCから「〇〇セグメントでC2サーバへの不審な通信を確認」というアラートが届いたとする。ここから人間がVPNを繋ぎ、スイッチにログインしてポートを閉じる……この数分間のタイムラグが、社内ネットワーク全体を暗号化の渦に巻き込む。
我々が目指すべきは、SIEMやEDRが「クロ」と判断した瞬間に、ネットワーク機器が自動的に対象のポートをVLAN隔離（検疫用VLANへの移動）させ、インターネットへの出口を断つ仕組みだ。
通信フロー：動的隔離の裏側
このアーキテクチャを実現するには、RADIUSサーバ（Cisco ISEやFreeRADIUSなど）とネットワーク機器、そしてインシデント管理システムをAPIで結ぶ必要がある。
1. 検知: EDRが端末の異常を検知し、Web API経由でセキュリティコントローラーへ通知。
2. 命令: セキュリティコントローラーがRADIUSサーバに対し、対象端末のMACアドレスを「隔離対象」としてマークし、再認証を促す（CoA: Change of Authorization）。
3. 隔離: RADIUSがスイッチへCoAパケットを送り、スイッチは対象ポートのVLANを「検疫用VLAN（隔離用VLAN）」へ動的に切り替える。
実践：Pythonで隔離命令をトリガーする
例えば、EDRからのWebhookを受け取ったバックエンドから、RADIUSサーバのAPIを叩いてCoAを発行する処理は、シンプルにこう書ける。
import requests
# RADIUSサーバの管理APIエンドポイント
NAC_API_URL = "https://radius-server.internal/api/v1/coa"
def quarantine_host(mac_address):
"""
対象のMACアドレスを持つ端末を隔離VLANへ追い出す関数
"""
payload = {
"mac": mac_address,
"action": "re-authenticate",
"vlan_id": 999 # 検疫用VLAN ID
}
headers = {"Authorization": "Bearer YOUR_API_TOKEN"}
try:
response = requests.post(NAC_API_URL, json=payload, headers=headers)
if response.status_code == 200:
print(f"成功: {mac_address} を検疫VLANへ移動しました。")
else:
print(f"失敗: ステータスコード {response.status_code}")
except Exception as e:
print(f"通信エラー発生: {e}")
# 実行例
quarantine_host("aa:bb:cc:dd:ee:ff")ネットワーク機器側の「受け皿」を作る
スイッチ側では、認証されたポートが突然「隔離」の指示を受けた際の動作を定義しておく必要がある。Cisco Catalyst系の環境であれば、radius-serverの設定と合わせて、VLANの動的割り当てを許可しておこう。
! スイッチ側の設定スニペット
interface GigabitEthernet1/0/1
description "社員用アクセスポート"
authentication port-control auto
dot1x pae authenticator
! RADIUSから渡されたVLAN IDを受け入れる設定
switchport mode access
switchport access vlan 10
! 隔離VLANへの遷移を許可する
authentication event fail action authorize vlan 999トラブルシューティングの勘所
現場でこの仕組みを構築すると、必ずといっていいほど「隔離されたはずなのに通信が止まらない」という事態に陥る。チェックすべきは以下の3点だ。
1. MACアドレスの学習保持: スイッチのshow mac address-tableを確認せよ。隔離後も古いVLANのテーブルに残っている場合、clear mac address-tableが必要になることもある。
2. CoAパケットの疎通: RADIUSサーバとスイッチ間のUDP 3799（CoAの標準ポート）がFWでブロックされていないか。ここが死んでいると、スイッチは命令を受け取れない。
3. クライアントのDHCPキャッシュ: 隔離VLANへ移動した際、IPアドレスが変わる。端末が古いIPを保持し続けていないか、ipconfig /releaseが発行されるか、あるいは隔離VLAN側でDHCPが適切に払い出されるかを確認すること。
最後に：守るべきは「ネットワークの知性」
NACによる隔離は強力だが、誤検知による「全社的業務停止」というリスクも孕んでいる。だからこそ、隔離を実行するAPIの前には、必ず「人の判断」や「複数のセキュリティエンジンの相関分析」を置くべきだ。
ネットワークは単なる土管ではない。異常を検知し、自ら身を引く「知性」を持たせること。それこそが、ゼロトラスト時代を生き抜くネットワークエンジニアの矜持である。
さあ、次は君のネットワークに、この「自律神経」を実装してみないか？
コメント