結論：「バックアップはある」と「ランサムウェア被害後に戻せる」はまったく別物である

ランサムウェア被害で最も残酷な瞬間は、暗号化されたサーバの前で「バックアップから戻そう」と管理画面を開いたとき、バックアップまで暗号化されていると気づく瞬間である。バックアップを取っていなかったのではない。毎晩きちんと取っていた。だがそのバックアップが本番と同一ネットワークに常時接続され、本番と同じ認証で管理されていたために、攻撃者には「もう一つの暗号化対象」でしかなかった。失敗の本質はバックアップの有無ではなく、隔離設計の不在にある。

  • ランサムウェアはバックアップごと暗号化しにいく。本番から常時到達できるバックアップは、本番と同じ被害域にある。
  • 身代金の支払い率は57.0%から43.8%へ低下し「払わない」が主流になりつつあるが、払わずに復旧できなかった割合は10.5%から13.0%へ上昇している（JIPDEC調査）。
  • 「払わない」を選ぶなら、払わなくても戻せるバックアップ——オフライン／イミュータブル（改ざん不可）な分離コピー——が前提になる。
  • 3-2-1ルール・オフライン／イミュータブル・復元テストは、サイバー保険の新規加入・更新でも事実上の前提条件になっている。
  • バックアップで守れるのは「データを戻す」範囲だけである。暗号化前に窃取されたデータの流出（二重脅迫）には別の備えが要る。

この連載「セキュリティ対策の失敗図鑑」は、対策を導入したはずの企業がそれでも被害に至る構造を一回ごとに分解している。第2回となる本稿は、ツールを入れたことで安心してしまう失敗（第1回：EDRを入れて「対策済み」と思い込む失敗）や、被害発生後の動き方の失敗（第5回：初動・報告フロー未整備の失敗、第12回：復旧優先で証拠保全を壊す失敗）とは切り口を分け、「バックアップはあるのに、肝心の場面で使えない」という隔離設計の不在に絞る。平時のバックアップ設計の全体像は3-2-1ルール実践ガイドで扱っているが、本稿は設計ガイドではなく、「あるのに復旧できない失敗」がなぜ起きるのかという構造の側から点検する。

なぜ「あるはずのバックアップ」が一緒に暗号化されるのか

本番と同一ネットワークに常時接続されている

最も多い構造が、バックアップ先のNASやバックアップサーバが本番ネットワークから常時マウントされている形である。日々の運用には便利だが、ネットワーク経由で到達できる場所にあるデータは、社内に侵入したランサムウェアからも到達できる。攻撃者は暗号化の実行前に社内を横移動し、共有フォルダやバックアップ領域を探す。本番と同じネットワークに見えているバックアップは、攻撃者から見れば「最初に潰すべき復旧手段」であり、本番より先に暗号化・削除されることすらある。

本番と同一の認証・権限で管理されている

ネットワークを分けていても、バックアップの管理コンソールが本番と同じ認証基盤・同じ管理者アカウントで操作できるなら、隔離は実質的に破られている。ランサムウェア攻撃の常套手段は管理者権限の奪取であり、ドメイン管理者を取られた時点で、その権限で消せるものはすべて消される。バックアップの世代を遡って削除し、復旧の選択肢を断ってから身代金を要求するのが攻撃側の合理である。「バックアップ系は別の認証・別の権限でしか触れない」という分離がなければ、世代を何本持っていても意味をなさない。

同期型クラウドを「オフサイト」と誤解している

「クラウドに上げているから大丈夫」も危うい。同期型のクラウドストレージは、手元のファイルが暗号化されると、その暗号化されたファイルをそのまま同期する。バージョン履歴機能がある場合は一部復旧可能だが、バックアップ専用の仕組みには及ばない。さらに見落とされやすいのが復元テストの不在である。バックアップは「復旧できてはじめて意味がある」のであって、ジョブの成功ログだけを見て安心していると、失敗に気づかないまま数週間が経過する事態も起きる。取れているかではなく、戻せるかを確認していない限り、バックアップは点検済みとは言えない。

データが示す現実：「払わず復旧できなかった」企業は増えている

