バックアップ復旧テストの始め方 ─ ランサムウェアに備える確認手順

バックアップは「ある」だけでは復旧できない

ランサムウェアや重大障害に備えるバックアップ復旧テストは、保存したデータを戻し、業務の再開条件を満たすか確認する作業だ。取得成功の表示だけでは、必要な権限・復号鍵・依存サービスまで使えるとは分からない。まず重要なシステムを1つ選び、目標と成功条件を決めて、本番から分離した環境で試す。

この記事では、攻撃手順ではなく、防御・確認・初動対応の観点でバックアップ復元テストの始め方を整理する。対象は、専任のCSIRTがない組織の情シス、SaaS管理者、開発者、セキュリティ初心者だ。まずは本番全体を止める大掛かりな訓練ではなく、1つの重要システムを小さく選び、「戻せるか」を事実で確認するところから始める。

---

読者別の影響：誰が何を確認するか

バックアップ復旧テストは、バックアップ担当だけの作業ではない。復旧できるかどうかは、認証、ネットワーク、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つから逆算して決める。

RTO・RPOの測定例：目標と実測を分ける

NISTのRTO定義は復旧に許容する時間、RPO定義は障害後に戻すべきデータの時点を扱う。実測と比較する前に、自社の業務継続計画で起点・終点・対象業務をそろえる。以下は架空の測定例であり、標準の目標値ではない。

記録点	このテストでの値	判断への使い方
想定停止時刻	10:00	この例では業務停止から測ると事前合意
復元作業	10:40開始、11:30終了	データ復元の50分は部分工程の値
業務受け入れ完了	12:10	停止から2時間10分。RTO目標4時間以内を満たす
整合性を確認できたデータ時点	09:15	停止から45分前。RPO目標30分以内は満たさない

この例では早く戻せても、データ時点の目標は未達となる。「復元に50分しかかからなかった」だけで合格にしない。バックアップジョブの終了時刻ではなく、実際に復元して整合性を確認できたデータ時点を使う。DB・添付・外部連携で時点がずれる場合は、欠落する取引の範囲も調べる。

検証環境の安全確認

テストの前に、作業責任者と業務責任者が対象・権限・停止条件を承認する。編集部の確認例は次のとおり。

• 本番の保存先を復元先に指定していないか、別担当者と照合する。
• 復元したジョブ・メール・Webhookが実顧客や本番APIへ送信しないよう、検証用の宛先・接続先に分離する。
• 本番の秘密情報が含まれる場合は、参照権限と保管期限を絞り、記録には値そのものを載せない。
• 決済、請求、注文などの検証はテスト用アカウント・sandboxで行い、実処理を発生させない。
• 本番接続や想定外のデータ更新を検出したら中止し、責任者へ報告する。
• 終了後に検証データ・一時権限を社内の保管・削除手順で処理し、残存リソースと費用を確認する。

---

初動対応：小さく試し、記録を残す

復旧テスト当日は、手順書の正しさだけでなく、判断の迷いを見つける。担当者が「次に何をすればよいか分からない」と感じた箇所は、実際の障害時にも止まりやすい。

実施中は、次の順番で記録する。

順番	やること	記録すること
1	対象バックアップを選ぶ	バックアップ世代、取得時刻、選定理由
2	復旧先を準備する	環境名、ネットワーク、接続できる担当者
3	データを復元する	開始時刻、終了時刻、エラー、所要時間
4	アプリ・SaaS連携を検証先で確認する	ログイン、主要画面、テスト宛先への通知、本番と分離した連携
5	データ整合性を確認する	件数、重要レコード、添付ファイル、権限
6	監視とログを確認する	EDR/SIEM、監査ログ、失敗ログ、異常通知
7	結果を判定する	RTO/RPOとの差分、未解決課題、再テスト要否

「戻ったように見える」で終わらせない。画面は開くが一部の添付が欠けている、IdP連携ができない、想定した検証宛先へ通知できない場合は未達を記録する。主要操作を3〜5個に絞り、成功条件を事前に決める。分離のため試していない本番連携は「未確認」とし、成功扱いにしない。

復旧テストの合否と再テスト

判定	必要な根拠	次の行動
合格（今回の範囲）	RTO/RPOの目標内、必須操作・整合性・権限・監視を確認し、業務責任者が受け入れ	記録を保管し、変更時の再検証条件を決める
未達	目標超過、欠損、必須操作失敗などを確認	課題ごとに担当・期限を付け、修正した条件で再テスト
判定保留	測定・証跡・業務担当者の確認が足りない	未確認項目を補う。復旧可能と対外説明しない

判定は今回の対象・条件に限る。1システムの合格を全社復旧の保証にしない。

---

やること・やらないこと・残す記録

復旧テストは、技術作業であると同時に、説明責任を作る作業でもある。後から「なぜその世代を選んだのか」「どこまで確認したのか」「何が未解決なのか」を説明できるようにする。

やること

• 復旧対象を1つに絞り、成功条件を事前に書く。
• RTO/RPOの目標と実測値を分けて記録する。
• 本番とは分離した復旧先で試す。
• 復旧後に認証、権限、ログ、外部連携を確認する。
• 問題が出た箇所を責任追及ではなく改善項目として残す。

やらないこと

• 初回テストで本番環境に直接復元する。
• バックアップ取得成功だけで復旧可能と判断する。
• 復旧手順を担当者の記憶だけに頼る。
• APIキー、Cookie、秘密鍵をチケットやメモに貼る。
• ランサムウェア疑い時に、侵入経路を確認しないまま本番復元する。

残す記録

復旧テスト記録

