小規模事業者の担当者2名が初動記録と小型ルーターを落ち着いて確認する場面

NOTES

Webサイトのインシデント対応手順|初動から復旧まで12項目

Webサイトの改ざん、乗っ取り、情報漏えい疑いが起きたときの対応を12項目で整理。最初の60分の指揮・隔離・証拠保全から、外部連携、報告判断、クリーン復旧、再開監視まで解説します。

チップス

Webサイトの改ざんや管理者アカウントの乗っ取りが疑われるとき、最初にするのは「すぐ元へ戻す」ことではありません。利用者への被害と侵害の拡大を止め、判断する人を決め、調査に必要な記録を失わないことが先です。焦って電源を落とす、ファイルを消す、バックアップを上書きすると、何が起きたか分からなくなる場合があります。

この記事では、Webサイトのセキュリティ事故を、検知記録から再開監視まで12項目で整理します。一般的な手順であり、実際の停止・隔離・証拠取得は、システム構成と被害状況を確認できる責任者や専門家の判断で行ってください。人命や犯罪被害など緊急性が高い場合は、所管機関へ速やかに連絡します。

最初の60分は「指揮・隔離・証拠」を優先する

IPAの中小企業向けインシデント対応の手引きは、検知・初動対応、報告・公表、復旧・再発防止の3段階で対応を整理しています。初動では、情報セキュリティ責任者から経営者へ報告し、責任者と担当者を定め、必要に応じてネットワーク遮断・隔離・サービス停止を行います。同時に、不用意な操作で記録を消さないことも重要です。

Webインシデント発覚後60分の検知・指揮・隔離・証拠・影響確認フロー
発覚後60分の初動目安
順序実施すること残す記録避けたい行動
1. 検知症状、URL、時刻、発見者を記録画面、通知、最初の連絡推測を事実として共有
2. 指揮責任者、技術、連絡、記録を割当判断者と連絡先全員が別々に指示
3. 安全・隔離利用者被害と拡大を止める止めた対象、時刻、理由影響を見ずに全停止
4. 証拠必要なログと状態を保全取得元、期間、担当先に削除・初期化
5. 影響機能、データ、期間を仮整理確定・未確定・次の確認早い段階で断定

時間は絶対的な締切ではありません。サイト訪問者へマルウェアやフィッシングの危険が及ぶ、個人データが外部から見える、攻撃が継続している、といった場合は安全確保を優先します。一方、証拠取得のために危険な公開を続ける判断も避けます。技術担当だけに任せず、責任者が事業影響と利用者保護を含めて決めます。

事故後の対応と事故前の脆弱性診断を分ける

インシデント対応は、すでに起きた、または起きた疑いがある事象を止め、調べ、復旧する活動です。脆弱性診断は、事故前または復旧後に、悪用され得る弱点を決めた範囲で確認する活動です。緊急対応中に診断の方式や料金比較から始めると、初動が遅れます。

事故の兆候がなく、診断対象・方式・成果物・再診断を比較したい場合は、脆弱性診断の発注と費用を整理する記事で準備してください。事故後は、まず16504の初動を進め、原因と再発防止の確認段階で必要な診断を選びます。

対応手順は12項目を一つの台帳で管理する

対応状況をチャットや口頭だけで管理すると、誰が何を止め、どの証拠を取得し、何を公表したか追えません。次の12項目を、時刻・担当・根拠・状態と一緒に記録します。項目ごとに「未確認」を許し、未確認を0件や問題なしへ置き換えないことが大切です。

Webサイトのインシデント対応を初動・調査連携・復旧再開に分けた12項目
Webインシデント対応の12項目
段階項目主な判断
初動1. 検知記録誰が、いつ、何を確認したか
初動2. 指揮と権限停止・支出・発信を誰が決めるか
初動3. 安全確保と隔離何を止め、代替手段をどうするか
初動4. 証拠保全どのログ・状態・作業履歴を残すか
調査・連携5. 影響範囲URL、機能、データ、期間、関係者
調査・連携6. 認証情報どの権限・鍵・連携を無効化、更新するか
調査・連携7. 外部連携保守、ホスト、法務、警察等へいつ連絡するか
調査・連携8. 法令・契約報告・通知・委託元連絡が必要か
調査・連携9. 社内外連絡何を、誰が、いつ伝えるか
復旧・再開10. 原因除去侵入経路、悪性物、不正アカウントを除けたか
復旧・再開11. クリーン復旧信頼できる構成とデータへ戻せるか
復旧・再開12. 再開・監視利用者安全、再侵入、業務、検索表示を確認したか

