ランサムウェア対策で見直すバックアップ｜復旧できるかを確認するテスト設計

更改漏れはなぜ起きるのか - EOL・EOSL管理の現場課題

ある朝、バックアップから戻せなかった - 失敗シナリオから考える

ランサムウェア対策としてのバックアップは、取得できていることと、そこから復旧できることを分けて捉える必要があります。まずは、実際に起こりうる失敗の場面から見ていきます。

ジョブは「成功」、復元は「失敗」──食い違いはどこで起きるか

バックアップジョブが正常終了しているのに、いざ復元するとアプリが起動しない。この食い違いは実際に起こります。復旧が失敗する場面を分解すると、次の3つの層に整理できます。

どの層が欠けても「取得済み＝復旧可能」は成立しません。さらにランサムウェアの場合、共有フォルダーやネットワーク経由でつながったバックアップ領域まで暗号化・削除される手口が確認されており、バックアップが攻撃対象になり得るという前提が、従来の「取得していれば安心」という考え方とずれてきています。

平常時には見えない3つの兆候（自己診断チェック）

次の項目に一つでも当てはまる場合、有事に「戻せない」状態が潜んでいる可能性があります。自社の状況を確認してみてください。

• • バックアップは毎日取得しているが、そこからの復元を一度も試したことがない

  • 復旧手順を把握しているのが特定の担当者だけで、その人が不在だと動けない

  • バックアップ先が常時オンラインで、業務データと同じネットワークに置かれている

いずれも平常時には問題として表面化せず、有事に初めて「戻せない」ことが分かります。この見えにくさが、対策の落とし穴になります。

まず「壊されないバックアップ」を固める - 隔離・世代管理・イミュータブル

復旧テストの前提として、バックアップ自体が攻撃で壊されない状態にあることが求められます。判断の軸になるのが、隔離・世代管理・不変性 (イミュータブル) の3つです。テスト設計に入る前に、まずこの土台から確認します。

隔離：感染経路を物理・論理で断つ

感染は「つながっている経路」をたどって広がります。逆に言えば、バックアップを常時接続のネットワークから外し、必要なときだけ接続する運用にすれば、その経路を断てます。これが隔離の考え方です。オフラインでの保管や、論理的に分離した領域を組み合わせることで、被害の波及を抑えやすくなります。

世代管理：気づく前の時点まで戻れるようにする

感染に気づいた時点のデータは、すでに暗号化されている可能性があります。そこで、複数の時点のバックアップを保持し、感染前の正常なデータまでさかのぼって復元できるようにします。最新の1本だけでなく、感染に気づく前まで遡れるよう、最低でも数世代は残す設計にします。

イミュータブル：保持期間内は上書き・削除を拒む

一度書き込んだら、決めた期間は上書きも削除も受け付けない――この「後から手を入れられない」性質が不変性 (イミュータブル) です。攻撃者が管理者権限を奪ってバックアップの消去を試みても、保持期間内は操作がはじかれます。ただし後述のとおり、イミュータブルだけで復旧可能性が保証されるわけではありません。

3つの条件は、それぞれ守る対象と弱点が異なります。単体では穴が残るため、組み合わせて運用することが前提になります。

隔離だけでは古い世代に戻れず、世代管理だけでは丸ごと暗号化に弱く、不変性だけでは復元可否が分からない。3つを重ねて、運用として回して初めて機能します。バックアップ取得の基本的な考え方は 321ルールとは？バックアップの基本から実装手順、最新動向まで解説 で整理していますので、取得段階から見直す場合はあわせて確認できます。

なぜ「復旧できるか」の確認は後回しになるのか

壊されない条件を整えても、復旧できるかの確認が後回しになる現場は少なくありません。そこには、いくつかの構造的な理由があります。

本番を壊す不安がテストを止める

「復元を試したら本番のデータを壊すのでは」――このためらいが、テストを止める最大の要因です。実際、復元先を間違えれば稼働中のボリュームを上書きしかねません。だからこそ、隔離した検証用の環境を用意し、本番に影響を与えずに復元を試す前提が要ります。方法さえ整えれば、本番を止めずに確認することは可能です。

