9.5 災害復旧と事業継続

概要と動機

遅かれ早かれ、計画していなかった何かがシステムを落とします。リージョン全体のクラウド停止、打ち間違いのDROP TABLE、データセンターの洪水、ランサムウェアの起爆、一夜にして消えるサプライヤー。問いは、中断が来るかどうかではなく、どれだけ速く回復し、その過程でどれだけ失うかです。この章は、悪い日が来る前に備えることについてです。

その備えには二つの規律が答え、それらは同じものではありません。事業継続計画(BCP)は、中断を通じて組織全体の機能を保ちます。人、オフィス、コミュニケーション、給与計算、顧客が頼る重要な業務プロセス。災害復旧(DR)は、システムが失敗した後にITシステムとデータを復元する、より狭く技術的な仕事です。継続が目標で、復旧は手段の一つです。すべてのサーバーを復元しても、誰が災害を宣言できるか、あるいはどう顧客に連絡するかを誰も知らなければ、顧客の期待を裏切りえます。この章は、DRをエンジニアリングの実践として、BCPをそれが仕える事業の枠として扱います。

大きなチームにとって、賭け金は規模とともに増します。企業は、規制上の復旧の義務、マルチリージョンの足跡、少数のサプライヤーへの集中リスクを負います。政府は、市民のために不可欠な機能を維持する法的な義務を負い、それは運用の継続として成文化されています。どちらも、テストされていない計画が、最悪の瞬間に発見する負債であるような精査のもとで運用します。復旧は、信頼性(9.1章)とインシデント対応(9.3章)が、設計では避けられない失敗を生き延びるという、より難しい問いに出会う所です。

主要原則

継続は復旧より広い。 サーバーを復元することは、事業を動かし続けることと同じではありません。
二つの数字がすべてを駆動する。 事業への影響から設定される復旧時間目標(RTO)と復旧時点目標(RPO)が、あらゆる決定の規模を決めます。
テストされていないバックアップはバックアップではない。 一度も行ったことのない復元は、能力ではなく願いです。
バックアップは標的だと想定する。 ランサムウェアはまずバックアップを狙うので、コピーを不変でオフラインに保ちます。
記憶ではなくコードから再構築する。 ソースからインフラストラクチャを再作成できなければ、確実には復旧できません。
依存するものを地図にする。 最も遅い上流の依存関係と同じ速さでしか復旧できません。
復旧を他のシステムと同じように測定する。 スライドに書いた数字ではなく、本物の訓練からの実際のRTOとRPO。

推奨事項

事業影響分析からRTOとRPOを設定する

あらゆる復旧の決定は二つの数字から下りてくるので、まずそれを正しく得てください。復旧時間目標(RTO)は、害が許容できなくなる前にシステムがどれだけ停止していられるかです。復旧時点目標(RPO)は、どれだけのデータ損失に耐えられるかで、復元できる最後の良いコピーの古さで測られます。決済の元帳は数分のRTOとゼロに近いRPOを要求し、内部の分析ダッシュボードは、それぞれ1日を許容するかもしれません。これらはエンジニアリングでは設定できません。業務プロセスを中断のコストで順位づけ、それぞれをそれが必要とするシステムとデータまでたどる事業影響分析(BIA)から導いてください。より厳しい目標はよりコストがかかるので、BIAが、些細なサービスを金メッキし、重要なサービスを守り不足にするのを防ぎます。

バックアップを正しく行う: 3-2-1ルール、不変性、テスト

バックアップは、あらゆる復旧戦略の下の床で、ほとんどの組織は、思っているよりそれをまずく行っています。3-2-1ルールとして知られるバックアップの規律に従います。データの少なくとも三つのコピーを、二つの異なる媒体あるいはシステムに、一つのコピーはオフサイトで保ちます。現代の脅威は、さらに二つの要件を加えます。少なくとも一つのコピーを不変(書き込み専用で、保持期間の間は削除不能)に、できればさらにオフラインあるいはエアギャップに保ちます。ランサムウェアは今や、自らを告げる前に、到達可能なバックアップを意図して暗号化あるいは削除するからです。何よりも、復元を予定に沿ってテストします。テストされていないバックアップはバックアップではなく、テストされていない想定です。訓練で見つかる失敗、壊れたアーカイブ、欠けた暗号鍵、間違ったボリュームのバックアップは、まさに本物の事象であなたを終わらせたはずのものです。

