「バックアップがあるから大丈夫」は危険｜ランサムウェアで復旧できない7つの理由【2026年版】

「バックアップは毎日取っています。だから、ランサムウェアに感染しても大丈夫です」

自社のセキュリティ対策について尋ねられた際、このように答える経営者や情報システム担当者もいるのではないでしょうか。

確かに、バックアップは重要です。

しかし、ここで一つ確認しておきたいことがあります。

そのバックアップを使って、実際にシステムを復旧させたことはありますか。

バックアップデータが存在していても、攻撃者によって暗号化・削除されていたり、必要なデータが不足していたりすれば、業務を再開できません。

2026年に警察庁が公表した統計でも、ランサムウェア被害に遭った組織の多くが、バックアップから復元できなかったことが明らかになっています。

今回は、IPAの「ランサムウェア被害から学ぶ教訓集」と最新の公的資料をもとに、バックアップが使えなくなる理由と、企業が取り組むべき対策を解説します。

近年注目されている「イミュータブルバックアップ」についても、その仕組みと注意点を詳しく取り上げます。

なお、この記事にはアフィリエイト広告が含まれています。

1．バックアップから復元できなかった組織は、回答40件中29件

警察庁が2026年9月10日に公表した「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」によると、2026年1月から6月までに報告されたランサムウェア被害は123件でした。

このうち79件が中小企業です。

さらに注目したいのが、バックアップの取得状況と復元結果です。

出典：警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」

https://www.npa.go.jp/publications/statistics/cybersecurity/

なお、取得状況と復元結果では回答母数が異なります。これらは被害組織からの回答に基づく統計であり、すべての企業に当てはまる復元失敗率を示すものではありません。

それでも、この結果から読み取れることがあります。

バックアップを取得していることと、実際に復旧できることは別の問題なのです。

特に注目したいのが、バックアップ自体の暗号化・消去と、運用の不備です。

攻撃者によってバックアップを破壊されるだけでなく、日頃の管理方法に問題があったために復元できなかったケースも報告されています。

「バックアップがあるから大丈夫」

この考え方を、一度見直す必要があるのではないでしょうか。

2．なぜ攻撃者はバックアップを狙うのか

ランサムウェア攻撃というと、突然ファイルが暗号化され、身代金を要求する画面が表示される光景を想像するかもしれません。

しかし、現在の企業を狙った侵入型ランサムウェア攻撃では、暗号化されるより前の段階から攻撃が進んでいることがあります。

攻撃者はVPN機器や外部公開システムの脆弱性、不正に入手した認証情報などを利用して侵入し、内部のネットワークや重要なシステムを調査します。

その過程で、管理者権限を奪取したり、セキュリティ機能を停止させたりすることもあります。

そして、攻撃者が探すものの一つがバックアップです。

なぜでしょうか。

企業がバックアップから自力で復旧できれば、攻撃者の要求に応じる必要性が小さくなるからです。

そのため、攻撃者は業務データを暗号化する前に、バックアップの保存先を調査し、削除や暗号化を試みることがあります。

IPAが2026年9月に公開した「ランサムウェア被害から学ぶ教訓集」でも、暗号化によって被害が発覚した時点では、攻撃者の活動が最終段階に達しているという特徴が説明されています。

つまり、被害に気付いたときには、既にバックアップまで攻撃されている可能性があるのです。

出典：IPA「ランサムウェア被害から学ぶ教訓集」

https://www.ipa.go.jp/security/todokede/crack-virus/ransomware_lessons_learned.html

3．バックアップがあっても復旧できない7つの理由

バックアップから復元できない原因は、攻撃者による暗号化や削除だけではありません。

企業のシステム構成や管理方法、日頃の運用によっても、復旧が困難になることがあります。

理由① バックアップも同じネットワーク上にある

中小企業では、社内にNASを設置し、ファイルサーバーや業務用パソコンのデータを自動的にバックアップしているケースがあります。

こうした構成自体が悪いわけではありません。

問題は、本番システムが侵害された際に、バックアップまで操作できてしまうことです。

