ブログ

マルウェア対策としてのバックアップ実践

はじめに

皆様、こんにちは。
ターンアンドフロンティアエンジニアの小寺です。

突然ですが皆様は業務システムなどのランサムウェア対策はされているでしょうか。昨今名だたる企業がランサムウェアの被害に遭い、その損失は計り知れず、もはや災害レベルと言っても差し支えないのではないでしょうか。

ランサムウェア被害に遭われた企業様でもバックアップは当然取っていたと想定されますが、それでも復旧に時間を要したのは、昨今のランサムウェア攻撃にバックアップが含まれる傾向があるからかもしれません。

そこで今回は AWS Backup を軸に、ランサムウェア対策として定番になってきた 3-2-1-1-0 バックアップルール を AWS 上でどう実装するかをまとめます。

さらに今回は「バックアップ自体が安全か?」という、もう一段深い論点——バックアップ内に潜む休眠マルウェア(復元した瞬間に再び動き出す系) への対策として、Amazon GuardDuty Malware Protection for AWS Backup(以下、Malware Protection for Backup)も組み込みます。バックアップは“取る”だけでなく、“守る”“クリーンさを担保する”“戻せることを証明する”までがセット、という観点で整理していきます。

3-2-1-1-0ルールとは?

3-2-1 は昔からあるバックアップの基本形です。そこに、近年の脅威(ランサムウェアや内部不正、鍵破壊、バックアップ削除)を踏まえた「不変コピー」と「検証」を加えたのが 3-2-1-1-0 です。

  • 3(3つのコピー):原本 + バックアップを2つ以上
  • 2(2種類のメディア/系統):同時に壊れない・同時に侵害されない“別系統”に分ける
  • 1(1つはオフサイト):別リージョンや別拠点など、災害・広域障害でも生き残る場所へ
  • 1(1つはイミュータブル/エアギャップ):侵害されても削除・改ざんされない保管先を持つ
  • 0(検証エラー0):復元テストで「戻せる」を継続的に確認する(そして“クリーンな復元点”を選べる状態にする)

ここで重要なのは、0(検証) を「ジョブが成功した」ではなく、「復元できた」「復元先が安全(少なくともマルウェアを持ち込まない)」まで含めた“実運用のゴール”として定義することです。バックアップに休眠マルウェアが混ざっていたら、復元は“成功”しても結果は最悪になり得ます。だからこそ、後段で Malware Protection for Backup を組み込む価値があります。

AWSでの実現方式

ここから、3-2-1-1-0 の各要素を AWS Backup + Malware Protection for Backup でどう満たすかを、実装パターンとして解説します。

まずは全体の構成図をご紹介します。

1) 「3つのコピー」を作る:同一リージョン + 別アカウント + 別リージョン

まずはコピー戦略です。王道は次の3段です。

  • 同一リージョンの標準Vault:RTO重視(早く戻す)
  • 別アカウントのVault(バックアップ専用アカウント):侵害の波及を抑える(本番権限を奪われても全部消されにくい)
  • 別リージョンのVault:災害・広域障害に備える(オフサイト)

AWS Backup の機能で、作成した復旧ポイントを コピーアクション で別アカウント/別リージョンへ自動転送する事が可能です。

2) 「2種類のメディア/系統」:標準Vault系統と“隔離系統”に分ける

クラウドで“媒体”と言うと分かりにくいですが、実務では 同時に侵害されない系統分離 と捉えるとよいかと思います。

例えば:

  • 標準のバックアップVault(日次・週次など運用しやすい)
  • 隔離されたVault(後述の Vault Lock / logically air-gapped vault)

この“2系統”があると、普段は標準Vaultで素早く復旧し、最悪時は隔離Vaultから“最後の砦”として復旧という設計ができます。

3) 「1つはオフサイト」:クロスリージョンコピー

オフサイトは クロスリージョン バックアップと捉えるとよいでしょう。

多数サーバがある場合、全部送るとコストが膨らみがちなので、以下のようにメリハリを付けることも可能です。

重要システム:日次で同一リージョン及び別リージョンへ
重要度が低い:週次だけ別リージョンへ

4) 「1つはイミュータブル/エアギャップ」:Vault Lock と logically air-gapped vault

ランサムウェア対策で一番“効く”のがここです。

A. Vault Lock(WORM的に削除・変更を縛る)

