Webサイト運用

「バックアップは取っている」だけでは戻せない|ランサムウェア時代のWebサイト・業務データの守り方

「うちはレンタルサーバーの自動バックアップがあるから大丈夫」「社内のNASに毎日コピーしているので心配していない」。Webサイトや業務データのバックアップについて尋ねると、こうした答えが返ってくることがよくあります。バックアップを取っていること自体は、とても大切な備えです。ただ、ランサムウェアが企業活動を長く止める事案が続く今、確認しておきたいのは「取っているかどうか」だけではありません。「いざというときに、本当に戻せるかどうか」です。

警察庁が2026年に公表した「令和7年におけるサイバー空間をめぐる脅威の情勢等について」によると、令和7年(2025年)のランサムウェアの被害報告件数は226件でした。規模別では、226件のうち143件を中小企業が占めています。同じ資料の統計データには、被害に遭った企業・団体へのアンケート結果も載っています。バックアップの取得状況に回答した116件のうち、105件はバックアップを取得していました。ところが、復元の結果に回答した99件のうち、バックアップから復元できたのは20件にとどまっています。

つまり、被害に遭った組織の多くは「バックアップを取っていなかった」わけではありません。取っていたのに、戻せなかったのです。復元できなかった理由として最も多かったのは、「バックアップも暗号化された」というものでした。バックアップが、攻撃者の手の届く場所に置かれていたということです。

これは大企業の基幹システムに限った話ではありません。WordPressで作られた会社のWebサイト、問い合わせフォームのデータ、ネットショップの注文情報、社内で共有している見積書や顧客台帳。どれも、壊れたり暗号化されたりすれば業務が止まり、元に戻せなければ信用にも関わります。

この記事では、Webサイトや業務データを預かる経営者・Web担当者の方に向けて、「バックアップを取っている」状態から「確実に戻せる」状態へ近づくための考え方を整理します。3-2-1ルールと呼ばれる保管の原則、バックアップをサーバーと同じ場所に置くリスク、世代管理と保存期間、実際に戻してみる復旧テスト、そして復旧までの目標時間の決め方です。

私はフリーランスのWebディレクター兼エンジニアとして、関西を中心にWebサイトの企画・制作から、WordPressやmicroCMSでの構築、公開後の保守まで携わっています。その立場から、専門の担当者がいない会社でも始めやすい進め方を中心にお伝えします。なお、Webサイトそのもののセキュリティ対策については「WordPressのセキュリティ対策ガイド」でまとめていますので、あわせてご覧ください。

「取っている」と「戻せる」は違う:警察庁の数字が示すこと

復元できなかった理由の多くは「バックアップも暗号化された」

先ほどの警察庁の統計データをもう少し詳しく見てみます。バックアップから復元できなかった理由に回答した72件のうち、48件が「バックアップも暗号化」、19件が「運用不備」、5件が「その他」でした。3分の2ほどが、バックアップそのものも被害を受けていたことになります。

なぜ、こうしたことが起きるのでしょうか。警察庁の同じ資料では、ランサムウェア攻撃の代表的な流れとして、攻撃者がネットワークに侵入した後、管理者の権限を奪ったりセキュリティを無効にしたりしながら、内部を探索して「重要データやバックアップを物色する」と説明されています。そのうえで、「復旧を妨害するため、バックアップも一緒に暗号化される場合が多い」とも書かれています。

攻撃者にとって、バックアップは身代金の交渉を邪魔する存在です。被害を受けた側がバックアップから戻せてしまえば、お金を払う理由がなくなるからです。そのため、攻撃者はデータ本体と同じように、あるいはそれ以上に、バックアップを狙ってきます。

たとえるなら「家の合鍵を、家の中に置いている」状態

同じサーバーや、常につながっているNASにバックアップを置いている状態は、家の合鍵を家の中の引き出しにしまっているのと似ています。玄関の鍵をなくしたときには役に立ちますが、空き巣に入られたときには、合鍵も一緒に持ち去られてしまいます。

