復旧を急ぐほど、最初の記録を残す — ランサムウェア対応の現場ノート

最初に守るのは、画面ではなく判断の余白

暗号化を示す拡張子、アクセスできない共有フォルダ、急に増える認証失敗。兆候は一つとは限らず、担当者が「本当に事故なのか」を確かめている間にも、別の端末へ影響が広がる。だからこそ、最初の判断は完璧な原因究明ではなく、被害を広げないための暫定線引きになる。

発見時刻、最初に見えた事象、確認できた端末、すでに止めた通信。これらを一枚の時系列に書く。短いメモでよいが、推測と確認済みの事実を分ける。復旧作業は後から参加する人が増えるほど、最初の前提を失いやすいからだ。

封じ込めと証拠保全を別々の仕事にしない

ネットワークから端末を切り離すことは、被害の拡大を防ぐために有効な場合がある。一方で、電源を落とす、ログを消す、共有アカウントのパスワードを一斉に変更する、といった操作は、原因調査に必要な手掛かりを失わせる可能性もある。

現場では「何を止めるか」と同時に「何を残すか」を決める。優先順位を次のように明文化しておくと、判断が分かれにくい。

1. 追加の書き込みや認証を止める。
2. 重要なログ、時刻情報、対象端末の状態を保全する。
3. 影響を受けていない経路を確認し、事業継続の代替手段を確保する。
4. 復旧した端末を再感染させない検証条件を決める。

すべてを同時に進められないときは、判断の責任者を一人置き、技術の作業と事業の判断を分けて記録する。

復旧計画は「戻せる」ではなく「戻す順番」

バックアップがあるかという問いは、復旧計画の入口にすぎない。最後に正常性を確認した時刻、復元できるデータの粒度、認証基盤が止まった場合の代替手段、復旧後に業務を再開する条件。ここまでを一つの手順にして、平時に小さく試す。

復旧順序は、サーバーの重要度だけで決まらない。依存関係の下流にある認証、名前解決、業務データ、監視を先に戻す必要があることもある。紙に書いた順序を、実際に手を動かして確認することで、見落としが見えてくる。

復旧の速度は、事故の最中に頑張る量ではなく、平時に決めておいた順番で決まる。

終了条件を宣言する

インシデントの終わりは、最後の端末が起動した時刻ではない。原因となる経路が塞がれ、認証情報が整理され、監視が通常の状態に戻り、関係者が同じ説明をできる状態だ。終了条件を先に置くと、復旧を急ぐ気持ちと、再発を防ぐ確認を両立できる。

事故後のレビューでは、誰が悪かったかではなく、どの情報がどの判断に届かなかったかを追う。記録を責める材料ではなく、次の余白をつくる材料にすること。それが、復旧を一度きりの成功で終わらせないための実務になる。