ランサムウェア被害からの復旧とバックアップ設計。3-2-1とイミュータブルで「戻せる」備えをつくる

ランサムウェアの被害が起きたとき、最終的に組織を救うのはバックアップです。攻撃者がファイルを暗号化してしまうと、その復号鍵は攻撃者しか持っておらず、技術的に自力でデータを取り戻す手段はほとんど残りません。だからこそ「侵入されても戻せる」状態を先につくっておくことが、被害を事業の停止ではなく一時的な不便にとどめる分かれ目になります。

ところが、バックアップは「取っていれば安心」という性質のものではありません。攻撃者は復旧を妨げるために、暗号化の前にバックアップそのものを探して破壊・暗号化しようとします。本番系と同じネットワークに常時つながり、同じ管理者権限で書き換えられるバックアップは、本番もろとも巻き込まれる「あるようでないバックアップ」になりかねません。実際、侵入後にまずバックアップの破壊・暗号化を狙う攻撃が広く確認されており、バックアップは守るべき対象そのものになっています。

この記事は、ランサムウェア被害からの復旧という観点に絞り、バックアップ設計の指針である3-2-1ルール、攻撃者から切り離すための隔離とイミュータブル（変更不可）の考え方、そして「本当に戻せるか」を確かめる復旧訓練までを、運用担当者が自分の環境に当てはめて判断できる粒度で解説します。感染経路や二重恐喝など侵入を防ぐ側の話は

まず押さえる早見表#

復旧の備えは、「複製をどう持つか」「攻撃者からどう切り離すか」「本当に戻せるかをどう確かめるか」の3点に集約できます。全体像を一枚で把握しておきます。

これらは独立した施策ではなく、上から順に積み上げる前提です。隔離やイミュータブルがないまま世代数だけ増やしても、攻撃者にまとめて消されれば意味がありません。逆に、隔離された退避先があっても復旧テストをしていなければ、いざというときに戻せない可能性が残ります。

なぜバックアップが復旧の本命なのか#

ランサムウェアの暗号化は、強力な暗号アルゴリズムを使ってファイルをロックします。復号には攻撃者が握る鍵が必要で、鍵がなければ現実的な時間で解くことはできません。つまり、暗号化されてしまったデータを技術的に元へ戻す道は、原理的にほぼ閉ざされています。例外として、特定のランサムウェアでは「No More Ransom」などで無償の復号ツールが公開される場合がありますが、これは攻撃主体の活動停止や専門家の解析に依存し、自分の被害に必ず使えるわけではありません。そのため実務上、残された選択肢は「攻撃者に身代金を払って鍵をもらう」か「自前の正常なバックアップから戻す」かに絞られますが、前者は犯罪者との取引であり、払っても完全に復旧する保証はなく、攻撃を助長する問題もあります。

JPCERT/CCの「侵入型ランサムウェア攻撃を受けたら読むFAQ」も、復旧の基本方針として、身代金の支払いに頼るのではなく、影響範囲を把握して被害を最小化し、侵入経路を塞いだうえでバックアップから復旧することを示しています。ここで重要なのは順序で、侵入経路を塞ぐ前にバックアップから戻すと、攻撃者がまだ内部に残っていて再び暗号化されるおそれがあります。

JPCERT/CCのFAQ（侵入型ランサムウェア攻撃を受けたら読むFAQ）では、正常なバックアップの保護を優先すること、侵入経路を塞いでから復旧すること、被害発生時の初動と相談先が整理されています。最新の更新内容は原典を確認してください。

この前提に立つと、バックアップは「保険」ではなく復旧の中核装置です。そして攻撃者もそれを知っているからこそ、バックアップを真っ先に狙います。だからバックアップ設計は、単に容量や頻度を決める運用作業ではなく、「攻撃者からどう守るか」というセキュリティ設計として考える必要があります。

3-2-1ルール ― 複製の持ち方の基本#