「担当者しか分からない」と「合格ラインがない」

もう一つの理由は、復旧手順が個人の経験に依存し、何をもって「復旧できた」とするかの基準が定まっていないことです。基準がなければ、テストをしても結果を評価できません。

ここで注意したいのが、イミュータブルストレージなどのツールを導入すれば安心という誤解です。改ざんされにくい保管方式は有効な場合がありますが、そこから復元できるかを確かめなければ、有事に機能するかは分かりません。ツールだけでは解決できない課題がある点は、事前に理解しておく必要があります。

復旧テストの設計図 - どこから・どの間隔で・何を合格とするか

復旧できるかを確認するには、テストを設計として組み立てる必要があります。感覚的に「たまに試す」のではなく、対象・頻度・合否基準を決めておくことが判断の助けになります。

どこから試すか - 重要システムの優先順位づけ

全システムを一度にテストしようとすると、負荷が大きく続きません。まずは事業への影響が大きい重要システムから対象を絞る進め方が、環境によっては現実的でしょう。復旧の優先度は、停止したときの業務影響を基準に考えます。

どの間隔で回すか - 続けられる頻度に寄せる

頻度は、システムの重要度と変更の多さで変わります。重要システムは定期的に、構成変更のあったタイミングでも確認する、といった組み合わせが考えられます。高頻度を前提にすると運用が回らなくなるため、続けられる頻度に設定することが望まれます。

何をもって合格とするか - RTO/RPOの2軸

合否は「戻せた／戻せない」の二択では決めません。判断軸は2つあります。ひとつは、あらかじめ決めた復旧時間の上限 (RTO) に間に合ったか。もうひとつは、どの時点のデータまで戻せたか、その欠損幅 (RPO) が許容内か。この2軸を満たして初めて「合格」と扱います。基準を数値で持っておくと、結果を評価しやすくなります。

向いているのは、重要システムが明確で、優先順位をつけて着実に確認したい環境です。逆に、対象を絞らず全システムを同時にテストしようとする場合は、負荷が高く形骸化しやすいため、範囲設計から見直す方が現実的です。

「誰が戻すか」を決める - 復旧を止めない体制づくり

テスト設計と並んで重要なのが、有事に実際に復旧を実行できる体制です。手順や役割が整理されていなければ、テストで確認できても本番で動けないことがあります。

手順書化と復旧責任者の指名

復旧手順を文書化し、誰が復旧の判断と実行を担うかを決めておくことが求められます。手順が特定の担当者の頭の中にある状態では、その人が不在のときに復旧が止まります。属人化を避ける意味でも、手順書化と責任者の指名は運用面の要点になります。

訓練と外部支援の使い分け

手順は、定期的に訓練で確認しておくと、有事に慌てにくくなります。とはいえ、少人数の情報システム部門で訓練まで手が回らないことも現実にはあります。自社だけで体制を維持するのが難しい場合、復旧確認や訓練の一部を外部の支援と組み合わせることも、選択肢の一つと考えられます。

確認を省くと何が残るか - 2つのリスクを事例で見る

対策の判断材料として、復旧テストをしなかった場合に何が残るかも、公平に見ておく必要があります。ここでは代表的な2つのリスクを取り上げます。

事業停止が想定以上に長引く

復旧できるか未確認のまま被害を受けると、復旧に想定以上の時間がかかり、事業停止が長期化するおそれがあります。バックアップがあっても戻せなければ、実質的に保護されていない状態と変わりません。

身代金の支払い検討に追い込まれる

復旧手段が確実でない場合、業務再開を急ぐあまり、身代金の支払いを検討せざるを得ない状況に追い込まれることもあります。復旧可能性を平常時に確認しておくことは、有事にこうした判断を避けるための備えにもなります。

ただし、これらは不安を煽るためのものではありません。リスクを正しく把握したうえで、優先度をつけて着手することが望まれます。

明日から始める復旧テスト - 1システムから広げる手順

最後に、復旧テストを始めるための現実的な手順を整理します。

まず1システムで試す（実行チェックリスト）