AWS Backup Vault Lock を使うと、保持期間内の復旧ポイントを削除・変更しにくくできます(WORMの考え方)。
「バックアップを消して復旧不能にする」タイプの攻撃に強くなります。

B. logically air-gapped vault(論理エアギャップ)

さらに隔離を強めたい場合は logically air-gapped vault を検討します。標準Vaultとは別系統として保管し、復旧時の取り回しも含めて“最後の砦”を作る発想です。

5) ここからが追加要素:休眠マルウェア対策として Malware Protection for Backup を組み込む

3-2-1-1-0 を作っても、「復元したら感染が再発した」という事故は起き得ます。理由はシンプルで、感染時点のデータがバックアップに混ざっているからです。しかもランサムウェアは侵入後すぐ暗号化せず、休眠して横展開・権限奪取・バックアップ削除を狙うこともあります。

このギャップを埋めるのが Malware Protection for Backup です。

5-1) Malware Protection for Backup で何ができる?

Malware Protection for Backup は、AWS Backup で保護されたリソース(例:EBS スナップショット、AWS Backup が作った EC2 AMI、S3 リカバリポイントなど)をスキャンし、バックアップデータ内のマルウェア混入の可能性を検出します。バックアップ作成/更新のタイミングでスキャンし、環境に復元する前に怪しいバックアップを見つけることが狙いです。

また、標準Vaultだけでなく、Vault Lock でロックされた(不変の)Vaultの復旧ポイントも対象になり得る点は、3-2-1-1-0 と相性が良いです。

5-2) どう動く?(自動スキャン / フル・増分 / オンデマンド)

AWS Backup 側でマルウェアスキャンを有効化すると、バックアップが成功した後に AWS Backup が GuardDuty の StartMalwareScan を呼び出してスキャンを開始します。

スキャンはバックアップデータを読み取り・復号して中身を検査し、バックアップ内容自体を書き換えるものではありません。

スキャン方式は フルスキャン と 増分スキャン を使い分けられます。増分を選ぶと、最初はフルで、その後は変更分中心にスキャンして効率化(コスト/時間の最適化)する考え方です。
さらに、復元前の確認や新しい脅威シグネチャ登場後の再チェック用途で、オンデマンドスキャン も可能です。

5-3) 3-2-1-1-0 の「0」を“本物”にする:復元テスト × クリーン復旧点

Malware Protection for Backup のいい点は、3-2-1-1-0 の「0」を“復元テストが通った”だけでなく、「クリーンな復元点を選んで戻した」 まで引き上げられる点です。

つまり運用としては、

  • バックアップ取得(複数コピー)
  • 自動スキャン(増分推奨)
  • 定期的に復元テスト

というループを回すと、「戻せる」だけでなく「戻した瞬間に再感染しない」確度を上げられます。スキャンの非同期性によりバックアップウィンドウを延ばしにくい、という観点も運用上ありがたいポイントです。

6) コストについて

Malware Protection for Backup は スキャンしたバックアップデータ量(GB/月) をベースに GuardDuty 側で課金され、AWS Backup 側のストレージ費用などは別建てです(無料枠はない旨も明記されています)。

全システムを対象に単純にフルスキャンをすると、高額になるやすいため、対象を絞ったり、増分スキャンを利用したりと色々と組み合わせる方がいいと思います。

例えば以下の運用例もありかと思います。

  • 重要システムのみ 自動スキャン(増分)
  • それ以外は「月次のオンデマンド」や「復元前オンデマンド」でスキャン
  • DRリージョン側はコピー保持中心、スキャンは“復元元リージョン”で回す(同一リージョン内のバックアップが対象という制約があるため)

まとめ

いかがでしたでしょうか?

今回は、AWS Backup で 3-2-1-1-0 を形にするだけでなく、バックアップ内に潜む休眠マルウェア まで見据えて GuardDuty Malware Protection for AWS Backup を組み込み、「復元できる」から「クリーンに復元できる」へ一段引き上げる構成として整理しました。バックアップのコピー戦略(3/オフサイト1)と、削除・改ざん耐性(不変1)に加えて、スキャン結果を EventBridge で運用に流し込み、復元テストと組み合わせて“0”を実効化するのがコツです。

もちろん、フルセット(マルチアカウント + マルチリージョン + 不変/エアギャップ + 自動スキャン + 定期復元テスト)はコストも増えますが、すべてを実現するコストが予算的に難しい場合は一部分を取り入れることも可能です。

元記事発行日: 2026年02月18日、最終更新日: 2026年01月29日