バックアップ設計の出発点として広く使われるのが「3-2-1ルール」です。元はデータ消失全般に備える一般的な指針ですが、ランサムウェアの文脈でも土台として有効です。数字の意味を分解します。

ただし注意したいのは、3-2-1の「1」が指すのは本来「別拠点（オフサイト）」であって、それだけではネットワーク経由の攻撃から切り離されているとは限らない点です。オフサイトであっても本番系とつながっていれば、攻撃者の権限でそこまで到達され得ます。ランサムウェア対策で決定的に重要なのは、このオフサイトに加えて「攻撃者から切り離す（オフラインまたはイミュータブル）」退避先を確保することです。常時マウントされたNASにだけバックアップを取っている状態は、たとえ別拠点にあっても切り離しの観点では不十分で、本番を暗号化した攻撃者の権限でそのままNASも暗号化され得ます。NAS活用時の落とし穴は

近年は、この3-2-1を補強した「3-2-1-1-0」という言い方も使われます。末尾に「1つは隔離（オフラインまたはイミュータブル）」と「0（復旧テストでエラーゼロを確認）」を足したもので、ランサムウェア時代の実務感覚に合った拡張です。数字の語呂を覚えることが目的ではなく、複製・媒体分散・隔離・検証という4つの要素を漏れなく満たすことが本質だと理解してください。

隔離とイミュータブル ― 攻撃者の手が届かない退避先#

「攻撃者から切り離す」には、大きく分けて2つのアプローチがあります。物理的・時間的に切り離す「隔離（オフライン・エアギャップ）」と、書き換え自体を禁止する「イミュータブル（変更不可）」です。

隔離は、バックアップを取得する時以外はネットワークや本番系から切り離しておく方法です。テープや外付けストレージにバックアップを取り、取得後は物理的に接続を外して保管庫にしまうのが典型例です。攻撃者の侵入経路がネットワーク越しである以上、線がつながっていない退避先には手が届きません。古典的ですが、ランサムウェアに対しては今も強力です。一方で、人手の運用に依存するため、付け替えを忘れる・接続したまま放置するといった運用ミスで効果が消える点に注意が必要です。

イミュータブルは、ストレージ側の機能で「一定の保持期間は書き換えも削除もできない」状態を作る方法です。クラウドのオブジェクトストレージで使えるオブジェクトロック（WORM: Write Once Read Many）や、専用バックアップ装置のイミュータブル機能が該当します。狙いは「管理者権限を奪われてもバックアップを消されない」ことですが、その強度はモードの選び方に依存する点に注意が必要です。たとえばAWS S3のオブジェクトロックには、特別な権限（Governance bypass）を持つ利用者なら保持を上書きできるガバナンスモードと、ルート権限でも保持期間中は削除できないコンプライアンスモードがあり、攻撃者による削除に確実に抗するには後者のように適切にロックされた設定が要ります。そのうえで、保持期間の設定や、バックアップ系の認証を本番系と分離する設計、bypass権限の最小化を正しく行わないと効果が損なわれます。常時オンラインのまま守れるため運用負荷が低いのが利点です。

IPAのランサムウェア対策特設ページでは、ランサムウェアの基本情報のほか、NISC・警察庁・JPCERT/CC等の対策資料や啓発コンテンツが集約されています。バックアップの隔離・オフライン保管の考え方も各資料で示されています。

実務では、この2つを組み合わせるのが堅実です。たとえば日次は本番近くの高速なストレージへ、週次・月次は隔離またはイミュータブルな退避先へ、というように頻度と隔離度を変えて多層に持ちます。こうしておけば、軽微な障害は手近なバックアップですばやく戻し、ランサムウェアのような全体被害には隔離済みの退避先で戻す、と使い分けられます。

この声が示すのは、「バックアップを取っているか」ではなく「そのバックアップは攻撃者から切り離されているか」が成否を分けるという点です。退避先の認証を本番と別系統にする、取得後に接続を切る、イミュータブルの保持期間を設けるといった一手間が、復旧できるかどうかを決めます。

