不正アクセス・情報漏えいが疑われるときの初動対応 ―― 最初の72時間の手順

最初の1時間は調査ではなく記録から始める

不正アクセスや情報漏えいを疑う連絡を受けたとき、最初にやるべきは原因調査ではない。時刻付きの記録を開始することだ。誰が、いつ、何を見て異常だと判断したかを、対象システムの外側(手元のPCのテキストファイルか紙)に書き始める。以降に実行したコマンド、開いた画面、電話した相手も同じ場所に追記していく。この記録が後の社内報告書と、監督官庁や外部機関への説明の土台になる。記憶で再構成した経緯は、細部が食い違って信用されない。

次に、対象機器を操作する人を一人に絞る。複数の担当者が同時にログインして確認を始めると、アクセスログが自分たちの操作で埋まり、攻撃者の痕跡と区別できなくなる。「確認のためにちょっと見ただけ」の操作が、最も価値の高い証拠を壊す。

この時点で原因や被害を確定させる必要はない。侵害の可能性がある事象として扱えば十分だ。未確定の内容を確定したように社内へ流すと、後で訂正するたびに情報システム部門の判断そのものが疑われる。

証拠保全:再起動と初期化が最も多い失敗

初動で取り返しがつかなくなる操作は、ほぼ決まっている。実務でくり返し起きているのは次のようなものだ。

• 再起動する。メモリ上にしか存在しない情報(実行中のプロセス、ネットワーク接続、復号された認証情報、ファイルレスマルウェアの本体)が消える。「とりあえず再起動したら直った」は、証拠を消して攻撃者を残した状態になりうる。
• OSを再インストールする、初期化する。復旧を急いだ結果、侵入経路が不明のまま同じ穴を残して再公開し、数日後に再侵入される。
• ウイルス対策ソフトで検体を駆除・削除する。何が置かれていたかを後から確認できなくなる。可能なら隔離(quarantine)にとどめ、検体を保持する。
• ログを整理する、容量を空ける。調査用のディスク領域を確保しようとしてログを消す事故が起きる。まずログローテーションと自動削除の設定を止める。
• 侵害されたアカウントで調査用のツールを入れる。攻撃者の権限で操作した記録が残り、後の切り分けを困難にする。

逆に、優先度の高い順に保全すべきものは、揮発しやすいものからになる。メモリの内容、現在のネットワーク接続とプロセス一覧、ARPテーブルなどが最も揮発性が高い。次にログ(認証ログ、Webサーバのアクセスログ、プロキシ・ファイアウォール・VPNのログ、クラウドの監査ログ)、最後にディスクの内容という順だ。クラウドサービスの監査ログには保持期間があり、既定のままだと数十日で消える。調査に入る前に、保持期間の延長かエクスポートを済ませておく。

ディスクを保全するときは、稼働中の環境をそのまま使わず、複製に対して調査する。仮想マシンならスナップショットとディスクイメージの取得が現実的だ。物理サーバで手段がなければ、無理に自力でイメージを取らず、電源を落とさないまま外部の専門事業者に引き継ぐ判断もある。あわせて、対象機器の時刻がNTPで同期されているかを確認し、ずれがあればその差分を記録に残す。複数機器のログを突き合わせるとき、時刻のずれは致命的になる。

隔離するか、動かしたまま監視するか

封じ込めは早いほどよいが、隔離の方法によって失うものが変わる。判断の軸は「被害が今も拡大しているか」だ。

ランサムウェアの暗号化が進行中、内部の他サーバへの横展開が観測できる、外部への大量のデータ送信が続いている ―― こうした進行中の被害があるなら、証拠より停止を優先する。ただし電源を抜く前に、まずネットワークからの切り離し(物理的なLANケーブルの抜線、スイッチポートの遮断、クラウドならセキュリティグループを全遮断に変更)を試す。ネットワークを切ればメモリ上の情報は保持されたまま拡散を止められる。電源断は最後の手段だ。

一方、侵入の痕跡はあるが現在進行形の動きが見えない場合は、遮断を急ぐと攻撃者に気づかれ、痕跡の消去やバックドアの切り替えを招く。この場合は通信の記録を強化しつつ、認証情報の無効化(侵害された可能性のあるアカウントのパスワードリセット、APIキー・アクセストークンの失効、VPN証明書の再発行)を先に進めるほうが被害を抑えられることが多い。

どちらの場合も、バックアップの保護は最優先で行う。バックアップサーバが同じ認証基盤に接続されていると、復旧手段ごと破壊されている例がある。バックアップの接続を切り、復元可能かを別環境で検証しておく。

影響範囲の特定:何が、いつから、どこまで

影響範囲の調査は、次の四つを埋める作業だと考えるとぶれない。

侵入時期は、検知した日ではなく最初の痕跡の日を探す。異常なログイン成功、公開サーバへの不審なリクエスト、初めて出現したファイルの作成日時などが起点になる。侵入経路は、外部公開資産(VPN機器、リモートデスクトップ、Webアプリ、公開ファイルサーバ)と、フィッシングによる認証情報窃取のどちらかであることが多い。到達範囲は、侵害された端末・アカウントから他にどこへログインできたかを、認証ログとネットワークログの両面から確認する。持ち出しの有無は、外向き通信の量と宛先、圧縮ファイルの作成痕跡、クラウドストレージへのアップロード記録から推定する。

