WordPressハッキング復旧の判断基準｜復元・再構築の選び方と再公開チェック

WordPressのハッキング復旧で難しいのは、サイトを表示できるようにすることだけではありません。「どの方法で戻すか」「注文や問い合わせのデータを失わないか」「誰が、何を確認したら再公開できるか」を決める必要があります。見た目が元に戻っても、不正な処理や侵入の手掛かりが残っていれば、復旧したとは判断できません。

この記事は、改ざんや不正な操作が確認され、これから復旧方針を決める企業向けのガイドです。駆除作業そのものの確認範囲はWordPressのマルウェア駆除で整理しています。ここでは、部分修復・バックアップ復元・クリーン再構築の選び方と、事業を再開するための判断に重点を置きます。

不正な転送やメール送信、顧客情報への影響が疑われる状態では、復旧案を比較する前に、保守会社・サーバー会社と被害拡大を止める対応を進めてください。状況を自社だけで判断しにくい場合は、WordPressトラブル調査・復旧へご相談いただけます。

WordPressハッキング復旧の前に「戻す対象」を決める

まず、復旧が必要な対象を三つに分けます。WordPress本体・テーマ・プラグインなどの動かすプログラム、記事・画像・注文・会員情報などの残すべきデータ、ドメイン・メール・決済・外部連携などの事業をつなぐ設定です。一つのバックアップを戻せば、すべてが正しくそろうとは限りません。

事業側からは、止められない機能、停止中に使う連絡先、失うと困るデータ、再開を優先する機能を伝えます。技術側からは、確認できた侵害範囲、取得できたログの期間、復旧候補のバックアップ、動作を確認できる環境を整理します。この二つを並べることで、単に最短時間の案ではなく、事業上受け入れられる復旧案を検討できます。

異常を発見した時刻、最後に正常だったと確認できる時刻、バックアップを取得した時刻は分けて記録してください。最後まで普通に表示されていた、というだけでは、その時点で内部に不正な処理がなかった証明にはなりません。

また、作業前のファイル・データベース・ログは、調査用の原本として安全に保全します。侵害された可能性があるデータを公開場所へ置いたり、そのまま復旧用の正常データとして扱ったりしないでください。取得や保存の範囲は保守・サーバー会社と相談し、緊急の被害抑止を保全完了まで一律に待たせないようにします。

部分修復・バックアップ復元・クリーン再構築をどう選ぶか

選択は「費用が安い順」「早く表示できる順」だけでは決められません。技術担当者が、影響範囲の根拠と、その方法では確認できないことを示したうえで比較します。侵害が複数の場所へ及んでいれば、途中で方針を切り替えることもあります。

部分修復は「怪しいファイルだけ消す」ことではない

確認されたファイルを直せても、追加されたプログラム、データベース内の不正な設定、管理者権限、別のサイトやテスト環境への影響が残ることがあります。部分修復を選ぶ場合は、「何を根拠に修復範囲を限定したか」「それ以外をどう確認したか」を報告で示してもらいます。ファイル名やスキャン結果だけで安全性を断定しないことが重要です。

バックアップは「いつのものか」と「何が入っているか」を確認する

最新だから安全、発見日前だから正常、と判断しないでください。ログや変更履歴、正規ファイルとの比較など、利用できる材料で復元候補を検証します。正常時点を特定できない場合は、その限界を明示して別の復旧方法を検討します。復元後に侵入口が残れば、同じ問題を繰り返すおそれがあります。

ファイルとデータベースで取得時刻が違えば、互いの内容が合わず動作しない場合もあります。事前に隔離した検証環境で復元できるかを確かめ、構成とデータの整合を見ます。バックアップが使えることを試験で確かめる考え方は、カナダ政府のバックアップの案内でも示されています。

クリーン再構築でも、移行データの検証は必要

新しい環境へWordPressを入れるだけでは、復旧は完了しません。正規配布元のWordPress・テーマ・プラグインを基本に構成し、独自機能は出所と内容を確認します。旧環境から移す投稿、画像、設定、ユーザー、受注情報にも確認が必要です。データベースやアップロード領域を無検証で丸ごと持ち込めば、不正な状態を引き継ぐ可能性があります。

PHPやデータベースを含む動作基盤が継続的に更新できるか、ライセンスや外部接続を再設定できるかも確認します。再構築は安全性を立て直すための選択肢ですが、「新しいサーバーだから絶対安全」という保証ではありません。

復元で失うデータと、再開時に二重処理するデータを分ける

企業サイトでは、侵害の除去と同じくらい、業務データの扱いが重要です。バックアップ後に増えた記事、問い合わせ、会員、注文、決済状態を一覧にし、どこに正しい記録が残っているかを確認します。失ったデータを戻せるかだけでなく、復元により処理済みのものを再度処理してしまわないかも見ます。

たとえば、午前2時のバックアップを使い、午前10時にECサイトを停止したケースを考えます。この間の注文は、サイトのデータ、決済事業者の取引記録、受注メール、出荷管理で状態が異なる場合があります。決済記録にある金額だけを見て注文を新規作成すると、在庫や通知が二重に動く可能性があるため、注文番号と取引番号を照合して復元方針を決めます。これは説明用の一般的な例であり、実際の案件を示すものではありません。