故障や操作ミスへの備えとしては、同じ場所のバックアップでも役に立つ場面があります。誤ってファイルを消してしまった、プラグインの更新で表示が崩れた、といったトラブルであれば、すぐ近くにあるバックアップから素早く戻せるのはむしろ利点です。問題になるのは、ランサムウェアや不正アクセスのように、「人の意思で」データとバックアップの両方が狙われる場合です。

「運用不備」も見過ごせない

もう一つ注目したいのが、19件あった「運用不備」です。統計データには内訳までは載っていないため、具体的に何が起きたのかは分かりません。ただ、一般的には、バックアップが途中から止まっていたことに誰も気付いていなかった、必要なデータが対象から漏れていた、戻し方を知っている人がいなかった、といった状況が考えられます。

暗号化への備えと並んで、バックアップが「今も意図どおりに動いているか」を確かめ続けることも大切です。この点は、後半の復旧テストの章で詳しく触れます。

被害が長引くほど、経営への影響は大きくなる

警察庁の資料では、復旧に総額1,000万円以上を要した組織の割合が全体の5割を超え、1か月未満で復旧できた組織は5割強にとどまったとされています。戻せるバックアップがあるかどうかは、止まる期間と、かかる費用の両方に関わってきます。バックアップは「IT担当の作業」ではなく、事業を続けるための経営判断の一つとして考える必要があります。

3-2-1ルールと「同じ場所に置かない」という原則

3-2-1ルールとは

バックアップの保管方法として広く紹介されているのが「3-2-1ルール」です。IPA(情報処理推進機構)の「日常における情報セキュリティ対策」では、次のように説明されています。

  • データを3つ持つ(運用データ1つ、バックアップデータ2つ)
  • 2種類の異なる媒体でバックアップする
  • そのうち1つは異なる場所(オフサイト)で保管する

NISC(内閣サイバーセキュリティセンター)が公表したランサムウエアに関する注意喚起でも、ファイルのコピーを3個取得し、異なる2種類の媒体に保存したうえで、1個は「保護対象のネットワークからアクセスできない場所等」に保管する対策例が示されています。

ランサムウェア対策で特に大切なのは「切り離す」こと

3-2-1ルールのうち、ランサムウェア対策で特に意識したいのが最後の「1」です。警視庁の「安全なバックアップの取得方法と注意点」では、バックアップ用のHDDなどを常にパソコンに接続したままにしておくと、感染時に「共倒れ」になると指摘しています。そのうえで、バックアップ時だけ接続して終了後に切り離す「オフラインバックアップ」や、書き換えや削除ができない「変更不能(イミュータブル)」な保存の活用を紹介しています。

IPAの「情報セキュリティ対策の基本と共通対策」でも、ランサムウェア攻撃に備えてネットワーク上隔離された場所へ保管し、外部記憶装置であればバックアップ取得時以外は物理的に接続を切ることが望ましい、とされています。

Webサイトと業務データで、よくある置き場所を見直す

中小企業でよく見かける保管方法を、リスクの観点で整理すると次のようになります。

保管のしかた

起きやすいこと

WordPressのバックアッププラグインで、同じサーバー内に保存

サーバーに侵入されると、本体と一緒に削除・改ざんされることがある

社内のNASに毎晩コピーし、常時接続

社内のパソコンが感染すると、NASのバックアップも暗号化されることがある

クラウドストレージと自動で同期

削除や暗号化された状態が、そのまま同期されることがある

外付けHDDに保存し、作業後は取り外して保管

共倒れは避けやすいが、人の作業に頼るため取り忘れが起きやすい

別の事業者のクラウドに、削除できない期間を設定して保存

管理画面の認証情報が漏れないよう、二段階認証などの管理が必要

どれか一つが正解というわけではありません。たとえば、同じサーバー内のバックアップは「すぐ戻せる」利点を活かし、それとは別に、サーバーとは異なる事業者の保管先や、普段は接続しない媒体にもう一つ残しておく。こうした組み合わせで、それぞれの弱点を補うのが現実的な進め方です。

現場でつまずきやすい点:「同期」と「バックアップ」を混同する