例えば、バックアップ用NASが社内ネットワークに常時接続され、侵害されたアカウントからアクセスできる構成だったとします。

攻撃者が管理者権限を奪取すれば、バックアップデータの削除や設定変更まで可能になるおそれがあります。

バックアップを別の機器に保存しているだけでは、十分な保護とは限らないのです。

理由② 管理者アカウントが共通になっている

バックアップの保存先を分離していても、管理者権限が共通になっていれば安心できません。

例えば、本番サーバーの管理者アカウントで、バックアップサーバーや保存先まで管理できる環境です。

普段の運用は容易になりますが、攻撃者にそのアカウントを奪われた場合、複数のシステムが同時に侵害される可能性があります。

バックアップ対策では、データの保管場所だけでなく、管理権限の分離も重要です。

理由③ クラウド同期をバックアップだと思っている

Microsoft OneDriveやGoogle Driveなど、クラウドサービスを利用する企業も増えています。

しかし、クラウドへのファイル同期とバックアップは、必ずしも同じではありません。

例えば、パソコン上のファイルがランサムウェアによって暗号化された場合、その変更がクラウド側にも同期される可能性があります。

もちろん、クラウドサービスによっては、バージョン履歴や復元機能が用意されています。

ただし、保持期間や復元範囲には条件があります。

「クラウドに保存しているから安全」ではなく、どの時点まで戻せるのかを確認する必要があります。

理由④ 攻撃者が侵入した後の状態をバックアップしている

侵入型ランサムウェア攻撃では、攻撃者が暗号化を実行する前から内部で活動している場合があります。

その間に不正なプログラムが設置されたり、システムの設定が変更されたりしていれば、そうした状態までバックアップされる可能性があります。

つまり、最新のバックアップが、必ずしも安全なバックアップとは限らないのです。

安全な復旧時点を判断するには、攻撃者がいつ侵入し、どのような操作を行ったのかを調査する必要があります。

そのためには、バックアップだけでなく、アクセスログや操作ログなどの保存も重要になります。

理由⑤ データは残っているが、システムを再構築できない

例えば、販売管理システムのデータがバックアップされていたとします。

しかし、実際にシステムを再構築するには、データベース、アプリケーション、ライセンス情報、設定ファイル、認証基盤などが必要になる場合があります。

必要な情報が不足していれば、データを取り出すことができても、業務システムを動かせないことがあります。

英国NCSCも2026年10月に公開した復旧ガイダンスで、バックアップの対象としてデータだけでなく、アプリケーション、認証基盤、設定情報などを挙げています。

バックアップからファイルを復元できることと、業務システムを再構築できることは別なのです。

理由⑥ バックアップを取得するだけで、復元テストをしていない

バックアップソフトの管理画面には「正常終了」と表示されている。

担当者も毎日確認している。

それ自体は良い運用です。

しかし、バックアップが正常終了したことと、実際に復元できることは同じではありません。

データが破損している、復元に必要な暗号鍵が分からない、システムの更新によって以前の復元手順が使えなくなっている、といった問題も考えられます。

重要なのは、バックアップを取ることだけでなく、実際に使えることを確認することです。

理由⑦ データは復元できても、業務を再開できない

最後は、経営者に特に考えていただきたい問題です。

仮にバックアップが無事で、データを復元できたとします。

しかし、システムの安全性を確認できなければ、そのまま業務を再開することはできません。

また、バックアップ取得後に発生した取引や作業記録が失われていれば、その情報を再入力する必要があります。

復旧作業には、侵入経路の調査、システムの再構築、ネットワークの安全性確認などが必要になる場合もあります。

バックアップから復元できることと、通常業務を再開できることは別の問題なのです。

ランサムウェア攻撃の実態を理解するために

『ランサムウェア攻撃対策マニュアル』（面和毅著・技術評論社）では、近年のランサムウェア攻撃の手法や侵入後の行動、バックアップ管理、ログ管理、インシデント対応などが体系的に解説されています。