コスト対速度の幅に沿ってDR戦略を選ぶ

DR戦略はお金を復旧速度と交換するので、すべてに一つの層を買うのではなく、システムごとにそのRTOとRPOに基づいて選ぶべきです。四つのパターンが幅を支えます。バックアップと復元は最も安く最も遅いです。災害が起きたらバックアップから再構築し、RTOは数時間から数日。パイロットライトは、最小限の中核(複製されるデータベース、整った中核の設定)を温かく縮小した状態で保ち、拡張に備えます。ウォームスタンバイは、スタック全体の小さな常時稼働のコピーを動かし、フェイルオーバーでスケールアップさせて、RTOを数分に削ります。マルチサイトのアクティブ・アクティブは、二つ以上の場所で完全な容量を動かして稼働中のトラフィックを提供し、最高のコストと複雑さで、ゼロに近いRTOを与えます。事業が承認した数字に層を合わせ、パイロットライトを許容するシステムにアクティブ・アクティブの価格を払わないでください。

一貫性のトレードオフを念頭にデータを複製する

復旧の速さは、スタンバイのデータがどれだけ最新かに依存し、ここで分散システム(3.3章)の難しい問題を引き継ぎます。同期レプリケーションは、すべての書き込みを承認する前に二つ目の場所で確認するので、書き込みのレイテンシが増え、距離に厳しい限界がある代わりに、ゼロに近いRPOを与えます。非同期レプリケーションは、ローカルで承認して後から変更を送るので、速く地理的に柔軟ですが、フェイルオーバーで失う複製遅延の窓を残します。自由な選択はありません。強い一貫性はレイテンシを、弱い一貫性はデータを代償にします。データストアごとにRPOから決め、典型的な複製遅延を知ってください。その遅延が、悪い日の本当のRPOであり、設計書の数字ではないからです。

インフラストラクチャ・アズ・コードでコードから再構築する

手でプロビジョニングした環境は、確実には復旧できません。誰もすべてのクリックを覚えていないからです。環境をインフラストラクチャ・アズ・コード(8.2章)として定義し、スタック全体を、既知の良い状態でバージョン管理されたソースから再作成できるようにします。これは復旧を、考古学のプロジェクトから、繰り返し可能なパイプラインの実行に変え、スタンバイのリージョンを誠実に保ち(両方が同じコードから築かれるとずれにくい)、侵害の後で新しいアカウントやリージョンに復旧用のインフラストラクチャを立ち上げるきれいな方法を与えます。コード、シークレットへの参照、ランブックを、主環境の喪失を生き延びる場所に保存します。

必要になる前に依存関係を地図にする

システムは、孤立してではなく網の目の中で失敗し、復旧は、忘れた依存関係で止まります。各重要なシステムが機能するために必要なものを地図にします。上流のサービス、DNS、アイデンティティと認証、認証局、メッセージキュー、サードパーティのAPIとSaaSプロバイダー。アプリケーションをそのデータベースやアイデンティティプロバイダーより先に立ち上げると、二つ目の停止を生むだけなので、復旧の順序に注意してください。特に外部のサプライヤーに注意を払います。あなたの復旧は彼らの復旧に上限を課され、その可視性がないかもしれないからです。この地図づくりは、レジリエンスとグレースフルデグラデーション(3.5章)に直接つながります。システムの強い依存関係が少ないほど、速く戻ります。

復旧を出来事ではなく実践としてテストする

演習していないDR計画は、作り話です。テストの梯子を築きます。机上演習は、役割、決定、コミュニケーションの隙間を見つけるために、紙の上でシナリオをチームに歩かせます。ゲームデーは、本番に近い環境に、本物の管理された失敗を注入します。完全なフェイルオーバーの訓練は、実際に復旧サイトに切り替えて、そこで動かします。これらを周期的に行い、シナリオを回し(鍵となる人やサプライヤーの喪失を含めて)、結果を測定します。達成した実際のRTOとRPOを捉え、目標と比較します。測定された復旧と約束された復旧の隔たりは、あなたが持つ最も誠実な信頼性の指標で、それを閉じることが訓練の要点のすべてです。

サイバー復旧を独自のシナリオとして計画する

