AI時代のホームページ保守、そのバックアップは安全ですか？

「バックアップ用のプラグインが入っているから大丈夫」と思っていませんか。では、そのバックアップが、ホームページと一緒に削除されたり、暗号化されたりしたらどうなるでしょうか。

保守契約に「バックアップ」と書かれていても、保存場所や保護の方法、復旧の手順までは分からないことがあります。確認したいのは、取っているかだけでなく、外から取られないか、一緒に失わないか、実際に戻せるかです。今回は、バックアップの備えから保守の範囲を考えてみます。

互換性の確認だけで、保守を終えていませんか

WordPressやプラグインを更新した後、表示崩れや動作不良がないかを確かめる。こうした互換性の確認は、ホームページの運用に必要な作業です。

ただ、契約の内容がそこまでなら、脆弱性、つまり攻撃に使われる弱点が見つかったときの対応や、攻撃を受けた後の復旧は誰が担うのでしょうか。制作会社に依頼している場合も、契約書や作業報告で対応範囲を確かめてください。

英国NCSC（国家サイバーセキュリティセンター）は2026年11月の報告で、AIが攻撃対象の調査や脆弱性の発見などを支援し、従来の攻撃手法を速く、効率的に進めると評価しています。［1］

セキュリティへの対応は、以前から保守に必要な仕事でした。攻撃にAIが使われる今、保守を互換性の確認だけで終わらせてよいのか。被害を防ぐ対策と、被害後に戻せる備えも含めて考えたいのです。

バックアップが、外部からアクセスできる場所にあった

実際に、弊社が確認したサイトでも、プラグインが作成したバックアップを外部から取得できる状態が見つかり、保存先やアクセス制限を見直して対処しました。

公開ディレクトリとは、Webサーバーがインターネットに向けてファイルを配信する領域です。その中に置かれたファイルでも、適切なアクセス制限があれば取得を防げます。今回の問題は、保存場所に加えて、実際に外部からアクセスできる状態だったことです。

バックアップには、取得対象によって、サイトのプログラムや設定、データベースなどが含まれます。公開するつもりのない情報まで、ひとまとめになっている可能性があります。Webの安全性に関するガイドを公開するOWASPも、Web上に残されたバックアップファイルから、認証情報やソースコードなどが漏れる危険を挙げています。［2］

復旧のために残したコピーが、情報を持ち出される入口になっていては困ります。「バックアップを取っているか」と同時に、そのデータが誰から見える状態なのかも確かめてください。

ファイル名が分からなければ大丈夫、ではありません

バックアップに長いファイル名やランダムな文字列が付いていても、それだけで安全とは判断できません。URLを知った人が認証なしで取得できるなら、ファイル名を知られたときに、バックアップを持ち出されるおそれがあります。

リンクを載せていないことや、フォルダ内の一覧を表示しないことも、個々のファイルへのアクセス制限とは異なります。一覧は見えなくても、ファイルのURLを直接開くと取得できる構成があります。［2］

確認すべきなのは、ファイル名を知られないかどうかだけではありません。名前やURLが分かっても、第三者による取得を拒否できるかです。バックアップの保存先は、そこまで確かめておきましょう。

同じサーバーにしかないバックアップは、一緒に失う可能性がある

外部からダウンロードできないようにしても、それで備えが完了するわけではありません。ホームページと同じサーバーにしかバックアップがなければ、サーバー障害で両方を失う可能性があります。

攻撃者にバックアップを変更・削除できる権限を奪われた場合も同じです。警察庁は、ランサムウェア（データを暗号化するなどして身代金を要求する不正プログラム）でバックアップまで暗号化された事例を挙げ、ネットワークから切り離して保存するなどの備えを勧めています。［3］

同じサーバー内のバックアップには、更新に失敗したときに戻せる利点があります。しかし、サーバー全体の消失や侵害に備えるなら、そこにしかないコピーを最後の復旧手段にはできません。

別のフォルダに移しただけでは、同じ障害や権限の影響を受けることがあります。サイトが使えなくなっても取り出せる場所に、復旧用のデータを残しておくことが必要です。

