はじめに
第1回では、バックアップそのものを守る「隔離」を扱いました。イミュータブル化と論理エアギャップによって、バックアップが削除・改ざんされるリスクは大きく下げられます。AWS Backup ＋ LAG ボールトで強固な環境を作ることで、対策として十分だという印象を持った方もいるかもしれません。しかし、ランサムウェア対策の本質的な難しさは、実はここから始まります。
「バックアップが削除されないように守る」ことと、
「バックアップの中身が安全である」ことは、
まったく別の問題です。
ランサムウェアは、感染に気づかれるまでの潜伏期間中も、正常に動作しているように見せかけながら環境内に留まります。その間もバックアップは通常どおり取得され続けるため、マルウェアが混入したバックアップ、あるいは暗号化・大量削除された後のデータが、そのままイミュータブルなストレージに保存されてしまいます。
攻撃者がバックアップの削除を試みても、イミュータブル設定によってそれ自体は防げます。しかし残るのは、「削除はされなかったものの、安全に復旧できるクリーンな状態かどうか分からない大量のバックアップ」です。
そこで本稿では「どのようにクリーンなバックアップを特定するか」について扱います。
WAFのベストプラクティス：サイバーレジリエンスに関する考慮事項
第1回で引用した REL09-BP02 の中で、サイバーレジリエンスに関する考慮事項には、イミュータブル化・論理的隔離に続く観点として、次のように定められています。
「AWS Backup Restore Testingを使用してバックアップの整合性を定期的に検証し、バックアップが破損しておらず、サイバーインシデント後に正常に復元できることを確認します。」
— REL09-BP02 Secure and encrypt backups
「破損していないか、復元できるか」という点に注目すると、単にリカバリ可能なバックアップであること、とも考えられます。しかし、ランサムウェア対策では、それに加えて「バックアップにマルウェアが混入していないか」「暗号化や大量削除された後のバックアップではないか」という安全性が重要になります。
バックアップは正常に取得・復元できても、その中身に脅威が含まれていれば、業務再開のために利用することはできず、リストアした瞬間に再感染してしまうリスクもあります。
AWSでの実装ポイント
AWS Backup Restore Testing（復元テスト）
まず、先ほどの WAF にも明記されている AWS Backup Restore Testing を紹介します。この機能を利用することで、バックアップの復元可能性を定期的に検証することが可能です。オプションの「Restore testing validation」を組み合わせることで、復元テストのジョブが COMPLETED になったタイミングで EventBridge 経由で Lambda 等を呼び出し、任意の検証ロジックを実行することができます。
例えば、Amazon GuardDuty Malware Protection の On-demand malware scan を API 経由で呼び出す構成を組み、復元可能性のテストとマルウェアスキャンを組み合わせることができます。なお、現在この機能の対象は EBS ボリューム、S3 のみとなります。EFS/FSx 等には対応しておりませんので、必要な場合はサードパーティ製のスキャンツールを実行するような検証ロジックを組み込む必要があります。
また、マルウェアスキャンには相応の時間がかかることが想定されるため、スキャン完了までの時間も考慮して復元したリソースを保持できる期間（最大168時間＝7日）を設計しておく必要があります。その間の復元リソースの保持コストも増えるため、「検証を厚くするほど、コストと時間がかかる」というトレードオフを認識しておく必要があります。
Amazon GuardDuty Malware Protection for AWS Backup
前述の Restore Testing を活用してマルウェアスキャンを行い、バックアップの正常性を確認する方法がありますが、万が一マルウェアが混入していた場合、再度リストア→検証のステップが必要となり、トライアンドエラーの繰り返しのために長時間を要する可能性があります。このリスクを回避するためのソリューションのひとつとして、2025年11月に Amazon GuardDuty Malware Protection for AWS Backup が登場しました。AWS Backup のバックアッププランで「マルウェア保護」を有効にすることで、バックアップジョブが完了するたびに GuardDuty の StartMalwareScan API が呼び出され、スキャンが行われるようになります。
図1：AWS Backup バックアッププランでのマルウェア保護設定
スキャンの方式には、フルスキャン／増分スキャンを選択することができます。増分スキャンは直近のベースポイントとの増分のみを対象とするため、高速かつ低コストになりますが、認識しておくべき注意事項があります。GuardDuty の脅威情報データベースが更新され、新しいマルウェアシグネチャが追加された場合、そのマルウェアが増分に含まれない既存データ（変更がなく、かつこれまでクリーン判定だった部分）に潜んでいたとしても、増分スキャンでは検知されないということになります。
また、シグネチャ更新以前に取得済みの過去のスナップショットに新しいマルウェアがすでに混入していたという可能性も考えられます。過去のスナップショットに対して自動的に再スキャンはされないため、脅威が検知された場合には、過去のリカバリポイントに対しても on-demand スキャンを実行することを推奨します。
この機能は、後述する Rubrik の Threat Monitoring 相当の動きを、AWSネイティブで実現するものと言えます。誤ってマルウェアが混入しているバックアップを復元してしまうというリスクや、リカバリ後のスキャンのトライアンドエラーの繰り返しを未然に防止するための重要な機能です。
Rubrik による強化
Amazon GuardDuty Malware Protection for AWS Backup によって、クリーンなバックアップを特定する機能が強化されましたが、実はまだ不十分です。近年は、認証情報を奪って正規ログインし、正規のコマンドで暗号化や大量削除を行うマルウェアフリー攻撃（※1）が増加しており、このような攻撃にも対応できるような備えが必要となります。また、監視をすり抜けた未知の脅威情報が、攻撃後のフォレンジック調査によって発見されることもあります。そのような新規に発見された脅威がバックアップに含まれていないかどうかを検知できる能力も重要となります。
Rubrik では、これらの脅威に対応し、クリーンなリカバリポイントの特定に役立つ3つの分析機能を提供しております。
※1 CrowdStrikeの 2026 Global Threat Report によると、2025年に検知された攻撃の82％はマルウェアフリーでした。
なお、ここから紹介する Rubrik の分析機能は、GuardDuty で監視可能な EC2・EBS・S3 の他に、EFS/FSx、EKS にも対応しております。
Threat Monitoring：既知の脅威検出
この機能は、Amazon GuardDuty Malware Protection for AWS Backup と同様にバックアップに含まれるマルウェアを検出します。バックアップを取得するたびに、脅威情報データベース（Rubrik 独自の情報に加え、Google Mandiant、CloudStrike との連携を含む）と照合し、既知の脅威がバックアップに混入していないかを継続的に監視します。これは、「本番環境では検知されずにすり抜けてしまった」「特権が奪われ EDR が停止されてしまい、検知が遅れてしまった」といったケースに対する二重の防御としても有効です。検出されたマルウェアは、誤って一緒にリカバリされないよう検疫（隔離）することができます。
Threat Monitoring と Amazon GuardDuty Malware Protection for AWS Backup との特徴的な違いとして「新しい脅威情報が更新された際の挙動」があります。Rubrik では、バックアップ取得時に各ファイルのハッシュ値をあらかじめデータベース化しているため、新しい脅威情報が更新されると、過去分を含むすべてのスナップショットに対応するハッシュデータベースを数秒〜数分で高速スキャンし、脅威に一致するスナップショットを即座に特定することができます。例えば、3 日前に混入した脅威が脅威情報の更新によって新たな脅威と判明した場合においても、過去のバックアップを含めて検出することが可能です。
これに対し、Amazon GuardDuty Malware Protection for AWS Backup では、脅威情報が更新された場合に自動でスキャン対象となるのは、バックアップ実行時の最新のみとなります。過去に遡って感染有無を確認するには、該当する過去のバックアップ期間に対して個別に on-demand スキャンを実行する必要があり、環境の規模によっては相応の時間を要します。
図2：新しい脅威情報更新時のスキャン範囲の違い
Anomaly Detection：異常の起点を特定
ここからは AWS ネイティブでは現状カバーされていない分析機能になります。Rubrik では、日々のバックアップデータのトレンドを機械学習で監視しており、暗号化・大量削除・大量変更・大量追加といった、通常のトレンドから外れた異常な状態をファイルレベルで検出します。これにより「いつのバックアップまでは使えて、どこからは使えないか」という異常の起点を特定することができます。
図3：Anomaly Detection による異常トレンド分析
Anomaly Detection では、バックアップスナップショットのファイルのメタデータのトレンド分析とファイルのエントロピー解析を組み合わせて、「実際のデータの変化状況」を分析します。これは、マルウェアフリー攻撃の検知にも有効です。また、一般的なふるまい検知では攻撃者の挙動を監視するため、誤検知が多いという課題を耳にすることも多いと思います。一方、この機能では実際のデータの変化状況を監視しているため、誤検知は極めて少ない仕組みになっています。
Threat Hunting：未知の脅威スキャン
AI の発展に伴い、新たな脅威は日々急増しています。このような背景もあり、Threat Monitoring の脅威情報データベースに登録されていない未知の脅威が環境内に潜んでいる可能性を考慮する必要があります。こうした未知の脅威が、フォレンジック調査によって新たに発見されることがあります。新たに判明した脅威のファイルハッシュ値を用いることで、過去のバックアップ群に対して Turbo Threat Hunting による高速スキャンを実行することができます。これは、Threat Monitoring の紹介で記載させていただいた内容と同様、ハッシュデータベースに対してスキャンを行う仕組みであり、数万件のスナップショットであっても数秒〜数分でスキャンが完了します。
フォレンジック調査によって新しい脅威情報が繰り返し報告されることは珍しくありませんが、そのたびに高速に再スキャンを行うことができるため、RTO に影響を与えることなく継続的なスキャンが可能です。
RUBRIK AI の活用とランサムウェアレスポンスチーム
ここまでの分析機能によりクリーンなリカバリポイントを特定することができますが、調査をさらに簡易かつ迅速にするために RUBRIK AI を活用することができます。RUBRIK AI は、お客様環境の分析結果や各種ログを参照し、ランサムウェア被害が疑われるワークロードを特定するとともに、クリーンなリカバリポイント候補を対話形式で提示します。
【RUBRIK AI との対話例】
運用管理者「ランサム被害を受けている EC2 をリストアップしてください。」
RUBRIK AI「10 台の EC2 で異常を検知しています。」
運用管理者「クリーンな復旧ポイントを特定してください。」
RUBRIK AI「9月11日 午前7時以前のスナップショットには脅威の痕跡がありません。」
RUBRIK AI「----- クリーンなスナップショットの一覧を表示 —--」
しかし、「AI の分析結果を信用して本番環境にリカバリするのは不安」というお客様も多くいると思います。Rubrik には「ランサムウェアレスポンスチーム（RRT）」という専門部隊があり、追加コスト不要で標準サポートに含まれたサービスです。有事の際には RRT と連携し、安心して復旧作業に取り組めるサポート体制を整えています。
まとめ
第1回で扱った「バックアップの隔離」だけでは、ランサムウェア対策として十分ではありません。攻撃者によるバックアップの削除を防ぐことができたとしても、その中身にマルウェアや暗号化されたデータが混在している可能性が残るためです。
AWS ネイティブの Amazon GuardDuty Malware Protection for AWS Backup は、バックアッププランに組み込むだけで既知の脅威を自動検知できる有効な一次防御になりますが、マルウェアフリー攻撃への対応や、未知の脅威に対するハッシュ値を指定したカスタムスキャンによる調査までは現状カバーできておりません。
Rubrik では、Threat Monitoring、Anomaly Detection、Threat Hunting の3つの分析機能でこれらのギャップを埋め、「クリーンなリカバリポイントの特定」を実現します。さらに、RUBRIK AI による調査の迅速化と、ランサムウェアレスポンスチームによる有事の際の専門家による支援も標準で提供しています。
次回は、こうして特定したクリーンなリカバリポイントから、WAFのベストプラクティスに沿ってどのように復旧するのか、ベストプラクティスを解説します。