ランサムウェアと破壊的なサイバー攻撃は、通常のDRの前提を壊すので、別に扱ってください。自然災害では、データは別の場所で無傷ですが、ランサムウェアの事象では、データとしばしばバックアップが武器であり、復旧環境自体が侵害されているかもしれません。クリーンルームでの復旧を計画します。不変のコピーから復元し、侵入をスキャンし、何かを再接続する前にアイデンティティと資格情報を再構築する、隔離された信頼できる環境。最後の既知のクリーンな時点がどのバックアップかを知り、それを見つけるには、通常のRTOが決して予算に入れなかったフォレンジックの時間がかかると予期してください。ここが、不変でオフラインのコピーがそのコストに見合う所で、インシデント管理(9.3章)と、侵害の取り扱いについてのコンプライアンスとガバナンスの義務(4.6章)に密接につながります。

トレードオフ: 長所と短所

DR戦略	長所	短所
バックアップと復元	最も安い。単純。低い継続コスト	遅いRTO(数時間から数日)。大きいRPO
パイロットライト	低コスト。中核のデータが温かく準備済み	手作業のスケールアップ。復旧に依然として実時間がかかる
ウォームスタンバイ	速いRTO(数分)。スタック全体が実証済み	二つ目の環境を動かす継続コスト
マルチサイトのアクティブ・アクティブ	ゼロに近いRTO。単一サイトの障害がない	最高のコストと複雑さ。一貫性が難しい
同期レプリケーション	ゼロに近いRPO	書き込みのレイテンシ。距離の制限。より強い結合
非同期レプリケーション	速く、柔軟で、地理的に自由	複製遅延に等しいデータ損失の窓

中心的な緊張は、復旧の速さとデータの鮮度がどちらもお金と複雑さがかかり、どの層でも無料ではないことです。組織ごとではなくシステムごとに解決してください。事業影響分析が各重要なシステムにRTOとRPOを割り当て、それを満たす戦略をちょうど買う。レポートツールにアクティブ・アクティブのお金を使うことは、それを必要とした元帳を飢えさせ、逆は怠慢です。規律は、支出を事業が所有する数字に合わせ、システムの重要性が変わるにつれてその対応を見直すことです。

チームで議論すべき問い