保存先だけでなく、削除できる権限も見直す

バックアップを別のサーバーやクラウドに保存するのは、一つの対策です。ただし、サイト側に保存された認証情報で、そのバックアップまで削除できるなら、侵入されたときの被害が保存先にも及ぶ可能性があります。保存先を分けるときは、アクセス権限も一緒に確認してください。警察庁も、公開サーバーが乗っ取られた場合に備え、アクセス可能な範囲を限定するよう案内しています。［3］

保存済みのコピーをサイト側の権限では削除できない構成にする。一定期間は書き換えや削除を防ぐ保存機能を使う。接続を切り離したコピーを残す。運用に合う方法を選び、少なくとも一つは、サイト側の被害に巻き込まれにくい形で保管します。警視庁も、バックアップの隔離や変更不能な保存、世代管理を案内しています。［4］

また、最新の一回分だけを残す運用では、改ざん後のデータで正常なコピーを上書きしてしまうおそれがあります。何日前まで戻す必要があるかを考え、複数の時点のバックアップを残すことも大切です。これは「世代管理」と呼ばれる方法で、JPCERT/CCも推奨しています。［5］

最後に、復元を試したのはいつですか？

管理画面に「バックアップ成功」と表示されていても、そのデータでサイトを元に戻せるかは、実際に復元するまで分かりません。

WordPressの復旧には、必要なファイルとデータベースの両方が欠かせません。データベースは、記事や設定などを保存する仕組みです。ファイルをコピーしただけでは、データベースまで保存できているとは限らないため、取得対象を確認します。［6］

公開中のサイトに影響しない検証環境で復元し、ページや画像の表示、管理画面、問い合わせフォームなど、必要な機能が動くかを確認しておきましょう。作業にかかった時間も記録すれば、停止したときの見通しを立てる材料になります。

攻撃を受けた後は、不正なプログラムや侵入に使われた弱点が残っていないかの確認も必要です。データを戻すだけで再公開せず、原因への対処まで誰が担当するかを決めておきます。［3］［5］

保守会社に確認したい五つのこと

いまの契約を見直すなら、次の点を聞いてみてください。「対応しています」という回答だけでなく、設定や確認結果も見せてもらうと、備えの範囲が分かります。

「バックアップは取っています」という説明を受けたら、保存場所と保護の設定、復元テストの結果まで確認してください。復旧作業が保守料金に含まれるか、別途依頼が必要かも確かめておきましょう。外部から取得できる状態なら、保存先やアクセス制限を修正し、取得できなくなったことまで確認してもらってください。

参考資料

1. ［1］英国NCSC「Annual Review 2026 — The impact of AI on cyber threat」（英語）。2026年11月3日公開。AIによる攻撃対象の調査・脆弱性発見の支援と、従来手法の高速化・効率化について。
2. ［2］OWASP WSTG「Review Old Backup and Unreferenced Files for Sensitive Information」（英語）。バックアップや未参照ファイルの公開による情報漏えいと、一覧非表示だけでは不十分なことについて。
3. ［3］警察庁「ランサムウェア被害防止対策」。バックアップの暗号化被害、権限の限定、復旧手順と侵入原因への対処について。
4. ［4］警視庁「安全なバックアップの取得方法と注意点」。2026年7月21日更新。バックアップの隔離、変更不能な保存、世代管理、復元テストについて。
5. ［5］JPCERT/CC「ランサムウエア対策特設サイト」。2026年6月18日更新。別ネットワークへの保管、世代管理、復元前の不正プログラムの駆除について。
6. ［6］WordPress公式「Backing Up Your WordPress Files」（英語）。2026年10月14日更新。ファイルとデータベースの両方を保存する必要性について。

情報確認日：2026年11月6日。

保存先や保護の設定が分からない、復元を任せられる人が決まっていない場合は、サイトURLと現在の契約内容を分かる範囲でまとめて、既存サイトの問題についてウェブモに相談することもできます。