攻撃者がどのような行動を取るのかを理解したうえで、自社の対策を見直したい情報システム担当者に参考になる一冊です。

Amazonで『ランサムウェア攻撃対策マニュアル』を確認する

4．注目される「イミュータブルバックアップ」とは

ここまで紹介した問題の中でも、特に対策が求められるのが、攻撃者によるバックアップの暗号化・削除です。

そこで近年、ランサムウェア対策として注目されているのが「イミュータブルバックアップ」です。

イミュータブル（Immutable）とは、「変更できない」「不変である」という意味です。

イミュータブルバックアップは、保存されたバックアップデータを、あらかじめ設定した保持期間中、変更・削除できないように保護する仕組みです。

例えば、バックアップデータを30日間変更・削除できない設定にしたとします。

適切に保護されたデータであれば、その期間中に攻撃者が削除や上書きを試みても、保護されたデータを維持できるように設計されています。

この仕組みを実現する代表的な技術が、WORM（Write Once, Read Many）です。

WORMは、一度書き込んだデータを繰り返し読み取ることはできても、保護期間中は変更・削除できないようにする考え方です。

なお、実際の保護範囲は製品やサービスの仕様、管理者権限、設定によって異なります。

通常のバックアップと何が違うのか

例えば、一般的なバックアップ用NASにデータを保存している場合、適切な権限を持つ管理者であれば、バックアップファイルを削除できる構成もあります。

攻撃者がその管理者権限を奪えば、バックアップそのものを破壊される可能性があります。

一方、適切に設定されたイミュータブルバックアップでは、管理者が削除を試みても、保持期間中のデータが保護される仕組みを実現できます。

これは、バックアップの保護において大きな違いです。

ただし、すべてのイミュータブル機能が、管理者による解除まで防げるわけではありません。

イミュータブル設定を無効化できる状態では、攻撃者がその設定を変更する可能性が残ります。

そのため「イミュータブル機能がある」という製品の説明だけではなく、保護設定を誰が解除できるのかまで確認する必要があります。

実際に利用されているイミュータブル技術

代表的な例として、Amazon Web Services（AWS）のAmazon S3 Object Lockがあります。

S3 Object Lockでは、オブジェクトに保持期間を設定し、その期間中の削除や上書きを防止する仕組みが提供されています。

主な保持モードには、ガバナンスモードとコンプライアンスモードがあります。

ガバナンスモードでは、特定の権限を持つ利用者が保護を回避できる場合があります。

一方、コンプライアンスモードでは、保持期間中はAWSアカウントのルートユーザーであっても、保護対象のオブジェクトバージョンを上書き・削除できない仕組みになっています。

また、Microsoft Azure BackupにもImmutable Vault（不変コンテナー）という機能があります。

こちらも、バックアップデータを不正な変更や削除から保護することを目的とした仕組みです。

Azure Backupでは、不変性を有効化しただけでは設定を解除できる状態があり、設定をロックすることで解除できない状態へ移行できます。

このように、イミュータブルバックアップと一口にいっても、保護の仕組みや設定によって実際の強度は異なります。

参考：

AWS「S3 Object Lock」
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/object-lock.html

Microsoft「Azure Backupの不変コンテナー」
https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-immutable-vault-concept

イミュータブルバックアップにも限界がある

ここで注意していただきたいのは、イミュータブルバックアップを導入すれば、すべての問題が解決するわけではないということです。

例えば、攻撃者が既に侵入した後の状態をバックアップしていた場合、不正な設定やプログラムを含むデータが保護される可能性があります。

また、攻撃者がバックアップ処理そのものを停止させれば、新しいバックアップが取得されなくなる場合もあります。

さらに、保持期間が終了すれば、削除や変更が可能になるため、保持期間が短すぎると必要なバックアップを失うおそれがあります。

加えて、イミュータブルバックアップは情報漏えいを防止する仕組みではありません。

攻撃者によってデータが窃取されていた場合、バックアップを保護できても、持ち出された情報を取り戻せるわけではないのです。

