ランサムウェア復旧計画とは？危険性や対策方法を徹底解説

何が起きた時に、ランサムウェア復旧計画が必要になるのか

復旧は『サーバを戻すこと』ではなく『業務を戻すこと』です

ランサムウェア復旧計画は、単純に暗号化されたサーバを復元する話ではありません。どの業務を先に再開すべきか、その業務に必要な周辺システム、承認、人手、代替手段が何かを整理し、事業を安全に戻す順番を決めることが主役です。

そのため、技術部門だけで完結しません。業務部門、経営、CS、物流、医療現場など、現場側の優先順位を一緒に確認する必要があります。

たとえば物流停止BCPや医療機関ランサムウェアのように、止められる業務と止められない業務が混在する分野では、この順序設計が特に重要です。

初動対応と復旧計画は別の役割です

ランサムウェア初動対応が悪化を止める実務であるのに対し、復旧計画はどこから戻せば全体の停止を短くできるかを決める実務です。

この二つを混ぜると、封じ込めが甘いまま復旧を急いだり、逆に復旧の優先順位が決まらず現場が止まり続けたりします。

RTO / RPO は、そのまま並べるだけでは足りません

検索意図としても、復旧計画を探す人は RTO や RPO をどう使うかで迷っています。ただし実務では、システムごとの RTO / RPO をそのまま表に並べても、現場の業務再開順には直結しません。受注、出荷、診療、問い合わせ対応のような業務単位の再開時刻に翻訳して初めて、復旧順序の判断材料になります。

たとえばデータベースの復旧が早くても、認証基盤、周辺連携、承認権限、現場手順が戻らなければ業務は再開できません。だから復旧計画では、技術指標を業務再開指標へ言い換える作業が欠かせません。

さらに、同じ「受注再開」でも、顧客向け画面を戻すことと、内部承認や在庫引当まで回ることは別問題です。復旧計画は、表面的なサービス再開ではなく、その業務が成立するための前提を洗い出す作業です。だから、業務 owner と IT 部門が別々に復旧優先順位を持つと、技術的には戻ったのに現場では使えない状態が残りやすくなります。

また、ランサムウェア事故では「復旧できたか」より「安全に使い始められるか」が重要です。復旧直後は、一部機能制限、暫定アカウント、代替フローを伴うことが多く、平常運用へ戻るまでの段階をあらかじめ分けておくと、現場説明と経営報告が整いやすくなります。

さらに、復旧計画では「どこから戻すか」だけでなく、「どこは意図的に後ろへ回すか」も決めておく必要があります。便利機能、周辺レポート、外部向けの補助画面などは、業務再開に必須でないなら後ろへ回した方が安全です。重要なのは、限られた人員と安全確認の時間を、本当に止められない業務へ集中させることです。

実務で最初にやること / 優先順位

CISA も復旧を『公共機能の再開』として整理しています

CISA のcyber risks to public safety from ransomware↗は、技術復旧だけではなく、住民や利用者へ必要な機能をどう戻すかを重視しています。これは民間企業でも同じで、停止した業務をどう優先して再開するかが重要です。

その前提として、初動対応で封じ込めと証拠保全が済んでいること、バックアップ破壊対策で戻せる状態が守られていることが必要になります。

復旧前提情報を決めていないと、訓練しても本番で迷います

復旧計画で抜けやすいのは、担当者名簿ではなく前提情報です。誰が復旧判断を出すのか、代替運用の開始条件は何か、どのアカウントを先にリセットするか、どの機能を制限付きで再開するかを決めていないと、訓練では回っても本番で止まります。

そのため、復旧計画書には手順だけでなく、業務 owner、依存先、代替運用の上限時間、復旧後の安全確認、利用者向け周知文面まで含めると、実際の再開に近い設計になります。

ここでいう前提情報には、技術情報だけでなく事業判断も含まれます。どの業務を1日止めるとどの程度の損失や信用低下が出るのか、法令や契約上止められない処理は何か、代替運用に必要な人員は誰かが分かっていないと、復旧順を決めても現場で実行できません。復旧計画は、システム表ではなく業務再開台本に近い文書です。

業務再開順をどう設計するか

『重要システム』ではなく『止められない業務』から逆算します

復旧計画で最も多い誤りは、「重要システム一覧」をそのまま復旧順序にしてしまうことです。しかし実際には、営業が使う CRM より受注 API が先かもしれず、会計サーバより出荷ラベル印刷が先かもしれません。復旧順序は IT 資産の重要度ではなく、止められない業務の成立条件から逆算する必要があります。

この時に有効なのが、業務ごとに「最低限必要な画面」「最低限必要なデータ」「代替手段の有無」を分けることです。全部を完全復旧させないと再開できないと考えると、復旧開始が遅れます。逆に、限定的な受注、限定的な診療、限定的な問い合わせ対応など、段階的再開の形を決めておくと、停止期間を短くしやすくなります。

