事業継続計画（BCP）と災害復旧計画（DRP）とは何か？
事業継続計画は、組織の業務を中断時にも維持するためのものであり、災害復旧計画は技術的障害発生後にITシステムを復旧するためのものです。両者は連携して機能する必要があり、ランサムウェアの事例がその理由を明確に示しています。
午前2時47分、ランサムウェアが本番システムをロックします。午前3時15分までにSOCが脅威を封じ込めますが、業務は依然として停止したままです。復旧には、4つの異なる運用タイムラインの連携が必要です：
- インシデント対応が最初に行われ、SOCが技術的な封じ込めを実施します。
- 危機管理が続き、セキュリティリーダーが経営層や関係者と連携します。
- 事業継続は、復旧作業中も組織の業務を維持します。
- 災害復旧は、事業継続目標を満たすためにITシステムを復旧します。
NIST SP 800-34 Rev. 1によると、事業継続計画は「重大な中断時およびその後に、組織のミッション／業務プロセスをどのように維持するかを記述した、あらかじめ定められた指示または手順」を提供します。BCPは、「通常業務が停止した際に、どのようにサービス提供を継続するか」という問いに答えます。
災害復旧計画は、より限定的な範囲を対象とします。NISTはDRPを「主要なハードウェアまたはソフトウェア障害、または施設の破壊に対応して、1つまたは複数の情報システムを代替施設で復旧するための文書化された計画」と定義しています。DRPは、技術的障害や破壊イベント後のITインフラ、アプリケーション、データの復旧に特化しています。
ランサムウェアが発生した場合、インシデント対応チームは数分から数時間で脅威を封じ込めます。危機管理は数時間から数日にわたり関係者を調整します。事業継続プロセスは、災害復旧チームが復旧システムのセキュリティベースラインを検証する間、数日から数週間にわたり業務を維持します。各計画は異なる対応フェーズを担い、それぞれに独自の計画、テスト、責任が必要です。サイバー攻撃の頻度が増加する中、この連携はかつてないほど重要になっています。
.jpg)
事業継続と災害復旧がサイバーセキュリティとどう関係するか
ランサムウェアは復旧計画を変化させました。ハードウェア障害向けに設計されたバックアップシステムは、攻撃者がデータ保護基盤を狙う際の主要な標的となります。 CISA NICE Frameworkでは、 サイバーレジリエンス職種の必須能力としてデータボールティング原則（K1278）が追加されており、イミュータブルバックアップが災害復旧のベストプラクティスから不可欠な サイバーセキュリティフレームワークコントロールへと進化したことを示しています。
復旧指標は財務的リスクを示します。 IBM Cost of a Data Breach Reportによると、ランサムウェアや恐喝による侵害の平均コストは5.08百万ドルで、全体の侵害平均（4.44百万ドル）より約14%高くなっています。 FEMAによれば、災害後に再開できない企業は40%、さらに1年以内に25%が廃業しています。
実際の攻撃事例は、サイバーインシデントと事業継続の失敗が相互に悪影響を及ぼすことを示しています。Colonial Pipelineの停止、NotPetyaによるMaerskのITインフラ全損、JBS Foodsの工場閉鎖など、いずれもランサムウェアが技術的被害を超えて連鎖的な業務中断を引き起こしました。
サイバーインシデントでは、4つの運用タイムラインすべてで連携した対応が必要であり、セキュリティプラットフォームは各フェーズの進行速度に直接影響します：
- インシデント対応（数分～数時間）： SOCが技術的封じ込め手順を実行します。セキュリティプラットフォームが脅威を迅速に検出することでこのタイムラインは短縮され、 Singularity Platformはアラート数を88%削減し、SOCが初期封じ込めから検証済み復旧まで迅速に進めます。
- 危機管理（数時間～数日）： セキュリティリーダーが経営層、取締役、規制当局、顧客と連携します。
- 事業継続（数日～数週間）： クロスファンクショナルチームがシステム停止中も業務を維持します。
- 災害復旧（数週間以降）： セキュリティエンジニアリングが復旧システムのセキュリティベースライン適合を検証し、本番復帰を判断します。
これらの長期化したタイムラインは、RTOおよびRPOの計算方法を変化させます。復旧はインフラ障害時の即時復旧とは異なり、4つの運用フェーズ全体にわたって進行します。セキュリティアーキテクチャは、攻撃シナリオも考慮する必要があります。マルチクラウド戦略はデータを複数プロバイダーに分散し、単一バックアップリポジトリの侵害リスクを低減します。バックアップデータが侵害された認証情報によって暗号化や削除されないデータボールティングも、同様の理由で不可欠なコントロールとなっています。
事業継続計画と災害復旧計画の範囲の違いを理解することで、より効果的なレジリエンスプログラムの構築が可能になります。
事業継続計画と災害復旧計画の主な違い
BCPとDRPは、レジリエンスプログラムの構築やセキュリティリソース配分に影響する7つの主要分野で異なる役割を果たします。
- 範囲： BCPは組織全体の業務およびミッションクリティカルなビジネスプロセスを包含します。DRPはITシステム、情報システム、技術インフラに特化します。
- 目的： BCPは中断時およびその後の業務維持を目的とします。DRPはインシデントによる技術的障害後のIT機能回復を目的とします。
- 時間的焦点： BCPはインシデントの前・最中・後に積極的かつ継続的に発動します。DRPは特定の災害発生時に技術的復旧が必要となった場合に発動します。
- カバレッジの広さ： BCPは人、プロセス、施設、サプライチェーン、コミュニケーション、技術全般を対象とします。DRPは技術インフラ、システム、アプリケーション、データ復旧に集中します。
- 復旧指標： BCPは組織レベルの業務プロセスや運用能力のRTO・RPOを定義します。DRPはシステム、アプリケーション、データ復旧のための技術的RTO・RPOを定めます。
- 組織統合： BCPは組織全体を統合する戦略的枠組みとして機能します。DRPはBCPの中の戦術的コンポーネントとして運用されます。
- 計画発動トリガー： BCPは業務に影響する重大な中断時に発動します。DRPはITシステム障害、データ損失、技術インフラ損傷時に発動します。
これらの違いが、各計画に必要な具体的コンポーネントを決定します。
事業継続計画と災害復旧計画の必須コンポーネント
事業継続計画には災害復旧計画とは異なるコンポーネントが必要ですが、両者はサイバーレジリエンスのために統合されなければなりません。以下は各計画に必要な要素と重複部分の内訳です。
DRI InternationalおよびFEMAのガイダンスによれば、BCPには以下が含まれる必要があります：
- 代替要員を含む復旧チーム
- 移動やリソースのためのロジスティクス文書
- デスクトップシステム、重要記録、通信インフラの要件
- 代替拠点のための主要連絡先と機器
DRPには、BCP目標を支援する技術特有のコンポーネントが必要であり、特に ランサムウェアからバックアップインフラを保護することが重視されます。主なDRPコンポーネントは以下の通りです：
技術的機能のための代替要員を含む復旧チーム
- バックアップシステムをカバーするデータおよびストレージ要件（ランサムウェアによる暗号化や削除を防ぐイミュータブルリポジトリ）
- ネットワーク帯域幅、電話交換機、代替拠点用ルーターなどの音声・データ通信ハードウェア仕様
- インフラ仕様（電源/PDU、発電機/UPS、冷却システム、配線）を含むハードウェア・ソフトウェア要件
- ファイアウォールや認証システムなどのセキュリティコントロール
- アプリケーション相互依存マップおよび体系的復旧のための詳細な技術手順
各コンポーネントは、BCPで定義されたビジネス要件に紐付ける必要があります。
FEMAのIT災害復旧ガイダンスによれば、計画にはビジネスインパクト分析で策定された優先順位と復旧時間目標が含まれていなければなりません。技術復旧戦略は、ハードウェア、アプリケーション、データをビジネス復旧時間内にどのように復旧するかを明記する必要があります。データバックアップとリカバリは、ネットワークサーバー、デスクトップ、ノートPC、ワイヤレスデバイス全体のデータを対象とする不可欠な要素です。
これらのコンポーネントは計画策定プロセスを推進しますが、各計画に何が必要かを知ることは第一歩に過ぎません。
事業継続計画と災害復旧計画の構築方法
効果的な計画を構築するには、ビジネス要件と技術的復旧能力を結びつける一連のプロセスが必要です。NIST SP 800-34は、BCPおよびDRPの策定に適用できる 7段階のコンティンジェンシープランニングプロセスを定めています。
以下の5つの主要ステップは、そのフレームワークを両計画構築の実践的ワークフローに適用したものです：
- ビジネスインパクト分析の実施。 BIAは、どのビジネスプロセスがミッションクリティカルかを特定し、その中断による運用・財務上の影響を定量化します。各部門責任者やプロセスオーナーにヒアリングし、各機能がどれだけ停止しても許容できるかを判断します。これらの許容閾値がRTO・RPO目標となります。
- リスク評価と脅威マッピング。 BIAで特定した重要機能に対し、ランサムウェアやインフラ障害、自然災害、サプライチェーン中断など各脅威の発生可能性と影響度を評価します。この評価により、計画で対応すべきシナリオと予防コントロールへの投資優先度が決まります。
- 復旧戦略の策定。 BCP戦略は、中断時に各重要業務をどのように維持するか（代替作業場所、手作業対応、通信プロトコル、サプライチェーン代替）を定めます。DRP戦略は、各技術システムをどのように復旧するか（バックアップ・リカバリ手順、フェイルオーバー構成、代替サイト起動、データ復元手順）を明記します。
- 明確な責任の割り当て。 BCPは、運用、コミュニケーション、人事、法務、財務を横断するリーダーシップが必要です。DRPは、ITおよびセキュリティチームによる技術的責任と、各重要役割の代替要員が必要です。エスカレーション経路と意思決定権限を文書化し、承認待ちせずに高圧下でも行動できるようにします。
- 運用詳細を含めて文書化。 手順書、連絡先リスト、ベンダー契約、ネットワーク図を含めます。会議室で読めるだけの計画ではなく、実際のインシデント時に機能する運用詳細が不可欠です。
実際のインシデントは、これらのステップを誤るコストを示しています。 Colonial Pipelineランサムウェア攻撃（2021年5月）は、インシデント対応・事業継続・災害復旧の連携不足がもたらす結果を示しました。同社は米国南東部に燃料を供給する5,500マイルのパイプラインを停止し、440万ドルの身代金を支払い、大統領による緊急宣言を要する燃料不足を引き起こしました。 NotPetya攻撃では、Maerskが4万5千台のPCと4千台のサーバーを失い、10日間でITインフラをゼロから再構築し、約3億ドルの損失を被りました。
いずれの事例も、計画策定プロセスがインフラ障害だけでなく攻撃シナリオも考慮すべき理由を示しています。計画が完成したら、次はその成否を左右する復旧指標の定義です。
RTOとRPO：事業継続と災害復旧のための復旧指標
復旧時間目標（RTO）と復旧時点目標（RPO）は、事業継続計画および災害復旧計画における最重要な サイバーセキュリティ指標です。BIAプロセスでこれらの目標を策定し、BCP・DRPのすべての復旧戦略はこれらに紐付ける必要があります。
復旧時間目標（RTO）
RTOは、業務プロセスが中断しても許容できる最大期間を定義します。午前2時47分にランサムウェアが本番環境をロックした場合、RTOが午前8時の営業開始までの復旧を求めるのか、業務終了までの中断を許容するのかを決定します。
ランサムウェア復旧は、 フォレンジック調査、マルウェア駆除検証、セキュリティ検証が必要なため、複雑さが増します。従来のRTO前提は、インシデント直後に復旧を開始できるものでしたが、サイバーインシデントでは実際の復旧期間が数時間から数日、場合によっては数週間に延びるため、現実的な指標の再計算が不可欠です。
復旧時点目標（RPO）
RPOは、通常業務再開に必要なバックアップデータの最大許容古さを定義します。最後のクリーンなバックアップが深夜で、午前2時47分にランサムウェアがシステムを暗号化した場合、2時間47分分の取引データ損失の可能性があります。RPOは、このデータ損失が許容範囲か否かを決定します。
Singularity Platformのロールバック機能は、フォレンジック調査中でもシステムを感染前の状態に復元できるため、RPO課題に対応します。
規制要件
規制フレームワークは、両指標に関する必須要件を定めています。 PCI DSSは決済カード処理業者に災害復旧計画を要求し、 HIPAAはePHI保護のためにRTO・RPOを定めた計画を義務付けています。 CISAのNICE Frameworkでは、イミュータブルバックアップ基盤がRPO目標達成に直結することを認識し、データボールティング原則（K1278）を必須能力としています。
これらの指標を定義するだけでは不十分です。RTO・RPO目標は、現実的な条件下で有効性を証明して初めて意味を持ちます。
テスト、保守、実装のベストプラクティス
コンプライアンスのための形式的なチェックボックスを超えたテストプログラムだけが、事業継続計画と災害復旧計画が必要な時に機能するかどうかを検証できます。
ISO 22301の8.5項は、計画がタイムリーかつ効果的な戦略であることを検証するための事業継続演習を要求しています。 NIST SP 800-34は、計画のテスト、トレーニング、演習を7段階プロセスの第6ステップとしています。DRI International Professional Practice Eightは「事業継続計画の演習／テスト、評価、保守」を統合能力として扱います。
FINRA Rule 4370は、規制対象企業に対し「BCPが更新されていること、およびミッションクリティカルなシステムやプロセスの機能に特に関して、その有効性を評価する」ための最低年1回のテストを義務付けています。金融サービス業で運用する場合、少なくとも年1回のテストが必要です。 Purple AIは、セキュリティデータへの自然言語アクセスを提供し、アナリストがテレメトリを横断的にクエリして復旧準備状況を迅速に確認できるため、この検証テストを加速します。
計画の保守は、単なる定期レビューではなく、変更駆動型の更新が必要です。ISO 22301のマネジメントレビュー要件は、「BCMSに関連する外部・内部課題の変化」や「BIAおよびリスクアセスメントからの情報」を考慮することを求めています。FINRAの規制ガイダンスも、「業務、組織構造、ビジネス、所在地の変更に応じてBCPを見直し、必要に応じて更新する」ことを要求しています。
新しいアプリケーションの導入、クラウドサービスへの移行、企業買収、新たな脅威の出現などは、計画の見直しを必須とします。技術スタックやビジネスモデルの変化はBCP・DRPの更新を要し、12か月経過のみでは十分ではありません。
実装アプローチは、NIST SP 800-34で定められた7段階プロセスに従うべきです：
- 組織のコミットメントとガバナンス構造を定めるコンティンジェンシープランニング方針の策定
- 実際のビジネス許容度に基づくRTO・RPO要件を体系的に決定するビジネスインパクト分析（BIA）の実施
- 予防コントロールの特定
- BIAの結果に基づく技術復旧および事業継続戦略の策定
- 情報システムコンティンジェンシープランの作成
- 計画のテストとトレーニングによる運用能力への転換
- Plan-Do-Check-Act手法による定期的な更新による計画の維持
ISO 22301の5項は、事業継続リーダーシップと監督責任を経営層および取締役会に割り当てています。リーダーシップは、戦略的方向性に沿った事業継続方針を策定・文書化し、この責任をITやセキュリティ部門だけに委任してはなりません。
バージョン管理と変更管理の徹底は、成熟したプログラムと単なるコンプライアンス対応を分ける要素です。DRI International Professional Practice 8は、変更管理プロセスの監査と厳格なバージョン管理の維持を要求しています。これらのガバナンス実践により、サイバーインシデント発生時にも計画が実行可能な状態を維持でき、適切なセキュリティプラットフォームが各フェーズの実行を迅速化します。
SentinelOneによる事業継続と災害復旧の強化
事業継続と災害復旧の有効性は、インシデント対応（数分～数時間）、危機管理（数時間～数日）、事業継続（数日～数週間）、災害復旧（数週間以降）の4つの運用タイムラインの連携に依存します。 Singularity Platformは、インシデント対応時に脅威を迅速に検出し、セキュリティベースラインを満たす検証済み復旧を可能にすることで、これらのタイムラインを短縮します。アラート数が88%削減されることで、SOCはトリアージに費やす時間を減らし、復旧推進により多くの時間を割けます。
Purple AIは、4つのフェーズすべてで調査と対応を加速し、アラートのコンテキスト要約、次のステップの提案、生成AIとエージェントAIによる詳細調査の開始を可能にします。アーリーアダプターは 脅威調査が80%高速化したと報告しています。
事業継続計画の実行は、調査中に一部業務機能を維持しつつ、感染端末を隔離できることで向上します。 Singularity Endpointは、異常行動分析と静的AIモデルによりランサムウェアをリアルタイムで検出し、ワンクリックロールバックで感染前状態への迅速な復元を実現します。これにより、業務全体の停止ではなく、業務継続を維持できるため、BCPの中核目標を達成できます。
SentinelOneのデモをリクエストし、Singularity Platformが事業継続および災害復旧戦略をどのように強化するかをご確認ください。
主なポイント
事業継続計画は中断時に組織の業務を維持し、災害復旧計画は技術的障害後にITシステムを復旧します。両者は連携して機能する必要があり、特にランサムウェア事案では、復旧前にフォレンジック調査とセキュリティ検証が求められます。
RTOおよびRPOの計算は、インシデント対応、危機管理、事業継続、災害復旧の各フェーズにまたがるサイバーインシデントの長期化を考慮する必要があります。テストは継続的なプログラム要件であり、規制業界では最低年1回の要件があり、業務や脅威の変化に応じて計画の有効性を維持します。
よくある質問
事業継続計画（BCP）は、組織全体の人員、プロセス、施設、テクノロジーに対応し、混乱時にも業務を維持します。災害復旧計画（DRP）は、技術的な障害や破壊的な事象の後にITシステム、アプリケーション、データを復旧することに特化しています。
BCPは戦略的な枠組みであり、DRPはその中の戦術的な要素として機能します。特に復旧に数週間を要するランサムウェアのシナリオでは、両者を連携させることが必要です。
BCPはランサムウェア調査に数日から数週間かかる間も業務を維持し、DRPは検証済みのセキュリティベースラインで技術システムを復旧します。
標準的なDRPプロセスはバックアップからの即時復旧を前提としていますが、ランサムウェアの場合はフォレンジック保全、マルウェア除去の検証、セキュリティ強化が本番環境への展開前に必要です。BCPはこの長期的な復旧期間中も業務を維持します。
SOCが即時のインシデント対応を実施し、セキュリティリーダーシップが危機管理を調整、クロスファンクショナルチームが事業継続を維持し、セキュリティエンジニアリングが災害復旧を検証します。
この4段階の責任モデルは、インシデント対応が数分から数時間、危機管理が数時間から数日、事業継続が数日から数週間、災害復旧が数週間以降という異なる運用タイムラインを反映しています。
インフラ障害では通常、即時の復旧開始が可能です。サイバーインシデントでは、フォレンジック調査、脅威の除去、セキュリティ検証が復旧開始前に必要です。
RTOはこの調査フェーズをすべての運用タイムラインで考慮する必要があり、許容される復旧時間が数時間から数日または数週間に延長されます。RPOはバックアップリポジトリが改ざん不可かつアクセス可能であることを保証しなければなりません。
FINRAルール4370は、規制対象の金融機関に対し年1回のテストを最低要件としています。テストではBCPの更新と有効性、特にミッションクリティカルなシステムや主要人員の可用性を確認する必要があります。
成熟したプログラムでは、四半期ごとのテーブルトップ演習、半年ごとの技術的復旧訓練、年1回の大規模シミュレーションを実施しています。
