サイバーBCPの必要性｜新たな災害
事業継続計画（BCP）とは、災害や緊急事態が発生した際に、重要な業務を継続または早期復旧するための計画です。従来は地震、火災、パンデミック等の物理的災害を想定していましたが、マルウェア感染という新たな「災害」が、企業の存続を脅かす時代となりました。
マルウェアを災害として認識
サイバー攻撃、特にランサムウェアは、もはや単なるITトラブルではなく、企業の存続を脅かす重大な災害として認識する必要があります。その脅威度は、自然災害を上回る場合すらあります。
- ランサムウェアの脅威度
- 事業停止期間は平均23日、復旧コストは平均4.5億円に上ります。自然災害を超える頻度と被害規模で、もはや「IF（もし起きたら）」ではなく「WHEN（いつ起きるか）」の問題です。警察庁の統計によると、2024年1-11月のランサムウェア被害件数は前年比57%増の257件に達し、特に中小企業での被害が急増しています。身代金を支払っても完全復旧できる保証はなく、約40%の企業がデータを完全には取り戻せていません。さらに、支払った企業の80%が再攻撃の標的となるというデータもあり、一度の被害で終わらないのが特徴です。
- 連鎖的影響
- サプライチェーン全体への波及、顧客サービス停止、レピュテーション損失など、物理災害より影響範囲が広いのが特徴です。例えば、製造業の基幹システムがランサムウェアで停止すれば、生産停止だけでなく、納品先の生産ラインも停止します。さらに、サプライチェーン攻撃として、取引先を経由した二次感染のリスクもあります。顧客データが漏洩すれば、個人情報保護法違反や損害賠償、そして何より顧客の信頼喪失という取り返しのつかない事態に発展します。SNSでの拡散により、レピュテーション損失は瞬時に広がり、株価下落や取引停止につながる可能性もあります。
- 復旧の複雑性
- データ復旧、システム再構築、セキュリティ強化を同時実施する必要があり、物理復旧より技術的に複雑で時間がかかります。建物の修復は手順が明確ですが、ランサムウェアからの復旧は「どこまで感染したか」「バックアップは安全か」「再感染をどう防ぐか」という不確実性との戦いです。暗号化されたデータの復号、感染経路の特定、脆弱性の修正、全システムの検証と、専門的な作業が多岐にわたります。さらに、攻撃者が潜伏している可能性もあり、完全なクリーンアップには数週間から数か月を要する場合もあります。復旧中も業務を継続する必要があるため、段階的な復旧戦略が不可欠です。
これらの特性から、マルウェア感染は「ITトラブル」ではなく「事業継続を脅かす災害」として、BCP/DR計画に統合する必要があるのです。
従来BCPの限界
多くの企業が既にBCPを策定していますが、サイバー攻撃を十分に考慮していないケースが大半です。従来のBCPには、サイバー時代の課題に対応できない限界があります。
IT依存度の増大
現代のビジネスは、ITシステムなしには成り立ちません。営業、製造、物流、経理、人事など、あらゆる業務がシステムに依存しています。
IT依存の実態
- 基幹業務：ERP、CRM、SCMなどのシステムが停止すれば、業務が完全に止まる
- コミュニケーション：メール、チャット、Web会議が使えなければ、社内外の連絡が不可能
- データアクセス：クラウドストレージ、データベースにアクセスできなければ、業務に必要な情報が取得できない
- 決済・取引：電子決済、オンライン取引が停止すれば、売上に直結する
従来のBCPでは、「サーバー室が浸水した」「停電でデータセンターが止まった」という物理的な被害を想定していました。しかし、フィッシングメール一通で侵入したマルウェアが、物理的に無傷のシステムを完全に使用不能にする時代です。物理的バックアップサイトがあっても、データが暗号化されていれば意味がありません。
サイバー特有の課題
サイバー攻撃には、物理災害にはない独特の課題があります。
物理災害との違い
| 特性 | 物理災害 | サイバー攻撃 |
|---|---|---|
| 発生の予測 | 気象情報等で予測可能 | 予兆なく突然発生 |
| 被害範囲 | 物理的に限定的 | ネットワーク全体に瞬時に拡散 |
| 攻撃の継続性 | 災害後は終息 | 攻撃者が潜伏し継続攻撃 |
| 復旧の確実性 | 手順が明確 | 完全復旧の保証なし |
| 証拠保全 | 不要 | 法的対応のため必須 |
| 犯罪者との交渉 | なし | 身代金交渉の可能性 |
特に重要なのが「攻撃の継続性」です。地震は一度発生すれば終わりますが、サイバー攻撃は継続します。攻撃者がバックドアを仕込んでいれば、復旧後も再侵入されるリスクがあります。また、標的型攻撃（APT）の場合、長期間潜伏してデータを窃取し続けることもあります。
統合的アプローチ
サイバーBCPは、従来のBCPとサイバーセキュリティを統合した、包括的なレジリエンス戦略です。
オールハザード対応
「オールハザード」とは、あらゆる脅威に対応できる包括的なアプローチです。地震、火災、パンデミック、サイバー攻撃など、原因が何であれ、「重要業務が停止した」という事態への対応を標準化します。
統合BCPの構成
- 共通部分：対策本部設置、意思決定プロセス、ステークホルダーコミュニケーション
- 脅威別サブプラン：地震対応、パンデミック対応、サイバー攻撃対応
- 業務別復旧計画：営業、製造、物流など、業務ごとの詳細手順
このアプローチにより、新たな脅威が出現しても、サブプランを追加するだけで対応できます。
レジリエンス思考
レジリエンス（回復力）とは、「被害を受けないこと」ではなく、「被害を受けても迅速に回復できること」を目指す考え方です。完璧な防御は不可能という前提に立ち、被害を最小化し、迅速に復旧する能力を重視します。
レジリエンスの3要素
- 予防（Prevention）：攻撃の成功確率を下げる（セキュリティ対策）
- 検知（Detection）：攻撃を早期に発見する（監視体制）
- 回復（Recovery）：迅速に業務を再開する（BCP/DR）
この3要素をバランスよく強化することで、サイバー攻撃に強い組織となります。マルウェア対策の組織体制として、CSIRT/SOCと連携したBCP体制の構築が重要です。
BIA（Business Impact Analysis）｜影響分析
BIA（ビジネスインパクト分析）は、BCP策定の出発点です。「どの業務が停止すれば、どれだけの影響があるか」を定量的に評価し、復旧の優先順位を決定します。
重要業務の特定
全ての業務を同時に復旧することは不可能です。限られたリソースを最重要業務に集中させるため、業務の重要度を評価します。
- 業務優先度評価
- 顧客影響、財務影響、法的影響、レピュテーション影響を4段階評価し、スコアリングで優先順位を客観化します。例えば、ECサイトの停止は「顧客影響：大、財務影響：大、法的影響：小、レピュテーション影響：大」と評価し、合計スコアで優先度を決定します。評価基準を明確にすることで、部門間の優先度争いを防ぎ、客観的な判断が可能になります。また、季節要因も考慮が必要です。例えば、小売業では年末商戦時期の受注システム停止は致命的ですが、閑散期なら影響は相対的に小さくなります。時期によって優先度が変わる業務は、その旨を明記します。
- 依存関係マッピング
- 業務→システム→データの依存関係を可視化し、単一障害点（SPOF）を特定して冗長化対象を明確化します。例えば「受注業務」は「受注システム」に依存し、受注システムは「顧客データベース」「在庫データベース」「決済API」に依存します。これらの依存関係を図示することで、「顧客データベースが停止すると、受注だけでなく、顧客問い合わせ対応も不可能」という連鎖的影響が見えてきます。SPOFが特定できれば、そこを優先的に冗長化・強化します。クラウドサービスへの依存も明示し、クラウド設定不備によるリスクも評価に含めます。
- 時間軸での影響評価
- 1時間、4時間、1日、3日、1週間での影響を段階評価し、許容停止時間から復旧優先度を決定します。例えば、ATMシステムは1時間停止でも顧客影響が大きいため最優先、給与計算システムは1週間の猶予があるため優先度は低くなります。この評価により、RTO（目標復旧時間）の設定根拠が明確になります。また、停止時間と影響の関係は線形ではありません。ECサイトの場合、1時間停止なら「不便」ですが、24時間停止すれば「顧客離れ」が始まり、1週間停止なら「事業継続不可能」となります。このような非線形な影響を考慮した評価が必要です。
表1：BIA評価マトリクス（例）
| 業務名 | 顧客影響 | 財務影響 | 法的影響 | レピュテーション | 合計 | 優先度 | 許容停止時間 |
|---|---|---|---|---|---|---|---|
| EC受注処理 | 5 | 5 | 3 | 5 | 18 | 最高 | 4時間 |
| 顧客問い合わせ | 4 | 3 | 2 | 4 | 13 | 高 | 8時間 |
| 在庫管理 | 3 | 4 | 2 | 3 | 12 | 高 | 24時間 |
| 会計処理 | 2 | 4 | 3 | 2 | 11 | 中 | 3日 |
| 人事管理 | 2 | 2 | 3 | 2 | 9 | 中 | 1週間 |
| 社内ポータル | 2 | 1 | 1 | 2 | 6 | 低 | 1週間 |
※スコア：5=致命的、4=重大、3=中程度、2=軽微、1=最小限
RTO/RPO設定
BIAの結果に基づき、各システムのRTO（Recovery Time Objective：目標復旧時間）とRPO（Recovery Point Objective：目標復旧時点）を設定します。
システム別目標値
業務の重要度に応じて、システムごとにRTO/RPOを設定します。
RTO/RPOの意味
- RTO：システム停止から復旧完了までの目標時間（例：4時間以内に復旧）
- RPO：どの時点のデータまで復旧するか（例：1時間前のデータまで復旧）
RPOが小さいほど、頻繁なバックアップが必要になり、コストが増加します。業務の性質に応じた適切な設定が重要です。
表2：RTO/RPO設定表（例）
| システム | 業務 | 優先度 | RTO | RPO | バックアップ頻度 | 復旧方法 |
|---|---|---|---|---|---|---|
| ECサイト | オンライン販売 | 最高 | 4時間 | 5分 | リアルタイム同期 | ホットスタンバイ |
| 基幹ERP | 受発注・会計 | 最高 | 8時間 | 1時間 | 1時間ごと | クラウドDR |
| CRM | 顧客管理 | 高 | 24時間 | 4時間 | 4時間ごと | バックアップリストア |
| メールサーバー | 社内外連絡 | 高 | 8時間 | 1時間 | 1時間ごと | クラウドメール切替 |
| ファイルサーバー | 文書共有 | 中 | 3日 | 24時間 | 日次 | バックアップリストア |
| 人事システム | 給与・勤怠 | 中 | 3日 | 24時間 | 日次 | バックアップリストア |
| 社内Wiki | 情報共有 | 低 | 1週間 | 1週間 | 週次 | バックアップリストア |
RTO/RPOは「理想」ではなく「現実的に達成可能」な目標を設定します。また、訓練で実際に達成できることを確認し、必要に応じて見直します。
データ別復旧要件
全てのデータが同じ重要度ではありません。データの種類に応じた復旧要件を設定します。
データ分類と復旧要件
- ミッションクリティカルデータ：顧客情報、取引データ、財務データ（RPO: 5分～1時間）
- 重要データ：製品情報、契約書、設計図（RPO: 1～4時間）
- 通常データ：社内文書、メール、議事録（RPO: 24時間）
- アーカイブデータ：過去の記録、参考資料（RPO: 1週間）
ランサムウェア攻撃では、最重要データが優先的に狙われます。データ漏洩と暗号化の二重脅迫も増加しているため、暗号化だけでなく、データ窃取への対策も必要です。
リソース要件定義
復旧に必要なリソースを事前に定義し、確保しておくことで、迅速な復旧が可能になります。
人的リソース
必要な役割と人員
- インシデント指揮官：全体統括、意思決定（経営層または部長クラス）
- 技術対応チーム：システム復旧、フォレンジック（IT部門、外部専門家）
- 業務対応チーム：代替業務の実施（各部門の担当者）
- コミュニケーション担当：顧客・取引先への連絡、広報対応（広報部門）
- 法務担当：法的対応、当局への報告（法務部門、顧問弁護士）
各役割に正担当とバックアップを割り当て、属人化を防ぎます。また、深夜・休日の対応も考慮し、オンコール体制を整備します。
技術リソース
必要な技術環境とツール
- 代替システム：クラウドDR環境、バックアップシステム
- 通信手段：衛星電話、モバイルWi-Fi（主要回線が使えない場合）
- フォレンジックツール：証拠保全、マルウェア解析ツール
- セキュリティツール：EDR、SIEM、サンドボックス
- バックアップメディア：イミュータブルストレージ、オフラインバックアップ
これらのリソースは、定期的に動作確認を行い、いざという時に確実に使えるようにします。バックアップ戦略の詳細は、専用ページで解説しています。
外部支援
自社だけで対応できない場合に備え、外部支援体制も構築します。
外部支援先のリスト化
- セキュリティベンダー：インシデント対応、フォレンジック調査
- クラウドプロバイダー：DR環境の緊急拡張、技術サポート
- 弁護士：法的対応、当局対応、身代金交渉
- PR会社：危機管理広報、レピュテーション管理
- 保険会社：サイバー保険の請求、復旧費用の補填
これらの連絡先を「緊急連絡リスト」としてまとめ、紙でも保管します（システムが使えない場合に備えて）。CSIRT/SOCとの連携体制も重要です。
サイバーインシデント対応計画｜実践的手順
BIAで「何を守るか」が明確になったら、次は「どう対応するか」の具体的な手順を策定します。時間軸に沿った対応計画により、混乱を最小化し、迅速な復旧を実現します。
初動対応（0-4時間）
インシデント発生直後の初動対応が、その後の復旧期間を大きく左右します。最初の4時間が勝負です。
- 対策本部設置
- 発生から30分以内に召集、1時間以内に初期評価完了を目標とします。役割分担、指揮命令系統を明確化し、混乱防止が最優先です。対策本部は物理的な会議室だけでなく、オンライン会議室も準備します（メインの会議システムが使えない場合に備え、複数の手段を用意）。本部メンバーは、インシデント指揮官、IT責任者、業務責任者、法務担当、広報担当の最小構成とし、状況に応じて拡大します。初動で最も重要なのは「全体像の把握」ではなく「被害拡大の阻止」です。完全な情報が揃うのを待たず、限定的な情報でも意思決定を行う覚悟が必要です。
- 被害範囲特定
- 感染システム、影響業務、データ損失を迅速に把握します。拡大防止のため、ネットワーク分離を即断する必要があります。具体的には、①感染が確認されたシステムのネットワークケーブルを物理的に切断（リモートからの操作では攻撃者に妨害される可能性）、②感染の疑いがあるセグメント全体を隔離、③重要システムへの感染を確認（最悪のケースを想定）、④バックアップの安全性を確認（バックアップも暗号化されていないか）。この段階では「過剰反応」でも構いません。後で「やり過ぎた」と判明する方が、「手遅れだった」よりはるかに良い結果をもたらします。初動対応の詳細な手順は専用ページで解説しています。
- 事業継続判断
- 縮退運転、代替手段、全面停止を経営判断します。顧客通知、ステークホルダー連絡も並行実施が必要です。判断基準は、①顧客への影響（サービス継続できるか）、②従業員の安全（感染拡大のリスク）、③法的リスク（個人情報漏洩の可能性）、④レピュテーションリスク（不完全なサービス提供による信頼低下）です。例えば、ECサイトが感染した場合、「サイトを停止して顧客に通知」が正しい判断です。無理に営業を続けて顧客情報が漏洩すれば、より大きな損害となります。また、この判断は速やかに顧客・取引先に伝達します。情報の空白期間が長いほど、憶測や風評被害が拡大します。
表3：インシデント対応タイムライン（最初の24時間）
| 経過時間 | フェーズ | 主要アクション | 担当 | 判断基準 |
|---|---|---|---|---|
| 0-30分 | 検知・通報 | ・異常検知 ・関係者への第一報 ・対策本部召集開始 |
監視担当 | EDRアラート、異常なネットワーク通信 |
| 30分-1時間 | 初期評価 | ・被害範囲の暫定評価 ・ネットワーク隔離判断 ・対策本部設置完了 |
指揮官 | 感染システム数、業務影響 |
| 1-2時間 | 封じ込め | ・感染システム隔離 ・バックアップ安全性確認 ・重要システム保護 |
技術チーム | 拡散の有無、バックアップ状態 |
| 2-4時間 | 暫定対応 | ・代替業務手段の発動 ・顧客への第一報 ・外部専門家の招集 |
業務チーム | 業務継続可否、顧客影響 |
| 4-8時間 | 詳細分析 | ・感染経路の特定 ・マルウェア種類の特定 ・データ損失範囲確定 |
技術チーム | フォレンジック結果 |
| 8-24時間 | 復旧準備 | ・復旧計画策定 ・必要リソース確保 ・ステークホルダー説明 |
全体 | 復旧可能性、必要期間 |
暫定対応（4-24時間）
初動で被害を封じ込めた後、完全復旧までの間、業務を継続する暫定対応を実施します。
代替業務プロセス
システムが使えない状況で、どう業務を継続するかを事前に定義します。
代替手段の例
| 通常業務 | 代替手段 | 制約・注意点 |
|---|---|---|
| オンライン受注 | 電話・FAX受注 | 処理能力が大幅低下、人員増強必要 |
| 在庫管理システム | Excelで手動管理 | リアルタイム性低下、誤入力リスク |
| 電子決済 | 請求書後払い | キャッシュフロー悪化、与信管理 |
| Web会議 | 電話会議、対面 | 効率低下、移動時間発生 |
| 社内メール | 外部メール（Gmail等） | セキュリティリスク、移行手間 |
代替手段は「完璧」を目指さず、「最低限の業務継続」を優先します。また、代替手段への切り替え訓練も重要です。いざという時に使えなければ意味がありません。
手動オペレーション
自動化されていた処理を手動で実施する手順を文書化します。
手動化の注意点
- 処理時間の増加：自動処理が1時間→手動で8時間など、大幅に増加
- ミスのリスク：人間が介在するため、誤入力や漏れが発生
- 記録の保持：復旧後にデータを移行するため、手動処理の記録を確実に保持
- 権限の緩和：通常は複数人承認の処理を、緊急時は簡略化（事後監査で対応）
手動オペレーションは疲労を伴うため、長期化する場合はシフト制を組み、担当者の負荷を分散します。
復旧フェーズ（1日以降）
暫定対応で業務を維持しながら、システムの完全復旧を進めます。
システム再構築
感染したシステムは、単純に復元するのではなく、クリーンな状態から再構築します。
再構築の手順
- 完全消去：感染システムのディスクを完全消去（フォーマットではなく、データ復元不可能なレベル）
- OSクリーンインストール：最新のOSをクリーンインストール
- セキュリティパッチ適用：全ての既知の脆弱性を修正
- アプリケーション再インストール：信頼できるソースから再インストール
- 設定の見直し：感染原因となった設定（開放ポート、弱いパスワード等）を修正
- セキュリティツール導入：EDR、アンチマルウェアを導入・設定
- 検証：マルウェアスキャン、脆弱性スキャンで安全性確認
この作業は時間がかかりますが、省略すると再感染のリスクが残ります。
データリストア
バックアップからデータを復元しますが、慎重な検証が必要です。
リストアの注意点
- バックアップの検証：リストアする前に、バックアップ自体が感染していないか確認
- 段階的リストア：全データを一度にリストアせず、重要データから順次
- クリーンルーム：隔離環境でリストアし、感染がないことを確認してから本番環境に
- 世代の選択：最新のバックアップが感染している可能性もあるため、複数世代を確認
ランサムウェアの中には、バックアップを標的にするものもあります。復旧と再発防止では、安全な復旧手順を詳しく解説しています。
セキュリティ強化
復旧と同時に、再感染を防ぐためのセキュリティ強化を実施します。
強化項目
- 侵入経路の遮断：フィッシングメール対策、脆弱性修正、アクセス制御強化
- 検知力の向上：EDR導入、SIEM強化、SOC体制の見直し
- 権限管理の見直し：最小権限の原則、多要素認証の徹底
- セグメンテーション：ネットワークのゼロトラスト化、マイクロセグメンテーション
- バックアップ改善：イミュータブルバックアップ、オフサイトバックアップの追加
インシデントは、セキュリティを根本的に見直す機会でもあります。「元に戻す」だけでなく、「より強固にする」ことを目指します。
復旧戦略とオプション｜多層防御
単一の復旧手段に依存せず、多層的な復旧オプションを用意することで、確実な事業継続を実現します。
バックアップ戦略
バックアップは復旧の要ですが、ランサムウェアはバックアップも標的にします。従来の「3-2-1ルール」を進化させた戦略が必要です。
- 3-2-1-1ルール
- 3つのコピー、2つの異なるメディア、1つのオフサイト、1つのイミュータブル（不変）バックアップ。これがランサムウェア対策の新標準です。具体的には、①本番データ、②オンサイトバックアップ（高速リストア用）、③オフサイトバックアップ（クラウドストレージ）の3つのコピーを用意します。メディアは、ディスク（オンサイト）とクラウド（オフサイト）の2種類。そして重要なのが「イミュータブル」バックアップです。これは、一度書き込んだら削除・変更ができないバックアップで、ランサムウェアが攻撃者権限を取得しても、暗号化や削除ができません。AWS S3 Object Lock、Azure Immutable Blob等のクラウドサービス、または専用のバックアップアプライアンスで実現できます。
- 復旧テスト
- 月次で部分復旧、四半期で全面復旧テストを実施し、目標時間内での復旧成功率90%以上を維持します。「バックアップがある」と「復旧できる」は別物です。実際にテストしてみると、①バックアップが壊れていた、②リストアに想定以上の時間がかかった、③手順書が古くて使えなかった、という問題が発見されます。テストは、本番環境に影響しない隔離環境で実施し、①バックアップの完全性確認、②リストアの実行、③データの検証、④所要時間の測定、⑤手順書の更新、というサイクルを回します。テスト結果は記録し、改善に活かします。
- クリーンルーム
- 隔離環境でのデータ検証と浄化を行います。感染データの混入防止、完全なクリーンインストールのためです。クリーンルームとは、本番環境から完全に隔離されたネットワーク環境で、外部インターネットにも接続しません。ここで、①バックアップをリストア、②マルウェアスキャン、③脆弱性スキャン、④動作確認、⑤問題がなければ本番環境へ、という手順を踏みます。クリーンルームがあれば、「バックアップに感染が混入していた」という最悪のケースでも、本番環境への影響を防げます。また、新しいシステムを構築してから切り替えることで、失敗時のリスクも軽減できます。
バックアップの保管期間と世代管理
| データ種類 | 保管期間 | 世代数 | 保管場所 | 備考 |
|---|---|---|---|---|
| 本番データ | - | 1 | オンプレミス | 最新データ |
| 日次バックアップ | 30日 | 30 | オンプレミス | 高速リストア用 |
| 週次バックアップ | 3か月 | 12 | クラウド | 中期保管 |
| 月次バックアップ | 1年 | 12 | クラウド（イミュータブル） | 長期保管 |
| 年次バックアップ | 7年 | 7 | クラウド（アーカイブ） | 法令遵守 |
ランサムウェアは、長期間潜伏してから発動することもあるため、長期保管のバックアップも重要です。
代替サイト戦略
バックアップだけでなく、システム自体の冗長化も検討します。
ホットスタンバイ
常時稼働している代替システムを用意し、メインサイトが停止しても瞬時に切り替えます。
ホットスタンバイの特徴
- 切り替え時間：数秒～数分（RPOほぼゼロ、RTO数分）
- コスト：高い（常時2倍のインフラが必要）
- 適用対象：ミッションクリティカルなシステム（EC、決済、基幹系）
- 構成例：アクティブ-アクティブ構成、リアルタイムレプリケーション
ホットスタンバイは、物理災害には有効ですが、論理災害（マルウェア感染）の場合、両方のサイトに同時に感染する可能性があります。そのため、①ネットワーク分離、②非同期レプリケーション（タイムラグを持たせる）、③定期的な隔離等の対策が必要です。
クラウドDR
クラウドを活用したDR（災害復旧）環境を構築します。
クラウドDRのメリット
- 初期コスト削減：使わない時は最小構成で、DRイベント時に拡張
- 柔軟性：必要に応じてリソースを増減
- 地理的分散：異なるリージョンで冗長化
- 早期構築：物理的なデータセンター構築より短期間
クラウドDRのパターン
| パターン | 平常時の状態 | RTO | コスト | 用途 |
|---|---|---|---|---|
| バックアップ＆リストア | バックアップのみ保管 | 数時間～数日 | 低 | 優先度低のシステム |
| パイロットライト | 最小構成で稼働 | 数時間 | 中 | 重要システム |
| ウォームスタンバイ | 縮小版で稼働 | 数十分 | 高 | 重要度高のシステム |
| ホットスタンバイ | 本番同等で稼働 | 数分 | 最高 | ミッションクリティカル |
自社の要件とコストのバランスで選択します。
代替業務手段
システムが復旧しない間の代替業務手段も重要です。
アナログ代替
デジタルシステムが使えない場合の、アナログ代替手段を準備します。
アナログ代替の例
- 紙の伝票：受注書、出荷指示書、請求書等の用紙を常備
- 電話・FAX：顧客対応、社内連絡の代替手段（専用回線を確保）
- 現金取引：電子決済停止時の現金対応（現金を事前に確保）
- 掲示板：社内連絡の掲示板（システムが使えない場合の情報共有）
「時代遅れ」と思われるアナログ手段ですが、システム障害時には極めて有効です。
外部委託
自社での対応が困難な場合、業務の一部を外部に委託することも選択肢です。
外部委託の例
- コールセンター：顧客問い合わせ対応を外部委託
- データ入力：手書き伝票のデータ化を外部委託
- 物流代行：出荷業務を外部倉庫に委託
- BPO：バックオフィス業務を外部委託
ただし、外部委託には時間がかかるため、事前に契約を結び、緊急時に迅速に発動できるようにします。
表4：復旧オプション比較
| 復旧手段 | RTO | RPO | コスト | 複雑性 | 適用システム | ランサムウェア耐性 |
|---|---|---|---|---|---|---|
| イミュータブルバックアップ | 1-2日 | 1-24時間 | 低 | 低 | 全システム | 高 |
| クラウドバックアップ | 数時間 | 1-4時間 | 低～中 | 低 | 全システム | 中 |
| ホットスタンバイ | 数分 | ほぼゼロ | 高 | 高 | ミッションクリティカル | 低（同時感染リスク） |
| クラウドDR | 数時間 | 1-4時間 | 中 | 中 | 重要システム | 中 |
| 代替業務（アナログ） | 即座 | - | 低 | 低 | 全業務 | 高（システム不要） |
| 外部委託 | 1-3日 | - | 中～高 | 中 | 限定業務 | 高（別組織） |
複数の手段を組み合わせることで、確実性が高まります。
訓練と改善｜実効性の確保
どんなに完璧な計画も、訓練しなければ絵に描いた餅です。定期的な訓練と継続的な改善により、実効性のあるBCP/DR体制を構築します。
訓練プログラム
訓練は、負荷とコストに応じて、複数のレベルを組み合わせます。
- 机上演習（月次）
- シナリオベースの意思決定訓練で、2時間で完結し、全管理職が参加します。判断の迅速化と役割理解が目的です。進行役が「ランサムウェア感染が検知されました。どう対応しますか？」というシナリオを提示し、参加者が「対策本部を設置します」「ネットワークを隔離します」等の判断を行います。実際にシステムを操作するわけではないため、業務への影響なく実施できます。机上演習のメリットは、①低コスト、②高頻度で実施可能、③判断力の向上、④コミュニケーション改善です。シナリオは、前回のインシデントや最新の脅威トレンドを反映させ、常に現実的な内容にします。
- 機能演習（四半期）
- 実際のシステムで復旧手順を確認します。バックアップからの復旧、代替システムへの切り替えを実施します。例えば、「本番環境のデータベースを、テスト環境に復元する」という訓練を行います。手順書通りに進めて、①復旧にかかる時間、②発生した問題、③手順書の不備、を記録します。機能演習では、実際のデータとシステムを使うため、より現実的な訓練となります。ただし、本番環境に影響を与えないよう、テスト環境や休日に実施する等の配慮が必要です。機能演習で発見される問題：①バックアップツールの操作方法が分からない、②想定より復旧に時間がかかる、③手順書が古く、現在の環境と合わない、等です。
- 総合演習（年次）
- 全社規模でのBCP発動訓練を行います。24-48時間の本格演習で、外部評価も実施し、改善点を次年度計画に反映します。シナリオ例：「金曜夜にランサムウェア感染が発生。週末を使って復旧を試みるが、月曜朝までに完全復旧できず。代替業務手段で営業開始」。この訓練では、①対策本部の設置、②ステークホルダーへの連絡、③代替業務の実施、④復旧作業、⑤記者会見（模擬）、まで行います。外部の専門家（セキュリティコンサルタント等）に評価を依頼し、客観的なフィードバックを得ます。総合演習は大規模で負荷が高いため、年1回が現実的です。
表5：訓練スケジュール（年間計画例）
| 月 | 訓練種類 | 対象 | 時間 | テーマ | 評価方法 |
|---|---|---|---|---|---|
| 1月 | 机上演習 | 管理職 | 2時間 | ランサムウェア初動対応 | 自己評価 |
| 2月 | 機能演習 | IT部門 | 半日 | バックアップリストア | 時間測定 |
| 3月 | 机上演習 | 管理職 | 2時間 | サプライチェーン攻撃対応 | 自己評価 |
| 4月 | 机上演習 | 管理職 | 2時間 | データ漏洩対応 | 自己評価 |
| 5月 | 機能演習 | IT部門 | 半日 | DR環境への切り替え | 時間測定 |
| 6月 | 総合演習 | 全社 | 2日間 | 全社BCP発動訓練 | 外部評価 |
| 7月 | 机上演習 | 管理職 | 2時間 | 内部不正対応 | 自己評価 |
| 8月 | 机上演習 | 管理職 | 2時間 | フィッシング起因のマルウェア | 自己評価 |
| 9月 | 機能演習 | IT部門 | 半日 | 代替業務手段の確認 | チェックリスト |
| 10月 | 机上演習 | 管理職 | 2時間 | 標的型攻撃対応 | 自己評価 |
| 11月 | 机上演習 | 管理職 | 2時間 | DDoS攻撃対応 | 自己評価 |
| 12月 | 機能演習 | IT部門 | 半日 | 年末の総復習 | 総合評価 |
このように、負荷の低い訓練を高頻度で実施し、本格的な訓練を年1回行うことで、継続的な改善が可能になります。
継続的改善
訓練の結果や実際のインシデント経験から学び、計画を継続的に改善します。
レッスンズラーンド
インシデント対応後、必ず「レッスンズラーンド（教訓抽出）」を実施します。
レッスンズラーンドの手順
- 事実の整理：何が起きたか、時系列で整理
- うまくいった点：計画通りに機能した部分を明確化
- うまくいかなかった点：問題が発生した部分を特定
- 根本原因：なぜうまくいかなかったのか、深掘り
- 改善策：具体的な改善アクション、担当者、期限を決定
- フォローアップ：改善策が実施されたか確認
レッスンズラーンドは「犯人探し」ではなく、「システムの改善」が目的です。責任追及ではなく、建設的な議論を心がけます。
計画のアップデート
BCP/DR計画は「生きた文書」として、定期的に更新します。
更新のトリガー
- 組織変更：部門統廃合、役員交代、事業所移転
- システム変更：新システム導入、クラウド移行、ネットワーク変更
- 脅威の変化：新たな攻撃手法、法規制の変更
- 訓練結果：訓練で発見された問題点
- インシデント経験：実際のインシデントから得られた教訓
最低でも年1回、全体の見直しを行い、常に最新の状態を保ちます。
成熟度評価
自社のBCP/DR体制がどのレベルにあるか、定期的に評価します。
ISO22301準拠
ISO22301は、事業継続マネジメントシステム（BCMS）の国際規格です。この規格に準拠することで、標準的なBCM体制を構築できます。
ISO22301の主要要求事項
- 組織の状況理解：事業環境、ステークホルダー要求の理解
- リーダーシップ：経営層のコミットメント、方針策定
- 計画：リスク評価、BIA、目標設定
- 支援：リソース確保、教育訓練
- 運用：BCP策定、訓練実施
- 評価：監視、内部監査、マネジメントレビュー
- 改善：是正処置、継続的改善
ISO22301認証取得は必須ではありませんが、体系的なBCM構築の指針として有効です。
ベンチマーク
業界他社や同規模企業とのベンチマークにより、自社の立ち位置を把握します。
表6：BCP/DR成熟度評価基準
| レベル | 状態 | 特徴 | 該当企業の割合 | 次のステップ |
|---|---|---|---|---|
| レベル1：初期 | 計画なし | ・BCPが策定されていない ・担当者が不明確 ・訓練未実施 |
30% | BCP策定開始 |
| レベル2：基本 | 計画あり | ・BCPは策定済み ・年1回の訓練 ・サイバー要素が不十分 |
40% | サイバーBCP追加 |
| レベル3：管理 | 統合運用 | ・サイバーBCPを統合 ・四半期訓練実施 ・継続的改善プロセス |
20% | 自動化・高度化 |
| レベル4：最適化 | 継続改善 | ・自動復旧機能 ・AI活用の予測 ・業界リーダー |
8% | イノベーション |
| レベル5：レジリエント | 自己回復 | ・自動的な復旧 ・学習する体制 ・ベストプラクティス創出 |
2% | 業界への貢献 |
現在のレベルを把握し、次のレベルへのロードマップを作成します。
自社評価の方法
以下のチェックリストで、各項目を5段階評価（1=不十分、5=優秀）し、平均点でレベルを判定します。
| 評価項目 | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| BCP/DR計画の策定 | 未策定 | 部分的 | 策定済み | 統合済み | 最適化 |
| サイバー要素の統合 | なし | 検討中 | 部分的 | 完全統合 | 業界リーダー |
| BIAの実施 | 未実施 | 簡易版 | 定期実施 | 詳細分析 | 予測的 |
| RTO/RPOの設定 | 未設定 | 一部設定 | 全システム | 最適化 | 動的調整 |
| バックアップ戦略 | 不十分 | 基本的 | 3-2-1 | 3-2-1-1 | 自動化・検証 |
| 訓練の実施 | 未実施 | 年1回 | 四半期 | 月次 | 継続的 |
| 外部専門家の活用 | なし | 緊急時のみ | 契約済み | 定期関与 | 戦略的提携 |
| 経営層の関与 | なし | 形式的 | 定期報告 | 積極関与 | リーダーシップ |
平均3.0以上で「レベル3：管理」、4.0以上で「レベル4：最適化」と評価できます。
よくある質問（FAQ）
- Q: 従来のBCPにサイバー要素を追加するだけではダメ？
- A: 不十分です。サイバー攻撃特有の要素として、①攻撃が継続する（自然災害は一過性）、②データ汚染の可能性、③犯罪者との対峙、④二次攻撃のリスク、⑤レピュテーション管理の重要性があります。これらを考慮した専用計画が必要です。既存BCPをベースに、サイバー特化のサブプランを作成することを推奨します。具体的には、従来BCPの「災害発生時の対応」に加えて、「攻撃者が潜伏している前提での対応」「感染範囲の特定と封じ込め」「証拠保全」「法執行機関との連携」「犯罪者との交渉（身代金要求への対応）」等の要素を追加します。また、物理災害は「復旧すれば終わり」ですが、サイバー攻撃は「復旧後も監視が必要」という違いもあります。
- Q: RTO 24時間は現実的ですか？
- A: 業務によりますが、段階的復旧なら可能です。優先度設定として、①最重要業務4時間、②重要業務24時間、③通常業務72時間、④その他1週間、というように段階的に設定します。完全復旧でなく、最小限の業務継続を目指します。重要なのは、「完璧な復旧」より「迅速な業務再開」です。例えば、ECサイトの場合、24時間以内に「受注機能」だけでも復旧できれば、顧客への影響を最小化できます。その後、「在庫管理」「顧客管理」「レポート機能」等を順次復旧していきます。全機能が揃うまで営業を停止するより、部分的でも営業する方が、ビジネスへの影響は小さくなります。ただし、RTO 24時間を実現するには、相応の投資（バックアップ環境、DR環境、訓練）が必要です。
- Q: バックアップがあれば大丈夫では？
- A: バックアップだけでは不十分です。課題として、①バックアップも暗号化される（ランサムウェアがバックアップを標的にする）、②復旧に時間がかかる（大容量データのリストアは数日かかる場合も）、③感染原因が残存（復旧しても再感染する）、④復旧中の業務継続（復旧完了まで業務が止まる）があります。必要な対策は、イミュータブルバックアップ（削除・変更不可能）、復旧訓練（実際にリストアして時間を測定）、代替業務手段（システムなしでの業務継続）、インシデント対応体制（感染原因の特定と排除）です。「バックアップ」と「復旧できること」は別問題で、バックアップの存在だけでなく、「確実に復旧できること」を訓練で確認する必要があります。
- Q: 中小企業でもBCP/DRは必要？
- A: 絶対に必要です。むしろ中小企業こそ重要な理由は、①復旧リソースが限定的（大企業のような潤沢なIT人材がいない）、②1回の攻撃で倒産リスク（大企業は財務的余裕があるが、中小企業は1回で致命傷）、③取引先からの要請（大手企業が取引条件としてBCP策定を求める）があります。最小限のBCPとして、①重要データの特定（なくなったら事業が継続できないデータ）、②バックアップ（クラウドストレージを活用すれば低コスト）、③緊急連絡網（紙で保管）、④代替業務手段（電話・FAX・紙伝票）を準備します。完璧でなくても、基本的な準備があれば生存確率が大幅に向上します。中小企業向けのクラウドバックアップサービスは月額数千円から利用でき、費用対効果は非常に高いと言えます。
- Q: BCP訓練の効果的な実施方法は？
- A: 段階的アプローチが効果的です。①読み合わせ（月次、30分）：手順書を読み合わせて内容を確認、②机上演習（四半期、2時間）：シナリオベースで意思決定を訓練、③部分訓練（半期、4時間）：特定機能（バックアップリストア等）を実際に検証、④総合訓練（年次、1-2日）：全体を通しての検証、という段階を設定します。重要なのは、完璧な訓練より頻度です。小規模でも定期実施することで、確実に対応力が向上します。訓練のコツは、①実際に起こりそうなシナリオを使う、②完璧を求めず、問題を発見することを目的とする、③訓練後に必ず振り返りを行い、改善点を文書化する、④次回の訓練で改善を確認する、というサイクルを回すことです。訓練で失敗することは、本番で失敗するより遥かにマシです。
まとめ｜サイバーレジリエンスの実現へ
BCP/DR計画とマルウェア対策の統合は、現代企業の生存戦略として不可欠です。本記事では、サイバーBCPの必要性、ビジネスインパクト分析（BIA）、実践的な対応計画、多層的な復旧戦略、そして実効性を高める訓練まで、包括的に解説しました。
本記事の重要ポイント
- マルウェアは災害：ランサムウェアによる事業停止は、自然災害と同等以上の脅威
- BIAの実施：業務の重要度を定量評価し、復旧優先順位を明確化
- 時間軸での対応：初動（0-4時間）、暫定（4-24時間）、復旧（1日以降）の段階的対応
- 多層的復旧：バックアップ、DR環境、代替業務手段を組み合わせ
- 継続的訓練：机上演習から総合訓練まで、段階的な訓練プログラム
サイバーレジリエンスの要素
サイバーレジリエンス（サイバー攻撃への回復力）は、以下の要素で構成されます。
これらを総合的に強化することで、「攻撃されても倒れない組織」を実現できます。
次のステップ
BCP/DR計画の策定・改善は、以下のステップで進めます。
- 現状評価：成熟度評価で自社のレベルを把握
- BIAの実施：重要業務の特定、RTO/RPO設定
- 計画策定：対応計画、復旧戦略の文書化
- リソース確保：バックアップ環境、DR環境、外部支援の契約
- 訓練開始：小規模な訓練から開始し、徐々に規模を拡大
- 継続改善：訓練結果やインシデント経験から学び、計画を改善
完璧な計画を作ることより、「今できること」から始めることが重要です。小さな一歩でも、ないよりは遥かにマシです。
関連リソース
さらに詳しい情報は、以下の関連ページもご覧ください。
また、サイバー保険の活用も、財務的なリスク軽減に有効です。
【重要なお知らせ】
- 本記事は一般的な情報提供を目的としており、個別の状況に対する助言ではありません
- BCP/DR計画は、組織の規模、業種、リスク許容度により異なります
- 実際のインシデント対応では、法執行機関（警察）や専門家への相談が必要な場合があります
- 記載内容は作成時点の情報であり、脅威やベストプラクティスは常に進化しています
- RTO/RPOの設定や復旧手段の選択は、コストとリスクのバランスを考慮した経営判断が必要です
- バックアップがあっても完全な復旧を保証するものではなく、定期的な復旧訓練が不可欠です
- ランサムウェアの身代金支払いについては、法的・倫理的な問題があるため、必ず専門家に相談してください
更新履歴
- 初稿公開