重要なシステムそれぞれのRTOとRPOは何で、事業側の誰がそれを承認しましたか。 エンジニアリングだけがこれらの数字を考案したなら、それは推測で、推測は過剰に気前よく、あるいはまったく資金を得ません。復旧時間と復旧時点の目標は、業務を中断のコストで順位づける事業影響分析から導かれるべきで、元帳には数分、内部のwikiには1日が与えられます。現在の階層づけを持ち込み、各業務プロセスに責任を負う人が、あなたが設計したデータ損失と停止時間を実際に受け入れるかを尋ねてください。大きな組織では、この会話が、すべてを均等に守るという高価な間違いを防ぎます。それは何もうまく守りません。エンジニアリングの外の誰もその数字を挙げられないなら、あなたはまだ目標を持っておらず、願いを持っているのです。
最後に本物の復元を行ったのはいつで、達成した実際のRTOとRPOを測定しましたか。 一度も復元したことのないバックアップはテストされていない想定で、あなたを殺す失敗の様式(壊れたアーカイブ、失われた暗号鍵、間違ったボリュームのスナップショット、立ち上がらない依存関係)は、試して初めて表面化します。最後の机上演習ではなく、最後の完全なフェイルオーバーの訓練の日付と結果、そして達成した復旧と約束した復旧の隔たりを持ち込んでください。大きなチームでは、一つのシステムの一度の成功した復元は、他を証明しないので、重要なシステムのどれだけの割合が、過去1年に端から端まで復旧されたかを尋ねてください。測定された隔たりが、あなたの最も誠実な信頼性の数字で、それを述べられないなら、証明されるまでは、計画は作り話です。
今夜ランサムウェアが本番を暗号化してバックアップに達したら、最後の既知のクリーンなコピーは何で、どこで再構築しますか。 通常の災害復旧は、データがどこか別の場所で安全だと想定し、破壊的なサイバー攻撃は、データとバックアップを武器にすることで、まさにその想定を壊します。少なくとも一つのバックアップのコピーが不変でオフラインか、最後のクリーンな復元の時点をどう特定するか、本番自体が侵害されているとき、信頼できるクリーンルームの環境がどこから来るかを尋ねてください。このシナリオは、通常のRTOが決して予算に入れなかったフォレンジックの時間を必要とするので、クリーンな時点を見つけるのに実際にどれだけかかるかの誠実な見積もりを持ち込んでください。企業と政府のチームにとって、これはコンプライアンスの事象(4.6章)でもあり、侵害の通知の時計が並行して走ります。答えが「最新のバックアップを復元する」なら、これをまったく計画していません。
どのシステムが、事業影響分析が正当化しない復旧の層に払っていて、どれが危険なほど守り不足ですか。 復旧の速さとデータの鮮度は、どの層でもお金がかかるので、一律の方針は、レポートツールにアクティブ・アクティブの予算を無駄にするか、それを本当に必要とした元帳を飢えさせるかのどちらかです。相反する引力は本物です。一つの標準の層は、多くのチームにとって運用がはるかに単純で、システムごとの階層づけは支出を価値に合わせますが、システムの重要性が移るにつれて継続的な選り抜きを要求します。各重要なシステムの現在のDR戦略、それが目標とするRTOとRPO、そのスタンバイとレプリケーションの月額コスト、新しい影響分析に対して階層づけが最後に見直された日付を持ち込んでください。企業あるいは政府の設定では、不一致な層はリージョンにわたって倍になり、監査は、使うお金と受け入れる露出の両方の正当化を求めるので、説明のつかないアクティブ・アクティブの請求書と、守られていない重要なサービスは、同じくらい擁護が難しいのです。
重要なシステムの復旧の順序を本当に知っていますか。そしてテストできないサプライヤーにどれだけ復旧が依存していますか。 システムは孤立してではなく網の目の中で失敗し、復旧は、誰も地図にしなかった依存関係で止まります。アプリケーションをそのデータベース、アイデンティティプロバイダー、DNSより先に立ち上げると、単に二つ目の停止を生みます。依存関係の地図づくりは退屈で、地図は古くなりますが、代わりに、フェイルオーバーの最中に復旧の順序を生で発見することになり、少数のSaaSプロバイダーへの集中リスクは、彼らが一緒に失敗して復旧に彼らの上限を課すまで見えません。現在の依存関係の地図、文書化された復旧の手順、外部のサプライヤーとその表明された復旧の約束の一覧と、そのいずれかを検証したことがあるかを持ち込んでください。大きなあるいは公的な組織では、サプライヤーの継続性と集中リスクがますます調達と規制の関心事なので、それらの復旧の義務は、ベンダーの宣伝ではなく、監査できる形で契約に属します。
今夜すべてのサーバーを復元したら、事業は実際に動き続けますか。そして誰が災害を宣言する権限を持っていますか。 災害復旧はITを復元し、事業継続は組織を機能させ続けます。人、コミュニケーション、給与計算、そして決定を下す権限を誰かが持っていることに依存する決定。すべてのシステムを復旧しても、誰が災害を宣言できるか、通常の経路も落ちているときにどうスタッフに連絡するかを誰も知らなければ、顧客の期待を裏切りえます。エンジニアリングは復旧を所有しますが、継続は、施設、人事、コミュニケーション、リーダーシップの継承にまたがり、部門間のそれらの継ぎ目が、まさに計画が静かに腐る所です。宣言の権限とエスカレーションの連鎖、代替のコミュニケーション計画、名指しされた後継者と代替施設、そしてITだけでなく事業側が計画を最後に演習した日付を持ち込んでください。政府は、名指しされた後継者と不可欠な機能を伴う、運用の継続の法的な義務を負い、企業は規制上の継続の義務に直面するので、どちらも、単にサーバーではなく、事業が悪い日を生き延びるかで判断されます。

セクター別の視点

スタートアップ。 小さなチームでほとんど滑走路がないなら、熱い二つ目のリージョンに払う余裕はないので、それでも救ってくれる安い部分を意図して選んでください。一つの誠実な復旧の層を設定し、自動化されたスナップショットと、自分の管理者が削除できない少なくとも一つの不変のコピーで3-2-1ルールに従い、ソースから再構築できるよう、環境全体をインフラストラクチャ・アズ・コードとして保ちます。手の込んだ計画は飛ばし、代わりに四半期に一度、本物の復元を捨ててよい環境に対して走らせてください。計った一度の訓練は、誰も読まないバインダーより多くを教えるからです。