ファイル共有サービスの同期機能を、バックアップの代わりにしているケースは少なくありません。同期は、手元の変更を別の場所にも反映させる仕組みです。便利な反面、手元でファイルが削除されたり暗号化されたりすると、その状態も反映されることがあります。サービスによっては過去の版に戻せる機能もありますが、保持される期間や条件はサービスや契約内容によって異なります。同期を使っている場合は、「どこまでさかのぼって戻せるのか」を公式のヘルプで確認しておきましょう。

世代管理と保存期間:レンタルサーバーの自動バックアップの範囲を確かめる

世代管理とは「複数の時点に戻れるようにしておく」こと

バックアップを1つだけ持ち、毎日上書きしている場合、もし改ざんや感染に気付くのが遅れると、その「汚れた状態」でバックアップが上書きされてしまいます。これを防ぐのが世代管理です。IPAの資料では、最新だけでなく過去のバックアップも保管し、複数の時点にリカバリできるようにしておくことが望ましいとされています。理由として、データの破損からそれを認知するまでに時間がかかると、最新のバックアップもすでに破損しているおそれがあることが挙げられています。

Webサイトの改ざんは、表示が大きく変わらない形で行われることもあります。たとえば、見た目はそのままで、裏側に不正なプログラムが埋め込まれている場合です。気付いたときには、何日も前から改ざんされていた、ということも考えられます。その場合に必要なのは、「改ざんされる前の時点」のバックアップです。

レンタルサーバーの自動バックアップは「範囲」と「期間」を確認する

多くのレンタルサーバーには、自動バックアップの機能があります。ここでは一例として、国内で広く使われているエックスサーバーの公式情報を確認してみます。自動バックアップ機能の案内ページによると、サーバー上のデータを1日1回バックアップ専用サーバーに自動でコピーし、Web・メールデータとMySQLデータベースをそれぞれ「過去14日分」保持するとされています。一部の旧サーバーでは、Web・メールデータの保持期間が7日間とされています。

あわせて、次のような注意点も明記されています。

  • WordPressのキャッシュディレクトリなど、一部の領域はバックアップの対象外
  • テーブル数が1,000を超えるデータベースなどは対象外となる場合がある
  • バックアップは「データの確実な保全を保証するものではありません」とし、利用者自身でもバックアップを行うことを強く勧めている

また、自動バックアップからのデータ復元マニュアルでは、復元を実行すると対象のディレクトリ・ファイルはバックアップの内容で上書きされ、バックアップ日以降に作成されたファイルは削除されると説明されています。

ここで挙げたのは一つの事業者の例です。保持期間や対象範囲、復元の手順は、事業者やプランによって異なります。自社で契約しているサーバーについて、公式のマニュアルで確認しておくことが大切です。

確認しておきたい5つの質問

レンタルサーバーやホスティングの自動バックアップについて、次の点を確認してみてください。

  1. 何日分(何世代分)さかのぼれるか
  2. Webのファイル、データベース、メールのうち、どれが対象か
  3. 対象外になっているディレクトリやデータはないか
  4. 復元は自分で操作できるのか、申し込みが必要なのか、費用はかかるのか
  5. サーバーのアカウント自体が乗っ取られた場合でも、そのバックアップは守られるのか

5つ目は見落とされやすい点です。自動バックアップの操作が管理パネルから行える場合、その管理パネルのログイン情報が漏れれば、第三者が古いバックアップで上書きすることも考えられます。管理パネルの二段階認証は、バックアップを守る意味でも設定しておきたい項目です。

14日分あれば十分とは限らない

保持期間が14日分の場合、改ざんに気付くまでに2週間以上かかれば、自動バックアップだけでは「改ざん前」に戻せないことになります。サーバーの自動バックアップを土台にしつつ、月に1回など間隔を空けた世代を、別の場所に保管しておくと安心です。

復旧テスト:実際に戻してみて、初めて分かること

「戻せるはず」は、試すまで分からない