RTOとRPO ― 復旧目標から頻度と世代数を逆算する#

バックアップの頻度や世代数を「なんとなく日次で1週間分」と決めていないでしょうか。本来は、業務が許容できる復旧の条件から逆算します。ここで使う2つの指標がRTOとRPOです。

RTO（Recovery Time Objective、目標復旧時間）は、被害発生から業務を再開するまでに許容できる時間です。RTOが短いほど、復旧を高速化する仕組み（手近で速いバックアップ、リストア手順の自動化、予備環境の確保など）に投資する必要があります。RPO（Recovery Point Objective、目標復旧時点）は、どの時点まで戻せれば許容できるか、言い換えると失ってもよいデータの最大幅です。RPOを小さくしたいほど、バックアップの取得間隔を短くする必要があります。

たとえば「半日分のデータ消失までは許容できる」業務ならRPOは半日で、最低でも半日に一度はバックアップを取る設計になります。「2日以内に復旧できればよい」ならRTOは2日で、その時間内に隔離済みバックアップから戻し切れる手順と体制を用意します。重要なのは、この2つを業務の重要度ごとに分けて決めることです。基幹システムと一時ファイルでは許容できる損失も停止時間も違うため、一律の頻度・世代数で運用すると、過剰な箇所と不足する箇所が同時に生まれます。

復旧訓練 ― 「取れている」と「戻せる」は別物#

バックアップ設計で最も軽視されがちで、しかし最も効くのが復旧訓練です。バックアップは取得が完了した時点では「取れている」ように見えても、ファイルが壊れている、世代が足りない、リストア手順が分からず時間がかかる、といった理由で「戻せない」ことが珍しくありません。これらは実際に戻してみて初めて発覚します。

NISTのCybersecurityFramework（CSF）でも、バックアップは作成して保護するだけでなく、維持しテストすることが求められています。復旧訓練は思いつきで行うのではなく、本番とは隔離した検証環境へ実際にリストアし、業務が再開できる状態まで戻せるかを確かめます。このとき、RTO（どれだけ時間がかかったか）とRPO（どの時点まで戻せたか）を実測し、設計値と乖離していれば頻度や手順を見直します。

NISTのCybersecurity Frameworkでは、バックアップデータの作成・保護・維持・テストが管理項目として位置づけられています。バックアップは取得だけでなく、復旧可能性の継続的な検証まで含めて設計すべきという考え方の根拠になります。

訓練は年に一度の儀式にせず、システム構成やバックアップ方式を変えたタイミングでも実施するのが望ましい運用です。構成変更でバックアップ対象から漏れた領域が生まれることはよくあり、それは実際に戻してみないと気づけません。

検証は許可された環境で ― 関連法令への注意#

ランサムウェアの挙動を理解するために、検体や攻撃手法を扱いたくなることがあります。しかし、マルウェア検体の実行や攻撃手法の検証は、自分が管理する環境または明示的に許可を得た対象でのみ行ってください。他人のシステムやネットワークに対する無許可のアクセス・操作は、不正アクセス禁止法をはじめとする関連法令に抵触するおそれがあります。バックアップの復旧訓練も、必ず自組織の正規の手続きと検証環境の範囲内で実施してください。

よくある質問#

まとめ#

ランサムウェアからの復旧は、暗号化された後に何とかするものではなく、暗号化される前にどれだけ「戻せる備え」を積んでおいたかで決まります。3-2-1を土台に、攻撃者から切り離した退避先（オフラインまたはイミュータブル）を確保し、認証を本番と分離する。そのうえで、業務に見合うRTO/RPOを決め、実際に戻せることを訓練で確かめておく。この一連が揃って初めて、バックアップは復旧の頼みの綱になります。侵入を防ぐ側の対策とあわせて備えるために、