VPN上の感染端末:封じ込めるのは経路ではなくセッション
分割トンネルは宛先が見るアドレスを変えるだけで、感染は変えない。封じ込め、証拠、復帰の順序は三つの条件で決まる。
エンドポイントの不正利用報告には、ノートPCを分割トンネルに載せて宛先に見えるアドレスを変えればよいという手軽な近道が、たいてい添えられている。それは観測を変えるだけで、感染を変えるものではない。端末はセッションがすでに握っている内部アクセスをそのまま保ち、マルウェアは誰も調べていないハードウェア上で動き続ける。作業の順序は、端末の資格情報がまだ何に届くのか、そのアクセスが今使われているのか、迅速な消去がどの証拠を壊すのかという三つの条件で決めるべきだ。
第一の条件:資格情報はまだ何に届くか
取り消された、あるいは無効化されたアカウントは答えの半分にすぎない。クライアントは証明書、キャッシュされたトークン、保存済みの事前共有鍵、パスワード変更後も残るマシン資格情報を保持していることがあるからだ。行動を選ぶ前にプロファイルが使うすべての認証要素を洗い出し、そのうえで製品が取り消し時にセッションを終了するのか、新しいものだけを拒否するのかを確認する。
ゲートウェイが対応しているなら、セッションを明示的に終了し、アカウンティング表またはセッション表で本当に消えたことを確認する。次回のログインにしか効かない変更では、現在のフローは動いたままになる。
第二の条件:そのアクセスは今使われているか
アラートの時間帯を、実際のセッション、割り当てられたトンネルアドレス、端末の識別情報と突き合わせる。共有された企業の出口はその背後にいる全員を表すため、観測された公開アドレスだけでは、どのエンドポイントがフローを生んだのかを特定できない。アラートが明白に見えるときこそ、人はこの突き合わせを飛ばす。
導入したサービスが実際に収集している記録、たとえばセッションを識別情報とアドレスに結びつけるアカウンティングの開始・停止イベントを使う。その記録が不完全なら、ファイアウォールの見え方で穴を埋めず、報告書にそう書く。証拠と推測を分けた報告書のほうが、そうでないものよりレビューに耐える。
第三の条件:対応を生き延びるべきものは何か
証拠の唯一のコピーを壊す封じ込めは、二度目のインシデントである。関連するログ、セッション記録、エンドポイントのアーティファクトを、保存とアクセスを所管するプロセスを通じて保全する。サポートチーム全員が読めるチケットにエクスポートを貼り付けてはならない。
次に、インシデントの責任者と、エンドポイントのどこまでを作り直すかを決める。検疫は範囲を確定する間の被害を抑えるが、対応者がまだ観察できるものも狭めるので、この二つの目的は意識的に天秤にかける必要がある。
封じ込めの実際の姿
効果的な封じ込めは、アクセス層でのネットワーク検疫、プロファイルが使うすべての認証要素の取り消し、セッションの明示的な終了、アカウントが持っていた内部権限の制限という層で成り立つ。どれか一つだけでは抜け道が残る。
| Condition | Act first | Defer |
|---|---|---|
| Credentials reach internal systems | Revoke and terminate the session | Endpoint rebuild |
| Access visibly in use | Quarantine, then scope the reach | Rotation of unrelated accounts |
| Evidence still on the device | Preserve artefacts, restrict read access | Reimage |
最初の一時間は、完全さよりも順序が重要だ。消去の前に取り消せばクライアントの反応を観察する機会が得られ、取り消しの前にセッションを終了すればゲートウェイがそれを尊重するかどうかが分かる。どの制御がどの効果を生んだかを記録する。
経路設計はサービスの判断であり、封じ込めの道具ではない
分割トンネルはオフィスの出口が運ぶものを減らし、全トンネルは選んだ検査経路により多くの通信を通す。どちらのモードもエンドポイントを証明せず、資格情報を取り消しもしない。
検査経路が検知と行動の能力を備えているなら、目の前のインシデントとは別のプロジェクトである全トンネルの設計には価値がある。インシデントの最中にモードを切り替えると、どのログがどの挙動のものか分からなくなるだけだ。モードは後から、サービスの所有者と監視チームを交えて決める。
復帰の条件
端末が戻る前に、検証すべき修復状態、露出したすべての資格情報の状況、報告を続けるべきエンドポイント制御、アカウントが偶然持っていた権限ではなく必要な最小権限という復帰条件を書き出す。必須と望ましいに分類する。元の権限セットは要件ではない。
きれいなスキャンは一つの入力にすぎず、ログインの成功は認証ワークフローが動いたことしか証明しない。承認された計画のもとで、セッションとリソース使用量を見ながら段階的にアクセスを戻す。残る制限の責任者を明記する。不正利用がオフィスの出口を通じてパートナーに届いたなら、相手が気づくのを待たず、契約が求める経路で伝える。