つまり、イミュータブルバックアップは、ランサムウェアによるデータの破壊や削除への耐性を高める重要な対策ですが、万能ではありません。

導入する際に確認したいこと

イミュータブルバックアップの導入や運用を検討する場合、少なくとも次の点を確認したいところです。

• 管理者が侵害された場合でも、保護設定を解除できない仕組みになっているか。

• 必要な期間、バックアップを保護できるか。

• 本番環境とは管理権限や認証情報が分離されているか。

• バックアップ処理が停止した場合に検知できるか。

• 保護されたバックアップから実際に復元できるか。

• 保存容量や保持期間に応じた費用を把握しているか。

特に、長期間の保持を設定する場合は、保存容量や費用の増加に加え、不要になったデータを保持期間内に削除できないことにも注意が必要です。

業務の重要性、法令上の保存・削除要件、予算などを踏まえて適切に設計することが重要です。

イミュータブルバックアップを詳しく学びたい方へ

『実践バックアップ設計 ランサムウェア時代の「復元」完全ガイド』（鎌田誠著・インプレス NextPublishing）では、イミュータブルバックアップ、エアギャップ、WORM、3-2-1-1-0ルールなどが取り上げられています。

単にデータを保存するのではなく、実際に復旧できるバックアップ環境を設計するための考え方を学べる書籍です。

バックアップの構成や運用を見直したい情報システム担当者に参考になる内容です。

Amazonで『実践バックアップ設計』を確認する

5．オフラインバックアップとイミュータブルバックアップはどちらがよいのか

イミュータブルバックアップについて説明すると、「それなら従来のオフラインバックアップは必要ないのでは」と考える方もいるかもしれません。

しかし、両者は必ずしも代替関係ではありません。

それぞれ異なる特徴があります。

なお、スナップショットとイミュータブルバックアップは、必ずしも別々の技術ではありません。

製品によっては、スナップショット自体を変更・削除できないように保護する機能が提供されています。

重要なのは、製品や方式の名称ではなく、どのような攻撃や障害からデータを保護できるのかという点です。

例えば、イミュータブルバックアップでデータの削除・改ざんに備え、さらにオフラインバックアップを保有しておくことで、一つの環境への依存を減らすことができます。

予算や運用負担との兼ね合いはありますが、複数の仕組みを組み合わせることが、より強固なバックアップ対策につながります。

6．バックアップ設計で参考になる「3-2-1-1-0ルール」

バックアップの設計において、以前から知られている考え方に「3-2-1ルール」があります。

近年は、ランサムウェア対策も考慮した「3-2-1-1-0」という考え方も紹介されています。

このルールの重要な点は、データのコピー数だけを増やすのではなく、保存場所や保護方式を分散させることです。

例えば、社内のファイルサーバーにあるデータを、同じネットワーク内のNASだけに保存している場合、複数のコピーがあっても一つの攻撃によって失われる可能性があります。

これに対し、別の場所にイミュータブルバックアップを保存し、定期的に復元テストを行っていれば、復旧できる可能性を高められます。

ただし、このルールを満たすだけで復旧が保証されるわけではありません。

バックアップ対象、復元に必要な情報、管理権限、保持期間、業務上の復旧要件まで確認することが必要です。

7．最後にバックアップから復元したのはいつですか

ここまで、さまざまなバックアップ対策を紹介してきました。

しかし、どのような製品や仕組みを導入していても、実際に復元できなければ意味がありません。

例えば、イミュータブルバックアップでデータが無事に保護されていたとします。

それでも、復元に必要な手順が分からなかったり、アプリケーションや認証システムを再構築できなかったりすれば、業務再開までに時間がかかります。

そのため、定期的な復元テストが必要です。

最初からすべてのシステムを復元する必要はありません。

重要なデータの一部を検証環境で復元するなど、小規模な確認から始めることもできます。

また、復元テストでは、データが戻るかどうかだけでなく、復元作業に必要な時間も確認しておきたいところです。

ここで重要になるのが、RTOとRPOです。

RTO（目標復旧時間）は、停止した業務やシステムを、どのくらいの時間で復旧させることを目指すかという指標です。

