RTOとRPOとは何か？
前四半期の3時間に及ぶ障害の後、CFOがシンプルな質問をします。「次回はどれくらい早く復旧できるのか？」あなたは答えようと口を開きますが、ふと立ち止まります。復旧速度かデータ保護か？システムの可用性か取引損失か？
その3時間の障害？RTOは4時間だったので目標は達成しました。しかし、前日の午後6時に最後のバックアップを実施していたため、顧客は8時間分の注文データを失いました。RPOは問題ではなかったはずが、突然問題となりました。
リカバリータイム目標（RTO）とリカバリーポイント目標（RPO）は、 事業継続性の異なる側面を測定します。RTOは、ビジネスへの影響が許容できなくなるまでシステムが利用不可でいられる最大時間を定義します。RPOは、最後の有効なバックアップと障害発生時点との間で許容できるデータ損失量を定義します。
NIST SP 800-34 Rev. 1（連邦政府のコンティンジェンシープランニング標準）によれば、RTOは「システムがどれくらいの間利用不可でいられるか」に答え、RPOは「どれだけのデータ損失を許容できるか」に答えます。これらを同じ質問として扱うことはできません。そうすると災害復旧計画にギャップが生じます。
ランサムウェアが夜間に本番データベースを暗号化した場合、RTOは6時までに復旧できるか、あるいは翌週の火曜日になるかを決定します。RPOは、15分分の取引データを失うか、3日分の顧客注文を失うかを決定します。両方の指標を独立して算出し、実際のビジネス要件に合致した復旧戦略を構築する必要があります。
重要な違い：RTOは障害発生からの前方（復旧までの時間）を測定し、RPOは障害発生からの後方（最後の復旧ポイント）を測定します。バックアップ頻度がRPOを定義し、復旧能力がRTOを定義します。1時間ごとにバックアップを取るシステムは、復旧に30分でも8時間かかってもRPOは1時間です。
.jpg)
RTOとRPOがサイバーセキュリティに与える影響
従来の災害復旧計画は、クリーンな復旧環境を前提としています。火災でデータセンターが破壊される。洪水で機器が損傷する。バックアップから代替インフラに復旧し、業務を再開します。
サイバーセキュリティインシデントはこの前提を複雑にします。 ランサムウェア攻撃はファイルを暗号化するだけでなく、マルウェアが存在しないことが検証されたバックアップポイントからの復旧が必要です。2021年5月のColonial Pipeline攻撃がこの現実を示しています。 米司法省のプレスリリースによれば、DarkSideランサムウェア攻撃により、米国最大の燃料パイプラインが6日間停止しました。同様に、JBS Foodsは2021年6月、ランサムウェアにより米国、カナダ、オーストラリアの食肉加工工場が停止し、REvil攻撃者に1,100万ドルの身代金を支払いました。
CISAの連邦政府サイバーセキュリティインシデントおよび脆弱性対応プレイブックによれば、重要システムのランサムウェア復旧には通常24～72時間が必要であり、従来の4～24時間目標よりも長くなります。この延長されたタイムラインは以下を考慮しています：
- マルウェア除去の検証
- セキュリティコントロールの再確立
- 脅威インテリジェンスの統合
- 法執行機関との連携
RPOの算出も同様に複雑です。午前6時のバックアップは一見クリーンに見えますが、フォレンジック分析により ラテラルムーブメントが午前3時に始まっていたことが判明します。実際の有効な復旧ポイントは初期侵害前の15時間前となります。
NISTサイバーセキュリティフレームワーク2.0（2024年2月発行）は、RTOとRPOをリカバリー（RC）機能内の必須要素として位置付け、復旧目標の確立を求めています。NISTガイダンスに沿った サイバーセキュリティ特有の復旧目標を策定すべきです。
両指標とそのサイバーセキュリティ上の意味を定義したところで、5つの主要な観点で両者がどのように異なるかを詳しく見ていきます。
RTOとRPO：主な違いの概要
RTOとRPOの本質的な違いを理解することで、復旧失敗につながる計画上のギャップを防ぐことができます。
- 測定の方向性：RTOは障害発生からの前方、すなわちシステムがオンラインに戻るまでの時間を測定します。RPOは障害発生からの後方、すなわち最後のクリーンなデータ状態までどれだけ遡るかを測定します。この方向性の違いにより、各指標の担当チームも異なることが多いです。インフラチームは復旧能力を通じてRTOを推進し、バックアップ管理者はレプリケーション頻度を通じてRPOを推進します。
- コスト要因：RTO短縮には冗長インフラ、ホットスタンバイシステム、自動フェイルオーバー機能への投資が必要です。RPO短縮にはストレージ容量、レプリケーション帯域幅、バックアップ頻度への投資が必要です。
- 技術要件：ほぼゼロのRTOには、ロードバランシングと自動フェイルオーバーを備えたアクティブ-アクティブ構成が必要です。ほぼゼロのRPOには、同期レプリケーションによる継続的データ保護が必要です。一方の指標で積極的な目標を達成するのは比較的容易ですが、両方を同時に達成するには指数関数的に高い投資が必要です。
- ビジネス影響のタイミング：RTOの影響は生産性損失、SLA未達、業務中断など即座に現れます。RPOの影響は復旧完了後に表面化することが多く、復旧後に取引データの欠落や記録の古さが判明します。
- テスト手法：RTOテストは実際のフェイルオーバー演習を通じて復旧手順を検証します。RPOテストは復旧ポイントの検証やデータ完全性チェックを通じてバックアップの整合性を検証します。
これらの違いは実際の財務的影響をもたらします。RTOとRPOを同一視する組織は、その前提のコストを復旧時に痛感することになります。
災害復旧計画におけるRTOとRPOの違い
Uptime Instituteの2024年グローバルデータセンター調査によれば、 影響の大きい障害の20%が100万ドル超の損失をもたらしています。しかし、RTOとRPOの影響は異なります。ダウンタイムコストは分単位で積み上がり、データ損失コストは失われた内容や再作成可能性に依存します。医療機関が4時間分の患者記録を失えば、復旧速度に関係なくHIPAA違反となります。
NISTガイダンスは、異なる復旧戦略を導く3つの影響レベルを定めています：
- 高影響システム（ミッションクリティカル）は、ミラーリングシステム、ディスクレプリケーション、即時フェイルオーバー可能なホットサイトが必要です。RTOは分単位、RPOはバックアップ頻度やデータ重要度に応じて分～数時間単位を目指します。
- 中影響システムは、光学バックアップ、WAN/VLANレプリケーション、ウォームサイト機能が必要です。許容RTOは数時間、RPOは15～60分間隔となります。
- 低影響システムは、テープバックアップやコールドサイト移転戦略を採用し、 リスク分析に基づき許容可能な業務中断をもとに復旧目標を設定します。これらのシステムは、ミッションクリティカルなインフラと比べて長い復旧ウィンドウを許容し、バックアップ頻度や復旧戦略は文書化されたビジネス影響により決定されます。
バックアップや災害復旧のモダナイゼーションをITの最優先事項とする組織は、環境全体に一律のソリューションを導入しているわけではありません。ビジネスの重要度に応じて異なるRTO・RPO目標を割り当てる階層化分類システムを通じて、復旧能力を差別化されたビジネス要件に合わせています。
これらの階層化復旧戦略が枠組みを提供します。次は、各システムにどの階層が適用されるかを決定する方法論が必要です。
RTOとRPOの算出方法
意味のある復旧目標を算出するには、許容閾値を推測するのではなく、ビジネス影響を定量化する必要があります。
RTOの算出
まず、ビジネスへの影響が壊滅的になるまでの絶対的な限界である最大許容ダウンタイム（MTD）を設定します。そこから逆算します。例えば、ECプラットフォームが1時間あたり5万ドルを生み出し、20万ドルの損失までなら耐えられる場合、MTDは4時間です。RTOはMTD未満、かつ余裕を持たせて3時間に設定します。
復旧手順を積み上げます：
- バックアップ取得：30分
- データ復元：90分
- アプリケーション再起動：20分
- 検証テスト：40分
合計が3時間なら目標達成です。5時間なら、より高速なインフラが必要です。
RPOの算出
データ変更率と失われたデータの再作成コストを特定します。システムが1時間あたり1,000件の取引を処理し、1件の再入力に15分かかる場合、4時間分のデータ損失は1,000時間の労働コスト（4,000件×15分）となります。その労働コストがバックアップインフラ投資を上回る場合、RPOを短縮します。医療画像、金融取引、センサーテレメトリなど再作成できないデータの場合、コストに関係なくRPOはゼロに近づきます。
NIST SP 800-34 Rev. 1によれば、RTOは復旧リソースコストとシステム停止継続コストが等しくなるポイントに設定すべきです。両方の曲線をプロットします：RTOが短くなるほど復旧コストは増加し、RTOが長くなるほどダウンタイムコストが増加します。その交点が最適なRTO投資ポイントです。
これらの算出方法は業界によって異なります。
業界別のRTOとRPOの例
規制要件、データの機密性、業務依存関係が復旧目標の「許容範囲」を決定します。主要4業界におけるRTOとRPOの例を示します。
- 金融サービス：取引プラットフォームは、市場状況が秒単位で変化し、規制要件で完全な取引記録が求められるため、ほぼゼロのRTOとRPOが必要です。SECの Rule 17a-4は、証券会社に書き換え不可形式で記録を保存することを義務付けています。銀行はコアバンキングシステムで2時間未満のRTO、取引データで15分未満のRPOを目標とするのが一般的です。
- 医療：HIPAAはデータの完全性と可用性の維持を求めますが、具体的なRTOやRPO目標は規定していません。ただし、患者ケアを支える臨床システムは4時間未満のRTOを目指すことが多いです。電子カルテは、臨床記録の再作成が患者安全を損ない、法的リスクを生むため、RPOは分単位が求められます。 HHSセキュリティ規則はコンティンジェンシープランニングを義務付けますが、具体的な目標はリスク評価に委ねています。
- EC・小売：ピーク時の大手小売業者は、 1時間あたり50万ドル超のダウンタイム損失を被ります。注文管理システムは通常1時間未満のRTO、15分未満のRPOが求められます。在庫システムはより長いウィンドウを許容する場合もあります。顧客向けWebサイトは、利用者が離脱するため、積極的なRTOが必要です。
- 製造：生産ラインを制御するOTシステムは、設備停止や生産スケジュール遅延がサプライチェーン全体に波及するため、RTOは分単位が求められます。ただし、製造業のRPO要件はさまざまです。生産テレメトリは1時間ごとのバックアップを許容する場合もありますが、品質管理記録は継続的な保護が必要です。
業界ベンチマークは参考になりますが、具体的な目標は厳密な内部分析から導き出す必要があります。一般的な数値では組織を守れません。文書化されたビジネス影響が重要です。
組織におけるRTOとRPO目標の設定
ビジネス影響分析（BIA）が復旧目標を導きます。NIST SP 800-34によれば、BIAは重要システムの特定、時間経過による影響評価、依存関係の文書化を行います。システム障害時に実際に何が起こるかを文書化せずに、適切な復旧目標を決定することはできません。
連邦規定は、重要システムのベースラインを定めています。ミッションエッセンシャルファンクション（MEF）、PMEF、NEFを支える情報システムは、FCD-1により最大許容ダウンタイム12時間以内を満たす必要があります。組織の重要システムでRTOがこの閾値を超える場合は、文書化された正当化が必要です。
テストは重要です。 障害の48%が手順上の失敗に起因（Uptime Institute 2024年レジリエンシー調査）。文書上4時間のRTOでも、復旧手順が検証されていなければ実際のインシデントでは復旧が遅れます。NIST SP 800-53のコンティンジェンシープランニング管理策は、低影響システムには年次テーブルトップ演習、中影響システムには機能演習、高影響システムにはフルスケール演習を要求しています。
静的な計画は避けましょう。RTOとRPOは、ビジネス要件の変化に応じて定期的な見直しが必要な動的パラメータとして扱ってください。3年前にオンプレミスインフラ向けに設定した復旧目標は、異なる障害モードを持つ クラウド環境には適用できない場合があります。
この方法論に従っても失敗することがあります。最も一般的な失敗は技術的なものではなく、災害発生時に初めて明らかになる計画上のミスです。
RTOとRPOでよくあるミス
組織は実際の復旧シナリオで初めて明らかになる同じ計画ミスを繰り返しがちです。
- 全システムで同一目標を設定する：すべてのシステムが同じ投資に値するわけではありません。RTO・RPOを一律に設定すると、重要でないシステムに過剰投資し、重要システムを過小保護することになります。メールサーバーと取引プラットフォームでは復旧投資が異なります。
- バックアップ頻度と実際のRPOを混同する：1時間ごとのバックアップでも、1時間のRPOが保証されるわけではありません。実際のRPOにはバックアップ完了時間、レプリケーション遅延、検証遅延が含まれます。バックアップに45分、レプリケーションに15分かかる場合、実効RPOは2時間近くになります。
- システム依存関係を無視する：顧客ポータルのRTOが4時間でも、依存するデータベースのRTOが24時間なら、ポータルの実効RTOは24時間です。目標設定前に依存関係をマッピングしましょう。NIST SP 800-34によれば、ビジネス影響分析はシステム間の相互依存関係を文書化し、意味のある復旧シーケンスを確立する必要があります。
- 復旧手順を一度もテストしない：Uptime Instituteの調査では、 障害の48%が手順上の失敗に起因しています。4時間のRTOも、実際の復旧手順を現実的な条件下で実行したことがなければ、紙の上だけの目標です。
- サイバーセキュリティがRTOを延長することを忘れる：従来の復旧はクリーンな環境を前提としています。ランサムウェア復旧では、脅威検証、認証情報のローテーション、セキュリティコントロールの検証が必要です。セキュリティインシデントでフォレンジック調査が必要な場合、インフラのRTOは下限値に過ぎません。
これらのミスを回避するには、計画の徹底と適切なテクノロジーが必要です。ランサムウェア攻撃時、手動手順はプレッシャー下で失敗しがちであり、まさにその時こそ復旧が確実に機能する必要があります。
SentinelOneで災害復旧を強化
ランサムウェアが本番環境全体のファイルを暗号化した場合、従来のバックアップ復旧は多くの作業を要します：クリーンな復旧ポイントの特定、データ復元、整合性検証、アプリケーション再起動。RTOは数時間から数日単位となります。
SentinelOneのSingularity Platformは、ランサムウェア復旧シナリオ向けに設計された自律型レスポンス機能を提供します。プラットフォームの 行動AIは脅威を検知し、影響を受けたエンドポイントに対して自律的なロールバックをトリガーできます。 Singularity Endpointは、異常な挙動をリアルタイムで分析する行動AIと静的AIモデルにより、人的介入なしでランサムウェアを特定します。
独立したMITRE ATT&CK評価において、SentinelOneは競合他社より88%少ないアラートを生成しました：他社の178,000件に対し、わずか12件です。これにより、セキュリティチームは復旧時に過剰なアラート処理ではなく、検証済みの脅威への対応に集中できます。
Purple AIは、サイバーセキュリティシナリオでRTOを延長させるインシデント調査フェーズを支援します。クリーンな復旧ポイントの特定が必要な場合、Purple AIは早期導入企業で脅威調査を80%高速化しています。
Singularity Platformは、Uptime Institute 2024年調査で文書化された主要な失敗要因、 障害の48%が手順上の失敗に起因、に対応します。自律型レスポンスは、スタッフがプレッシャー下で誤って実行する手動手順への依存を低減します。
SentinelOneのデモをリクエストし、自律型レスポンスとPurple AI機能が積極的なRTO・RPO目標をどのように支援するかをご確認ください。
まとめ
RTOとRPOは災害復旧の異なる側面—システム停止許容時間と許容データ損失—を測定し、独立した計画が必要です。サイバーセキュリティインシデントは従来のRTO目標を大幅に延長し、CISAはマルウェア検証やセキュリティコントロール検証の要件から、重要システムで24～72時間を設定しています。
ビジネス影響分析が意味のある復旧目標を導きますが、それらの目標はテストされて初めて意味を持ちます。Uptime Instituteの調査では、障害の48%がスタッフの手順不履行に起因しています。自律型レスポンス機能は、プレッシャー下で失敗しがちな手動手順ではなく、行動分析に基づき対応することで人的ミスリスクを低減します。
RTOとRPOに関するよくある質問
リカバリータイム目標（RTO）は、システムが中断後にどのくらいの時間まで利用不可であっても業務への影響が許容範囲内であるかを定義します。リカバリーポイント目標（RPO）は、組織が許容できるデータ損失量を定義し、最後の有効なバックアップと障害発生時点との時間差で測定されます。
RTOは災害発生後からの復旧までの時間（業務再開までの時間）を測定し、RPOは災害発生時点から遡って最後に利用可能なリカバリーポイントまでの時間を測定します。両方の指標は、完全な災害復旧計画に必要です。
RTOとRPOの目標は、異なる復旧の側面を測定するため、相反することはありません。RTOは復旧までの時間を定義し、RPOは許容可能なデータ損失量を定義します。システムによっては、RTOが4時間（業務復旧までの時間）、RPOが15分（最後のバックアップ間隔）となる場合があります。
これらは連携して機能します。15分ごとに取得したバックアップを用いて、4時間以内に業務を復旧します。指標を混同したり、ビジネスインパクト分析を行わずに目標を設定した場合に、矛盾が生じます。ビジネス要件で1時間のRTOが求められているにもかかわらず、復旧に8時間かかる場合、それは目標の矛盾ではなく、復旧インフラが不十分であることを意味します。
最大許容停止時間（MTD）は、ビジネスへの影響が壊滅的となる絶対的な上限を示します。まず、1時間あたりの収益損失、規制上の罰則閾値、顧客契約のSLA制限、長期停止による競争上の損害を特定してください。
NIST SP 800-34 Rev. 1によると、MTDはRTOが遵守すべき制約を定めます。RTOはMTDより短く、予期しない復旧の複雑さに備えてバッファを設ける必要があります。運用継続のための重要任務機能（MEF）、PMEF、またはNEFを支える通信システムの場合、FCD-1の要件によりMTDは12時間を超えてはなりません。
クラウドバックアップサービスは、特定のRPO目標を達成するための技術を提供しますが、適切な設定がなければビジネス成果を保証することはできません。RPOはバックアップ頻度、データ変更率、レプリケーションのタイミングに依存します。継続的なレプリケーションを備えたクラウドサービスは、正しく設定すればほぼゼロのRPOをサポートします。
毎日のバックアップスケジュールでは、クラウドの機能に関係なく24時間のRPOとなります。NIST SP 800-53 Control CP-6(2)によると、リカバリー時間およびリカバリーポイント目標に従ってリカバリー作業を促進するために、代替ストレージサイトを設定する必要があります。サービスは機能を提供しますが、設定と検証はお客様の責任です。
ランサムウェア復旧は、単にシステムを復元するだけでなく、アクティブな脅威を除去するため、RTOが延長されます。CISAの連邦サイバーセキュリティインシデントおよび脆弱性対応プレイブックでは、ランサムウェア復旧には、マルウェア除去の検証、セキュリティコントロールの再確立、脅威インテリジェンス分析、攻撃手法の修復を実施し、システムを本番環境に戻す前にこれらを完了する必要があると定められています。
従来の災害復旧はクリーンな復旧環境を前提としていますが、サイバーセキュリティインシデントではバックアップが汚染され、認証情報が侵害され、フォレンジック分析によって検証済みのクリーンな復旧ポイントを特定する必要があります。一般的なランサムウェアのRTOは、重要なシステムで24～72時間であり、従来のインフラ復旧目標である4～8時間と比べて長くなります。
NIST SP 800-53のコンティンジェンシープランニング管理策は、システムの影響レベルごとに最小テスト頻度を定めています。低影響システムには年次テーブルトップ演習、中程度影響システムにはバックアップリカバリを伴う機能演習、高影響システムには代替サイトへのフェイルオーバーを含むフルスケール演習が求められます。
Uptime Instituteの2024年レジリエンシー調査によると、障害の48%はデータセンター担当者が手順を遵守しなかったことに起因しており、未検証のリカバリ計画が実際のインシデント時に機能しないことが裏付けられています。ミッションクリティカルなシステムは四半期ごと、重要な業務システムは半年ごと、支援インフラは年次でテストを実施してください。
