ランサムウェア対策のバックアップは「何世代残すか」だけでは設計できない

ランサムウェア対策として、バックアップとリストアの仕組みを確立することは重要です。本番環境が暗号化された場合でも、正常な時点のデータをバックアップから復元できれば、被害を抑えながら業務を再開できます。

しかし、単にバックアップを取得しているだけでは不十分です。ランサムウェア対策では、攻撃や侵害に気付くまでに時間がかかる可能性を考慮し、複数の世代を保持する必要があります。さらに、その世代を実際に保存できるだけの容量が確保されていなければなりません。

バックアップポリシーとして 30 日分を設定していても、保存先の容量が足りなければ、30 日分を確実に保持できるとは限りません。この記事では、ランサムウェア対策のバックアップを、世代数、保存容量、変更量、容量不足時の動作から整理します。

ランサムウェア対策では世代管理が重要になる

バックアップが最新の 1 世代しか存在しない場合、そのバックアップ自体が既に侵害後の状態である可能性があります。ランサムウェアへの感染やアカウント侵害が発生してから、実際に異常を検知するまでに数日から数週間かかることがあります。その間もバックアップ処理は継続されます。

結果として、次のような状態が正常なバックアップとして保存される可能性があります。

• 暗号化されたファイル。
• 改ざんされたデータ。
• 不正な設定が追加されたサーバー。
• 攻撃者が作成したアカウント。
• 侵入経路が残ったシステムイメージ。
• マルウェアが混入した状態の仮想マシン。

最新世代しか保持していない場合、侵害前の状態へ戻ることができません。そのため、バックアップでは複数の復旧時点を残し、状況に応じて正常だった時点を選択できるようにする必要があります。

一般的な世代管理の例

一般論として、次のような保持ポリシーが考えられます。日次、週次、月次、年次で異なる世代を残す GFS 型の考え方です。

区分	保持期間の例	主な使いどころ
日次バックアップ	直近 30 日	直近の障害、誤操作、短期的な復旧
週次バックアップ	直近 3 か月	発見が遅れた侵害や改ざんへの対応
月次バックアップ	直近 1 年	監査、長期的な復元、過去時点の確認
年次バックアップ	数年間	法的要件、長期保管、限定的な復元

直近の障害や誤操作には日次バックアップを使用し、侵害の発見が遅れた場合には週次や月次のバックアップまで遡ります。ただし、この期間はあくまで保持ポリシーの例です。「日次 30 日」と設定しただけで、30 日分が確実に保存されるわけではありません。

保持ポリシーと保存可能期間は別である

バックアップの設計では、保持したい期間と、実際に保持できる期間を分けて考える必要があります。

項目	意味	決まり方
保持したい期間	業務、セキュリティ、監査などの要件に基づいて決める期間	復旧要件、監査要件、侵害検知までの想定期間
実際に保持できる期間	バックアップ先の容量や方式から決まる技術的な上限	保存容量、変更量、増加率、圧縮、重複排除、イミュータブル期間

保持ポリシーが 30 日でも、保存先が 20 日分で満杯になる場合、30 日保持という要件は実現できません。設定上の保持期間と、物理的に保証できる保持期間は別物です。

バックアップ容量は対象データ量だけでは決まらない

必要なバックアップ容量を考える場合、最初にバックアップ対象のデータ量が必要です。しかし、対象データ量だけでは容量を計算できません。少なくとも、次の情報が必要になります。

確認項目	容量に与える影響
バックアップ対象データ量	初回フルバックアップの基準になる
日々の変更量	増分バックアップの容量を左右する
データ増加率	将来のフルバックアップ量が増加する
フル、差分、増分の方式	各世代の保存量が変わる
フルバックアップの取得頻度	長期的な容量消費に影響する
圧縮率	データの種類によって削減効果が異なる
重複排除率	同一ブロックが多い環境ほど効果が高い
イミュータブル期間	容量不足でも古いデータを削除できない
合成フルの方式	合成処理やマージに作業領域が必要になる
リストア試験	復元先や一時領域の容量も必要になる

単純化すると、必要容量は「初回フルバックアップ、保持期間中の変更データ、週次・月次・年次の長期保存データ、メタデータや作業領域、容量余裕」の合計として考えます。ただし、実際の値はバックアップ製品の保存方式によって大きく変わります。

データ量と世代数の単純な掛け算では計算できない

対象データが 10 TB あり、日次バックアップを 30 世代保持する場合でも、必ず 300 TB 必要になるわけではありません。増分バックアップを使用し、日次変更率が 2% であると仮定すると、単純計算では次のようになります。

項目	計算	容量
初回フルバックアップ	10 TB	10 TB
日次増分	10 TB × 2% × 29 日	5.8 TB
単純合計	10 TB + 5.8 TB	約 15.8 TB

実際には、圧縮、重複排除、メタデータ、合成フル、保存形式などが影響するため、この計算だけで容量を確定することはできません。それでも、対象データ量と変更量を把握しなければ、必要容量を概算することすらできない点は変わりません。

ランサムウェア発生時には変更量が急増する

