マルウェア感染被害、特にランサムウェア攻撃による事業停止は、平均で数日から数週間に及び、その間の損失は甚大です。従来の自然災害を想定したBCP(事業継続計画)だけでは、サイバー攻撃特有の課題に対応できません。本記事では、サイバーインシデントに特化した事業継続計画の策定方法を、業務影響分析(BIA)、RTO/RPO設定、復旧戦略の選択、訓練計画まで体系的に解説します。経営層が果たすべき役割と意思決定のポイントも含め、組織のサイバーレジリエンス向上に必要な知識をお伝えします。
サイバーインシデントと事業継続の関係
サイバー攻撃による事業中断は、自然災害とは根本的に異なる特性を持ちます。BCP/DRの観点から、その違いを理解することが対策の第一歩です。
従来BCPとサイバーBCPの違い
| 観点 | 自然災害型BCP | サイバー攻撃型BCP |
|---|---|---|
| 被害の性質 | 物理的損壊(建物、設備) | 論理的破壊(データ、システム) |
| 被害範囲の特定 | 比較的明確 | 調査に時間を要し、拡大する可能性 |
| バックアップの有効性 | 地理的分散で保護可能 | バックアップ自体が破壊される可能性 |
| 復旧の複雑さ | インフラ再構築が中心 | セキュリティ確保が前提条件 |
| 再発リスク | 同一災害の再発は稀 | 攻撃者が再侵入する可能性 |
| 風評リスク | 比較的限定的 | 情報漏洩による信用失墜 |
サイバー攻撃特有の課題
- 被害の長期化
- ランサムウェア攻撃の場合、復旧に平均で数日から数週間かかるケースが報告されています。原因調査、セキュリティ確保、段階的復旧という手順を踏むため、自然災害よりも復旧に時間を要します。
- 二次被害・風評被害
- 情報漏洩が発生した場合、顧客の信頼失墜、株価下落、訴訟リスクなど、事業中断以外の被害が発生します。これらへの対応も事業継続計画に含める必要があります。
- サプライチェーンへの影響
- 自社のシステム停止が取引先の業務に影響を与え、サプライチェーン全体に波及するリスクがあります。契約上の責任問題にも発展する可能性があります。
事業継続に関する統計
- サイバー攻撃による平均ダウンタイム
- ランサムウェア攻撃後の平均ダウンタイムは、業界や準備状況により異なりますが、数日から3週間程度という調査結果が複数あります。中小企業では復旧に1か月以上かかるケースも報告されています。
- 事業停止による損失額
- ダウンタイムによる損失は、業種によって1時間あたり数十万円から数千万円に達します。これに加えて、復旧費用、調査費用、法的対応費用、信用回復費用が発生します。
- 復旧不能による廃業
- 深刻なサイバー攻撃を受けた中小企業の一部は、数年以内に事業継続が困難になるという調査もあります。事業継続計画の有無が企業の存続を左右する可能性があります。
業務影響分析(BIA)の実施
BIA(Business Impact Analysis:業務影響分析)は、事業継続計画策定の出発点です。どの業務・システムがどの程度重要かを明確にし、復旧の優先順位を決定します。
BIAの目的と進め方
- 重要業務の特定
- 組織の存続に不可欠な業務(コア業務)を特定します。売上に直結する業務、法的義務のある業務、停止すると取り返しがつかない業務などが対象です。
- 依存リソースの洗い出し
- 各重要業務を支えるリソース(ITシステム、人員、設備、外部サービス)を洗い出します。ITシステムだけでなく、人的リソースや外部依存も考慮します。
- 許容停止時間の決定
- 各業務・システムが停止した場合、どの程度の期間まで許容できるかを、業務部門と協議して決定します。
| BIA実施ステップ | 内容 | 参加者 | 所要期間目安 |
|---|---|---|---|
| 1. 準備 | BIA計画策定、ヒアリング対象選定 | BCP担当、経営企画 | 1〜2週間 |
| 2. 情報収集 | 業務部門へのヒアリング、現状調査 | 全業務部門 | 2〜4週間 |
| 3. 分析 | 影響度評価、依存関係整理 | BCP担当、IT部門 | 2〜3週間 |
| 4. 優先順位付け | 復旧優先順位の決定 | 経営層、業務部門 | 1〜2週間 |
| 5. 文書化 | BIA報告書の作成 | BCP担当 | 1〜2週間 |
RTO/RPOの設定
- RTO(Recovery Time Objective:目標復旧時間)
- システムや業務が停止してから、復旧するまでの目標時間です。「4時間以内に復旧」「24時間以内に復旧」といった形で設定します。業務影響度が高いシステムほど、短いRTOを設定します。
- RPO(Recovery Point Objective:目標復旧ポイント)
- データの損失を許容できる最大期間です。「1時間前のデータまで復旧」「1日前のデータまで復旧」といった形で設定します。バックアップの頻度に直結します。
- Tier1(最重要)
- 基幹業務システム、顧客対応システム。RTO: 4時間以内、RPO: 1時間以内。リアルタイムレプリケーション、ホットスタンバイが必要。
- Tier2(重要)
- 社内業務システム、メールシステム。RTO: 24時間以内、RPO: 4時間以内。頻繁なバックアップと迅速な復旧手順が必要。
- Tier3(通常)
- ファイルサーバー、グループウェア。RTO: 72時間以内、RPO: 24時間以内。日次バックアップで対応可能。
- Tier4(低)
- 開発環境、アーカイブ。RTO: 1週間以内、RPO: 1週間以内。週次バックアップで対応可能。
相互依存関係の把握
- システム間の依存関係マップ
- システムAが動くためにシステムBが必要、システムBが動くためにシステムCが必要、といった依存関係を可視化します。復旧順序を決定する際に不可欠です。
- 外部サービスへの依存
- クラウドサービス、SaaS、決済サービスなど、外部依存を洗い出します。外部サービスの障害時の対応策も検討します。
- サプライチェーンの考慮
- 主要な取引先・仕入先との情報連携システムを特定し、相互の依存関係を把握します。
サイバーインシデント対応DR計画
DR(Disaster Recovery:災害復旧)計画は、インシデント発生後のシステム復旧を具体的に定める計画です。サイバー攻撃特有の要素を組み込みます。
復旧戦略の選択肢
| 復旧戦略 | 概要 | RTO目安 | コスト | 適用場面 |
|---|---|---|---|---|
| ホットサイト | 常時稼働の冗長環境 | 数分〜数時間 | 高 | Tier1システム |
| ウォームサイト | 設備はあるが起動が必要 | 数時間〜1日 | 中 | Tier2システム |
| コールドサイト | 場所と電源のみ確保 | 数日〜1週間 | 低 | Tier3-4システム |
| クラウドDR | クラウド上に復旧環境 | 数時間〜1日 | 中(従量課金) | 柔軟性重視 |
| ハイブリッド | オンプレミス+クラウド | システムにより異なる | 中〜高 | 大規模環境 |
復旧手順書の整備
- システム復旧の優先順位
- BIAで決定した優先順位に基づき、どのシステムから復旧するかを明確にします。依存関係を考慮し、基盤システム(Active Directory、DNS等)から順に復旧します。
- 段階的復旧アプローチ
- 全システムを一度に復旧するのではなく、フェーズを分けて段階的に復旧します。各フェーズで動作確認を行い、問題がないことを確認してから次のフェーズに進みます。
- 検証・確認ポイント
- 各システムの復旧後、正常動作を確認するチェックリストを用意します。データ整合性、機能テスト、セキュリティ確認を含めます。
- フェーズ1:基盤復旧
- Active Directory、DNS、DHCP、ファイアウォールなど、他のシステムの前提となる基盤を復旧します。セキュリティ強化(パスワードリセット等)も並行実施。
- フェーズ2:Tier1システム復旧
- 基幹業務システム、顧客対応システムを復旧します。最小限の機能から開始し、段階的に機能を拡張。
- フェーズ3:Tier2システム復旧
- 社内業務システム、メールシステムを復旧します。従業員の業務再開を可能にします。
- フェーズ4:全体復旧
- Tier3-4システムを復旧し、通常運用に戻します。監視強化体制は継続。
代替手段の確保
- 手作業での業務継続
- ITシステムが使えない間、紙ベースやオフラインツールで業務を継続する手順を定めます。過去に使用していた手作業の手順を再整備します。
- 代替システムの準備
- 主要システムの簡易的な代替手段(例:Excelでの受注管理、Webメールの利用)を事前に準備します。
- 外部委託先の確保
- 復旧支援を依頼できるベンダー、一時的に業務を委託できる先を事前に確保します。契約条件や連絡先を文書化しておきます。
復旧実行のポイント
ランサムウェア対応プレイブックと連携し、実際の復旧作業のポイントを解説します。
復旧判断の意思決定
- 復旧開始のトリガー
- フォレンジック調査が一定程度進み、感染範囲が特定され、侵入経路が遮断されたことを確認してから復旧を開始します。早すぎる復旧は再感染のリスクがあります。
- 経営判断を求める事項
- 復旧に要するコストと時間、業務再開の優先順位、外部専門家への依頼、顧客・取引先への通知について、経営層の判断を仰ぎます。
- 復旧vs再構築の判断基準
- 感染したシステムをクリーンにして再利用するか、完全に再構築するかを判断します。再構築は時間とコストがかかりますが、潜在的なリスクを排除できます。重要度の高いシステムや、感染が深刻なシステムは再構築を検討します。
復旧作業の実際
| 作業項目 | 内容 | 担当 | 所要時間目安 |
|---|---|---|---|
| 環境準備 | クリーンなOSイメージ、パッチ適用 | インフラ担当 | 4〜8時間 |
| システム再構築 | サーバー・端末の再インストール | インフラ担当 | 8〜24時間 |
| データ復元 | バックアップからのリストア | バックアップ担当 | 12〜48時間 |
| セキュリティ強化 | 認証情報リセット、設定強化 | セキュリティ担当 | 4〜8時間 |
| 動作検証 | 機能テスト、データ整合性確認 | 業務部門・IT | 4〜8時間 |
業務再開の判断
- 安全確認の基準
- マルウェアの完全駆除、侵入経路の遮断、認証情報のリセット、セキュリティ強化が完了していることを確認します。チェックリストを用いて漏れなく確認します。
- 段階的再開の進め方
- 最初は限定的なユーザー、限定的な機能から再開し、問題がないことを確認しながら徐々に拡大します。
- モニタリング強化
- 復旧後も通常より厳しい監視体制を維持します。攻撃者の再侵入や、見落としていたマルウェアの活動を早期に検知します。
訓練と継続的改善
BCPは策定して終わりではありません。定期的な訓練と見直しにより、実効性を維持・向上させます。
BCPテスト・訓練の種類
| 訓練種類 | 概要 | 参加者 | 所要時間 | 実施頻度目安 |
|---|---|---|---|---|
| チェックリスト演習 | 計画書の読み合わせ、理解度確認 | 対応チーム | 1〜2時間 | 半年に1回 |
| ウォークスルー演習 | 手順を順に追って確認 | 対応チーム | 半日 | 半年に1回 |
| 机上演習(Tabletop) | シナリオに基づく議論形式 | 経営層含む関係者 | 半日〜1日 | 年1回 |
| 機能訓練 | 特定機能(バックアップ復旧等)のテスト | IT担当 | 数時間〜1日 | 四半期に1回 |
| 総合訓練 | 本番さながらの復旧訓練 | 全関係者 | 1〜3日 | 年1回 |
訓練からの学び
- 課題の抽出
- 訓練を通じて発見された課題(手順の不備、連絡体制の問題、スキル不足など)を文書化します。
- 計画の見直し
- 発見された課題に基づき、BCPを修正します。訓練後2週間以内を目安に改善計画を策定します。
- 手順書の更新
- 実際に訓練で使用してわかりにくかった点、古くなった情報を更新します。
継続的改善サイクル
- 年次見直し
- 少なくとも年1回、BCP全体を見直します。組織変更、システム変更、新たな脅威を反映します。
- インシデント後の反映
- 実際にインシデントが発生した場合、対応の教訓をBCPに反映します。根本原因分析の結果も活用します。
- 外部環境変化への対応
- 新たなサイバー脅威、法規制の変更、技術の進歩に応じてBCPを更新します。
経営層の役割と責任
事業継続は経営課題です。経営層のサイバーリスクに対する理解と関与が、BCPの実効性を左右します。
経営層が果たすべき役割
- リソース配分の意思決定
- BCP策定・維持に必要な人員、予算、時間を確保します。サイバーセキュリティ投資の優先順位を決定します。
- 対外コミュニケーションの責任
- 重大インシデント発生時、顧客、株主、メディアへの対外説明は経営層の責任です。事前に想定シナリオと対応方針を確認しておきます。
- 再発防止への投資判断
- インシデント後の再発防止策について、必要な投資を承認します。短期的なコスト削減よりも、長期的なリスク軽減を重視した判断が求められます。
- 経営層向けBCPチェックリスト
- □ BIAは実施され、重要業務・システムが特定されているか
□ RTO/RPOは業務部門と合意されているか
□ バックアップは定期的にテストされているか
□ 訓練は年1回以上実施されているか
□ インシデント発生時の意思決定プロセスは明確か
□ 外部専門家との連携体制は整っているか
□ サイバー保険は適切にカバーされているか
ガバナンス体制
- BCP推進体制
- BCP全体を統括する責任者(多くの場合、CIO、CISO、またはリスク管理担当役員)を明確にします。部門横断のBCP推進チームを設置します。
- 報告・エスカレーションライン
- インシデント発生時、誰にどのタイミングで報告するかを明確にします。深刻度に応じたエスカレーション基準を設定します。
- 外部専門家の活用
- フォレンジック業者、法律事務所、PR会社など、インシデント時に必要な外部専門家との事前契約や連携体制を確立します。
よくある質問(FAQ)
- Q: サイバー攻撃用のBCPは通常のBCPと別に作るべきですか?
- A: 完全に別にする必要はありませんが、サイバー攻撃特有の要素を追加することが重要です。自然災害と異なり、サイバー攻撃は被害が長期化しやすく、バックアップも破壊される可能性があります。既存BCPにサイバーシナリオを追加し、IT復旧手順、証拠保全、外部通知などの要素を盛り込んでください。サイバー特有の意思決定(身代金の是非など)も事前に検討しておくと有効です。
- Q: RTO/RPOはどうやって決めればよいですか?
- A: 業務部門へのヒアリングを通じて決定します。「このシステムが何時間止まったら、どの程度の損失が発生するか」「何時間前のデータに戻されたら、業務にどの程度影響があるか」を具体的に質問します。金額換算できると経営判断がしやすくなります。設定したRTO/RPOは、バックアップ戦略やDR環境の設計に反映します。
- Q: 訓練はどのくらいの頻度で実施すべきですか?
- A: 最低でも年1回の机上演習を推奨します。理想的には、机上演習を年1回、機能訓練(バックアップ復旧テストなど)を四半期に1回実施します。特にインシデント対応チームのメンバーが変わった場合や、システムが大きく変更された場合は、臨時の訓練も検討してください。
- Q: 中小企業でもBCPは必要ですか?
- A: 必要です。むしろ中小企業こそ、サイバー攻撃からの復旧が遅れると事業存続に直結するリスクがあります。大企業のような本格的なBCPでなくても、最低限、重要システムのリスト、バックアップの確認、連絡体制の整備から始めてください。組織的なマルウェア対策の一環として取り組むことを推奨します。
- Q: クラウドサービスを使っていればBCPは不要ですか?
- A: 不要ではありません。クラウドサービス自体の障害、認証情報の漏洩によるデータ破壊、クラウド上のバックアップがランサムウェアで暗号化されるリスクなど、クラウド利用に固有のリスクがあります。クラウドプロバイダーのSLAを確認し、自社責任の範囲でBCPを策定する必要があります。
まとめ
マルウェア感染、特にランサムウェア攻撃からの事業継続は、従来の自然災害型BCPでは対応しきれない複雑な課題です。業務影響分析(BIA)による重要業務の特定、RTO/RPOの適切な設定、サイバー攻撃特有のリスクを考慮したDR計画の策定、そして定期的な訓練を通じて、組織のサイバーレジリエンスを高めることができます。
経営層の関与とリソース配分、セキュリティガバナンスの確立も、実効性あるBCPには欠かせません。本記事の内容を参考に、自組織のBCPを見直し、サイバーインシデントへの備えを強化してください。
具体的なインシデント対応手順はランサムウェア対応プレイブックを、バックアップ戦略の詳細はバックアップ戦略ガイドをご参照ください。
重要なお知らせ
- 本記事は一般的な情報提供を目的としており、個別の状況に対する助言ではありません。
- BCP策定においては、自組織の業種・規模・リスク特性に応じたカスタマイズが必要です。
- 法的・規制上の要件については、専門家にご相談ください。
- 実際にマルウェア被害に遭われた場合は、警察(#9110)やIPA(03-5978-7509)などの公的機関にご相談ください。
更新履歴
- 初稿公開