この失敗の重さは、統計で裏づけられる。JIPDEC（日本情報経済社会推進協会）の「企業IT利活用動向調査2026」（株式会社ITRと共同・有効回答1,107社・2026年1月調査）では、ランサムウェアの感染経験がある企業が45.8%にのぼった。これは「過去1年」ではなく「感染を経験したことがある」割合である点に注意が要るが、約2社に1社が経験しているという事実は、感染が特別な不運ではなく起こりうる前提であることを示す。業種別では製造業が57.1%で最多、従業員299名以下でも37.0%と、中小企業も例外ではない。

注目すべきは支払いをめぐる二つの数字である。身代金の支払い率は57.0%から43.8%へ低下し（感染企業ベース・3年連続で低下）、「払わない」が主流になりつつある。ところが、払わずに復旧できなかった割合は10.5%から13.0%へ上昇した。つまり「払わない」と決める企業が増える一方で、払わなくても戻せる備えが追いついていない。支払っても完全復旧の保証はなく、支払い自体が次の標的化につながりうる以上、「払わない」という方針は正しい。だがその方針は、健全な隔離バックアップと事業を戻す計画があって初めて成立する。詳細な数値の読み解きはJIPDEC調査の解説記事で、復旧の優先順位づけはBCP策定ガイドで扱っている。

もう一つの外圧がサイバー保険である。2026年のサイバー保険では、EDR・MFA・バックアップの3点セットが新規加入・更新の事実上の前提条件となり、バックアップ要件は3-2-1ルール（3コピー／2媒体／1オフサイト）、オフライン・イミュータブルなコピー、復元テストの四半期以上の頻度での実施にまで踏み込んでいる。審査されるのは「取れているか」ではなく「戻せるか」である。隔離設計の不在は、被害時の復旧不能だけでなく、保険の引受可否という形でも顕在化する。背景はサイバー保険2026年の引受条件厳格化で整理している。

バックアップだけでは守れない範囲——穴吹興産の事例

ただし、隔離バックアップを完璧にしても守れない範囲がある。不動産デベロッパーの穴吹興産が受けたランサムウェア攻撃では、同社が身代金の支払いを拒否した後、49.6万人分の個人情報がダークウェブ上で公開された。支払い拒否への報復とみられる。侵入から流出確認まで37日間あり、攻撃者は暗号化の前に十分な時間をかけてデータを窃取していた可能性が高い。バックアップがあればシステムは復旧できるが、盗まれたデータは取り戻せない。暗号化への備え（バックアップ）と、窃取・流出への備え（侵入の検知と封じ込め）は別の対策であり、本稿が扱う隔離設計は前者を確実にするものだと理解しておく必要がある。事例の詳細は穴吹興産の事案解説を参照されたい。

隔離方式の比較：オフライン・イミュータブル・別認証クラウド

「本番から到達できない場所にコピーを置く」実現方法は一つではない。代表的な三方式を比較する。

観点オフライン（物理切り離し）イミュータブル（改ざん不可）別認証クラウド
仕組み取得後に媒体（テープ・外付けHDD等）をネットワークから切り離して保管一定期間は管理者でも変更・削除できないストレージに書き込む本番と分離した認証・権限のバックアップ専用クラウドに保管
ランサムに強い理由ネットワーク経由では到達できない到達されても上書き・削除ができない本番の管理者権限を奪われても消されにくい
主な弱点手動運用に依存し、取得間隔が空きやすい保持期間・権限の設定ミスで無効化されうる同期型と混同すると暗号化ファイルが複製される
運用負荷切り離し・搬出の人手がかかる自動化しやすいが対応製品が前提自動化しやすいが回線・容量の費用が利く
位置づけ最重要データの最終防衛線日次の自動運用と隔離の両立オフサイト要件の現実解

三方式は択一ではない。日々の世代はイミュータブルまたは別認証クラウドで自動取得し、最重要データはオフラインの最終防衛線も併せて持つ、という重ね方が現実的である。どの方式でも共通して効くのは「本番の認証情報だけでは触れないこと」「感染後のデータで世代が埋まらない保持期間を持つこと」「復元テストで戻せることを確認すること」の三点であり、方式選定よりも先にこの三点が満たせるかを見るべきである。