NISCの注意喚起では、バックアップの設定を確認するだけでなく、「バックアップデータから実際に復旧できることを確認する」ことが挙げられています。警察庁の春の大型連休に向けた注意喚起でも、最新のバックアップが取得されていることと、バックアップデータから実際に復旧できることを確認するよう呼びかけています。

バックアップのファイルがあることと、そのファイルから元の状態に戻せることは別の話です。WordPressのサイトを例にとると、元に戻すにはファイル一式とデータベースの両方が必要です。どちらか一方だけでは、サイトは正しく表示されません。

悪い例と改善例

バックアップの運用を、よくある状態と見直した状態で比べてみます。

項目

悪い例

改善例

確認のしかた

「バックアップ完了」のメール通知が届いているので安心している

年に1〜2回、テスト用の環境に実際に戻して表示と動作を確かめる

対象

Webのファイルだけを保存している

ファイル、データベース、設定ファイルをセットで保存している

手順

戻し方は制作会社の担当者の頭の中にある

戻す手順を文書にし、社内の担当者も読める場所に置いている

時間

どれくらいで戻せるか、誰も知らない

テストのたびに、戻し終わるまでの時間を記録している

認証情報

サーバーのパスワードを知っているのは退職した前任者だけ

管理者アカウントの情報を、社内で決めた方法で保管している

Webサイトの復旧テストの進め方

本番のサイトに直接上書きするのは避け、テスト用の環境で行うのが基本です。たとえば、次のような流れで進めます。

  1. テスト用のサブドメインや、別のサーバー領域を用意する
  2. バックアップからファイルとデータベースを戻す
  3. トップページや主要なページが正しく表示されるかを確認する
  4. 管理画面にログインできるか、問い合わせフォームが送信できるかを確認する
  5. 戻し終わるまでにかかった時間と、つまずいた点を記録する
  6. 確認が終わったら、テスト環境は削除するか、外部から見られないようにする

6つ目は忘れられがちです。テスト環境がそのまま公開状態で残っていると、検索エンジンに登録されたり、更新されないまま放置されて新たな弱点になったりすることがあります。

現場でつまずきやすい点

復旧テストを行うと、普段は気付かない問題が見えてきます。よく挙がるのは次のようなものです。

  • データベースの接続情報が分からず、設定ファイルを書き換えられない
  • サーバーのPHPのバージョンが、バックアップを取った当時と違っていて正しく動かない
  • 画像などのファイルが多く、容量が足りずに復元が途中で止まる
  • サーバーやドメインの管理画面のログイン情報を、誰も把握していない

最後の点は、担当者の退職や制作会社の変更をきっかけに起こりやすい問題です。「担当者が退職した後の契約とログイン情報の控え方」でも整理していますので、あわせて確認してみてください。

復旧までの目標時間を決める:RTOとRPOの考え方

「どれくらいで」「どの時点まで」戻したいか

バックアップの方法を決めるとき、技術的な手段より先に決めておきたいのが「目標」です。IPAの「中小企業の情報セキュリティ対策ガイドライン 第4.0版」では、事業上重要なシステムについて、目標復旧時間(RTO)と目標復旧時点(RPO)に合わせてバックアップの取得や手順の整備を行い、訓練で実効性を検証することが求められています。

  • 目標復旧時間(RTO): 止まってから、どれくらいの時間で元の水準まで戻すか
  • 目標復旧時点(RPO): どの時点のデータまで戻せればよいか(どこまでのデータの消失なら許容できるか)

たとえば、RPOを「1日前」とするなら、少なくとも1日1回はバックアップが必要です。RTOを「半日」とするなら、半日で戻せる手順と体制が必要になります。

業務によって、求められる水準は変わる

同じ会社の中でも、データの種類によって求められる水準は違います。次の表は、考え方を整理するための例です。実際の目標は、各社の業務の状況に合わせて決める必要があります。

対象

止まったときの影響

目標の考え方の例

会社案内のWebサイト

問い合わせが届かない、信用に関わる

数日以内に再公開できればよい。更新頻度が低ければ、週1回の世代でも足りることがある

ネットショップの注文データ

売上と顧客対応が止まる

