バックアップがあるだけでは復旧できない～AWS環境でランサムウェアからの復旧判断をRubrikで検証

ランサムウェア被害からの復旧では、バックアップがあれば十分とは限りません。重要なのは、攻撃の影響を受けていないデータを見極め、「どの時点のバックアップを復旧に使うのか」を判断することです。通常の障害復旧で重視されるRPO（目標復旧時点）やRTO（目標復旧時間）に加え、ランサムウェア対応では感染したデータを復旧に使わないための確認が求められます。

この課題を受け、AWS環境におけるランサムウェア対策を検討する中で、バックアップから復旧までの対応をどのように設計できるかを確認するため、Rubrikを使った検証を行いました。Rubrikは、バックアップ、復旧、データ保護、サイバーリカバリを支援するデータセキュリティ製品で、ランサムウェアなどの脅威による異常な変化の検知や、復旧候補の特定を支援します。

今回の検証では、AWS上の仮想マシン（EC2）が未知のランサムウェアに感染したシナリオを想定しました。EC2やEBS、AMI、スナップショットなど複数のリソースで構成されるAWS環境で、「異常の検知」と「クリーンな復旧候補の特定」がどのように行えるのかを確認しました。本記事では、AWSやクラウドのセキュリティ、バックアップ、インシデント対応に携わる方に向けて、製品の機能紹介だけでなく検証から見えてきた復旧判断のポイントを紹介します。また、今後の体験型PoCへの活用も見据えた検証結果をお伝えします。

未知の脅威にさらされたときの対応フェーズ

未知のランサムウェア感染に対応する際には、各フェーズで確認すべきポイントがあります。

Phase1では、まず異常に気付くことが重要です。未知の脅威では、事前にハッシュ値などのIOC（攻撃や侵害が発生した可能性を示す痕跡情報）が分かっているとは限らないため、通常時とは異なるファイル変化を捉え、インシデント対応を開始するきっかけを得る必要があります。ここでAnomaly Detectionは、バックアップデータ上の変化から異常を検知する入口として位置付けられます。

Phase2では、検知した異常に対して調査と封じ込めを行います。対象EC2の隔離や証拠保全を行ったうえでフォレンジック調査を実施し、未知だった脅威をハッシュ値などのIOCとして特定します。このフェーズで重要なのは、被害拡大を防ぎつつ、後続の影響範囲確認や復旧候補の選定に利用できる情報を整理することです。

Phase3では、復旧候補の選定と判断を行います。バックアップが存在していても、どの世代が影響を受けているのか分からなければ、安全に復旧することはできません。そこで、Phase2で特定したIOCを用いてThreat Huntsで複数世代のバックアップを横断検索し、脅威の痕跡を含む世代と含まない世代を切り分けます。その結果を、フォレンジック調査や業務影響、侵入経路の封じ込め状況と合わせて評価し、最終的なリカバリ判断につなげます。

本シナリオでは、Phase1で異常を検知し、Phase2で未知の脅威をIOCとして特定し、Phase3でそのIOCを使って復旧候補を絞り込む流れを想定しています。

※ IOC：攻撃や侵害が発生した可能性を示す痕跡情報。例えば、マルウェアのハッシュ値、ファイル名、通信先IPアドレス、ドメイン名などが該当します。本記事では、フォレンジック調査で判明したハッシュ値をIOCとして扱います。

今回の検証では、この中でも重要な要素であるPhase1の①Anomaly DetectionとPhase3の⑥Threat Huntsに着目しました。

検証①：Anomaly Detectionで未知の異常を捉える

Anomaly Detectionは、バックアップデータを利用してファイルの追加、変更、削除などの傾向を分析し、通常時とは異なる変化を検知する仕組みです。ランサムウェア感染では、多数のファイルが短時間で暗号化されるなど、通常の業務利用とは異なるファイル変化が発生するため、その変化をバックアップ世代間の差分として捉えられるかが重要になります。今回の検証では、この仕組みを確認するため、まず通常状態のファイルを用意し、一定期間にわたってバックアップを取得しました。その後、EC2内の多数のファイルを一括して暗号化し、その状態で再びバックアップを取得しました。具体的なファイル数ではなく、大量のファイルに短時間で暗号化による変更が発生した状態を再現しています。