RPO（目標復旧時点）は、どの時点までのデータを復旧できるようにするか、どれだけのデータ損失を許容するかという指標です。

これらを決めるには、情報システム担当者だけでなく、経営者や業務部門の関与も必要になります。

8．バックアップを守っても、事業を守れるとは限らない

仮に、ランサムウェアによって社内の主要システムが停止したとします。

バックアップからデータを復元できる見込みはあるものの、安全な環境を再構築するまで数日かかる。

その間、企業はどうやって業務を継続するのでしょうか。

製造業であれば、生産指示や在庫管理、出荷業務をどうするのか。

小売業であれば、受発注や請求業務をどう継続するのか。

医療機関であれば、電子カルテが利用できない状況で、どのように診療を継続するのか。

バックアップから復旧するまでの時間を、ただ待っていればよいわけではありません。

そこで必要になるのが、サイバーBCPです。

サイバーBCPは、ランサムウェアや不正アクセスなどによって情報システムが停止した際に、重要な業務をどのように継続し、復旧するかを定めた事業継続計画です。

例えば、次のようなことを事前に整理しておきます。

• どの業務を優先して継続するのか。

• システムが使用できない場合、どのような代替手段を使うのか。

• 誰がシステムの利用停止や再開を判断するのか。

• 復旧作業の優先順位を誰が決めるのか。

• 従業員や取引先へどのように連絡するのか。

• バックアップが使えなかった場合、どのように対応するのか。

こうした内容を整理し、机上訓練などで実際に確認しておくことが重要です。

IPAの教訓集でも、経営者による迅速な判断と明確な関与、インシデント対応体制の整備、事業継続計画への反映が重要な項目として挙げられています。

ランサムウェア被害を経営上の問題として理解するために

『ランサムウェア攻撃対応の実務 ―公表情報の分析からみる傾向と対策』（山岡裕明著・中央経済社）は、公表された被害事例などをもとに、被害金額、侵入経路、バックアップ、ログなどを分析した書籍です。

技術的な対策だけではなく、サイバー攻撃が企業経営に与える影響を理解する際にも参考になります。

Amazonで『ランサムウェア攻撃対応の実務』を確認する

9．中小企業は何から始めればよいのか

ここまで紹介した対策を、すぐにすべて実施するのは難しいと感じる企業もあるでしょう。

特に、専任の情報システム担当者がいない中小企業では、バックアップ環境の設計や復元テストまで十分な時間を確保できない場合があります。

そのような場合、まずは現在の状況を把握することから始めるのが現実的です。

最初に確認したいのは、次の5つです。

1. どのシステムやデータをバックアップしているか。

2. バックアップはどこに保存され、誰が削除・変更できるか。

3. オフライン保管やイミュータブル化など、バックアップ自体を保護する仕組みがあるか。

4. 最後に復元テストを実施したのはいつか。

5. 復旧できなかった場合、重要業務をどう継続するか。

保守事業者へ委託している場合は、バックアップの取得範囲、保持期間、復元作業の担当範囲なども確認しておきましょう。

また、イミュータブルバックアップを導入済みの場合は、機能を有効にしているかだけではなく、保護設定の解除権限や保持期間、実際の復元方法まで確認することが重要です。

新しい製品を購入する前に、現在の仕組みで何ができて、何ができないのかを把握することが大切です。

10．まとめ｜バックアップは「あるか」ではなく「使えるか」

ランサムウェア対策において、バックアップは非常に重要です。

しかし、バックアップが存在していても、攻撃者によって暗号化・削除される可能性があります。

また、バックアップが無事だったとしても、復元に必要な情報や手順が不足していれば、業務再開までに時間がかかることがあります。

イミュータブルバックアップは、こうした問題のうち、バックアップデータの変更・削除に対する耐性を高める有効な手段の一つです。

ただし、イミュータブルバックアップを導入するだけで、ランサムウェア対策が完成するわけではありません。

重要なのは、複数の保護策を組み合わせ、実際に復元できることを確認しておくことです。