実務では、この段階的再開を業務部門と一緒に決めておかないと、IT 部門だけが「まだ危険だから開けられない」と判断し、現場側は「最小限でもよいから再開したい」と考えて対立しやすくなります。復旧計画の価値は、その対立を事故当日に持ち込まないことにあります。平時のうちに、限定再開で許容できる品質と、絶対に守るべき条件を言語化しておく必要があります。

依存関係は『技術依存』と『運用依存』を分けて見ます

復旧計画では、DB がアプリに依存する、認証基盤がポータルに必要という技術依存は見えやすい一方で、承認者が在席しているか、帳票出力用プリンタが使えるか、委託先の夜間窓口が動くかといった運用依存は見落とされがちです。実際の業務停止は、この運用依存で長引くことが多いです。

したがって、依存関係表にはシステム間連携だけでなく、人、委託先、物理機器、承認フロー、規制上の確認を載せる必要があります。ここまで見えて初めて、「どの順で戻せば業務が動くか」を語れます。

段階的再開の目安を最初から決めておきます

復旧は「停止」と「完全再開」の二択ではありません。一次再開、制限付き再開、通常再開の三段階程度に分け、各段階で使える機能と使えない機能を明文化すると、利用者も現場も動きやすくなります。たとえば問い合わせ受付だけ先に戻す、出荷は一部顧客に限定する、診療は予約枠を絞るといった形です。

この段階設計がないと、技術チームは「まだ完全ではないから公開できない」と考え、業務側は「いつまで待てばよいか分からない」と感じます。復旧計画は、この認識差を埋める文書でもあります。

さらに、各段階で「何を確認したら次へ進めるか」を決めておくと、再開判断がぶれにくくなります。たとえば一次再開では認証基盤と主要データが安全であること、制限付き再開では監視強化と代替運用の引き継ぎが完了していること、通常再開では委託先導線や外部公開面の再点検まで済んでいることを条件にすると、速度だけでなく再停止しない再開へ寄せやすくなります。

現場で失敗しやすいポイント

『戻せるものから戻す』は、最適とは限りません

復旧計画で起こりやすい失敗は、技術的に早く戻せるものから順に再開することです。実際には、利用者が使えるか、周辺システムがつながるか、紙運用が限界かという業務側の制約が先にあります。

だから復旧順序は、システムの都合より、業務の再開価値と依存関係で決める必要があります。

もう一つ多い失敗は、「安全確認は後でやる」と考えることです。戻した直後に同じ認証情報で再侵入されたり、監視がまだ弱いまま公開を再開したりすると、短時間で再停止が起こります。復旧計画には、戻す順番だけでなく、戻す前に確認すべき条件を載せなければなりません。

復旧を急ぐほど、この確認は省略されやすくなります。しかし再停止は最初の停止より説明が難しく、現場負担も大きくなります。だから復旧計画では、早さより再停止しないことを優先する基準を持つ必要があります。

安全確認の項目は、復旧計画の本文に書いて初めて現場で使える条件になります。

これはバックアップ破壊対策と公開RDP 危険性の話ともつながります。戻した後に同じ入口が開いている、同じ高権限が残っている、同じ保管先が弱いままだと、復旧したこと自体が次の被害機会になります。

また、現場では「ひとまず限定公開で戻す」という判断がよく出ますが、その限定条件を決めていないと結局ほぼ通常公開と同じ運用になりがちです。復旧計画には、利用対象者、許可する操作、監視強化、問い合わせ対応、ロールバック条件まで書いておくと、限定再開を現実的に運用しやすくなります。

代替運用と復旧後安全確認の考え方

代替運用は『苦しい時の暫定策』ではなく計画対象です

代替運用は、単に紙で頑張る話ではありません。誰が記録するか、どの情報は後でシステムへ戻すか、顧客へどこまで説明するか、品質や安全をどこまで担保するかを決めないと、代替運用自体が事故源になります。復旧計画では、代替運用をシステム停止時の正式な業務モードとして扱う必要があります。

そのため、代替運用の章には、開始条件、責任者、利用期間の上限、通常運用へ戻す条件、記録の引き継ぎ方法を明文化します。これがあると、停止中も現場判断がぶれにくくなります。

復旧後の安全確認は『開ける前に見る』を徹底します

復旧後安全確認では、パッチ適用や EDR の有効化だけでなく、公開面、管理アカウント、委託先導線、バックアップ保護、監視ルールの再点検が必要です。つまり、戻した後に再び外へ開く前に、どの入口が残っていないかを確認します。

特に SaaS、委託先、外部ポータルが絡む環境では、社内システムが戻っても外部接点がまだ安全でないことがあります。外部接続点の可視化を平時から回しておくと、復旧時に再点検すべき候補が見えやすくなります。

訓練では『誰に何を伝えるか』まで確認します

復旧計画の訓練は、復元手順だけでは不十分です。利用者へ「何が使えるか」「何がまだ制限付きか」「次の案内はいつ出るか」をどう伝えるかまで練習しないと、再開後の混乱は減りません。特に顧客向けサービスでは、復旧そのものより復旧の見せ方が信頼に影響します。