初動1〜4:記録を消さず、拡大を止める

検知した症状を短文で固定する

「ハッキングされた」だけでは、外部支援先が動けません。改ざんされたページ、見覚えのない管理者、勝手な転送、ブラウザ警告、フォームの異常送信、ホストからの停止通知など、観測した症状をそのまま残します。発見時刻、直前の更新、該当URL、端末、通知元を記録し、確定していない原因は書き分けます。

隔離と証拠保全は同時に判断する

公開停止、管理画面制限、該当アカウント凍結、感染端末のネットワーク隔離など、被害を止める方法は構成により異なります。警察庁はランサムウェア被害時の案内で、感染端末をネットワークから隔離し、ログ等が消える可能性があるため不用意に電源を落とさないよう案内しています。これは全事案で電源を維持するという意味ではなく、専門家と証拠・安全・業務影響を比較するための注意点です。

証拠は、公開ページの画面だけでは足りません。アクセス・認証・サーバ・WAF・メール・DNS・ホスティングのログ、変更ファイル、ユーザー一覧、作業履歴、システム構成、時刻情報が候補です。ただし必要もなくサイト全体のコピーを何度も作るのではなく、調査責任者が目的、対象、取得時刻、保管先、アクセス権を決めます。調査用証拠と復旧用バックアップも分けて管理します。

調査・連携5〜9:影響と連絡先を一本化する

影響範囲をURL・機能・データ・期間で分ける

Webサイト本体だけでなく、問い合わせフォーム、採用応募、決済、メール配信、DNS、解析、外部SaaS、同じホスティング上の別サイトを確認します。「漏えいした」と断定する前に、保存していたデータ、外部から到達できた範囲、実際のアクセス記録、対象期間、本人や取引先への影響を分けます。

管理者パスワードだけを変えて終わらせず、CMS、ホスト、DNS、メール、クラウド、API鍵、バックアップ保管先、Search Consoleなど、関連する権限を棚卸しします。認証情報を更新する順番は、攻撃者がまだ管理権限を持つ可能性と、正規担当者が締め出されるリスクを見て決めます。平時の権限・契約資料はリニューアル前の既存資産整理にもまとめています。

外部支援へ渡す初動票を1枚にする

外部支援へ最初に渡す情報
項目内容状態の書き方
症状改ざん、転送、警告、不正ログイン等観測事実と推測を分ける
時刻発見、最終正常、直前変更タイムゾーンも記録
対象URL、機能、サーバ、アカウント未確認範囲を残す
初動停止、隔離、権限変更実施者・時刻・理由
証拠ログ、状態、通知、構成取得元・期間・保管先
連絡社内責任者、委託先、法務窓口と承認者を一本化

制作会社、保守会社、ホスティング、フォーム提供者の誰が、ログ取得、隔離、復旧、顧客連絡を担当するかを確認します。保守契約があっても、専門調査や夜間対応が範囲外の場合があります。更新作業と緊急対応の境界はホームページ更新の費用と見積範囲で平時に整理しておくと、連絡が速くなります。

個人データと犯罪被害は報告要否を早く確認する

個人データの漏えい等が起きた、またはそのおそれがある場合、すべてが同じ報告対象になるわけではありません。個人情報保護委員会の漏えい等の対応案内では、報告対象事態について、速報は発覚日から概ね3〜5日以内、確報は原則30日以内、不正目的のおそれがある場合は60日以内とされています。該当性、本人通知、委託元との役割は、現行法令・契約と専門家の助言で判断します。

犯罪被害の通報・相談は、警察庁のサイバー事案に関する相談窓口から、都道府県警察を選べます。通報前に証拠を完璧にそろえることを優先して連絡が遅れないようにし、何を保全すべきかも相談します。業種別の監督官庁、サイバー保険、取引先への連絡条件がある場合は並行して確認します。

対外説明は確定・未確定・対応中を分ける