さらに、システムが停止した際にも重要な業務を継続できるよう、サイバーBCPの整備も必要になります。

最後に、一つ質問させてください。

「明日、社内の重要システムが停止した場合、バックアップから何時間で業務を再開できますか？」

この質問に答えられるでしょうか。

「バックアップは取っています」と答えるだけでなく、「復旧できます」と根拠を持って説明できる状態を目指すこと。

それが、実効性のあるランサムウェア対策につながります。

株式会社クロイツでは、サイバーBCPの策定・見直しを支援しています

株式会社クロイツでは、医療機関や中小企業を対象に、情報セキュリティ対策やサイバーBCPの策定・見直し、机上訓練などを支援しています。

重要な業務や情報システムの整理、復旧優先順位、インシデント発生時の判断、代替業務の検討など、実際の運用を踏まえた支援を行っています。

「バックアップを取っているが、実際に復元できるか確認していない」

「保守事業者に任せているため、現在のバックアップ構成が適切か分からない」

「サイバー攻撃でシステムが停止した際の事業継続計画を整備したい」

こうした課題がある場合は、まず現状を整理することから始められます。

新たな製品や仕組みを導入することだけを目的とせず、現在の環境や運用体制を踏まえ、実際に機能する対策へと改善していくことを重視しています。

株式会社クロイツ｜サイバーBCP策定・机上訓練支援サービス

よくある質問

Q．イミュータブルバックアップとは何ですか？

イミュータブルバックアップとは、保存したバックアップデータを、設定した保持期間中に変更・削除できないように保護する仕組みです。

ランサムウェアによるバックアップの破壊や、管理者権限を悪用した削除などへの対策として利用されます。

Q．イミュータブルバックアップなら、ランサムウェアに感染しても安全ですか？

必ずしも安全とは限りません。

保護対象のバックアップデータを変更・削除されにくくする効果はありますが、攻撃者の侵入を防ぐ仕組みではありません。

また、不正なプログラムを含む状態がバックアップされる可能性もあるため、ログの保存や復元テスト、適切な保持期間の設定などが必要です。

Q．通常のNASでもイミュータブルバックアップは実現できますか？

製品によっては、スナップショットの変更・削除防止など、イミュータブルな保護機能が提供されています。

ただし、すべてのNASに同じ機能があるわけではありません。

管理者権限で保護設定を解除できるか、機器自体が故障した場合にどうなるかなども確認する必要があります。

Q．イミュータブルバックアップとオフラインバックアップは、どちらがよいですか？

それぞれ特徴が異なります。

イミュータブルバックアップは、保存データの変更・削除に対する保護を重視する仕組みです。

一方、オフラインバックアップは、ネットワークから切り離して保管することで、ネットワーク経由の攻撃から隔離する方法です。

可能であれば、それぞれの長所を組み合わせた設計が望まれます。

Q．イミュータブルバックアップがあれば、復元テストは不要ですか？

いいえ。復元テストは必要です。

イミュータブルバックアップはデータの変更・削除を防止する仕組みであり、業務システムの復旧を保証するものではありません。

実際にデータやシステムを復元できるか、必要な時間はどの程度かを確認しておくことが重要です。

参考資料

本記事は、2026年10月23日時点で確認できる以下の資料を参考にしています。

1．警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」

https://www.npa.go.jp/publications/statistics/cybersecurity/

2．IPA「ランサムウェア被害から学ぶ教訓集」（2026年9月8日公開、10月16日更新）

https://www.ipa.go.jp/security/todokede/crack-virus/ransomware_lessons_learned.html

3．警察庁「ランサムウェア被害防止対策」

https://www.npa.go.jp/bureau/cyber/countermeasures/ransom.html

4．英国NCSC「Prepare your technical recovery capability」

https://www.ncsc.gov.uk/collection/disruptive-cyber-attacks/preparing/3-prepare-technical-recovery

5．AWS「S3 Object Lock」

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/object-lock.html

6．Microsoft「Azure Backupの不変コンテナー」

https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-immutable-vault-concept