副題：耐性度を起点に、依存先・復旧順序・代替運用を一本につなぐ
想定読者：BCM/BCP担当、CISO、インフラ責任者、システム企画
多くの金融機関では、システムごとの復旧目標を定めています。RTO（目標復旧時間）は4時間、RPO（目標復旧時点）は前日夜間バッチ開始前時点。BCPの訓練もしています。
それでも、ランサムウェアのようなサイバー事象では計画どおりに戻らないことが少なくありません。原因は手順の不備ではなく、RTO・RPOという考え方そのものが置いている前提にあります。
第1回では、経営が決めるべきこととして「どの業務を止めてはならないか」「どこまでなら止まってよいか」を挙げました。本稿は、その2つを起点に復旧を設計し直す方法を扱います。
1. RTO・RPOが前提にしていること
RTO・RPOは、主にハードウェア故障や自然災害を想定して発達してきた考え方です。そこには暗黙の前提があります。壊れるのは器（システム）であり、中身（データ）は正しいという前提です。
観点 | 従来型の障害（故障・災害） | サイバー事象（ランサムウェア等） |
|---|---|---|
壊れるもの | 機器・設備・拠点 | データそのもの（暗号化・改ざん） |
バックアップ | 正しいものとして使える | 暗号化・削除・汚染されている可能性がある |
事象の始点 | 障害発生時点が明確 | 侵入は発覚より前。どこまで遡るべきか分からない |
復旧先の環境 | 安全 | 攻撃者が残っている可能性がある |
再発 | 同じ事象が直後に起きることは稀 | 同じ手口で再侵入されうる |
RPOを「前日夜間」と決めていても、前日夜間のバックアップがすでに攻撃者のツールを含んでいれば、そこへは戻れません。RTOを「4時間」と決めていても、戻した環境が安全か確かめる工程が計画に入っていなければ、4時間では済みません。
RTO・RPOが不要になるわけではありません。サイバー事象では、それだけでは計画が成立しないということです。
2. 起点を変える ― システムのRTOから、業務の耐性度へ
もう一つの問題は、RTO・RPOがシステムごとに決められていることです。システム担当者がそれぞれ目標を置き、積み上げた結果として業務の復旧時間が決まる。このボトムアップの決め方では、業務として許容できるかどうかが誰にも確認されていません。
そこで起点を逆にします。金融庁がディスカッション・ペーパーで示した「耐性度」（英語圏ではImpact ToleranceやTolerance for disruptionと呼ばれます）を業務ごとに先に決め、そこから下の階層へ目標を割り付けるのです。
RTO・RPO | 耐性度 | |
|---|---|---|
対象 | システム・データ | 顧客や市場に提供する業務 |
決める人 | システム部門 | 経営（取締役会・経営会議の承認） |
性質 | 自社として目指す目標 | 超えてはならない限界 |
表現の例 | 勘定系を4時間以内に復旧 | 振込の受付停止は2時間まで。それ以上は顧客影響が受容できない |
守る手段 | システムの復旧 | システムの復旧＋代替運用 |
最後の行が重要です。耐性度を守る手段はシステムの復旧だけではありません。システムが戻らなくても、手作業や縮退運用、別チャネルで業務を続けられれば、耐性度は守れます。耐性度は、システム復旧と代替運用の組み合わせで守るものです。
図1 目標はトップダウンで割り付け、復旧はボトムアップで積み上げる（© ProSol）
3. 復旧設計を構成する5つの要素
逆算の設計は、次の5つを1本の線でつなぐ作業です。
① 重要な業務と耐性度
対象は10前後に絞ります。すべての業務を対象にすると、優先順位がつかなくなるからです。業務ごとに「何時間止まると、顧客・市場にどのような影響が出るか」を時間軸で書き出し、受容できない時点を耐性度として経営が承認します。
② 業務を支える資産（データを含む）
その業務に必要なシステム、データ、人、拠点を洗い出します。ここで問うべきは「どのシステムが必要か」だけではありません。「どの時点のデータなら信頼できるか」も合わせて決めます。これが後述するRPOの読み替えにつながります。
③ 依存先
委託先、クラウド、共用の決済・通信サービス。Series 02第3回で扱った依存マップがそのまま使えます。依存先が止まったときの復旧目標が自社の耐性度と整合しているか、契約と相手の実力の両面で確認します。
④ 復旧順序
業務システムだけを戻しても、業務は再開できません。認証基盤が戻らなければ誰もログインできず、ネットワークとログ基盤が戻らなければ安全かどうかを確認できません。サイバー事象からの復旧では、ID基盤・ネットワーク・ログ・バックアップ基盤といった共通基盤を最初に戻す順序を計画に組み込みます。Series 03第3回で「Tier 0」と呼んだ領域です。
⑤ 代替運用
システムが戻るまでの間、業務をどう続けるか。手作業での受付、処理件数を絞った縮退運用、店舗や電話など別チャネルへの誘導。実際の事象では、耐性度を守る主役はシステム復旧ではなく代替運用であることが多いのです。代替運用には人手と手順と判断権限が必要です。事前に決めておかなければ、当日に機能しません。
4. サイバー事象に特有の3つの設計ポイント
5つの要素に加えて、サイバー事象からの復旧には固有の設計が必要です。欧州のDORA（2025年1月適用開始）と、NISTのサイバーセキュリティフレームワーク（CSF 2.0）は、いずれもこの点に具体的な要求を置いています。
ポイント1：クリーンな復旧点を確保する
バックアップが暗号化・削除されないよう、変更不能（イミュータブル）なバックアップ、ネットワークから切り離したオフラインのバックアップ、通常の管理者権限ではアクセスできない論理的に分離された保管を組み合わせます。
NIST CSF 2.0は復旧（Recover）機能の中で、バックアップなどの復旧資産の完全性を、復旧に用いる前に検証すること（RC.RP-03）を求めています。持っているだけでは足りず、使う前に確かめる工程が必要です。
ポイント2：隔離された環境に戻す
侵害された環境にそのままデータを戻せば、攻撃者のツールごと復元しかねません。DORA第12条は、自社システムでバックアップから復元する場合、元のシステムから物理的かつ論理的に分離されたシステムを用いることを求めています。
実務上は、クリーンな復旧環境（いわゆるクリーンルーム）をあらかじめ設計しておき、そこで復元・検証してから本番に切り替える構成になります。これを当日に一から組み立てることはできません。
ポイント3：戻したものを検証してから再開する
NIST CSF 2.0は、復元した資産の完全性を検証し、通常の稼働状態にあることを確認すること（RC.RP-05）を求めています。DORA第12条も、復旧時には複数のチェックと照合でデータの完全性を確認し、外部の関係者からの情報でデータを再構築する場合もシステム間の整合を確かめるよう求めています。
金融機関にとって、ここは特に重い工程です。残高や取引記録を、決済ネットワークや取引先の記録と突き合わせて整合を確認しなければ、業務を再開できないからです。この照合の時間を見込まずに置かれたRTOは、計画として成立していません。
5. RPOを読み替える ― 「最後のバックアップ」ではなく「最後の信頼できる時点」
サイバー事象では、侵入から発覚までに時間がかかることがあります。その間に取得されたバックアップには、攻撃者のツールや改ざんが含まれているかもしれません。
そのため、RPOは「最後に取得した時点」ではなく「最後に信頼できると確認できる時点」として設計し直します。実務上は次の3点を見直します。
- 保持する世代数と期間：直近だけでなく、侵入から発覚までの期間を見込んで遡れるようにする
- 復旧点を判定する手段：どの世代がクリーンかを判断するためのログ、マルウェアスキャン、整合性チェックの手順
- 失われた期間の再構築手段：信頼できる時点から現在までの取引を、取引先・決済ネットワーク・顧客からの情報でどう復元するか
3つ目は技術だけでは解決しません。外部との照合手順と、その間の顧客対応を業務部門と一緒に設計する必要があります。
復旧設計チェックリスト（10項目）
- 重要な業務を10前後に絞り、耐性度を経営が承認しているか
- システムのRTOを、業務の耐性度から逆算して割り付けているか
- 各業務について「どの時点のデータなら信頼できるか」を定めているか
- 依存先の復旧目標が自社の耐性度と整合しているか確認したか
- ID基盤・ネットワーク・ログ・バックアップ基盤を先に戻す順序が計画にあるか
- 耐性度を守るための代替運用（手順・人員・判断権限）を用意しているか
- 変更不能・オフライン・論理分離のバックアップを組み合わせているか
- 復旧に使う前にバックアップの完全性を検証する手順があるか
- 元の環境から分離された復旧環境を事前に設計しているか
- 復元後のデータ照合（外部記録との突合を含む）の時間をRTOに見込んでいるか
まとめ
サイバー事象からの復旧は、システムを元に戻す作業ではなく、信頼できる状態を作り直す作業です。だからこそ、システムごとのRTO・RPOを積み上げるのではなく、業務の耐性度から逆算し、代替運用で時間を稼ぎながら、基盤から順に、検証を挟んで積み上げる設計が必要になります。
ただし、どれだけ精緻に設計しても、計画は試すまで計画にすぎません。次回は、机上・技術・経営の各演習とバックアップ復元テストを組み合わせて、「本当に復旧できるか」を検証する方法を扱います。
主要出典
- 金融庁「オペレーショナル・レジリエンス確保に向けた基本的な考え方」（ディスカッション・ペーパー、2023年4月）
- 欧州連合「デジタル・オペレーショナル・レジリエンス法（DORA、規則(EU)2022/2554）」第11条・第12条
- NIST「The NIST Cybersecurity Framework (CSF) 2.0」（2024年2月）RC.RP-03、RC.RP-05
- 金融庁「金融分野におけるITレジリエンスに関する分析レポート」（2025年6月）
- 金融庁・日本銀行「バーゼル銀行監督委員会による『オペレーショナル・レジリエンスのための諸原則』の公表について」（2021年5月）
本記事は公開情報に基づく一般的な解説です。DORAは日本の金融機関に直接適用される法令ではありませんが、国際的な要求水準の参考として引用しています。制度の動向に応じて定期的に見直します。