バックアップが成功しても復旧できない：業務再開までの確認点
運用報告のバックアップ欄には、毎日「成功」が並んでいる。ところが障害の日、データを戻せても利用者がログインできない。認証基盤が止まり、暗号鍵の保管場所へ入れず、復旧担当の連絡先も社内システムにしかない。保存できていたのに、仕事は再開しない。
バックアップの成功記録は無意味ではない。保存処理を監視するための大切な証拠である。しかし、そこから「事業が止まっても間に合う」と判断するには距離がある。止められない業務ほど、ファイルがあるかではなく、必要な人が必要な処理を再開するまでを確かめる。本稿の問いは、どこまで試せばその判断の材料になるかだ。
この記事の目次
保存、復元、業務再開は別の到達点
第一の到達点は、予定した情報が所定の場所へ保存されたこと。第二は、その情報を読み出して復元できたこと。第三は、復元した環境で業務を再開できたことである。この三つを一つの「復旧済み」で扱うと、未確認の範囲が隠れてしまう。
例えば、データベースが起動しても、受注システムとの接続がなければ請求できない。画面を開けても、金額や顧客との紐付けが崩れていれば、利用開始は早い。外部送信を再開した結果、同じ注文を二重に処理するようなら、技術的な復元だけを成功とは呼べない。
したがって監査で尋ねたいのは、「復元試験をしましたか」だけではない。何を失った想定で、どの環境を使い、誰が、どの業務まで確かめたかである。成功したという結論と、成功とした範囲を一組で読む必要がある。
先に決めるのは、何時間でサーバーを起動するかではない
米国のNISTが2010年に公表した情報システムの緊急時対応ガイドは、事業影響の分析を踏まえて復旧の優先順位を決め、計画を試験・訓練する考え方を示している。ここでRTOは資源が利用できない時間の目標、RPOはどの時点までのデータを戻す必要があるかという目標であり、異なる問いである。NIST SP 800-34 Rev.1
これは米国の連邦情報システム向けの指針であって、日本企業で一定の試験回数が義務になるという話ではない。また、導入企業の損失減少率を測った実験でもない。参考にするのは、事業上の必要性から確認範囲を決める順番である。
自社で「午前中に復旧」と決める前に、何が午前中まで待てるのかを明らかにしたい。注文の受付は紙で続けられても、出荷指示は止まるかもしれない。データが前夜まで戻ればよい業務もあれば、その後の取引を別の記録から再入力しなければ成立しない業務もある。
システムの起動に使える時間と、事業が停止を許容できる時間も同じとは限らない。起動後の照合、再入力、利用者への連絡に時間が要るなら、それを含めて仕事が戻る見通しを作る。「サーバーが間に合ったから目標達成」と報告しても、現場が使えない時間は残る。
試験の範囲を決めるための、三つの問い
以下は指針を踏まえた編集上の提案である。最初に、今回失うものを明記する。ファイルの誤削除と、拠点全体の停止では、残る認証、回線、担当者が違う。普段の認証を使って復元できた試験は、その認証も失う状況での成功を示していない。
次に、途中で必要になるものを挙げる。鍵、アカウント、設定、接続先、ソフトウェアの入手先、作業権限などだ。全てを別々に棚卸しするだけでなく、復元の順序に並べる。認証を復旧するための手順書が認証後の共有フォルダーにしかない、といった循環は、順番にすると見つけやすい。
最後に、業務側の終了条件を置く。画面表示だけでよいのか、代表的な受注から請求まで通すのか。金額、件数、権限、外部連携のどれを照合するのか。対象とした業務責任者が結果を確認して初めて、その範囲の再開可能性を評価できる。
全面訓練を増やす場合と、部分確認を積み重ねる場合
架空の卸売会社で、請求処理の基盤を変更したとする。データの保存先は同じだが、認証と暗号鍵の管理方法が変わった。この場合、以前の復元試験の成功だけでは新しい依存関係を説明できない。隔離した検証環境などを使い、変更した入口から請求処理の確認まで通す試験を優先したい。
一方、復旧経路を一度確認済みで、構成変更がなく、再取得できる補助資料の保存処理を日々点検する場面なら、毎回の全業務訓練が適切とは限らない。保存失敗の監視や抽出したデータの読み出し確認を日常点検として行い、広い範囲の試験は変更やリスクに合わせて計画する方が現実的である。
この選択が逆転するのは、資料の位置付けが変わったときだ。その補助資料が唯一の原本になった、再取得先がなくなった、締切が短くなったなら、以前の軽い確認を維持する理由は弱くなる。「重要システムではない」という分類名を引き継ぐのではなく、失った際の影響を更新する。
部分確認は、全体の復旧能力を自動的に証明するものではない。何を未確認として残したかを記録し、その残りをいつ、どの方法で確かめるかを決める。反対に、全面訓練を行った場合でも、想定しなかった拠点障害や外部サービス停止まで保証したことにはならない。
新しいバックアップほど良い、とは限らない
ランサムウェアへの対応では、単に新しいデータを戻すことが復旧にならない場合がある。米国CISAの対策ガイドは、重要データのオフラインでの暗号化バックアップと復元可能性の試験に加え、復旧時の再感染を避ける対応を示している。CISAのランサムウェア対策ガイド
保存処理が成功していても、その中身が既に破損・改変されていた可能性は別に調べる必要がある。これは、バックアップが不要という反論ではない。「保存できたものを戻す」と「安全に使える状態を戻す」の差である。侵害の疑いがある場合は、専門の対応担当と連携し、復元先や復元時点を判断する。
訓練でも、本番の送信先へ意図せず注文や支払いを流してはならない。外部連携を切り離す、試験データを使うなど、何を実行し何を模擬したかを分ける。その結果、実際の接続確認が残るなら、その限界も結果に含める。安全に試す工夫と、試していない範囲を隠さないことは両立する。
机上の訓練で分かること、実際に戻して分かること
担当者を集めて手順をたどる机上訓練では、連絡先の欠落や判断者の不在を見つけられる。一方、保存媒体を読み出せるか、鍵を使えるか、復元したデータに整合性があるかは、話し合っただけでは確認できない。両者は代わりになる試験ではなく、異なる欠落を探す方法である。
実際の訓練で途中から担当者が普段の管理画面を使ったなら、それが想定した障害でも利用できるかを記録する。想定上は使えない道具で助けた部分があれば、その時点以降を無条件の成功に含めない。失敗した箇所と支援を入れた箇所を残す方が、見かけ上の完走より次の改善につながる。
復元が終わった時刻から、業務再開までにも仕事があります。仮に転送2時間、整合確認1時間、権限と連携の再開2時間なら合計5時間で、4時間の目標には届きません。保存成功、復元操作、代表業務の完了を別々に記録し、認証手段の復旧が必要なら、その時間も除外しません。戻せる時点と再開所要時間も別の証拠です。
次の運用報告では、成功件数の隣に何を置くか
日次報告の成功件数は残してよい。ただし、その隣に「最後に復元した対象」「確認できた業務」「その後の構成変更」を置きたい。さらに、復元開始から利用可能と判断するまでの時間と、戻せたデータの時点を区別する。こうすれば、保存処理の健康状態と、復旧能力の証拠を混同しにくくなる。
重要な業務で、新しい依存関係がまだ試されていないなら、次に投資すべきなのは成功表示を増やすことではなく、その経路を通す確認である。既知の経路を維持する日常点検なら、部分確認で変化を捉える。バックアップ監査の結論は「保存されています」で終わらせず、どの業務を、どの想定まで再開できると確かめたかへ進めたい。