Rubrikは、このバックアップを通常時とは異なる状態として検知し、ランサムウェアの脅威にさらされている可能性を画面上に表示します。

この検証で重要なのは、あらかじめハッシュ値などのIOC（攻撃や侵害が発生した可能性を示す痕跡情報）を登録していなくても、平常時のデータ変更傾向との差から異常を捉えられた点です。既知の脅威情報だけに依存せず、未知のランサムウェアや亜種による可能性がある異常を、バックアップデータの変化から調査の入口として提示できることを確認しました。

検証②：Threat Huntsでクリーンな復旧候補を探す

Threat Huntsは、既知となった脅威の痕跡情報を手がかりに、保管されている複数世代のバックアップを横断検索する仕組みです。フォレンジック調査などでマルウェアのハッシュ値やファイル名といったIOCが判明した後、その情報を使って、どのバックアップ世代に脅威の痕跡が含まれているかを確認できます。今回の仮想シナリオでは、フォレンジック調査によって脅威ファイルとそのハッシュ値が判明した後の工程としてThreat Huntsを利用します。

仮想シナリオでは、AWS上の仮想マシン（EC2）内に検証用ファイルを配置し、このファイルをランサムウェアに見立てています。検証用ファイルのハッシュ値をThreat Huntsへ登録し、保管されている複数世代のバックアップを横断検索しました。

その結果、対象ファイルを含む世代と含まない世代を画面上で切り分けられることを確認しました。

対象ファイルが存在しない直近のバックアップを特定できたことで、クリーンである可能性が高い復旧候補を具体的に絞り込めました。

※ シナリオ上はAnomaly Detection後にThreat Huntsとなりますが、個別に機能の検証を行ったため実際の日付は前後しています。

「検出されない」は安全確定ではない

ただし、IOCが検出されなかった世代を、そのまま安全な復旧点と断定することはできません。未登録のIOCや別の侵害痕跡が残っている可能性があるためです。Threat Huntsの結果は、クリーンである可能性が高い復旧候補を絞るための材料として扱い、ほかの監視ログ、フォレンジック調査、業務データの整合性、侵入経路の封じ込め状況などと合わせて最終判断する必要があります。

Threat Huntsがない場合、復旧候補の特定に何が必要か

Threat Huntsのようなバックアップ横断検索が利用できない場合、脅威ファイルを含まない復旧候補を見つけるには、調査対象となるバックアップを1つずつ調査環境へ戻し、対象ファイルや侵害痕跡の有無を確認する必要があります。複数のEC2があり、それぞれに複数世代のバックアップが保管されていれば、この復元と調査をEC2ごと、世代ごとに繰り返さなければなりません。

各世代について、スナップショットから調査用のEBSボリュームを作成してEC2へ接続し、フォレンジック調査を行い、ランサムウェアや関連する侵害痕跡が存在するかを判断する作業には相応の時間がかかります。対象のEC2やバックアップ世代が増えるほど確認対象も増えるため、早期復旧が求められる状況では、復旧候補を絞り込むまでの作業量が課題になります。Threat Huntsでバックアップを横断検索し、調査対象をあらかじめ絞り込めることは、この作業時間を短縮するうえで重要です。

Rubrikから得られた3つのメリット

今回の検証では、ランサムウェア発生時に「異常をどう捉えるか」「影響範囲をどう確認するか」「どのバックアップを復旧候補とするか」という一連の判断を、Rubrikを使ってどのように支援できるのか確認しました。

1. 未知の異常を検知できる

Anomaly Detectionにより、平常時のデータ変更傾向との差から、未知のランサムウェアや亜種による可能性がある異常を捉えられます。あらかじめハッシュ値などのIOCが判明していない段階でも、調査を開始する契機を得られます。

