3. 侵害から事業停止まで：技術障害を経営障害にしない

3.1 被害は「暗号化された台数」では測れない

ランサムウェア対応で最初に作るべき表は、感染端末数の一覧ではない。業務、システム、データ、依存先、復旧手順、許容停止時間を結ぶ依存関係表である。例えば、販売システムが動いても、ID認証、DNS、証明書、ネットワーク、データ連携、帳票出力、決済、物流、コールセンターのどれかが失われれば、実務上は再開できない。

図5　「システム復旧」と「業務復旧」の差

この順序は固定ではないが、サーバーを復元したことと業務が安全に再開できることの間に、多くの検証があることを示す。復旧時間目標（RTO）と復旧時点目標（RPO）は、アプリケーション単位ではなく、業務の復旧単位で確認する。

3.2 可用性・完全性・秘密性を同時に扱う

ランサムウェアは可用性の問題として語られがちだが、現代の事案では三要素が同時に揺らぐ。

特に完全性は難しい。侵害者がどの期間から環境にいたか、どのアカウント・設定・データに届いたかが不明なまま復旧すると、攻撃者の永続化や改変を戻してしまうおそれがある。これは「復旧を遅らせよ」という意味ではなく、クリーンな復旧境界を定義し、優先順位を持って進めよという意味である。

3.3 依存関係を平時に可視化する

最低限、重要業務ごとに次を記録する。

1. 業務責任者と技術責任者。
2. 停止の影響と許容停止時間。
3. 必須アプリケーション、データ、ID、ネットワーク、外部サービス。
4. 代替手順（紙、手入力、別拠点、優先顧客の扱い）。
5. 復旧順序、検収者、復旧成功の判定基準。
6. バックアップの場所、世代、復元に必要な鍵・アカウント・手順。

これをCMDBやBCPと別のExcelに閉じ込めない。変更管理、サービスオーナー、バックアップ運用、インシデント訓練で同じ情報を更新する。現場で情報が見つからないこと自体が、復旧時間を伸ばす重大なリスクになる。

3.4 バックアップ設計：保管ではなく復旧能力

バックアップはランサムウェア防御の最後の砦として重要だが、万能ではない。侵害者が通常の管理権限を得ている場合、オンラインで書き換え可能なバックアップ、スナップショット、管理コンソールに到達する可能性がある。CISAは、バックアップの保護、定期的な復元テスト、重要データの複数コピーを含む対策を推奨している。[S01]

設計の確認項目

• 本番IDと同じ特権資格情報だけで、バックアップ削除・保持変更・暗号鍵操作ができないか。
• 本番ネットワーク障害時にも、バックアップの状態と復元手順を確認できるか。
• 変更不能性・隔離・オフライン保管のいずれを、どの重要データに適用するか。
• 復元テストはファイル一個ではなく、アプリケーション、認証、依存サービス、性能、データ整合性を含むか。
• 復元に必要なライセンス、DNS、証明書、秘密情報、設定管理、管理端末が失われた場合を想定しているか。
• 失われた最終数時間・日間のデータを、どの業務手順で補正するか。

実務判断：バックアップの「成功」はジョブ完了通知では測らない。復元した環境で、所定の業務を、所定の時間内に、安全に実行できたときに初めて成功である。

3.5 事業継続と危機対応の分業

インシデント中、技術調査と経営判断を同じ会議で混ぜると、両方が遅くなる。役割を分け、情報を統合する構造が必要である。

3.6 支払いをどう位置づけるか

支払いの是非を技術論だけで決めることはできない。復号ツールが提供される保証、窃取データが削除される保証、再攻撃されない保証はいずれもない。さらに、適用法令、制裁対象、保険条件、捜査機関への相談、取引先との契約、社会的責任が関係する。CISAのガイドも、支払いは復旧を保証せず、組織は法務・捜査機関等と連携すべきことを強調する。[S01]

本書の立場は明確である。身代金支払いを、技術的な復旧策の一部として設計してはならない。 それは極限状態での経営・法務判断であり、バックアップ、復旧演習、代替運用、侵害範囲調査を置き換えない。

3.7 演習で検証すべき問い

• 日曜の深夜にID基盤への侵害疑いが出たとき、誰がアカウント停止を承認するか。
• バックアップ管理者のIDが疑わしいとき、どの別経路で復旧基盤へ入るか。
• 顧客ポータルを止める判断と、業務部門への影響通知は誰が行うか。
• リークサイト掲載の主張を見つけたとき、誰が保存・検証し、誰が外部発信を止めるか。
• 72時間後に「復旧済み」と発表するために、何をもって安全性を確認するか。

演習の目的は、完璧な台本をなぞることではない。連絡先の不備、権限の曖昧さ、復元の前提不足、事業部との言葉の違いを平時に見つけることである。