「毎晩バックアップを取っているから、ランサムウェアにやられても戻せる」と考えている方は多いと思います。ところが近年の攻撃では、本番データを暗号化する前に、バックアップのほうを先に壊しにきます。バックアップまで暗号化されてしまうと、復旧の手段がなくなります。
この記事では、ランサムウェアがバックアップを狙う理由と、バックアップを守るための共通の考え方を整理します。そのうえで、バックアップ製品各社の公開資料を調べ、メーカーによらない形に一般化して、規模別の構成例と復旧の流れを説明します。上から順に読めば、全体像がつかめるようにしています。
- 本記事は、Veeam、Rubrik、Cohesity、Commvault、Dell Technologiesの公開資料を調べたうえで、特定の製品によらない形に一般化した一般例です。特定の製品の実装を説明するものではなく、構成図と構成例は筆者が作成した想定例です。各製品の内部構造や動作を保証しません。
- 実際の実装、対応する機能、必要な機器やライセンスは製品によって異なります。導入や設計の前に、必ずメーカーや販売元に確認してください。この記事の内容については、免責とさせてください。
- 製品の機能、名称、ライセンスは変更されることがあります。調べた情報の出典は、記事末尾の「参考URL」にまとめています。
- 本ブログの掲載内容は個人の見解によるものです。
端末側の対策は 【図解】EDRとは?ウイルス対策ソフト(EPP)との違いと、不審な動きを見つける仕組み と 【図解】EDRだけでランサムウェアは防げる?RDRの考え方とEDRを補う仕組み で解説しています。この記事は、それでも侵入されたときに備える「バックアップ」の話です。
- ランサムウェアがバックアップまで狙う理由と、攻撃の流れ
- バックアップを守る5つの原則(3-2-1-1-0、不変性、認証の分離、隔離、検証)
- 各社の実装に共通する、守り方の種類
- 規模別の構成例3つと、選び方
- 復旧の流れと、導入前に確認したいこと
ランサムウェアがバックアップを狙う理由
以前のランサムウェアは、感染した端末のファイルを暗号化するだけの単純なものが中心でした。いまは、攻撃者が組織の内部に入り込み、時間をかけて権限を広げてから実行する攻撃が増えています。バックアップが残っていると身代金を払ってもらえないため、攻撃者は先にバックアップを探して壊します。米国のCISAも、多くのランサムウェアは、アクセスできるバックアップを探して削除または暗号化しようとする、と注意しています。
数字でも、その傾向は出ています。Sophosが2024年の初めに実施した調査では、ランサムウェア攻撃を受けた組織の94%で、攻撃者がバックアップを侵害しようとしました。そのうち57%で、侵害に成功しています。バックアップを侵害された組織は、そうでない組織に比べて、要求された身代金の中央値が高く(2.3百万ドル対1百万ドル)、復旧にかかった費用も約8倍でした。
国内でも、ITRが2025年に実施した調査(2024年以降にランサムウェア被害を受けた企業315社)で、バックアップまで暗号化されていた企業が約半数(47%)、システムを完全には復旧できなかった企業が70%でした。警察庁によると、2024年に報告されたランサムウェア被害は222件で、中小企業の被害が前年から増えています。調査の対象と時期が異なる数字なので、傾向を見るものとして読んでください。
バックアップが壊れる4つの経路
バックアップが使えなくなる経路は、大きく4つに整理できます。
| 経路 | 起きること | なぜ可能になるのか |
|---|---|---|
| 管理画面からの削除・設定変更 | バックアップの削除、保持期間の短縮、ジョブの停止 | 管理者アカウントを奪われると、正規の操作として実行できてしまう |
| 保存先の直接暗号化 | 共有フォルダ(SMB/NFS)やNAS上のバックアップファイルが暗号化される | 本番のサーバから見える場所に保存していると、端末と同じように暗号化の対象になる |
| 認証基盤の共有による乗っ取り | バックアップサーバやストレージの管理が、まとめて奪われる | ADの管理者アカウントと共通の認証で管理していると、ADが落ちた時点で一緒に落ちる |
| 汚染された状態の保存 | 感染後のデータがバックアップに入り、復元しても再び感染する | 侵入から実行までに時間があると、古い世代のバックアップにも攻撃の準備が入っていることがある |
多くの組織で見落とされやすいのが、2つ目と3つ目です。バックアップサーバをADに参加させていると、ADの管理者権限を奪った攻撃者が、そのままバックアップの管理者にもなれます。ADやIDの守りについては 【ゼロトラスト】なぜ、IAM/IDaaSによるID認証が必要なのか も参考になります。
RAIDやレプリケーションはバックアップの代わりになるか
「RAIDにしているから大丈夫」「別拠点に同期しているから大丈夫」という考えも、ランサムウェアに対しては十分ではありません。暗号化された結果も、そのまま同期されるためです。
| 仕組み | 守れるもの | ランサムウェアに対して |
|---|---|---|
| RAID | ディスクの故障 | 暗号化された内容がそのまま書き込まれる。バックアップではない(RAIDの種類) |
| レプリケーション(同期) | 機器や拠点の障害 | 暗号化や削除も相手側へ同期される |
| スナップショット | 過去の時点へのロールバック | 同じ管理者権限で削除できる構成だと、まとめて消される |
| 通常のバックアップ | 誤削除、故障、過去の時点への復元 | ネットワークから書き換えられる場所にあると、暗号化や削除の対象になる |
つまり、「コピーを取る」だけでなく、「攻撃者に届かない場所に、書き換えられない状態で持つ」ことが必要になります。次の章から、そのための原則を順に説明します。
バックアップを守る5つの原則
各社の公開資料を読み比べると、バックアップを守るための考え方は、おおむね次の5つに整理できます。製品によって呼び方や実現方法は違いますが、狙いは共通です。
| 原則 | 守るもの | 一言でいうと |
|---|---|---|
| ① コピーを分ける(3-2-1-1-0) | 機器の故障、拠点の災害、単一の保存先の全滅 | 1か所に頼らない |
| ② 不変にする(イミュータブル) | 管理者権限を奪われたときの削除・暗号化 | 保持期間中は、誰も書き換えられない |
| ③ 管理の入口を分ける | 認証情報の流用、管理サーバの乗っ取り | 本番の認証では、バックアップを触れない |
| ④ 切り離す(エアギャップ) | ネットワーク経由の攻撃全般 | 普段はつながっていない |
| ⑤ 検証してから戻す | 復元失敗、汚染データの再投入 | 戻せること、きれいなことを確かめる |
① コピーを分ける:3-2-1-1-0ルール
古くから使われている「3-2-1ルール」は、データのコピーを3つ持ち、2種類の媒体に保存し、1つは別の場所に置く、という考え方です。ランサムウェア対策では、これに「1つは不変またはオフラインのコピー」と「復旧テストでエラー0」を加えた3-2-1-1-0ルールがよく使われます。
3-2-1だけでは足りないのは、別の場所に置いたコピーでも、ネットワークから管理者として操作できれば、削除されてしまうからです。そこで「不変またはオフライン」の1つが必要になります。
② 不変にする:イミュータブル(WORM)
不変性は、設定した保持期間のあいだ、バックアップを変更・削除・再暗号化できないようにする仕組みです。一度書いたら変更できない記録方式の考え方(WORM:Write Once, Read Many)が元になっています。実現方法は、製品によって次のように分かれます。
- Linuxなどのファイルシステムの不変属性を使う。
- オブジェクトストレージの保持機能(オブジェクトロック)を使う。
- バックアップ専用の機器やソフトウェアが持つ、追記型の保存形式や保持ロックを使う。
- テープなど、書き込み後に取り外せる媒体を使う。
- モードによっては、特別な権限があれば保持期間中でも解除できます。例えばオブジェクトストレージには、特別な権限で解除できるモードと、誰も解除できないモードがあります。どのモードで使うのかは、設計で決めておく必要があります。
- 誰も解除できないモードでも、クラウドによっては、アカウントごと削除されると保護の前提が崩れることがあります。クラウドのアカウントの守りも同じくらい重要です。
- OSの不変属性は、OSの管理者権限があれば外せます。SSHの接続を閉じる、管理者の認証情報をバックアップサーバに保存しないなど、OS側の守りと組み合わせて使う製品があります。
- CISAも、不変ストレージは、コンプライアンス要件や設定ミスのコストを踏まえて、注意して使うよう案内しています。
③ 管理の入口を分ける
バックアップの管理サーバが乗っ取られても、保存先のデータは消せないようにする考え方です。実装では、次のような仕組みが使われます。
- バックアップ管理サーバと保存先を、ADや本番の認証から分離する。管理者アカウントは専用にし、多要素認証を必須にする。
- 保存先への接続に一時的な認証情報を使い、管理サーバに恒久的な認証情報を残さない。
- 保持期間の短縮やデータの削除など、重要な操作に、複数の管理者の承認(クォーラム)を求める。
- 管理画面を、インターネットや業務用のネットワークから見えない場所に置く。
これらは、「バックアップだけ別のゼロトラスト」と考えるとわかりやすいです。管理者の1つのアカウントを奪われても、バックアップ全体には届かない作りにします。
④ 切り離す:エアギャップ
エアギャップは、バックアップを本番のネットワークから切り離しておく考え方です。形は大きく3つあります。
| 種類 | 仕組み | 特徴 |
|---|---|---|
| 物理的な切り離し | テープや取り外せるディスクを、書き込みのあとに本番から外して保管する | ネットワーク経由では触れない。復旧には人手と時間がかかる |
| 運用による切り離し | 通常は通信を遮断し、複製するあいだだけ、保存先側の管理で通信路を開ける | 自動化できる。制御の権限を保存先側だけに置くことが重要 |
| 論理的な分離(クラウドなど) | 別のアカウントや別のテナントに、本番とは別の認証で保管する | 運用の手間は小さい。クラウドのアカウント管理が守りの要になる |
この切り離した保管場所は、金庫になぞらえて「Vault(ボルト)」や「サイバーボルト」と呼ばれることがあります。
⑤ 検証してから戻す:復旧テストとクリーン復旧
バックアップがあっても、戻せない、あるいは戻したら再び感染する、という失敗があります。そのため、次の2つを仕組みにします。
- 復旧テスト:バックアップから実際に復元できるかを、定期的に、できれば自動で確かめる。3-2-1-1-0の最後の「0」に対応します。
- クリーン復旧:バックアップの内容をマルウェアや異常の兆候について検査し、隔離した環境(クリーンルームなどと呼ばれます)に復元して、安全を確認してから本番へ戻す。
検査の方法は製品によって異なり、既知のマルウェアのパターンやルールによる検査、データの変化量や暗号化に特有の乱れ(エントロピー)の解析などがあります。どの方法も、すべての感染を見つけられると保証するものではありません。検査は復旧の判断材料の一つとして使い、最終的には、侵入経路の調査と合わせて判断することになります。
各社の実装に共通する守り方の種類
調べたメーカーの実装は、細かい名前や仕組みは違っても、守り方を整理すると、次の表のように分類できます。製品を比べるときの「ものさし」として使えます。
| 守りの要素 | よくある実現方法 | 確認したい点 |
|---|---|---|
| 不変性 | ファイルシステムの不変属性、オブジェクトロック、専用機器の追記型形式や保持ロック、テープ | 保持期間を誰が短縮できるか。管理者でも解除できないモードがあるか |
| 管理の分離 | 専用アカウント、多要素認証、一時的な認証情報、複数人の承認、管理画面の閉域化 | ADや本番の認証と切り離せるか。重要操作に承認を求められるか |
| 隔離 | 物理的に取り外す、通信を普段は遮断する、別のアカウントや別のテナントに置く | 通信路を開ける権限が、どちら側にあるか |
| 異常の検知 | データ変化率や暗号化の兆候の分析、マルウェアのパターンによる検査 | バックアップの取得時、保管中、復元時のどこで検査するか |
| 安全な復旧 | 復旧テストの自動化、隔離環境(クリーンルーム)への復元、安全な復元地点の特定 | 隔離環境を自前で用意するのか、サービスとして使えるのか |
メーカーによって、強みを置く要素が違います。例えば、汎用のLinuxサーバを使って不変リポジトリを作れる製品、専用の保存形式と管理API以外を外部に出さない製品、クラウド上の隔離Vaultをサービスとして提供する製品、専用機器による運用エアギャップと解析を組み合わせた製品、隔離復旧環境をクラウド上に作る機能を持つ製品などがあります。どの組み合わせが向くかは、自社の規模と運用体制で決まります。
規模別の構成例
ここからは、メーカーを特定しない形で、3つの構成例を紹介します。どれも、前の章の原則をどこまで取り入れるかの違いです。
モデルA:オンプレミス中心+クラウドの不変保管
拠点内のサーバや仮想基盤が中心の、中小〜中堅の環境を想定した構成です。既存のインフラを活かし、バックアップの保存先を不変にして、二次コピーをクラウドに置きます。
- 一次バックアップは、不変の設定をした保存先(汎用サーバに不変属性を設定したもの、または不変に対応したストレージ)へ保存する。
- 二次コピーは、保持期間を設定したクラウドのオブジェクトストレージへ送り、拠点が被害を受けても残るようにする。
- バックアップサーバはADに参加させず、専用の管理者アカウントと多要素認証で運用する。
- 残る課題は、バックアップサーバ自体が乗っ取られた場合の運用と、不変の保持期間に合わせた容量の確保。
モデルB:ハイブリッド+クラウドの隔離Vault
オンプレミスとクラウドのデータが混在し、運用の負担を減らしたい環境を想定した構成です。バックアップ基盤とは別に、クラウド上の隔離されたVaultへ、最後の安全な控えを置きます。
- バックアップ基盤は、不変の保存形式を持ち、管理画面を閉域に置き、本番とは別の認証で管理する。
- 隔離Vaultは、別のアカウントまたは別のテナントに置き、本番の認証情報ではアクセスできないようにする。
- 保持期間の短縮などの重要な操作に、複数人の承認を求められる製品もある。
- 残る課題は、クラウドのアカウントの管理と、データ量に応じた費用、復旧時にクラウドから戻す時間。
モデルC:隔離Vault+クリーンルーム復旧
止められない基幹システムや、厳しい要件のある環境を想定した構成です。本番とは別管理のVaultへ、通信路を普段は閉じた状態で複製し、検査して、有事には隔離環境で復旧を確認します。
- 複製のあいだだけ、Vault側の管理で通信路を開き、終わったらすぐ閉じる(運用エアギャップ)。
- Vault内のデータは保持ロックで不変にし、マルウェアや異常の兆候を検査する。
- 有事には、隔離復旧環境(オンプレミスまたはクラウド)へ復元し、安全を確認してから本番へ戻す。
- 残る課題は、機器や環境の追加費用、Vaultと復旧環境を運用する体制、復旧手順の訓練。
構成例の選び方
| 項目 | A オンプレ中心 | B ハイブリッド | C 隔離Vault+クリーンルーム |
|---|---|---|---|
| 向く環境 | 既存のインフラを活かしたい中小〜中堅 | 運用負担を減らしたい、クラウドを使っている | 止められない基幹システム、厳しい要件 |
| 不変性 | 不変リポジトリ+クラウドの保持機能 | バックアップ基盤+Vaultの不変コピー | Vaultの保持ロック |
| 切り離し | クラウドのアカウントで分離 | 別アカウント・別テナント | 運用エアギャップ |
| 復旧の確認 | 復旧テストが中心 | 復旧テスト+製品の検査機能 | 隔離環境での復元と検査 |
| 費用と運用の負担 | 小さめ | 中くらい(データ量で変動) | 大きめ |
いきなりモデルCを目指す必要はありません。モデルAの「不変にする」「管理を分ける」から始めて、システムの重要度に応じて、隔離やクリーン復旧を足していく進め方が現実的です。
復旧の流れ
バックアップが無事でも、復旧の順番を間違えると、再感染や二次被害につながります。一般的な流れは次のとおりです。
| 段階 | やること | 注意点 |
|---|---|---|
| ① 隔離 | 感染した端末やサーバを、ネットワークから切り離す | 電源を落とす前に、調査に必要な情報を残すかを判断する |
| ② 遮断・入替 | 侵入経路を塞ぎ、管理者の認証情報を入れ替える | ADの管理者やバックアップの管理者の認証情報も対象にする |
| ③ 地点の選定 | 感染前の時点を特定し、復元する地点を決める | 侵入から実行までに時間があるため、直近のバックアップが安全とは限らない |
| ④ 検証 | 隔離環境に復元して、マルウェアが残っていないかを確認する | 感染の準備段階のマルウェアが入っていないかも確認する(CISAも、復元前に確認するよう案内) |
| ⑤ 復旧 | ADなどの基盤から先に復旧し、重要な業務システムを優先して戻す | 復旧の優先順位は、事前に決めておく |
導入前に確認したいこと
| 確認すること | 見ておく点 |
|---|---|
| バックアップの管理認証 | バックアップサーバの認証は、ADや本番と分離されているか。管理者アカウントは専用で、多要素認証が有効か。 |
| 保存先の見え方 | バックアップの保存先が、共有フォルダ(SMB/NFS)として業務側のサーバから見えていないか。 |
| 不変性の設定 | どのバックアップが不変か。保持期間は何日か。誰が、その期間を短縮できるか。 |
| 切り離し | 本番のネットワークや認証から切り離されたコピーが、1つ以上あるか。 |
| 復旧テスト | 最後に復旧テストをしたのはいつか。復元後の確認や、マルウェアの検査をする仕組みがあるか。 |
| 容量と費用 | 不変の保持期間のあいだは、バックアップを削除できないため、容量が増える。クラウドは取り出し時の費用も確認する。 |
| 運用体制 | Vaultや復旧環境を、誰が運用するのか。復旧手順の訓練をしているか。 |
まとめ
| 項目 | ポイント |
|---|---|
| 狙われる理由 | バックアップが残っていると、身代金を払ってもらえないため、攻撃者が先に壊す |
| 壊される経路 | 管理画面からの削除、保存先の直接暗号化、認証基盤の共有、汚染された状態の保存 |
| 5つの原則 | コピーを分ける、不変にする、管理の入口を分ける、切り離す、検証してから戻す |
| 構成の選び方 | まず不変性と管理の分離から始め、重要度に応じて隔離とクリーン復旧を足す |
| 確認の軸 | 管理認証の分離、不変の保持期間、切り離したコピー、復旧テスト |
ランサムウェア対策のバックアップは、「コピーを取る」から、「書き換えられない状態で持ち、きれいなものだけを戻す」へ考え方が変わってきています。製品によって実現方法は違いますが、5つの原則のどこを、どの仕組みで満たすのかを確認すると、比べやすくなります。実際の実装は、必ずメーカーや販売元に確認してください。
参考URL
調べた時点(2026年10月)の公開情報です。最新の内容は各社の公式ドキュメントで確認してください。
被害の状況・一般的な指針
- CISA:#StopRansomware Guide
- TechRepublic:Sophos Study: 94% of Ransomware Victims Have Their Backups Targeted
- @IT:ランサムウェア攻撃被害が中小企業で増加、完全復旧できない企業が7割(ITRの調査、警察庁の統計を引用)
- Veeam:What is the 3-2-1 Backup Rule?
- AWS:Amazon S3 Object Lock(保持モードの考え方)
Veeam
Rubrik
- Rubrik:The Secure Data Layer
- Rubrik:Rubrik Cloud Vault
Cohesity
Commvault
- Commvault:Cleanroom Recovery (Isolated Recovery Environments)
- Commvault:Threat Scan
Dell Technologies
- Dell Technologies:PowerProtect Cyber Recovery: Reference Architecture
コメント