小規模事業者。 専任の継続の専門家はおらず予算も厳しいので、復旧を築くものではなく買うものとして扱ってください。オーダーメイドのDRインフラストラクチャを立ち上げるのではなく、クラウドプロバイダーのマネージドなバックアップ、スナップショット、リージョン間のレプリケーションに頼り、バックアップが不変で、復元のプロセスを自分で実行できるベンダーを選びます。演習全体を、専門家なしに答えられる二つの問いを軸に枠づけてください。どれだけのデータを失えるか、どれだけ停止していられるか。そして信頼する前に、一度の復元が機能することを証明します。

大企業。 規模での問題は、多くのチームにわたるポートフォリオのガバナンスです。すべてのサービスにRTOとRPOを割り当てる事業影響分析、バックアップと復元からアクティブ・アクティブまで階層づけられた復旧戦略、集中リスクを含む上流とサプライヤーの依存関係の中央の見方。スタンバイ、レプリケーション、不変のコピーのコストに明示的に予算を付け、周期的に規制当局が立ち会う完全なフェイルオーバーを行い、実際の復旧を目標に対して、追跡される信頼性の指標として測定します。サイバー復旧を、不変の保管庫のコピーとクリーンルームのランブックを備えた独自のプログラムとして維持し、自然災害の訓練とは独立にテストします。

政府。 調達規則、透明性、公的な説明責任がすべての選択を形づくり、継続はしばしば好みではなく法的な義務です。不可欠な機能を特定し、その復旧を順序づけ、決定が認可された人の不在で止まらないよう、後継者と代替施設を名指しする運用継続のプログラムを築き、FISMAの義務を支えるNIST SP 800-34のような認められた指針に揃えます。エアギャップのバックアップのコピーを保ち、代替リージョンでの再構築のためにインフラストラクチャ・アズ・コードを定義し、年次の完全な演習に加えて、ランサムウェアの机上訓練を行い、その測定結果を、不可欠なサービスが生き延びる証拠として監督機関に報告します。

事例

スタートアップ。 12人のSaaS企業は、熱い二つ目のリージョンに払う余裕がないので、安い部分を意図して選びます。一つの誠実な層を設定します。顧客データベースのRTOは4時間、RPOは15分。3-2-1ルールに従い、自動化されたスナップショット、二つ目のクラウドのリージョンに複製された一つのコピー、自社の管理者が削除できない、ロックされた保持期間を持つ一つの不変のコピーを用意します。環境全体がインフラストラクチャ・アズ・コード(8.2章)なので、ソースから新しいスタックを立ち上げられます。四半期に一度、金曜日の午後に本物の復元を捨ててよい環境に走らせ、時間を計り、短いメモを残します。最初の訓練は9時間かかってマイグレーションの手順の欠落を見つけ、その修正のおかげで、次は3時間で済みました。

大企業。 多国籍の銀行は、重要なサービスにテスト済みの継続を義務づける規制上の復旧要件のもとで運用します。中核の銀行プラットフォームに、二つ目のリージョンでウォームスタンバイを動かし、ゼロに近いRPOのために都市圏の対の内側で同期レプリケーション、地域の災害を生き延びるために遠くのリージョンへ非同期レプリケーションを行います。事業影響分析がすべてのサービスにRTOとRPOを割り当て、中央のチームが、集中リスクとして印を付けた二つのSaaSプロバイダーを含む上流の依存関係を地図にします。年に2回、規制当局が立ち会う完全なフェイルオーバーを行い、実際を目標に対して測定し、隔たりを次の周期にフィードバックします。別のサイバー復旧のプログラムが、不変の保管庫のコピーとクリーンルームのランブックを維持し、自然災害の訓練とは独立にテストされます。

