バックアップ復旧テストの進め方を初心者向けに整理。RTO/RPO、復旧手順、記録、エスカレーション条件を確認し、ランサムウェア時に慌てない準備へつなげます。
バックアップは「ある」だけでは復旧できない
ランサムウェアや重大障害に備えるうえで、バックアップは最後の復旧手段になる。しかし実務では、「バックアップを取っている」ことと「業務を戻せる」ことの間に大きな差がある。復旧手順を試していない、権限や鍵が足りない、復元先が決まっていない、バックアップ自体が古い、という理由で復旧に失敗することは珍しくない。
この記事では、攻撃手順ではなく、防御・確認・初動対応の観点でバックアップ復旧テストの始め方を整理する。対象は、専任のCSIRTがない組織の情シス、SaaS管理者、開発者、セキュリティ初心者だ。まずは本番全体を止める大掛かりな訓練ではなく、1つの重要システムを小さく選び、「戻せるか」を事実で確認するところから始める。
- RTO/RPOを使って復旧テストの範囲を決める。
- 事前準備、実施中の記録、終了後の改善点をチェックリスト化する。
- 復旧テストで問題が出たときのエスカレーション条件を整理する。
読者別の影響：誰が何を確認するか
バックアップ復旧テストは、バックアップ担当だけの作業ではない。復旧できるかどうかは、認証、ネットワーク、SaaS、業務部門、法務・広報の判断にも影響する。
| 読者 | 影響 | まず見ること |
|---|---|---|
| 情シス・IT管理者 | 障害時に業務を再開できるか | 復旧対象、復旧手順、バックアップ世代、権限 |
| 開発者・SRE | アプリとDBの整合性を戻せるか | DBスナップショット、設定値、シークレット、依存サービス |
| SaaS管理者 | SaaS上のデータや権限設定を戻せるか | 監査ログ、削除復元、外部共有、管理者権限 |
| セキュリティ担当 | 復旧後に再感染・再侵害しないか | 侵入経路、認証情報、EDR/SIEMの監視、隔離環境 |
| 経営・業務責任者 | どの業務から再開するか | 優先業務、許容停止時間、顧客影響、代替運用 |
「バックアップが成功している」と表示されていても、業務として戻るとは限らない。たとえばDBは戻せても、IdPの設定、APIキー、DNS、メール配送、SaaS連携が戻らなければ、利用者はサービスを使えない。復旧テストは、バックアップ製品の成功表示ではなく、業務が再開できる状態を確認する作業として扱う。
まず確認すること：復旧テスト前のチェックリスト
最初の復旧テストでは、対象を広げすぎない。いきなり全社システムを対象にすると、関係者が多すぎて記録も判断も曖昧になる。まずは、業務影響が大きく、復旧手順を検証する価値が高いシステムを1つ選ぶ。
| 確認項目 | なぜ重要か | 記録する内容 |
|---|---|---|
| 復旧対象 | 対象が曖昧だと成功条件が決まらない | システム名、データ範囲、依存サービス |
| RTO | いつまでに戻すべきかを決める | 目標復旧時間、業務上の許容停止時間 |
| RPO | どの時点までのデータ損失を許容するかを決める | バックアップ時刻、許容データ損失 |
| 復旧先 | 本番に戻す前に安全に試すため | 検証環境、隔離ネットワーク、アクセス権限 |
| 権限と鍵 | 復旧時に必要な権限不足を防ぐ | 管理者、復号鍵、シークレット管理場所 |
| 依存関係 | DBだけ戻しても業務が戻らないことを防ぐ | IdP、DNS、メール、外部API、SaaS連携 |
| 監視 | 復旧後の異常を見逃さないため | EDR、SIEM、監査ログ、ヘルスチェック |
特に重要なのは、RTO と RPO を分けて考えることだ。RTOは「どれだけ早く戻すか」、RPOは「どこまでのデータ損失を許容するか」を示す。バックアップ頻度、復旧手順、人員体制、代替運用は、この2つから逆算して決める。
初回の復旧テストで本番環境へ直接戻すと、失敗時の影響が大きい。まずは隔離された検証環境で、データの完全性、認証、アプリ起動、ログ監視を確認する。
初動対応：小さく試し、記録を残す
復旧テスト当日は、手順書の正しさだけでなく、判断の迷いを見つける。担当者が「次に何をすればよいか分からない」と感じた箇所は、実際の障害時にも止まりやすい。
実施中は、次の順番で記録する。
| 順番 | やること | 記録すること |
|---|---|---|
| 1 | 対象バックアップを選ぶ | バックアップ世代、取得時刻、選定理由 |
| 2 | 復旧先を準備する | 環境名、ネットワーク、接続できる担当者 |
| 3 | データを復元する | 開始時刻、終了時刻、エラー、所要時間 |
| 4 | アプリ・SaaS連携を確認する | ログイン、主要画面、通知、外部連携 |
| 5 | データ整合性を確認する | 件数、重要レコード、添付ファイル、権限 |
| 6 | 監視とログを確認する | EDR/SIEM、監査ログ、失敗ログ、異常通知 |
| 7 | 結果を判定する | RTO/RPOとの差分、未解決課題、再テスト要否 |
「戻ったように見える」で終わらせない。たとえば、画面は開くが一部の添付ファイルが欠けている、IdP連携ができない、APIキーが古い、通知が外部へ飛ばない、という状態は復旧成功とは言いにくい。業務上の主要操作を3〜5個に絞り、成功条件を事前に決めておくと判定しやすい。
やること・やらないこと・残す記録
復旧テストは、技術作業であると同時に、説明責任を作る作業でもある。後から「なぜその世代を選んだのか」「どこまで確認したのか」「何が未解決なのか」を説明できるようにする。
やること
- 復旧対象を1つに絞り、成功条件を事前に書く。
- RTO/RPOの目標と実測値を分けて記録する。
- 本番とは分離した復旧先で試す。
- 復旧後に認証、権限、ログ、外部連携を確認する。
- 問題が出た箇所を責任追及ではなく改善項目として残す。
やらないこと
- 初回テストで本番環境に直接復元する。
- バックアップ取得成功だけで復旧可能と判断する。
- 復旧手順を担当者の記憶だけに頼る。
- APIキー、Cookie、秘密鍵をチケットやメモに貼る。
- ランサムウェア疑い時に、侵入経路を確認しないまま本番復元する。
残す記録
復旧テスト記録
対象システム:
実施日時:
参加者:
想定シナリオ:
選択したバックアップ世代:
RTO目標 / 実測:
RPO目標 / 実測:
復旧先:
確認した業務操作:
確認したログ・監視:
発生した問題:
未確認事項:
次回までの改善アクション:
エスカレーション要否:この記録は、Tabletop Exercise や インシデントレスポンス の訓練にも使える。机上演習では判断と連絡を確認し、復旧テストでは実際に戻せるかを確認する。両方を分けて実施すると、技術手順と意思決定の穴を見つけやすい。
判断基準：いつエスカレーションするか
復旧テストで失敗が出ること自体は悪いことではない。問題は、失敗を「次回直す」で流し、リスクの大きさを判断しないことだ。次の条件に当てはまる場合は、情シス内の課題ではなく、事業継続・セキュリティリスクとしてエスカレーションする。
| 条件 | エスカレーション理由 |
|---|---|
| RTOを大幅に超える | 業務停止時間が想定より長くなる |
| RPOを満たせない | 許容以上のデータ損失が起きる |
| 復旧に必要な権限者が1人だけ | 休日・退職・不在時に復旧できない |
| バックアップが本番から削除可能 | ランサムウェア時に復旧手段を失う |
| 復旧後の認証・権限確認ができない | 再侵入や権限悪用を見逃す |
| 重要データの整合性を確認できない | 顧客影響や監査対応に耐えられない |
ランサムウェア対策では、Backup Immutability のように、一定期間バックアップを削除・改ざんできない設計が重要になる。ただし、イミュータブルバックアップを導入していても、復元手順、鍵、権限、復旧先、依存関係を確認していなければ、実務上はまだ不十分だ。
よくある誤解
「クラウドだからバックアップは不要」
クラウドやSaaSでも、誤削除、権限設定ミス、外部共有、アカウント侵害、連携アプリの誤操作は起きる。SaaS側が提供する復元機能、監査ログ、保持期間、エクスポート方法を確認しておく必要がある。SaaSの権限や外部共有は SaaS権限棚卸しチェックリスト も併用したい。
「バックアップ世代が多ければ安全」
世代数が多くても、復旧手順を試していなければ安全とは言えない。重要なのは、どの世代を選ぶか、どの時点のデータなら業務上許容できるか、復元後に整合性を確認できるかだ。
「復旧テストは年1回で十分」
頻度は組織規模やシステム重要度による。少なくとも、重要システムの構成変更、認証基盤の変更、SaaS連携追加、バックアップ方式変更、委託先変更があったときは、復旧手順も見直したい。
「復旧できればインシデント対応は完了」
復旧は終点ではない。原因が残ったまま戻すと、再感染や再侵害が起きる。ランサムウェア疑い時の初動は ランサムウェア初動テンプレート と ランサムウェア初動対応の最初の1時間 を合わせて確認する。
関連用語・関連ページ
復旧テストを深めるときは、次のページを順番に読むと全体像を整理しやすい。
- RTO と RPO — 復旧目標と許容データ損失を分けて理解する。
- Disaster Recovery と Business Continuity — IT復旧と業務継続の関係を確認する。
- Backup Immutability — ランサムウェア時に復旧手段を守る考え方を確認する。
- ランサムウェア防御 — 侵入、横展開、バックアップ破壊への備えを学ぶ。
- ランサムウェア初動テンプレート — 発生時の封じ込め、調査、復旧、報告を整理する。
- アクセスログ解析ミニCTF — 復旧後のログ確認に必要な読み方を練習する。
- 用語クイズ — RTO/RPO、インシデント対応、復旧関連の用語を復習する。
公式情報・参考情報
バックアップ復旧テストは、組織の契約、法務、個人情報、顧客影響、業務継続計画によって判断が変わる。公開情報だけで断定せず、自社規程、委託先契約、専門家の助言と照らして実施したい。
- CISA: #StopRansomware Guide — ランサムウェア対策、バックアップ保護、復旧準備の公式ガイド。
- CISA: StopRansomware.gov — ランサムウェア関連の公式リソース集。
- NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems — 復旧計画、訓練、保守の考え方を確認できる。
- NIST Cybersecurity Framework: Recover — インシデント後の復旧機能と関連資料を確認できる。
まとめ：復旧テストは「戻せる証拠」を作る作業
バックアップ復旧テストの目的は、担当者を試すことではない。障害やランサムウェア疑いが起きたときに、どのデータを、どこへ、誰が、何分で、どこまで戻せるのかを事実で確認することだ。
最初の一歩は小さくてよい。重要システムを1つ選び、RTO/RPO、復旧先、必要権限、依存関係、成功条件を決め、検証環境で戻してみる。その結果を記録し、未確認事項と改善アクションを残す。これだけでも「バックアップはあるはず」という曖昧な安心から、「ここまでは戻せる」という実務の判断へ進める。
次にやることは、ランサムウェア初動テンプレート を開き、自社のバックアップ確認欄、復旧判断欄、報告先を埋めておくことだ。平時に一度でも試しておけば、本番の緊急時に選べる行動は増える。