はじめから網羅的に取り組むより、重要なシステムを一つ選び、隔離した環境で復元を試すところから始めます。次の順で進めると、本番影響を抑えながら課題を洗い出せます。

• • 復旧の優先度が高い重要システムを一つ選ぶ

  • 隔離した検証環境を用意し、本番に影響しない状態を確保する

  • バックアップから実際に復元を試す

  • RTO/RPOの合否基準に照らして結果を確認する

  • 復元手順を文書化し、担当者以外でも再現できる形にする

手順が固まったら段階的に対象を広げる

一つのシステムで手順が固まったら、対象を段階的に広げていきます。完璧なテスト体制を最初から目指すより、回せる範囲から始めて調整していく進め方が、環境によっては現実的でしょう。自社の復旧可能性を客観的に確認したい場合は、外部のアセスメントを利用する選択肢もあります。

現場からよくある4つの疑問

Q1. バックアップは取っています。それでも復旧テストは必要ですか。

必要です。理由は、バックアップジョブの「成功」ログと、そこから業務が立ち上がる「復旧」は別物だからです。ジョブは正常終了しているのに、いざ復元するとアプリが起動しない、という食い違いは実際に起こります。取得したデータが破損している、必要な範囲が含まれていない、手順が分からないといった理由で、取得済みでも復旧に失敗することがあります。まずは重要システムを一つ選び、小さく試す方法が挙げられます。

Q2. 復旧テストはどのくらいの頻度で行えばよいですか。

システムの重要度と構成変更の多さによって異なります。重要システムは定期的に、加えて構成を変更したタイミングで確認する、といった組み合わせが考えられます。高い頻度を前提にすると運用が続かないため、無理のない範囲に設定することが望まれます。

Q3. イミュータブルストレージを導入すれば、ランサムウェア対策は十分ですか。

改ざんされにくい保管方式は有効な場合がありますが、それだけで復旧可能性が保証されるわけではありません。保管したデータから実際に復元できるか、許容時間内に業務を戻せるかは、テストしなければ分かりません。ツールの導入と復旧できる状態の確保は、分けて考えることが望まれます。

Q4. 少人数で復旧体制まで整えるのが難しいのですが、どう進めればよいですか。

まず復旧手順を文書化し、担当者以外でも実行できる状態にすることが出発点になります。訓練や定期的な復旧確認まで自社だけで担うのが難しい場合は、確認作業やアセスメントの一部を外部の支援と組み合わせることも、選択肢の一つと考えられます。

まとめ

ランサムウェア対策としてのバックアップは、取得しているかどうかだけでなく、有事に復旧できるかまで確認して初めて意味を持ちます。この記事の要点を、担当者が明日から確認できる順に並べ替えると、次のようになります。

1. 1. 「取得と復旧は別」と捉え直す──ジョブの成功と復旧可能は別物であり、バックアップ自体も攻撃対象になり得る

   2. 壊されない条件を満たす──隔離・世代管理・イミュータブルを組み合わせ、運用として回す

   3. 復旧テストを設計する──対象・頻度・合否基準 (RTO/RPO) を決めて確認する

   4. 有事に動ける体制にする──手順書化と責任者の指名がなければ、テストで確認できても本番で動けない

この順で一つずつ潰していくほど、「戻せない」リスクは下がります。まずは重要システムを一つ選び、隔離環境で復元を試すところから小さく始める進め方が、現実的な出発点になると考えられます。

自社のバックアップが有事に復旧できる状態にあるか、テストの範囲や合否基準をどう設計するか。自社だけで判断が難しい場合は、現状のバックアップ構成や復旧可能性を客観的に確認するアセスメントを利用する選択肢もあります。まずは現状整理の材料としてご活用ください。

横河レンタ・リース株式会社は日本ヒューレット・パッカード社の Platinum パートナーとして、IT 機器のレンタル・販売に加え、バックアップやセキュリティーの構成設計から運用保守までを組み合わせて提供しています。復旧テストの設計や体制づくりを自社だけで判断するのが難しい場合は、構成の確認やアセスメントについて、お気軽にご相談ください。

お問い合わせ (総合) | 法人向けパソコン (パソコン) ・計測器レンタルなら横河レンタ・リース