数時間〜1日で戻したい。注文データは、より短い間隔での保存を検討する

社内の見積書・顧客台帳

営業や請求の業務が止まる

業務が止まる日数と、作り直しにかかる手間から逆算する

決めるのは経営者の役割

RTOやRPOを短くするほど、費用や手間はかかります。毎時のバックアップや、すぐに切り替えられる予備の環境を用意するには、それなりの投資が必要です。一方で、目標を決めないまま「とりあえず毎日バックアップ」としていると、いざというときに「この時点では古すぎる」「戻すのに何日もかかる」ということになりかねません。

どこまでの停止とデータの消失なら事業として受け入れられるかは、技術の担当者だけでは判断できません。経営者が決め、担当者や制作会社がその目標に合う方法を選ぶ。この役割分担が、無理のない進め方です。

サイバー攻撃を想定したBCPに組み込む

警察庁の資料では、ランサムウェア被害に遭った企業・団体のうち、サイバー攻撃を想定したBCP(業務継続計画)を策定済みだった組織は約18%だったとされています。また、データの暗号化は地震などの物理的な災害とは被害の状況が異なり、調査や復旧、広報のあり方も異なる対応が求められると指摘しています。

すでに災害向けのBCPがある会社であれば、そこに「Webサイトや業務データが暗号化・改ざんされた場合」の項目を加え、RTO・RPOと復旧手順、連絡先を書き込んでおくとよいでしょう。復旧テストの記録も、この計画を見直すための材料になります。

まとめ:「戻せる」を確かめるところから始める

ランサムウェアの被害に遭った組織の多くは、バックアップを取っていなかったわけではありませんでした。警察庁の統計データでは、取得していた組織が多い一方で、復元できた組織は限られ、その理由の多くは「バックアップも暗号化された」ことでした。バックアップは、取るだけでなく、攻撃者の手の届かない場所に分けて置き、複数の時点を残し、実際に戻せるかを確かめて、初めて備えとして機能します。

この記事で取り上げたポイントを振り返ります。

  • 3-2-1ルールを土台に、少なくとも1つは普段つながっていない場所や、別の事業者の保管先に置く
  • 世代管理で、改ざんや感染に気付くのが遅れても「その前の時点」に戻れるようにする
  • レンタルサーバーの自動バックアップは、保持期間と対象範囲を公式情報で確認し、それだけに頼らない
  • テスト用の環境で実際に戻してみて、手順と所要時間を記録する
  • どれくらいの時間で、どの時点まで戻したいか(RTO・RPO)を経営者が決める

どれも、大きな予算をかけなくても始められることです。まずは、次の3つを確認するところから始めてみてください。

  1. 自社のWebサイトと業務データのバックアップは、どこに、何日分あるか
  2. そのバックアップは、本体と同じサーバーやネットワークから切り離されているか
  3. 最後に「実際に戻してみた」のはいつか

3つ目に答えられない場合は、次の保守のタイミングで、テスト環境への復元を一度試してみることをおすすめします。手順書がなければ、そのテストの記録が、そのまま最初の手順書になります。

制作会社や保守会社に運用を任せている場合は、「バックアップはどこに何世代あるか」「最後に復元を試したのはいつか」を尋ねてみるのも一つの方法です。答えがはっきりしていれば安心材料になりますし、曖昧であれば、見直しのきっかけになります。

ランサムウェアの手口は変わり続けていますが、「別の場所に、複数の時点を残し、戻せることを確かめる」という基本は、攻撃の種類が変わっても役に立ちます。バックアップを「取っている」状態から「戻せる」状態へ。その一歩を、今の運用の確認から始めてみてください。

「自社サイトのバックアップが本当に戻せるか確かめたい」「レンタルサーバーの設定や復旧手順を一緒に整理してほしい」とお考えの企業・店舗の方は、現状の確認と運用の見直しのご相談を承っています。相談・お問い合わせからお気軽にご連絡ください。

指定の意味を辞書で確認する

タグとプロパティは、リファレンスに意味とコードを置いています。

リファレンスを開く