• 記事・画像：正常な原稿や制作データから戻せるものと、確認が必要なものを分ける。
• 問い合わせ：保存されたフォームデータ、受信メール、対応記録を照合し、未対応分を確認する。
• 注文・決済・在庫：注文番号、決済状態、返金、発送、在庫変動を対応付ける。
• 会員・権限：正規の登録者と管理者を確認し、不明な権限を持ち込まない。
• 通知・自動処理：テストやデータ取込で顧客へメールを再送しないよう、送信先と実行条件を確認する。

差分の取り込みは、その方法と対象を記録し、必要なデータだけを検証したうえで行います。顧客情報の入ったファイルを個人用ツールやAIへ安易にアップロードしないでください。回収できないデータがある場合は、隠さず件数・期間・業務への影響を整理し、利用者への対応を決めます。

再公開は、確認結果を見て段階的に判断する

「スキャンで検出されなくなった」「トップページが表示された」は確認項目の一部です。再公開前には、技術担当者と事業責任者が、少なくとも次の内容を共有できる状態にします。

1. 侵害への対応範囲：確認した不正な変更、対応した場所、調査対象外や記録不足の範囲が分かる。
2. 認証と侵入口：疑いのあるアカウント・接続・秘密情報の見直しを行い、必要な更新や代替策を確認している。
3. データの整合：復元時点と差分の扱いが明確で、注文・問い合わせ・会員などの欠落や二重処理を確認している。
4. 事業機能：管理画面、問い合わせの実受信と自動返信、会員ログイン、決済・通知などを適切なテスト環境・方法で確認している。
5. 公開側と計測：主要ページ、検索流入先、転送設定、計測タグ、警告の状態を確認し、未解決項目の扱いを決めている。
6. 再開後の体制：監視対象、連絡先、再停止の条件、戻し先、承認者が決まっている。

安全性に関わる重要項目が未確認なら、通常公開のまま様子を見るのではなく、公開範囲を限定する、該当機能を止める、検証を続けるなどの対応を選びます。企業情報の静的な案内と連絡先を先に用意し、確認済みの機能から段階的に再開する方法もあります。ただし、案内ページも侵害が残る環境へ安易に置かず、提供方法を技術担当者と決めます。

侵入経路を特定できなかった場合は、その事実を報告に残します。だから何もできないわけではありませんが、再構築や権限の見直しで何を改善し、どの不確実性が残るかを説明し、安全に関わる未確認事項を放置したまま再公開を承認しないことが重要です。警告表示の解除や検索結果への反映は、復旧作業が終わった時刻と一致しないこともあるため、対応状況を別に追います。

誰に、どこまで説明するかを決める

技術的な調査と並行して、社内、顧客、取引先への説明担当を決めます。伝える内容は、把握した事実、未確認の影響、実施中の対応、利用者に必要な行動、問い合わせ先、次の報告予定に分けます。原因が不明なのに特定の担当者や製品の責任と決めつけたり、調査が終わっていないのに「情報漏えいはありません」と断定したりしないでください。

個人情報への影響が疑われる場合は、技術調査がすべて完了するまで報告・通知の検討を先送りにしないことも大切です。個人情報保護委員会への報告や本人通知が必要になる場合があるため、同委員会の漏えい等への対応案内を確認し、情報の種類と状況に応じて法務・専門家と速やかに判断します。

公開する説明には、復旧に関係するパスワード、内部の保存先、悪用に直結する未対処の詳細、個人情報を含めません。説明を控えることと、必要な情報提供をしないことは別です。対外説明と、契約上必要な個別報告・専門家向けの技術資料を分けて管理します。

復旧完了報告を、次の担当者が使える引き継ぎ資料にする

作業報告には「駆除しました」だけでなく、発見から再開までの時系列、採用した復旧方法と理由、戻したデータの時点、差分の処理、変更した構成、テスト結果、未解決事項、再開の承認を残します。認証情報そのものは記載せず、安全な保管場所と管理責任者が分かるようにします。

再発防止では、使っていないプラグイン・テーマやテスト環境も含めて必要性を確認し、不要な権限を整理します。実際の削除や変更は、調査と保全、依存関係の確認を経て進めます。急ぐべき脆弱性対応と、互換性の検証が必要な大型更新を区別し、月次の報告日を待たずに対応できる体制が必要です。

バックアップも、取得の成否だけでなく、保存先・世代・復元試験・事業データをどの時点まで戻せるかを見直します。再開後は、不審なログイン、権限やファイルの変更、フォーム・注文・メールの異常など、確認対象と頻度を決めて追跡します。更新履歴や検知した事象を月次レポートで共有すれば、復旧時の判断を日々の運用へ引き継げます。

現在ハッキング被害や不正な変更への対応が必要な場合は、WordPressトラブル調査・復旧へご相談ください。最初の問い合わせでは症状と影響する機能を伝え、ログや認証情報の受け渡しは、安全な方法を確認してから行います。

復旧後の管理体制を整えたい場合は、WordPress保守（Web／EC）で、権限、バックアップ、更新、監査、引き継ぎを継続的に確認する運用をご相談いただけます。+STOCKは、リアルタイムの自動更新と日々の人的監査を組み合わせ、表示を戻して終わらせず、会社の信用を支えるWeb資産を長く使える状態へ整えていきます。