通常時の日次変更率が 1% や 2% であっても、その値だけを使って容量を設計するのは危険です。ランサムウェアが大量のファイルを暗号化した場合、バックアップシステムから見ると、多数のファイルやブロックが変更された状態になります。

通常時には 200 GB 程度だった増分バックアップが、攻撃発生後には数 TB へ増える可能性があります。さらに、暗号化されたデータが新しい世代として保存され、イミュータブル設定により過去世代を削除できず、容量不足によって新しいバックアップが失敗することもあります。

異常時に起きること	容量設計への影響
暗号化されたデータが新しい世代として保存される	増分容量が急増する
イミュータブル世代を削除できない	容量不足時に退避できない
新しいバックアップが失敗する	復旧ポイントが増えなくなる
バックアップの再実行が必要になる	追加容量が必要になる
合成フルやマージ処理が止まる	バックアップチェーンの保守に影響する

ランサムウェア対策としてバックアップを用意していても、ランサムウェアによる大量変更が原因でバックアップ領域が枯渇するという矛盾が発生します。そのため、容量設計では平常時の変更量だけでなく、異常時の変更量も考慮する必要があります。

容量不足時の動作も確認する

バックアップ先が満杯になった場合の動作は、製品や設定によって異なります。容量不足時の挙動を確認していないと、保持ポリシーが守られるのか、バックアップジョブが止まるのか、古い世代が消えるのかを判断できません。

容量不足時の動作	ランサムウェア対策上の注意点
最も古い世代を自動削除する	侵害前の世代を失う可能性がある
保持期間内でも削除対象になる	設定値と実際の保持期間がずれる
新しいバックアップジョブが失敗する	復旧ポイントが更新されなくなる
合成フルやマージ処理だけが失敗する	後からバックアップチェーンに影響が出る
イミュータブル世代を削除できない	書き込み不能になりやすい
バックアップチェーン全体が不整合になる	復元試験で初めて問題が分かる可能性がある

特に注意が必要なのは、容量不足を解消するために古い世代から削除される構成です。ランサムウェア対策では、侵害前の古い世代に価値があります。古い世代を自動的に削除して最新世代を保存する動作は、通常の運用では合理的でも、ランサムウェア対策としては逆効果になる場合があります。

希望値ではなく保証値を明確にする

バックアップ設計では、「日次バックアップを 30 日保持する」という表現だけでは不十分です。実際には、現在の対象データ量、日次変更量、年間増加率、保存先の総容量、実測した圧縮率と重複排除率、容量逼迫時の動作まで説明できる必要があります。

重要なのは、「30 日保持する予定です」という希望値ではありません。現在のデータ量、変更量、保存方式、保存先容量を踏まえ、最低何日分を確実に保持できるのかという保証値です。

確認すべき問い	目的
現在の対象データ量は何 TB か	初回フルと将来容量の基準を把握する
日次の変更量はどの程度か	増分容量を見積もる
データは年間どの程度増加するか	保持期間中の成長を織り込む
保存先の総容量と使用可能容量はいくつか	実際に保持できる上限を把握する
異常な大量変更を何日間吸収できるか	ランサムウェア発生時の容量耐性を確認する
最低何日前までの復旧ポイントを保証できるか	復旧可能性を要件として示す

バックアップ容量の設計手順

バックアップの容量と世代管理は、次の順番で設計すると整理しやすくなります。

手順	内容
1. 復旧要件を決める	RPO だけでなく、侵害を検知するまでにかかる期間も考慮する
2. 対象データ量を把握する	現在の使用量だけでなく、バックアップ対象全体を確認する
3. 変更量と増加率を測定する	日次変更量、月次増加量、繁忙期の増加量を実測する
4. バックアップ方式を確認する	フル、差分、増分、永久増分、合成フルの方式を明確にする
5. 必要容量を試算する	平常時だけでなく、大量変更、再実行、合成処理の容量も加える
6. 保存先容量と比較する	保持したい期間を実際に保存できるか確認する
7. 容量不足時の動作を確認する	古い世代が削除されるのか、新しいバックアップが失敗するのかを把握する
8. 実績値を継続的に監視する	データ量、変更率、圧縮率、保存期間の実績を追う

バックアップは保存できて初めて意味を持つ

ランサムウェア対策として世代管理は重要です。しかし、日次 30 日、週次 3 か月、月次 1 年といった保持ポリシーを設定するだけでは、その期間を確実に保存できるとは限りません。

バックアップ先の容量、対象データ量、日々の変更量、データ増加率、バックアップ方式が不明確な状態では、保持期間は希望にすぎません。さらに、ランサムウェア発生時には大量のデータが変更され、通常時よりもバックアップ容量を大きく消費する可能性があります。

バックアップ設計では、「何日分を保持したいのか」と「何日分を確実に保持できるのか」を明確に分ける必要があります。バックアップポリシーの設定値ではなく、異常時も含めて保証できる復旧ポイントを示すことが重要です。

ランサムウェア対策として本当に必要なのは、「バックアップを取得しています」という説明ではありません。必要な世代が保護され、容量不足で失われず、実際にリストアできることを確認した仕組みです。

参考書籍

参考資料

• CISA: StopRansomware Guide
• NIST SP 800-209: Security Guidelines for Storage Infrastructure

関連する記事