フェイルオーバーテスト：机上演習とDR訓練

一度もテストされていない災害復旧計画は、単なる文書にすぎません。実際の保証がないまま、誤った安心感を与えます。実際の災害時に初めて発覚し、テストされていない計画では見つからない一般的な問題には、古い連絡先リスト（重要な担当者の役割が変わった、または退職している）、ソフトウェアのバージョン不一致によるバックアップ復元の失敗、計画では30分と想定していたのに復元に4時間かかるシステム、災害の宣言権限を持つ人物が誰なのか分からない意思決定権限の空白などがあります。テストを行えば、危機の最中ではなく、管理された環境でこうした問題を明らかにできます。

DRおよびBCPのテストは、複雑さと現実性が段階的に増す幅広い範囲で実施されます。文書レビューは、計画が最新かつ完全であることを確認するもので、最低限の基準です。テーブルトップ演習では、システムを稼働させずに議論を行います。ウォークスルー訓練では、参加者が手順を口頭で確認します。機能演習では、コールツリーや部分的なシステムフェイルオーバーなど、特定のコンポーネントを稼働させます。フルスケールテストでは、実際にDRインフラストラクチャへ切り替え、代替サイトから業務を運用します。段階が上がるほど、コストと中断の影響は大きくなりますが、より高い確信を得られます。

テーブルトップ演習では、主要なステークホルダーが集まり、実際のシステムを稼働させずに、想定した災害シナリオを口頭で確認します。ファシリテーターが「月曜日の朝、ランサムウェアによってプライマリデータベースサーバーが暗号化され、ネットワーク全体に拡散しているというアラートを受け取りました。どうしますか」とシナリオを提示します。参加者はリアルタイムで対応し、意思決定権限、コミュニケーションプロトコル、復旧手順に関する知識の不足を明らかにします。しかも、業務を中断する必要はありません。

機能演習では、DR計画を全面的に発動することなく、特定のコンポーネントをテストします。例として、コールツリーテスト（午前2時にすべての緊急連絡先へ実際に電話し、番号が正しく、担当者が目標時間内に応答することを確認する）、バックアップ復元テスト（バックアップからテスト環境へデータベースを復元し、データの整合性を確認する）、フェイルオーバーテスト（重要度の低い単一のアプリケーションをDRサイトへフェイルオーバーする）、通信システムテスト（帯域外通信チャネルを使用して模擬インシデントの対応を調整する）があります。それぞれの機能演習によって、計画の特定のコンポーネントを検証できます。

フルスケールDR訓練では、実際に本番業務をDRサイトへ切り替え、復旧プロセス全体が機能することを検証します。組織は代替サイトを稼働させ、バックアップからシステムを読み込み、DNSをDR環境へ向け直し、実際の業務運用を試みます。フルスケールテストでは、復旧全体に実際どのくらい時間がかかるのか、すべてのアプリケーションがDRサイトで機能するのか、ネットワーク構成がすべて正しいのか、監視ツールとアラートツールがDR環境で機能するのかという重要な疑問に答えられます。これらのテストは費用が高く、業務への影響も大きいものの、最も高い確信を得られます。

DR演習では、RTOおよびRPOの目標に対する実際のパフォーマンスを測定する必要があります。訓練中は、DRサイトで各システムが起動した時刻、最初のユーザーが正常に認証され各アプリケーションを使用できるようになった時刻、システムがオンラインになった時点でのデータの経過時間、そして「災害宣言」から「業務復旧」までの総経過時間を記録します。これらをRTOおよびRPOの目標と比較します。目標と実績の間にあるすべての差異から、次回の演習までに行うべき具体的な改善点が明らかになります。

結果にかかわらず、すべてのDR演習ではAfter-Action Report（AAR）を作成する必要があります。AARには、テストしたシナリオ、うまくいった点、失敗した点または計画より時間がかかった点、特定された具体的なギャップ、担当者と目標完了日を含む優先順位付きの改善項目一覧を記録します。AARは経営幹部と共有し、プログラムの成熟度を示すとともに、特定されたギャップへの投資の必要性を説明します。AARのアクションアイテムを文書化してフォローアップしなければ、演習で明らかになった問題が修正されないまま残ってしまいます。

大規模なDRテストには、2つのアプローチがあります。切り替えテストでは、実際に本番トラフィックをDRサイトへ切り替えます。現実的である一方、DRサイトに障害が発生すると長時間の停止につながるため、高リスクです。並行テストでは、本番環境と並行してDR環境を起動し、本番環境が実際のユーザーへのサービスを継続する間にテストトラフィックをDRへルーティングします。本番環境が稼働し続けるため、低リスクでDRの機能を検証できます。多くの組織では、重要システムには並行テストを使用し、重要度の低いシステムや計画メンテナンス時間帯には切り替えテストを使用します。

明確な災害宣言プロセスは不可欠です。DRをいつ起動するかが曖昧だと、危険な遅延が発生するためです。計画には、DRの起動を自動的にトリガーする、具体的で測定可能な基準を定義する必要があります。たとえば、「プライマリデータセンターに2時間を超えてアクセスできない場合」や、「本番サーバーの50%超が利用できない場合」などです。また、誰が災害を宣言する権限を持つか（通常はCIOまたはCTO。不在時に備えて代理人も指名します）、その権限者に連絡できる24時間365日の電話番号、第一権限者に連絡できない場合の明確なエスカレーション経路も計画に定義する必要があります。

テストの頻度は、システムの重要度と環境の変化の速さに合わせる必要があります。業界のベストプラクティスでは、テーブルトップ演習を四半期ごと（低コストで効果が高く、スキルを維持できる）、機能演習を半年ごと（特定のコンポーネントをテストする）、大規模なDR訓練を年1回（計画全体を完全に検証する）、そして抜き打ちテストを少なくとも年1回（事前準備なしでチームが対応できるかをテストする）実施します。クラウド移行、新しいアプリケーションのデプロイ、データセンターの移転など、重要なインフラ変更があった場合は、更新したDRテストを実施する必要があります。

多くの規制フレームワークでは、特定の頻度と文書化要件を伴うDRテストが義務付けられています。HIPAAでは、対象事業者に対して、コンティンジェンシープランを定期的にテストおよび改訂することを求めています。PCI-DSS Requirement 12.10では、インシデント対応計画を少なくとも年1回、また重要な変更があった際にテストすることを求めています。銀行を対象とするFDICおよびOCCのガイダンスでは、取締役会への報告を伴うBCPテストを年1回実施することを求めています。SOC 2 Type IIの監査人は、BCP/DRPテストの頻度、結果、特定されたギャップの是正に関する証拠を確認します。監査人による確認に備え、すべてのテスト、結果、是正措置の証拠を文書化して保管してください。

このレッスンでは、DRテストは、テーブルトップディスカッションから機能演習、大規模な訓練へと、現実性とコストが高くなる順に進めること、すべてのテストでRTOおよびRPOの目標に対する実際のパフォーマンスを測定する必要があること、そして担当者を割り当てたアクションアイテムを含むAfter-Action Reportにより、次のインシデントが発生する前に特定された弱点を是正できることを学びました。Business Continuity and Disaster Recoveryモジュールの修了、おめでとうございます。次は高度な脅威のトピックに進む準備が整いました。