目次
毎晩バックアップが成功している。それでも、サイトの管理権限を奪われたときに、同じ権限でバックアップまで消せるなら復旧の選択肢を失うおそれがあります。保存先が違うというだけで、本番から独立した備えになっているとは限りません。
情報確認日：2026年10月15日。本記事はAWS公式資料などをもとにした復旧設計の解説です。特定のWordPressサイトで新たな被害が発生したという報告ではありません。AI悪用による攻撃の有無を断定せず、侵害や誤操作の後でも戻せる構成を扱います。
スポンサーリンク
バックアップの成功と、復旧の成功を分ける
バックアップ処理の成功表示は、予定した保存が終わったことを示します。しかし、必要なデータがそろっているか、破損していないか、復旧先で動くかまでは別に確認する必要があります。復旧に使う資格情報が手元にない場合もあります。
本サイトでは、バックアップを取る目標に加え、どの時点まで戻れるか、どの程度の停止時間を許容するかを決める方法を提案します。一般に前者はRPO、後者はRTOとして整理されますが、用語を導入するだけでは足りません。記事サイトと受注サイトでは必要な条件が違います。
説明用に、毎日更新するブログなら一日前の記事へ戻せることが候補になります。一方、受注や会員情報が動くサイトでは、その間に発生した取引の扱いが必要です。すべてのサイトへ同じ頻度や保持日数を推奨するべきではありません。
WordPressで戻したいものを一覧にする
本文や設定の多くはデータベースにありますが、画像やテーマ、プラグインなどはファイル側にあります。DBだけの復旧では、画像や独自コードが不足する可能性があります。逆に、ファイルだけ戻しても投稿や設定が元に戻るとは限りません。
本サイトでは、DB、アップロード、テーマと独自プラグイン、環境設定、サーバー設定、外部サービスとの接続を分けて記録する方法を提案します。何をバックアップへ含め、何を安全な別経路から再作成するかを決めると、復旧時の迷いが減ります。
資格情報を含む設定ファイルには注意します。復旧に必要だからといって、公開ディレクトリーへ平文の複製を置かないようにします。バックアップには本番と同じ個人情報が含まれる場合があり、閲覧権限と保持期間も管理対象です。
スポンサーリンク
保存先を分けても、削除権限が同じなら境界が弱い
本番サーバーから別のストレージへコピーしていても、その接続用の資格情報で保存物をすべて削除できるなら、侵害時に同時に失うおそれがあります。物理的な場所だけでなく、誰が削除・変更できるかを確認します。
本サイトでは、日々の保存を担当する権限と、過去のバックアップを管理する権限を分けることを提案します。さらに、ホスティングの管理アカウント、バックアップサービス、復旧用の認証情報が、同じ共有パスワードへ依存していないかを点検します。
別アカウントや別サービスを採用する場合も、アクセスできる担当者と復旧手順を把握します。分離を強めた結果、必要な時に誰もログインできないのでは復旧できません。通常は広く配らず、緊急時に取り出せる管理方法が必要です。
Object Lockは、保存した版の削除や上書きを制限する
Amazon S3のObject Lockは、対象となるオブジェクトの版を保持期間などで保護する仕組みです。AWSの公式資料は、governanceとcomplianceの二つの保持モードを説明しています。単にフォルダー名に「保護」と付ける設定とは違います。 根拠資料：AWS：Locking objects with Object Lock。
Governanceでは、通常の利用者による変更や削除を制限しつつ、特別な権限による解除が可能です。Complianceでは、保持期間中の対象版の削除や保持期間の短縮に、より強い制約があります。導入時には、制約を理解しないまま本番で長期間の保持を確定しないでください。
本サイトでは、検証用の小さな保存物で、通常の書き込み、削除拒否、期限、復元方法を確かめることを提案します。Object Lockはサービス固有の機能であり、すべてのレンタルサーバーのバックアップへ同じ名前の設定があるわけではありません。
スポンサーリンク
消せないことと、読み出せることは別
AWSのObject Lockの考慮事項は、暗号鍵へのアクセス喪失までは防がないと説明しています。データが保持されていても、復号に必要な鍵が削除されたり、権限を失ったりすれば読めなくなる場合があります。 根拠資料：AWS：Object Lock considerations。
そのため、バックアップの保存物、復号に必要な鍵、復旧する利用者の権限を一組として点検します。鍵の管理者を分ける場合は、復旧時に必要な手続きを確認します。ロックが有効という画面表示だけを、復旧可能性の証明にしないでください。
また、S3では削除マーカーと保存された版の削除を区別する必要があります。通常の一覧で見えなくなっても、保護された版が残っている場合があります。運営担当者が古い版を特定し、取り出せることを手順として検証します。
感染や改ざんを、そのまま保管している可能性もある
バックアップは、取得時点の内容を保存します。その時点ですでに不正なコードや設定が入っていれば、それも保管される可能性があります。保存物が消えないことだけで、クリーンな状態へ戻れるとは限りません。
本サイトでは、異常の発生時刻を調べられるログと、複数の復旧候補を対応させる方法を提案します。侵害が疑われる場合は、既知の正常な配布元からコードを再構築し、必要なデータを選んで戻す方法も検討します。すべてを上書き復元して安全と判断しません。
JPCERT/CCの2026年10月の国内組織向け注意喚起も、環境設定やバックアップファイルの窃取、侵害後の横展開などの点検につながる内容を扱っています。ただし、同文書の全事案がランサムウェアやバックアップ削除だったと読むべきではありません。 根拠資料：JPCERT/CC：国内組織における不正アクセスの注意喚起。
復元テストは、メールや決済を止めた別環境で行う
本番のコピーをそのまま立ち上げると、通知メールの送信、定期処理、外部APIの実行などが動く場合があります。復元を試す環境では、外部への処理を止め、必要なら匿名化したデータを使います。テストで顧客へ重複通知を送らないことが重要です。
確認するのはトップページだけではありません。画像、記事のリンク、管理画面、フォーム、権限、検索、必要な設定を順に確認します。DBとファイルを別の時点から戻した場合に、不整合がないかも点検します。
実際にかかった時間と不足した手順を記録します。ダウンロードに想定以上の時間がかかる、古いPHPでは動かない、復旧先の容量が足りないといった課題は、取得成功のログからは見えません。目標の停止時間と、測った復旧時間を比較してください。
バックアップの閲覧は、通常のサイト閲覧より強い権限になり得る
DBの複製には、公開記事だけでなく、非公開の下書きや会員情報、プラグインの設定が含まれる場合があります。本サイトでは、バックアップを取り出せる人と、日常の編集者を別に評価することを提案します。記事を編集する権限があるからといって、DB全体を配布してよいとは限りません。
復旧作業を委託するときも、必要な期間と対象を限定し、作業後に一時コピーをどう処分するかを決めます。チャットやメールへそのまま添付するより、認可された転送経路と記録を使います。暗号化されたバックアップでも、鍵を同じ連絡へ添付すれば、閲覧の境界が期待どおり働かない場合があります。
スポンサーリンク
変更のたびに、復旧手順の前提を更新する
PHPの版、プラグイン、ドメイン、配信方式、データ量が変わると、以前の復旧手順がそのまま使えないことがあります。定期的な復元テストに加え、大きな構成変更の後にも、必要な版と設定を記録する方法を提案します。バックアップの取得処理を変えていなくても、戻す条件は変化します。
AIへ復旧手順の整理を頼む場合は、秘密の値と実際の個人情報を渡さず、構成とエラーを限定した資料を使います。生成されたコマンドは、対象を消す処理や本番への書き込みが含まれないかを確認し、隔離した環境で検証します。復旧の緊急性を理由に、未確認の提案を本番へ一括実行しないための準備が重要です。
レンタルサーバーでは、提供範囲を具体的に聞く
自動バックアップ付きという説明だけでは、保持期間、保存場所、削除権限、復旧の受付時間が分かりません。事業者へ、アカウント侵害時にバックアップへ影響するか、個別のDBやファイルを取り出せるかを確認します。
契約終了や利用停止、容量超過時の扱いも対象です。サイト本体の契約と同時に保管物が消える条件なら、必要な範囲で独立した保存を検討します。ただし、複製を増やすほど情報管理の対象も増えるため、保存する目的と期限を明確にします。
- 何を戻すか：DB、画像、コード、設定、外部接続を一覧にする。
- 誰が消せるか：本番用とバックアップ管理用の権限を分けて確認する。
- 何で読めるか：暗号鍵、認証、復旧環境を確保する。
- どこへ戻すか：隔離した環境で、正常性と副作用を検証する。
- いつまで残すか：業務上の必要性、費用、削除要件を両立させる。
AIを使った攻撃が関係するかにかかわらず、誤操作や侵害後の復旧には同じ境界が役立ちます。バックアップを取るだけで安心せず、消せる人、読める人、戻す手順をセットで確認しましょう。
スポンサーリンク