対象システム:
実施日時:
参加者:
想定シナリオ:
選択したバックアップ世代:
RTO目標 / 実測:
RPO目標 / 実測:
測定の起点 / 終点 / タイムゾーン:
復元データの確認済み時点:
復旧先:
本番接続・通知を防ぐ確認:
確認した業務操作:
確認したログ・監視:
発生した問題:
未確認事項:
合否 / 業務受け入れ担当者:
証跡の保管場所（秘密情報は記載しない）:
検証データ・一時権限の後片付け:
次回までの改善アクション:
エスカレーション要否:

この記録は、Tabletop Exercise や インシデントレスポンス の訓練にも使える。机上演習では判断と連絡を確認し、復旧テストでは実際に戻せるかを確認する。両方を分けて実施すると、技術手順と意思決定の穴を見つけやすい。

判断・連絡の訓練を初めて企画する場合は、インシデント対応の机上訓練：60分のシナリオ・進め方も使える。復旧テスト結果を事前資料にし、誰が業務再開を承認するかまで話し合う。

---

判断基準：いつエスカレーションするか

復旧テストで失敗が出ること自体は悪いことではない。問題は、失敗を「次回直す」で流し、リスクの大きさを判断しないことだ。次の条件に当てはまる場合は、情シス内の課題ではなく、事業継続・セキュリティリスクとしてエスカレーションする。

条件	エスカレーション理由
RTOを満たせない	超過幅と事業影響を責任者へ共有し、改善・代替運用を判断する
RPOを満たせない	許容以上のデータ損失が起きる
復旧に必要な権限者が1人だけ	休日・退職・不在時に復旧できない
バックアップが本番から削除可能	ランサムウェア時に復旧手段を失う
復旧後の認証・権限確認ができない	再侵入や権限悪用を見逃す
重要データの整合性を確認できない	顧客影響や監査対応に耐えられない

ランサムウェア対策では、Backup Immutability のように、一定期間バックアップを削除・改ざんできない設計が重要になる。ただし、イミュータブルバックアップを導入していても、復元手順、鍵、権限、復旧先、依存関係を確認していなければ、実務上はまだ不十分だ。

---

よくある誤解

「クラウドだからバックアップは不要」

クラウドやSaaSでも、誤削除、権限設定ミス、外部共有、アカウント侵害、連携アプリの誤操作は起きる。SaaS側が提供する復元機能、監査ログ、保持期間、エクスポート方法を確認しておく必要がある。SaaSの権限や外部共有は SaaS権限棚卸しチェックリスト も併用したい。

「バックアップ世代が多ければ安全」

世代数が多くても、復旧手順を試していなければ安全とは言えない。重要なのは、どの世代を選ぶか、どの時点のデータなら業務上許容できるか、復元後に整合性を確認できるかだ。

「復旧テストは年1回で十分」

頻度は組織規模やシステム重要度による。少なくとも、重要システムの構成変更、認証基盤の変更、SaaS連携追加、バックアップ方式変更、委託先変更があったときは、復旧手順も見直したい。

「復旧できればインシデント対応は完了」

復旧は終点ではない。原因が残ったまま戻すと、再感染や再侵害が起きる。ランサムウェア疑い時の初動は ランサムウェア初動テンプレート と ランサムウェア初動対応の最初の1時間 を合わせて確認する。

---

関連用語・関連ページ

復旧テストを深めるときは、次のページを順番に読むと全体像を整理しやすい。

• RTO と RPO — 復旧目標と許容データ損失を分けて理解する。
• Disaster Recovery と Business Continuity — IT復旧と業務継続の関係を確認する。
• Backup Immutability — ランサムウェア時に復旧手段を守る考え方を確認する。
• ランサムウェア防御 — 侵入、横展開、バックアップ破壊への備えを学ぶ。
• ランサムウェア初動テンプレート — 発生時の封じ込め、調査、復旧、報告を整理する。
• アクセスログ解析ミニCTF — 復旧後のログ確認に必要な読み方を練習する。
• 用語クイズ — RTO/RPO、インシデント対応、復旧関連の用語を復習する。

---

公式情報・参考情報

バックアップ復旧テストは、組織の契約、法務、個人情報、顧客影響、業務継続計画によって判断が変わる。公開情報だけで断定せず、自社規程、委託先契約、専門家の助言と照らして実施したい。

2026年10月4日に以下の一次情報を確認した。時刻を使った測定例、合否表、記録欄は編集部による架空の実務例であり、実測結果や認証基準ではない。

• NCSC: Mitigating malware and ransomware attacks — バックアップの分離と定期的な復元確認。
• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems — 復旧計画、訓練、保守の考え方を確認できる。
• NIST Glossary: Recovery Time Objective — 復旧時間目標の定義。
• NIST Glossary: Recovery Point Objective — 復旧すべきデータ時点の定義。

---

まとめ：復旧テストは「戻せる証拠」を作る作業

バックアップ復旧テストの目的は、担当者を試すことではない。障害やランサムウェア疑いが起きたときに、どのデータを、どこへ、誰が、何分で、どこまで戻せるのかを事実で確認することだ。

最初の一歩は小さくてよい。重要システムを1つ選び、RTO/RPO、復旧先、必要権限、依存関係、成功条件を決め、検証環境で戻してみる。その結果を記録し、未確認事項と改善アクションを残す。これだけでも「バックアップはあるはず」という曖昧な安心から、「ここまでは戻せる」という実務の判断へ進める。

次にやることは、ランサムウェア初動テンプレート を開き、自社のバックアップ確認欄、復旧判断欄、報告先を埋めておくことだ。平時に一度でも試しておけば、本番の緊急時に選べる行動は増える。