はじめに
ランサムウェア対策について調べていると、「定期的にバックアップを取得することが重要」という説明をよく見かけます。
確かにバックアップがあれば、ランサムウェアによってデータが暗号化されても、以前の状態に戻せる可能性があります。
しかし、バックアップそのものが削除されたり、正常なデータが残っていなかったりする場合はどうなるのでしょうか？
2026年9月28日には、AWSがバックアップを論理的に隔離・保護する「Logically Air-Gapped Vault」の対応サービスを拡張しました。
そこで今回は、バックアップがあっても復旧できないケースと、ランサムウェア対策として何を考慮すべきなのかを整理してみます。
※本記事は2026年10月時点の公開情報をもとにしています。
1. バックアップがあっても復旧できない？
ランサムウェアはバックアップも攻撃対象にする
ランサムウェアは、データを暗号化して利用できなくするなどの攻撃を行うマルウェアです。
近年はデータを暗号化するだけでなく、情報を盗み出し、公開をちらつかせて金銭を要求するケースもあります。
バックアップが残っていれば、暗号化されたデータを復元できる可能性があります。しかし、攻撃者がバックアップの管理権限まで取得していた場合、バックアップ自体が削除・暗号化されるおそれがあります。
米国のCISAも、ランサムウェア対策としてオフラインバックアップの保持と定期的な復元テストを推奨しています。
バックアップがあっても問題になるケース
例えば、次のような状況が考えられます。
| 状況 | 想定される問題 |
|---|---|
| バックアップも削除された | 復元するデータがなくなる |
| 感染後のデータしか残っていない | 正常な状態に戻せない |
| 復元手順を確認していない | 復旧に時間がかかる |
| データが外部に流出した | 復元しても情報漏えいは解決しない |
つまり、バックアップはデータを復元するための対策であり、攻撃そのものや情報漏えいを防ぐ対策ではないということです。
2. バックアップを守るためには何が必要？
イミュータブルバックアップとは？
バックアップを保護する方法の一つに「イミュータブルバックアップ」があります。
イミュータブル（Immutable）は「変更できない」という意味で、一定の保存期間中、バックアップの変更や削除を制限する仕組みです。
例えば、攻撃者がバックアップの管理権限を取得しても、適切に設定された変更不可のバックアップであれば、保存期間中の削除を防げる場合があります。
ただし、正常なバックアップが作成されていなかった場合まで解決できるわけではありません。
2026年9月：AWSがバックアップの隔離機能を拡張
AWSは2026年9月28日、「Logically Air-Gapped Vault」がAmazon FSx for NetApp ONTAPに対応したと発表しました。
これはAWS Backupにおいて、バックアップを論理的に隔離し、変更や削除から保護するための仕組みです。
主な特徴は以下のとおりです。
- 変更・削除からの保護： バックアップは標準でロックされる
- 論理的な隔離： AWSアカウントを分けたバックアップ保管などに対応
- 復元への対応： 他のアカウントと共有し、直接復元することも可能
なお、論理的な隔離は、ネットワークから完全に切り離す物理的なオフライン保管とは異なります。
今回のAWSの発表からも、バックアップは単に保存するだけでなく、攻撃者に操作されにくい状態で保管することが重要だと分かります。
参考：AWS公式：Logically Air-Gapped Vaultの対応拡張
3. 実務では何を考慮する必要がある？
① バックアップの保存先と権限
本番システムとバックアップが同じ管理権限に依存している場合、管理者アカウントの侵害によって双方が影響を受ける可能性があります。
そのため、保存先の分離やアクセス権限の制限が重要です。
また、バックアップの保存先を複数用意する「3-2-1ルール」という考え方もあります。
これは、データを合計3つ保持し、2種類の媒体に保存して、1つを別の場所に保管するという基本的な考え方です。
ただし、これだけで削除や改ざんを防げるわけではないため、イミュータブル化などと組み合わせることが重要です。
② どの時点まで戻せるのか？
例えば、1日1回バックアップを取得している場合、障害の発生時刻によっては最大で約1日分のデータが失われる可能性があります。
このように、どの時点までデータを戻せるかを示す目標を「RPO（目標復旧時点）」といいます。
一方、システムを何時間以内に復旧させるかという目標が「RTO（目標復旧時間）」です。
| 指標 | 考えること |
|---|---|
| RPO | どこまでのデータ損失を許容するか |
| RTO | どれくらいの停止時間を許容するか |
バックアップの取得頻度や復旧方法は、これらの目標に応じて設計する必要があります。
③ 実際に復旧できるか確認する
バックアップが正常に取得されていても、復元に失敗する可能性があります。
例えば、復旧先の環境が用意できない、必要な設定情報が不足している、復元に想定以上の時間がかかるといったケースです。
そのため、定期的な復元テストが重要になります。
AWS Backupにも、バックアップからの復元を定期的に実行し、所要時間などを確認できる機能があります。
さらにランサムウェアの場合は、復元するデータや環境が安全か確認しないと、復旧後に再び感染するおそれもあります。
「バックアップを取得できているか」だけでなく、「安全な状態に復旧できるか」まで確認する必要があるということです。
まとめ
今回は、バックアップがあってもランサムウェア被害から復旧できないケースと、運用上の注意点を整理してみました。
特に重要だと感じたのは、次の3点です。
- バックアップ自体も攻撃対象になるため、変更・削除から保護する必要がある
- 保存先やアクセス権限だけでなく、RPO・RTOを考慮した設計が重要
- バックアップの取得と、実際に復旧できることは別の問題
また、バックアップはデータの復旧には役立ちますが、情報漏えいやランサムウェアへの感染そのものを防ぐことはできません。
そのため、アクセス制御や脆弱性対策など、ほかのセキュリティ対策と組み合わせる必要があります。
今回調べてみて、バックアップ運用では**「取得・保護・復元」の3つをセットで考えることが重要**だと感じました。
今後はバックアップの取得状況だけでなく、障害時にどこまで復旧できるのかという視点も意識していきたいと思います。