加えて、訓練では「想定していない依存」がどこで出るかを記録しておくと、次の改訂が具体的になります。印刷、配送、支払、顧客通知、委託先承認など、復旧作業そのものではないが業務再開に必要な要素は、本番で初めて気づくと大きく遅れます。訓練結果は成功か失敗かだけでなく、次回までに補う依存関係の一覧として残すべきです。

実務では、この一覧をそのまま次回訓練の開始条件に使うと改善が回りやすくなります。前回の訓練で詰まった承認経路、委託先連絡、帳票出力、限定公開条件を次回の冒頭で確認すれば、計画書が棚に置かれた文書ではなく、事故経験に追随して更新される運用資産になります。

訓練と改訂をどう回すか

年1回の机上確認だけでは追いつきません

復旧計画は、年1回の文書確認だけではすぐ古くなります。新しい SaaS の導入、委託先変更、認証方式の変更、業務移管、拠点再編があると、依存関係と代替運用は簡単に変わるからです。したがって、重大なシステム変更や組織変更があった時点で復旧計画を見直す運用にしておく必要があります。

とくに、平時の運用では目立たない周辺サービスほど復旧計画から抜けやすいです。ファイル受け渡しポータル、委託先専用接続、帳票出力基盤、部門別の独自ツールなどは、事故時に業務再開を止める要因になりがちです。復旧計画の改訂では、こうした周辺だが止まると困る要素を毎回洗い出す視点が欠かせません。

計画の更新は incident review と結び付けます

実際の障害やセキュリティ incident が起きた時、その振り返りを復旧計画へ反映しないと計画は育ちません。ログ取得に時間がかかった、委託先連絡が遅れた、代替運用の説明が不足した、といった反省点をそのまま計画へ戻すと、次回の停止時間を短くしやすくなります。

その意味で復旧計画は、災害計画と同じく「事故を経験するほど精度が上がる文書」です。だから incident review、BCP 見直し、外部接続点整理、バックアップ運用見直しを別々に閉じず、一つの改善サイクルに戻すことが大切です。

更新した計画は、単に共有ドライブへ置くだけでなく、関係部門が実際に参照できる形で配布し直す必要があります。連絡先、代替運用、優先業務、復旧条件、再開時の注意事項が変わったら、古い手順書を残したままにしないことも運用品質の一部です。復旧計画は、作ることより更新を回し続けることの方が難しい文書です。

検知・防御・運用で押さえるべき対策

復旧計画は、技術作業の手順書ではなく、事業再開の設計図です。平時から依存関係と代替運用を見える化しておくと、事故時の迷いを減らせます。あわせて戻せる状態の確保と前段の外部露出の縮小を進めておくと、復旧中の再侵入にも備えやすくなります。

さらに、復旧計画は一度作って終わりではありません。新しい業務、委託先変更、SaaS 追加、拠点再編で依存関係はすぐ変わります。だから訓練のたびに、復旧順、代替運用、周知文面、安全確認条件を更新し、現行の事業構造に合った計画へ保つ必要があります。

前段になる外部導線の棚卸しなら ASM診断 PRO

ASM診断 PRO は復旧計画ツールではありませんが、公開RDP、古いログイン面、委託先導線など、平時に減らしておくべき外部導線の棚卸しを補助します。

復旧を長引かせる原因の一つは、前段の侵入口が広く残っていることです。平時に外部露出を整理しておくと、復旧中の不安定な期間を短くしやすくなります。

具体的には、公開された管理ポータル、古い認証画面、委託先向けの保守接続、停止済みなのに残っているサブドメインを台帳へ戻しておくことで、復旧時に「まず閉じるべき外部導線」を短時間で判断しやすくなります。復旧計画は業務再開の設計ですが、その前提には「戻した後に同じ入口から再侵入されにくいこと」があります。ASM診断 PRO は、その前提づくりを外から見える範囲の棚卸しで支える補助線として使えます。

具体的には、どのサブドメインが現役か、どの管理画面が外から見えるか、どの委託先接続がまだ残っているかが分かるだけでも、復旧時の安全確認は速くなります。事故後の現場では、確認対象を増やすより、確認対象を絞れることの価値が大きいです。

また、復旧計画はバックアップやサーバだけで完結しません。外から見える入口が整理されていないと、戻した後の監視対象もぼやけます。外部公開資産台帳や未管理公開資産のリスクと組み合わせて外部面を整理しておくと、復旧と再発防止を一本の流れにしやすくなります。

つまり ASM診断 PRO は復旧計画そのものではありませんが、平時に「戻した後どこを再確認するか」を明確にする補助線です。復旧の速さは、事故時の頑張りだけでなく、平時の棚卸し品質にも左右されます。

よくある質問

まとめ

ランサムウェア復旧計画の本質は、どのシステムからではなく、どの業務から安全に戻すかを決めることです。

依存関係、代替運用、安全確認を平時から整理しておくことで、事故時の迷いと停止期間を減らしやすくなります。