ここで重要なのは、「漏えいした証拠がない」と「漏えいしていない」は別物という点だ。ログが残っていないために確認できないなら、それは「漏えいのおそれあり」として扱う。後述する報告義務は、確定した漏えいだけでなく「漏えいが発生したおそれがある事態」も対象にしている。

社内エスカレーションと記録の残し方

技術的な封じ込めと並行して、意思決定できる人に上げる。連絡先は事前に決めておくのが理想だが、決まっていない場合でも、経営層、法務・総務、広報、個人情報保護管理者、該当システムの業務所管部門には早い段階で共有する。「調査が終わってから報告する」は、後述の報告期限に間に合わなくなる典型的な失敗だ。

連絡には、侵害された可能性のある社内メールやチャットを避け、電話や別系統の連絡手段を使う。攻撃者が社内のやり取りを読んでいる前提で動く。

記録は、事実と推測を明確に分けて書く。「◯時◯分、ファイアウォールのログに外部IPアドレスへの大量通信を確認(事実)」「情報の持ち出しが行われた可能性がある(推測)」というように区別しておくと、後から報告書を作るときに書き直しが要らない。実施した対処についても、実行者・実行時刻・対象・結果をそろえて残す。

個人情報保護委員会への報告と本人への通知

個人データの漏えい等について、個人情報保護法は一定の事態を報告義務の対象としている。執筆時点の制度では、要配慮個人情報が含まれる場合、財産的被害が生じるおそれがある場合(クレジットカード番号など)、不正の目的による行為によるものである場合、そして対象者が1,000人を超える場合が、報告と本人通知の対象になる。不正アクセスは三つ目に該当するため、件数にかかわらず報告対象になる点に注意する。

期限は二段階だ。速報は事態を知った時点から速やかに行うものとされ、ガイドライン上はおおむね3〜5日以内が目安とされている。この時点では判明している範囲だけでよく、調査中の項目は調査中と書いて出す。確報は原則30日以内、不正の目的による行為が原因の場合は60日以内とされている。不正アクセス事案は後者にあたることが多い。

本人への通知は、本人が二次被害を防ぐ行動を取れるようにするためのものだ。したがって、全容解明を待つより、パスワード変更やカード利用明細の確認といった具体的な行動を示せる段階で出すほうが目的に合う。連絡先が不明で通知が困難な場合は、公表と問い合わせ窓口の設置といった代替措置が認められている。

他社から個人データの取扱いを委託されている立場であれば、委託元に通知することで自ら委員会へ報告する義務が免除される扱いがある。まず委託元への連絡を優先する。

個別の事案がどの類型にあたるか、どこまでを報告対象とするかは法的な判断を含む。ここでの説明は手順の見取り図であり、最終的な判断は法務部門や弁護士と、個人情報保護委員会の漏えい等報告に関する公式案内を確認したうえで行う。医療・金融・電気通信など業種別のガイドラインや、他法令に基づく別の届出義務が重なる場合もある。

外部機関に相談するタイミング

自組織だけで調査を完結できないと判断した時点が、相談のタイミングになる。判断材料は、ログが十分に残っているか、フォレンジックの手段があるか、事業継続の判断を支える技術的根拠を出せるかの三点だ。迷うなら早いほうがよい。相談が遅れるほど、消えるログが増える。

JPCERT/CCにはインシデント報告・相談の窓口があり、攻撃元への連絡調整や、同種事案の情報提供を受けられる。中小規模の組織や個人利用者向けにはIPAの情報セキュリティ安心相談窓口がある。不正アクセス禁止法違反や不正指令電磁的記録に関する罪など刑事事件としての対応を考えるなら、都道府県警察のサイバー犯罪相談窓口に連絡し、被害届の提出を検討する。証拠保全の方法について事前に警察と相談しておくと、後の手続きが進めやすい。デジタルフォレンジックを外部委託する場合は、契約前に、取得する対象(メモリ・ディスク・クラウドログ)と成果物の形式を確認しておく。

72時間の行動チェックリスト

迷ったときに戻る三つの基準

初動では判断材料が足りないまま決断を迫られる。そのとき戻る基準は三つある。第一に、消えるものを優先する。メモリとログは待ってくれないが、復旧作業は後からでもできる。第二に、確認できないことは「おそれあり」として扱う。楽観的な仮定で報告や通知を先送りすると、後で判明したときの損失のほうが大きい。第三に、復旧より原因特定を先に置く。経路が分からないまま復旧したシステムは、同じ経路で再び侵入される。

そして、この記事の手順を実際に使う場面が来る前に、確認しておくことが一つある。今、自組織のサーバとクラウドサービスで、認証ログとアクセスログが何日分残っているかだ。侵入から発覚まで数か月かかる事案は珍しくない。ログの保持期間が30日しかないなら、この記事の影響範囲特定は最初から成立しない。初動対応の成否は、事故が起きる前のログ設計で半分決まっている。