ランサムウェア前提のバックアップ設計:情シスが押さえる復旧力の要件

ランサムウェア前提のバックアップ設計:情シスが押さえる復旧力の要件

侵害前提で問われる「復旧できるか」

ランサムウェア対策は侵入防止だけでは不十分であり、侵害後に事業を止めない復旧力が勝負になる。ゼロデイや設定不備、委託先経由の侵害は避けきれず、最終的に差が出るのは短時間で確実に復旧できるかどうかである。

特に近年は暗号化に加えて情報窃取と公開脅迫を組み合わせる二重恐喝が一般化した。さらに攻撃者はバックアップ基盤やスナップショット、管理者資格情報を先に破壊し、復旧手段を奪って交渉を迫る。

情シスが見るべき指標は「バックアップがあるか」ではなく、RPO/RTOを満たす形で復旧できるかである。取得と復旧は別物であり、復旧工程の依存関係まで含めて設計する必要がある。

3-2-1-1-0とイミュータブルの実装

バックアップの基本は3-2-1-1-0であり、本番含め3つ保持し、2種類以上の媒体に分散し、1つはオフサイトに置く。加えて1つはオフラインまたはエアギャップ、イミュータブルで保護し、復旧テストでエラーをゼロに近づける。

ランサムウェア対策で決定的なのは「攻撃者権限が及んでも消せない・改ざんできない」変更不可能性である。クラウドのオブジェクトロックやWORM、イミュータブルストレージ、テープなど方式は複数あるが、保持期間変更や削除の統制が要件になる。

運用面では、保持期間短縮やイミュータブル解除が単独操作でできる設計は事故と侵害の両面で危険である。承認フローやPAMを組み合わせ、復旧データの完全性を守ることが必要だ。

バックアップ基盤の分離と最小権限

バックアップ環境は攻撃者にとって最優先の標的であり、本番同等以上の防御が要る。ネットワーク分離、管理アカウント分離、本番AD管理者とバックアップ管理者の分離などで侵害範囲を限定する。

保管先も別クラウドアカウントや別テナントに分離し、バックアップ削除や保持期間変更といった破壊操作の権限を切り出す。管理コンソールは多要素認証を必須化し、特権の常用を避ける。

また、復旧の前提となる認証基盤やDNSなどの順序を事前に整理し、ランブックに落とし込むべきである。帯域制限や大量データのリストア時間を見誤ると、目標RTOを満たせない。

復旧テストと二重恐喝への現実的な備え

バックアップ運用の成熟度を決めるのは復旧テストであり、ログ上の成功は信用できない。世代不足、鍵不整合、設定漏れ、依存サービス未復旧などで「戻せない」事態が起きるため、段階的にリストア検証から全体復旧演習まで行う。

演習は技術チームだけでなく、業務部門・広報・法務・経営の意思決定も含めて実施する。停止許容や復旧優先順位を合意し、支払わない選択肢を現実にすることが交渉力にもつながる。

なおバックアップは暗号化による停止には効くが、情報窃取には直接効かない。重要データ暗号化と鍵管理、特権ID監査、外部公開資産管理、EDR/SIEMによる検知、DLPなどを並行して整備する必要がある。

参照元:ランサムウェア時代のバックアップ戦略:侵害を前提に「復旧力」を高める実践ポイント