2. クリーンな復旧候補を素早く絞り込める

Threat Huntsにより、フォレンジック調査で判明したハッシュ値などのIOCを使って、複数世代のバックアップを横断検索できます。EC2やバックアップ世代を1つずつ復元して調査する前に、脅威ファイルを含む世代と含まない世代を切り分けられるため、クリーンである可能性が高い復旧候補を短時間で絞り込めます。

3. 異常検知から復旧判断までを同じ基盤上でつなげられる

Rubrikでは、バックアップを単なる保管物ではなく、異常の検知、影響範囲の確認、復旧候補の選定に利用できる情報源として扱えます。Anomaly Detectionで異常を捉え、Threat Huntsで影響範囲と復旧候補を確認することで、調査からリカバリ判断までを連続した運用として設計しやすくなります。

画面の情報を復旧判断へつなげる

仮想シナリオでは、Anomaly Detectionの通知がインシデント対応を始める契機となり、フォレンジック調査によって未知だった脅威がIOC（ハッシュ値）という検索可能な情報へ変わります。その情報をThreat Huntsへ引き継ぐことで、過去のバックアップのどこまで影響が及んでいるかを確認し、復旧候補を絞り込めます。

例えば、12日、13日、14日のバックアップがあり、13日と14日では対象ファイルが検出され、12日では検出されなかったとします。この場合、担当者は12日の世代を最初の復旧候補とします。ただし、Threat Huntsで対象ファイルが検出されなかったことだけを根拠に本番復旧を決めるのではありません。フォレンジック調査の結果、AWSログから確認した攻撃の時系列、認証情報や侵入経路の封じ込め状況、12日以降に失われる業務データの量を合わせて評価します。

条件を満たすと判断した後は、候補データを隔離された環境へリストアし、ファイルが意図したとおりに利用できるか、欠損や破損がないか、追加の不審な挙動がないかを確認します。その結果をインシデント対応責任者や業務部門と共有し、本番環境への復旧可否を決定します。この一連の流れにより、画面上の検索結果が、単なる検出情報ではなく、復旧候補の選定、追加確認、本番復旧の意思決定へつながります。

実運用やPoCへの適用可能性

今回の検証により、Anomaly Detectionによる異常の発見と、Threat Huntsによる影響範囲の確認・復旧候補の絞り込みは、実際のインシデント対応でも活用できそうだと確認できました。特に、平常状態の学習、異常の再現と検知、IOCの特定、バックアップの横断検索、候補世代の選定、隔離リストア、業務確認という一連の手順をPoCやリカバリ訓練として体験すれば、製品機能だけでなく、自組織の役割分担や判断基準の不足も可視化できます。

また、未知の異常をAnomaly Detectionで捉え、調査で判明したIOCをThreat Huntsへ登録し、クリーンな復旧候補を特定するところまでを体験できるPoCやリカバリ訓練を組み込むことを検討しています。現時点では構想段階であり、具体的な提供内容を確約するものではありません。

おわりに

今回の検証で得た一番の学びは、ランサムウェアからの復旧には、バックアップの取得に加えて、異常の発見から影響範囲の確認、クリーンな復旧候補の特定を一連の流れとして設計する必要があるということです。Anomaly Detectionでは、通常状態との差から未知の異常を捉えられることを確認しました。Threat Huntsでは、フォレンジック調査により既知となったIOCを基に複数世代のバックアップを横断し、対象ファイルが存在しない復旧候補を具体化できました。

もちろん、Anomaly Detectionの検知やThreat Huntsの未検出結果だけで、安全な復旧点を自動的に確定できるわけではありません。それでも、未知の異常を捉える段階から、既知の脅威情報を使ってクリーンな復旧候補を探す段階までを同じバックアップ基盤上でつなげられることは、インシデント対応における大きな価値です。皆さんの環境でも、「バックアップがあるか」だけでなく、「異常をどう見つけ、どの画面を見て、何を根拠に復旧を判断するか」まで確認できているでしょうか。

プロフィール