RTO、RPO、MTTR：復旧目標の定義

具体的で測定可能な復旧目標がなければ、適切なバックアップ戦略の設計、適切なDRサイト階層の選択、復旧技術への投資が正当かどうかの評価はできません。RTO、RPO、MTTRは、業務の可用性要件を正確なエンジニアリング目標に変換します。これらの指標により、セキュリティチームとITチームは、停止のコストとDR投資のコストについて、経営層と根拠に基づいて話し合えるようになります。その結果、ビジネス上の妥当性を抽象的ではなく具体的に示せます。

復旧時間目標（RTO）とは、中断の開始から通常サービスの復旧までに許容される最大時間です。重要な決済システムが午前10時に停止し、許容できる停止時間が、許容できない収益損失やSLA違反に至るまでの最大2時間である場合、RTOは2時間です。つまり、遅くとも正午までにシステムを復旧する必要があります。RTOは、DRサイトの階層（15分のRTOにはホットサイト、48時間のRTOにはコールドサイト）、レプリケーション頻度、フェイルオーバーの自動化に関する選択を左右します。

復旧ポイント目標（RPO）とは、時間で表した許容可能な最大データ損失量、つまり災害発生時にどれだけのデータ損失を許容できるかを示す指標です。RPOが1時間の場合、システムの復旧時に含まれるデータは、災害発生時刻から1時間以上前のものであってはなりません。RPOはバックアップ頻度を決定します。1時間のRPOには、少なくとも1時間ごとのバックアップ（または継続的なレプリケーション）が必要です。4時間のRPOであれば、4時間間隔のバックアップを許容できます。RPOはデータの復旧に関する指標であり、RTOはサービス可用性の復旧に関する指標です。

RTOとRPOは復旧の異なる側面を扱うため、それぞれ独立して定義する必要があります。システムのRPOを厳しく設定して（1時間、つまりデータを頻繁にレプリケーションする）、RTOを緩く設定することが可能です（データが最新でも、DR環境の起動に4時間かかる）。逆に、RPOを緩く設定して（24時間、夜間バックアップで十分）、RTOを厳しく設定することも可能です（1時間でのフェイルオーバーが必要なため、すぐに起動できるよう事前にプロビジョニングしたDR環境が必要です）。どちらの指標も事業影響分析に基づいて決定されます。

平均復旧時間（MTTR）とは、インシデント発生後にサービスを復旧するまでに実際にかかった平均時間であり、復旧性能を運用面から測定する指標です。RTOが最大許容停止時間（目標・要件）であるのに対し、MTTRは観測された平均値（実際の性能）です。組織は一定期間にわたるインシデントのMTTRを測定し、RTOと比較して復旧能力を評価します。MTTRが継続的にRTOを超えている場合、DR能力が不十分であり、自動化、人員、またはインフラへの投資が必要であることを示します。

平均故障間隔（MTBF）は、システムの信頼性、つまりシステムが故障と故障の間に稼働する平均時間を測定します。MTBFが高いほど、信頼性が高いことを示します。MTBFとMTTRによって、システムの可用性の割合が決まります。可用性 = MTBF / (MTBF + MTTR)です。MTBFが2,000時間、MTTRが2時間のシステムの可用性は、2,000/2,002 = 99.9%です。MTBFを理解すると、故障が発生しやすい時期を予測し、それに応じてメンテナンス期間を計画できます。MTBFが低下しているハードウェアは寿命が近づいているため、予防的に交換する必要があります。

最大許容停止時間（MTD）とは、顧客の喪失、規制上の罰則、契約上の義務を履行できないことなど、業務に回復不能な損害が生じる前に、システムを停止させておける絶対的な最大時間です。MTDは常にRTO以上になります。その関係は、MTDが業務上の限界であり、RTOがIT上の目標であるというものです。契約で、罰則が発生する前に4時間のSLA違反が許容されている場合、MTDは4時間になる可能性があります。ITチームは、MTDに達する前の安全余裕を確保するため、RTOを1～2時間に設定して設計します。

サービスレベル契約（SLA）は、顧客に対する契約上の取り決めを定めるもので、RTOとRPOの要件に直接影響します。稼働率99.95%を約束するクラウドプロバイダーのSLAでは、年間約4.4時間の停止が許容されます。SLA違反が発生すると、サービスクレジットの付与や契約解除の権利が発生します。IT部門と事業部門の間の内部SLAも同様に機能します。実際の停止時間がSLA上の約束の範囲内に収まるようにRTOとRPOを設計し、コンプライアンスを示すためにMTTRを測定して報告する必要があります。

技術の選択は、RTOとRPOの要件によって直接決まります。RTO 15分、RPOゼロには、同期レプリケーションを使用したアクティブ-アクティブクラスタリングが必要です。これによりデータ損失がなく、自動フェイルオーバーが可能になります。RTO 4時間、RPO 1時間であれば、ウォームスタンバイへのログ配送または非同期レプリケーションを使用できます。RTO 24時間、RPO 24時間であれば、コールドストレージへの日次バックアップを使用できます。必要以上に高い耐障害性を設計すると予算を無駄にし、必要より低い耐障害性を設計すると、インシデント発生時に許容できない業務リスクが生じます。

復旧目標は、定期的なテストによって継続的に検証されている場合にのみ有効です。組織は、実際のMTTRを測定し、実際のデータ復旧ポイント（復元時のデータはどの程度古いものか）を確認する復旧テストを実施する必要があります。RTOが1時間であるのに、テストの結果、MTTRが一貫して3時間であることが判明した場合は、その差を解消しなければなりません。方法としては、DRインフラストラクチャ（自動化、事前プロビジョニング）を改善するか、更新したBIAによってビジネス上の期待値を見直します。テストの頻度は重要度に合わせる必要があり、重要なシステムは四半期ごと、それ以外は年1回が目安です。

RTO、RPO、MTTRのレポートは、ビジネス部門のステークホルダーに、相手が理解できる表現で伝える必要があります。「Tier 1システムのMTTRは47分です」と言うのではなく、「最も重要なシステムに障害が発生した場合、平均1時間未満でサービスを復旧できます。これは契約で許容されている2時間以内です」と伝えます。定期的な報告によってステークホルダーの信頼が高まり、組織のレジリエンス状況について共通理解が形成されます。MTTRの経時的な推移をダッシュボードで報告すると、プログラムの改善を示し、DR投資の予算確保を裏付けることができます。

このレッスンで扱ったCompTIA Security+ (SY0-701)の概念について、理解度を確認しましょう。

このレッスンでは、RTOはサービスを停止できる最大時間であり、フェイルオーバー速度の要件を決定すること、RPOは許容される最大データ損失量であり、バックアップとレプリケーションの頻度を決定すること、そしてMTTRは実際の平均復旧時間を測定した値であり、RTOと比較してDRプログラムの有効性を評価することを学びました。次は、3-2-1ルールや、ランサムウェアでも破壊できないイミュータブルバックアップなど、バックアップ戦略について説明します。