戻せるバックアップの設計と運用 — 3-2-1、イミュータブル保管、リストア訓練まで

バックアップは「取れているか」ではなく「戻せるか」で評価する

バックアップジョブが正常終了していたのに復旧できなかった、という事例は繰り返し報告されている。原因はおおむね三つに集約される。バックアップ先が本番と同じ資格情報で書き込み可能だったため一緒に暗号化された。世代が短く、侵入前の健全な時点まで遡れなかった。復元を実行した経験がなく、所要時間も可否も事前に分からなかった。いずれも取得の失敗ではなく、設計と運用の欠落である。

機器障害や誤操作だけを想定した設計は、攻撃者が管理者権限を得た状況では機能しない。障害対策は「本番が壊れる」ことだけを前提にするが、ランサムウェア対策では「バックアップ自体が攻撃対象になる」ことを前提にする。この前提の差が、以下の判断のほとんどを決める。攻撃者はまず日常業務では触れないはずのバックアップ管理コンソールを探し、ジョブ定義と保存済みデータを削除してから本番を暗号化する。復旧手段を先に潰すのが定石だからだ。

3-2-1ルールを攻撃者の視点で読み替える

3-2-1ルールは、データの複製を3つ保持し、2種類の媒体に分散し、うち1つを別拠点に置くという指針である。障害と災害に対しては今も有効だが、これだけではランサムウェアに耐えられない。3つの複製がすべてオンラインで、同一のドメイン認証で到達できるなら、攻撃者にとっては1つと変わらない。

そこで近年は、別拠点の1本に加えて「改ざん不能または切り離された1本」を持ち、復元検証のエラーをゼロにする、という拡張(3-2-1-1-0と呼ばれる整理)が使われる。中小規模の環境で最初に着手すべきは、この「もう1本」を作ることだ。ディスク上の複製本数を増やすより、性質の異なる1本を用意するほうが復旧確率は大きく上がる。

イミュータブルとオフラインは代替関係ではない

イミュータブル保管は、保持期間中は上書きも削除もできない状態でデータを固定する方式を指す。オブジェクトストレージのオブジェクトロック、ストレージ装置のWORM機能、バックアップ製品の強化リポジトリ機能などが該当する。運用の手間が小さく、日次で回せるのが利点である。一方で、機能を提供する基盤そのものの管理権限が奪われた場合や、設定した保持期間が短すぎた場合には無力になる。

オフライン保管は、テープや取り外したドライブのように、物理的にネットワークから切り離す方式だ。手間はかかるが、論理的な権限の話とは無関係に守られる。イミュータブルを日次の主軸に据え、月次または四半期の長期世代をオフラインで別に持つ、という二層構成が現実的な落としどころになる。

バックアップ基盤と認証情報を業務ドメインから切り離す

侵害の広がり方を考えると、バックアップ管理サーバを業務用のActive Directoryに参加させる構成は避けたい。ドメイン管理者権限が奪われた時点で、バックアップ基盤も同時に落ちるためである。管理サーバはドメイン非参加とし、専用のローカル管理アカウントで運用する。管理コンソールへのログインには多要素認証を設定し、パスワードは業務用のパスワード管理基盤とは別の場所に保管する。

ネットワーク側では、バックアップ用のセグメントを分け、管理コンソールへ到達できる端末と経路を限定する。保管先ストレージに対しては、バックアップ用アカウント以外からの削除操作を許可しない。あわせて、復旧手順書と管理アカウントの資格情報を紙またはオフライン媒体でも保持しておく。手順書がファイルサーバにしか存在せず、そのファイルサーバごと暗号化されて手順を参照できなくなる、という状況は実際に起こり得る。

RPO/RTOから世代と頻度を逆算する

RPOは「どこまでのデータ喪失を許容するか」、RTOは「いつまでに復旧させるか」を示す。この二つを業務システムごとに決めないと、頻度も世代数も保管先も決められない。全社一律の日次バックアップは、重要システムには不足し、そうでないデータには過剰であることが多い。

世代設計では、侵入から暗号化実行までに数週間から数か月の潜伏期間が生じる場合がある点を考慮する。直近7世代しか持たない設計では、侵入時点より前の状態に戻せない。日次を数週間分、月次を数か月から1年分、というように時間軸の異なる世代を重ねておくと、感染前の時点を選び直せる。RTOについては、必要な復元時間が回線帯域と媒体の読み出し速度で決まるため、実測しない限り机上の数字にとどまる。次節の訓練で確定させる。

リストア訓練は本番と同じ制約下で行う

訓練が形骸化する典型は、管理者が普段使っている端末から、正常なドメイン認証を使い、既知の小さなファイルを1つ戻して終わりにする形である。本番の障害時にはそのいずれも使えない。訓練は次の順序で組む。

1. 対象を選ぶ。年1回はRTOの厳しい基幹システムを、四半期ごとにファイルサーバなどの一部データを対象とする。
2. 復旧先を用意する。本番とは分離した検証環境またはクリーンな仮想マシンに戻し、本番へ上書きしない。
3. 制約を課す。業務ドメインの認証は使えない、手順書はオフライン媒体のものだけを見る、担当者1名は不在という条件を置く。
4. 計測する。媒体の取り出しから業務データが参照可能になるまでの経過時間を記録し、RTOと突き合わせる。
5. 検証する。復元したデータを業務担当者が開き、直近の更新内容が含まれているかを確認する。ファイル数の一致だけでは不十分である。
6. 差分を記録する。手順書の誤り、不足していたライセンスキーや暗号化回復キー、想定より遅い転送速度を課題として残し、期限を付けて改善する。

すぐ点検できるチェックリスト

着手の順序と判断の基準

すべてを同時に整えるのは難しい。優先度は、失われたときに事業が止まるデータから決める。まずそのデータについて、改ざん不能またはオフラインの複製が1本あるかを確認する。無ければそこが最優先の投資対象である。次にバックアップ管理系の認証を業務ドメインから切り離す。ここまでは、既存製品の設定変更と運用手順の見直しで対応できる場合が多い。世代設計の見直しと訓練の定例化はその後で構わない。

設計が妥当かどうかは、「攻撃者が管理者権限を取り、本番とバックアップの両方を消しにきたとき、どの複製が残るか」を一つずつ指し示せるかで判断できる。指し示せない構成は、まだ障害対策の域にとどまっている。なお、被害発生時の報告義務や公表の要否は、扱うデータの種類や事案の性質によって判断が分かれる。事前に確認する場合は、個人情報保護委員会やIPA、JPCERT/CCが公開する一次情報にあたり、必要に応じて自社の法務や顧問弁護士と手順を決めておきたい。復旧計画の枠組みを体系的に整理したい場合は、NISTのSP 800-34 Rev.1が参照点になる。脅威の傾向や攻撃手口は変化するため、本稿の前提は執筆時点のものとして扱い、製品固有の設定は各ベンダーの公式ドキュメントで最新の内容を確認してほしい。