政府。 給付を提供する国の機関は、あらゆる中断の間に不可欠な機能を維持するよう築かれた、運用継続(COOP)のプログラムを維持します。運用の継続の実践と、FISMAの義務を支えるNIST SP 800-34の緊急時計画の指針に従い、不可欠な機能を特定し、その復旧を順序づけ、決定が認可された人の不在で止まらないよう、後継者と代替施設を名指しします。市民向けのシステムは文書化されたRTOとRPOを持ち、バックアップはエアギャップのコピーを伴う3-2-1ルールに従い、代替リージョンでの再構築のためにインフラストラクチャがコードとして定義されます。年次の完全な演習と、ランサムウェアのシナリオの机上訓練が、計画を測定された復旧に対してテストし、結果は、不可欠なサービスが悪い日を生き延びる証拠として、監督機関に報告されます。

ビジネスケース: 動機、ROI、TCO

DRと継続の見返りは、避けられた大惨事で、必要になるまでは評価が本当に難しく、必要になったときは痛々しいほど具体的です。リスク管理として枠づけてください。中断の期待コストは、その可能性かける影響で、大きな組織の影響は、停止1時間あたりの失われた収益から、規制上のペナルティ、侵害の通知のコスト、停止より長く続く評判の毀損まで及びます。一度の復旧不能なランサムウェアの事象が会社を終わらせ、公共部門では、不可欠な市民サービスを数週間オフラインにしました。それに対して、テストされた復旧能力のコストは控えめで、知ることができます。

総所有コスト(TCO)は本物で継続的です。スタンバイのインフラストラクチャ、レプリケーションの帯域、バックアップのストレージ(不変とオフラインのコピーで倍増)、自動化を築いて訓練を行うエンジニアリングの時間。まさにこれが、どこでもアクティブ・アクティブを買うのではなく、RTOとRPOで階層づける理由で、支出が一律の方針ではなく各システムの価値に追随します。リーダーシップに論拠を示すには、計画を彼らの言葉に翻訳してください。今日耐えられる停止時間とデータ損失はこれ、目標への隔たりはこれ、それを閉じるコストはこれ、そうしなければ露出はこれ。最も説得力のある成果物は、測定された訓練です。実証した復旧は、リーダーシップが信頼できる数字であり、テストされていない計画は、資産を装った負債だからです。

アンチパターンと落とし穴

テストされていないバックアップ。 一度も行ったことのない復元は願いで、訓練こそ、壊れたデータ、欠けた鍵、間違ったボリュームを見つける所であること。
本番から到達可能なバックアップ。 ランサムウェアがバックアップを暗号化あるいは削除できるなら、三つではなく一つのコピーしかないこと。一つを不変でオフラインに保つ。
すべてに一つのRTOとRPO。 一律の層は、些細なものを過剰に守り、重要なものを守り不足にすること。事業影響分析から階層づけること。
DRとBCPの混同。 誰が災害を宣言するか、どうスタッフに連絡するかを誰も知らないままですべてのサーバーを復元することは、復旧したシステムと失敗した事業であること。
手で作った復旧環境。 コードから再構築できないインフラストラクチャはずれ、ずれはフェイルオーバーの最中に発見されること。
無視された依存関係。 アプリをそのデータベース、アイデンティティプロバイダー、DNSより先に復旧すると、二つ目の停止を生むだけであること。
計画の腐敗。 一度書かれて演習されないバインダーは、もう存在しないシステムを記述していること。
サプライヤーの死角。 復旧は重要なサプライヤーの復旧に上限を課され、集中リスクは彼らが一緒に失敗するまで見えないこと。

成熟度モデル

