最初に記録すること
発見日時とタイムゾーン、URL、画面、警告、気付いた経緯を保存します。検知サービスの通知、ユーザー一覧、直前の更新履歴も退避します。ログは保存期間が短い場合があるため、サーバー会社へ早めに保全を依頼します。
被害拡大を抑える判断
不正な転送や情報取得が継続している場合は、公開停止やアクセス制限を検討します。停止画面だけを出しても、裏側の処理が動く構成では十分でない場合があります。利用者と業務への影響を確認し、サーバー・CDNの管理者と遮断範囲を決めます。
証拠保全と認証情報の保護
- DB、ファイル、ログ、設定のコピーを保全用として分離する。
- 操作した人、日時、対象、変更内容を記録する。
- 安全な端末から、関係する認証情報の失効・再発行を進める。
- サーバー、WordPress、メール、ドメイン、APIキーも調査対象にする。
- 信頼できない環境で新しい秘密情報を入力しないようにする。
パスワード変更だけで終わらせない
不正な管理者、残されたプログラム、定期実行、外部連携があれば、パスワードだけ変えても再侵入される可能性があります。接続元のログだけで個人を特定できるとは限らず、時系列で複数の情報を照合します。
復旧は正常な構成を再構築する
信頼できる配布元からの再配置や、侵害前と確認できるバックアップを検討します。原因となった脆弱性・権限・認証情報を対処し、復旧前に検証します。感染前か不明なコピーをそのまま戻すと、同じ状態を再公開するおそれがあります。
関係者への説明と再発監視
事実、推定、未確認を分けて報告します。情報漏えいの可能性がある場合は、扱う情報と契約・社内方針に応じて専門家と報告要否を確認します。公開再開後も変更検知やアクセスを監視し、原因と対策を記録してください。
時系列表を作る
「発見」「連絡」「証拠の取得」「公開制限」「認証失効」「調査」「復旧」「再開」の時刻、担当、対象、根拠を記録します。事実と推定を分け、初期に分からない点を無理に埋めません。後から情報が判明した場合は、元の記録を残して追記します。ファイルのコピーを保全する場合、通常の復旧用バックアップと混ぜず、保管者と取得方法を記録します。専門的な証拠保全が求められる案件では、その要件に合う担当者へ早めに依頼してください。通常のコピー取得だけで専門的な調査要件を満たすとは限りません。
公開再開の条件を決める
原因の対処、信頼できる構成、不要な権限と資格情報の整理、主要機能、監視、関係者への説明を確認します。原因をまだ特定できない場合は、残るリスクと追加調査を明示して判断します。「画面が戻った」だけを再開基準にしないことが重要です。
不正なファイルを見つけたら即削除しますか？
被害拡大の防止を優先しつつ、可能なら隔離・取得などで証拠を残します。ファイルだけを消しても入口が残る場合があるため、サーバーや専門担当と進めます。
復旧後に全パスワードを変えれば終わりですか？
残存処理、外部連携、ユーザー、サーバー・メール・ドメイン側の権限も確認します。安全な端末と環境から再発行し、不要なセッションやキーを失効させます。