早い説明と正しい説明は両立させる必要があります。発信窓口と承認者を一つにし、発生日時、対象サービス、利用者への影響、現在の安全措置、利用者が取るべき行動、次回更新予定を、確認できた範囲で示します。原因や漏えい件数を調査前に断定しません。

インシデント時の情報区分
区分書く内容例
確定証拠で確認できた事実特定ページを停止した
未確定調査中で断定できない範囲個人データへのアクセス有無
対応中現在行っている安全措置ログ調査、認証情報の見直し
利用者対応相手に求める具体的行動不審メールを開かない
次回更新次に情報を出す日時・条件翌営業日正午に続報

復旧10〜12:原因を除き、信頼できる状態から戻す

見える改ざんを消しただけでは、侵入経路、不正アカウント、予約タスク、未知のファイル、脆弱な拡張機能が残る場合があります。WordPress.orgのハッキング時の公式FAQも、具体的な侵害兆候を整理し、何が起きたか、どこから侵入したかを調べ、復旧後に再侵入防止を行う考え方を示しています。自社で調査できない場合は、早い段階で専門支援を検討します。

復旧点は「新しいから安全」とは限りません。侵害前と確認できる構成・データを選び、CMS・拡張機能・サーバを更新し、不要な権限とファイルを除き、認証情報を再設定します。バックアップは世代数を増やすこと自体が目的ではなく、由来、取得時刻、完全性、侵害の混入有無、復元手順、業務データの差分を確認できることが必要です。

移管や管理者交代が原因で権限・復旧情報が分からない場合は、サイト移管と所有権・引継ぎの手順を確認します。復旧作業を変更管理、受入、公開判定へ落とす場合は、ホームページ制作の発注後7ステップの変更・受入記録を使えます。

再開判定はWeb表示だけで終わらせない

  1. 侵入経路と悪性物、不正アカウント、脆弱性へ対処した。
  2. 管理画面、ホスト、DNS、メール、外部連携の正規権限を確認した。
  3. 主要ページ、フォーム、決済、メール、採用応募を実操作で確認した。
  4. PC・スマホ、ログイン前後、Googlebotから見える内容に不審な差がない。
  5. ログと監視を強化し、再侵入の判定条件と担当を決めた。
  6. 個人データ、委託元、取引先、警察等への報告・通知判断を記録した。
  7. 利用者への説明と問い合わせ窓口を更新した。
  8. 復旧後の変更、未解決事項、次回確認を台帳へ残した。

検索結果やブラウザ警告が関係する場合は、Search Consoleのセキュリティの問題レポートで、ハッキングされたコンテンツ、マルウェア、ソーシャルエンジニアリング等を確認します。問題を十分に修正してから再審査を依頼し、警告が消えたことだけでなく、サイトと業務が正常に動くことも確認します。

手順書は薄く始め、訓練で更新する

最初から分厚いマニュアルを作るより、連絡先、停止権限、12項目の台帳、外部支援先、報告判断、再開条件を1つの実行票にします。IPAの中小企業の情報セキュリティ対策ガイドラインは、対象範囲・レベル・判定基準・エスカレーション、対応手順と体制、事業継続に沿う復旧準備を求めています。

年1回だけ連絡先を眺めるのではなく、改ざん、管理者乗っ取り、フォーム漏えい疑いなど一つの状況を選び、短い机上演習を行います。夜間に責任者へ連絡できるか、ホストへ依頼できるか、サイトを止めたとき代替受付が使えるか、誰が続報を承認するかを試し、結果を手順へ戻します。

まとめ

Webサイトのインシデント対応は、復旧作業だけではありません。検知記録、指揮、隔離、証拠、影響、認証情報、外部連携、法令・契約、連絡、原因除去、クリーン復旧、再開監視の12項目を同じ台帳で管理すると、技術・経営・利用者対応をつなげられます。

みやあじよでは、Webサイトの保守・運用、更新、権限整理、復旧手順、外部サービスとの責任分界を整理します。支援範囲はホームページ保守・運用サービスをご覧ください。事故が疑われる場合は、危険な操作を増やす前に状況を記録し、お問い合わせフォームからご相談ください。緊急性や法的判断が必要な場合は、警察、法務、セキュリティ専門家など適切な窓口へも並行して連絡してください。