復旧可能性を点検する手順（チェックリスト）

自社のバックアップが「ある」ではなく「戻せる」状態かは、次の点検で判定できる。

  • バックアップ先（NAS・バックアップサーバ・クラウド）に、本番ネットワークから常時アクセスできる状態になっていないか。
  • バックアップの管理コンソール・削除操作が、本番と同じ認証基盤・同じ管理者アカウントで実行できてしまわないか。
  • 3-2-1ルール（3コピー／2媒体／1オフサイト）に照らして、本番から到達できないコピーが少なくとも1つあるか。
  • オフラインまたはイミュータブルなコピーがあり、その保持期間・権限設定を第三者の目で確認したか。
  • 感染から暗号化までの潜伏期間を考慮し、すべての世代が「感染後のデータ」で埋まらない保持期間を確保しているか。
  • 復元テストを定期的に実施し、復旧にかかる時間を計測・記録しているか（取得ジョブの成功ログ確認だけで済ませていないか）。
  • どの業務を・どの順で・いつまでに戻すか（RTO／RPO）が決まっており、バックアップの設計と整合しているか。
  • バックアップでは守れない窃取・流出のリスクに対し、検知・封じ込めの備えを別枠で持っているか。

一つでも該当しない項目があれば、被害時に「バックアップはあったのに戻せなかった」側に回る可能性がある。自社だけで判定が難しいのは、認証分離やイミュータブル設定の「つもり」が実際に機能するかの検証である。GXOではランサムウェア対策支援として、現状のバックアップ構成が本当に復旧に使えるかの点検から、隔離方式の設計・復元テストの運用化までを支援している。全体のリスクを俯瞰したい場合はセキュリティ事業の診断を入口にするとよい。

関連記事

よくある質問

Q1. 毎日バックアップを取っていれば安心と考えてよいか。

よくない。問題は頻度ではなく隔離である。バックアップ先が本番と同一ネットワークに常時接続され、同一の認証で管理されていれば、ランサムウェアに本番と一緒に暗号化・削除される。サイバー保険の審査でも「取れているか」ではなく「戻せるか」が見られており、本番から到達できない分離コピーと復元テストまで揃って初めて安心の根拠になる。

Q2. クラウドにファイルを同期していれば「オフサイト」を満たすか。

満たさない。同期型のクラウドストレージは、手元で暗号化されたファイルをそのまま同期してしまう。バージョン履歴で一部復旧できる場合もあるが、確実ではない。オフサイトとして機能させるには、本番と分離した認証・権限で動くバックアップ専用の仕組みか、イミュータブル（改ざん不可）なストレージを使う必要がある。

Q3. いざとなれば身代金を払えばデータは戻るのか。

当てにできない。支払っても完全復旧の保証はなく、支払い自体が次の標的化につながりうる。JIPDEC「企業IT利活用動向調査2026」でも支払い率は57.0%から43.8%へ低下し、「払わない」が主流になりつつある。一方で払わずに復旧できなかった割合は10.5%から13.0%へ上昇しており、「払わない」を選ぶなら、払わなくても戻せる隔離バックアップと復旧計画が前提になる。

Q4. 隔離したバックアップがあればランサムウェア対策は完了か。

完了ではない。バックアップで守れるのは「データと業務を戻す」範囲に限られる。穴吹興産の事例では、暗号化前にデータが窃取され、身代金の支払い拒否後に49.6万人分の個人情報が公開された。盗まれたデータはバックアップでは取り戻せない。窃取・流出には侵入の早期検知と封じ込め、被害時の初動体制という別の備えが必要で、本連載の第1回・第5回で扱う論点と組み合わせて設計すべきである。

「バックアップはあるが、本当に戻せるかは確認したことがない」という状態は、ランサムウェア被害の現場で最も多い後悔である。自社のバックアップが本番から隔離されているか、復元テストまで運用に乗っているかを点検したい場合は、無料相談から現状の構成を持ち込んでいただきたい。復旧可能性の点検から隔離設計の実装まで、現実的な順序で整理する。

出典