レベル1: 開始: 復旧はその場しのぎで反応的です。バックアップは動いているかもしれませんが、復元はテストされていません。合意されたRTOもRPOもなく、事業影響分析もなく、復旧はインシデントの間に即興されます。深刻なデータ損失やランサムウェアの事象は、おそらく復旧不能です。
レベル2: 発展: 基本的な実践は存在しますが、チーム間で一貫していません。一部の重要なシステムは3-2-1ルールに従うバックアップを持ち、最も重要なサービスには文書化されたRTOとRPOがあり、基本的なDR計画が存在して復元が時折テストされます。カバレッジは部分的で、依存関係は地図にされておらず、訓練はその場しのぎで、あるチームの規律が次のチームの規律を意味しません。
レベル3: 標準化: 復旧の実践は文書化され、組織全体で徹底されます。事業影響分析がシステムにわたる階層化されたRTOとRPOを駆動し、復旧戦略はそれらの層に合わせられ、環境はインフラストラクチャ・アズ・コードで、依存関係と復旧の順序が地図にされ、予定された訓練(机上、ゲームデー、フェイルオーバー)が定義された周期で走ります。不変でオフラインのコピーを伴うサイバー復旧の計画は、個々のチームに任されるのではなく、文書化されて一貫して適用されます。
レベル4: 管理: 復旧が、ベースラインに対して測定され制御されます。すべての訓練が、達成された実際のRTOとRPOを捉えて目標への隔たりを追跡し、復元の成功率、過去1年に端から端まで復旧された重要なシステムの割合、バックアップのカバレッジと不変性、本当のRPOとしての監視された複製遅延といった指標が、ダッシュボードで報告されます。逸脱は行動を引き起こし、階層づけはシステムが実際にどう使われるかのデータから再導出され、実行か中止かの決定は、スライドに書かれた数字ではなく証拠に基づきます。
レベル5: オーケストレーション: 復旧は継続的に改善され、組織全体に統合され、適応的です。フェイルオーバーとサイバー復旧のクリーンルームでの復元は日常としてリハーサルされ、サプライヤーと集中リスクは積極的に管理され、継続は信頼性(9.1章)とインシデント対応(9.3章)と統合されているので、組織は、見たことのない失敗から予測可能に回復し、システムの状況と脅威の状況が移るにつれて、復旧の姿勢の範囲を見直します。

議論のためのアイデア

重要なシステムのうち、端から端まで復元されたことがないのはどれで、それができると証明するには何が必要ですか。
主要なクラウドのリージョンを丸一日失ったら、どの業務プロセスが止まり、どの順序でシステムを復旧させますか。
自分の復旧を見ることもテストすることもできないサプライヤーに、復旧のどれだけが依存していますか。
事業影響分析が正当化しない復旧の層に払っているのはどこで、守り不足なのはどこですか。
今夜バックアップが到達可能で暗号化されたら、本当の最後の既知のクリーンな復元の時点は何ですか。
約束したRTOとRPOと、最後の訓練が実際に達成したものとの、誠実な隔たりは何ですか。

要点

継続が目標で、復旧は手段である。 事業継続計画は組織を動かし続け、災害復旧はそれが依存するITシステムを復元します。
RTOとRPOがすべてを駆動する。 どちらも事業影響分析から来るもので、エンジニアリングの推測ではありません。すべてを等しく守るのではなく、システムを階層づけます。
テストされていないバックアップはバックアップではない。 3-2-1ルールに従い、ランサムウェアに備えて少なくとも一つの不変でオフラインのコピーを保ち、復元を予定に沿ってテストします。
DR戦略を数字に合わせる。 バックアップと復元、パイロットライト、ウォームスタンバイ、アクティブ・アクティブを、各システムのRTOとRPOで選びます。
レプリケーションは一貫性を鮮度と交換する(3.3章)。本当のRPOは設計書ではなく、複製遅延です。
コードから再構築する。 インフラストラクチャ・アズ・コード(8.2章)で、必要になる前に依存関係を地図にします。
机上演習、ゲームデー、完全なフェイルオーバーの訓練でテストし、実際のRTOとRPOを目標に対して測定します。
サイバー復旧を別に計画し、クリーンルームでの復元を備え、実践全体を信頼性(9.1章)、インシデント対応(9.3章)、コンプライアンス(4.6章)につなげます。

参考文献とさらなる読み物

ISO 22301, Security and resilience: Business continuity management systems: Requirements (the international standard for BCP).
National Institute of Standards and Technology, SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems (RTO, RPO, and recovery strategies for government systems).
National Institute of Standards and Technology, SP 800-61 Rev. 2: Computer Security Incident Handling Guide (incident and cyber-recovery handling).
U.S. Federal Emergency Management Agency, Continuity Guidance Circular and federal COOP guidance (essential functions and continuity of operations).
Federal Financial Institutions Examination Council (FFIEC), Business Continuity Management booklet (regulatory recovery expectations for financial institutions).
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, eds., Site Reliability Engineering: How Google Runs Production Systems (reliability and disaster testing).
Kelly Shortridge and Aaron Rinehart, Security Chaos Engineering (deliberately exercising failure and recovery).
Cybersecurity and Infrastructure Security Agency (CISA), #StopRansomware Guide (ransomware prevention and recovery practice).