ランサムウェア対策として、クラウドストレージのバージョン管理機能が役立つと聞いたことはあっても、「何世代まで遡れるのか」「誰が復元できるのか」まで確認できているケースは多くありません。感染時に本当に復元できるのかを把握していなければ、いざというときに判断が遅れます。
本記事では、そうした場面で判断を求められる担当者に向けて、感染の疑いが浮上した瞬間から業務を再開するまでの意思決定フローを軸に、バージョン履歴がランサムウェア対策として機能する条件、機能しない落とし穴、そして自社環境を自己診断するためのチェックリストを順番に示します。
Contents
バージョン履歴がランサムウェア対策になる「原理」と「前提条件」
ランサムウェア対策としてバージョン履歴を使う発想は、「暗号化される前の版を取り戻す」という単純な原理に基づきます。ただし、これが成立するにはいくつかの前提条件がそろっている必要があります。
「暗号化されても戻せる」が成立する仕組み
クラウドストレージがファイルを更新するたびに版（バージョン）を別のオブジェクトとして保管している場合、ランサムウェアが既存のファイルを暗号化して上書きしても、以前の版は保管領域に残り続けます。復元とは、「最新版（暗号化済み）を廃棄して、感染前の版を現行版として指定し直す」操作に相当します。この原理が成立するための前提は、次の3つです。
- バージョン機能が有効になっていること
デフォルトで無効のサービスもあるため、有効化の確認が前提になります。 - 感染前の版が保持期間・世代数の上限に達していないこと
古い版から自動削除されるため、発覚が遅れると遡れる限界を超えてしまいます。 - クラウド側の版管理領域がエンドポイント（PC端末）から直接操作できない設計であること
端末から版管理領域まで書き換えられる構成では、版ごと暗号化されるリスクがあります。
クラウド保存だけでは対策にならない理由
クラウドに保存しているからといって、自動的にランサムウェア対策になるわけではありません。特に同期型のクラウドストレージ（PCローカルフォルダとクラウドを常時同期する方式）は、端末上のファイルが暗号化されると、同期処理によって暗号化後のファイルがクラウドにも即座に反映されます。バージョン管理機能が有効であれば暗号化前の版が残りますが、機能が無効、あるいは世代数が少なすぎると、暗号化された版しか残らない状態になります。「クラウドに入れているから守られている」という思い込みは、感染後の復元失敗の典型的な原因の一つです。
バックアップ・同期・バージョン管理の違い
混同されやすい3つの仕組みですが、ランサムウェア対策としての役割はそれぞれ異なります。
- バックアップ
特定時点のデータを、元のシステムとは別の場所に複製して保管する仕組みです。一般に、エンドポイントから直接操作しにくい構成であれば、ランサムウェアの影響を受けにくくなります。 - 同期
複数の端末や保存先のファイルを常に同じ状態に保つ仕組みです。変更内容をそのまま反映するため、感染端末で暗号化されたファイルもクラウド側に同期されます。 - バージョン管理
ファイルの変更履歴を世代単位で保持し、過去の版に戻せる仕組みです。ランサムウェア対策として機能するのは、感染前の版が保持されている場合に限られます。
感染疑い発覚から業務再開までの対応フロー
ランサムウェア対策で最も見落とされやすいのは、発覚直後にどう動くかの手順が社内に存在しないことです。このフローは、情シス専任担当がいない環境でも、総務兼任担当者が初動の判断を誤らないための道標として設計しています。
フェーズ1：感染疑い発覚直後
最初にすべきことは「感染を広げないこと」であり、ファイルを操作することではありません。
- 該当端末をネットワーク（有線LAN・Wi-Fi）から即座に切断します。シャットダウンより先に切断します。シャットダウン処理中に暗号化が進む場合があるため、切断を優先するのが一般的な初動の考え方です。
- 他の端末・共有フォルダへのアクセスが発生していないか確認します。
- 「いつ・誰が・どのファイルを操作していたか」をメモに取ります。これはバージョン履歴の調査で参照する基準時刻になります。
フェーズ2：感染範囲の確認
- クラウドストレージの管理画面（管理者権限が必要）にログインし、直近の変更ログを確認します。
- 暗号化されたファイルの拡張子変更や異常なファイル名への書き換えが何時から始まっているかを特定します。これが「遡るべき基準時刻」になります。
- 影響を受けた可能性のあるフォルダ・ファイルの一覧を書き出します。
フェーズ3：復元可否の判断
感染範囲が確認できたら、バージョン履歴を使った復元が可能かどうかを、以下の判断軸で確認します。
- 感染前の版が存在するか
基準時刻より前の版が履歴に残っているかを確認します。 - 復元に必要な権限を自分が持っているか
バージョン履歴からの復元操作は管理者権限が必要なサービスが多くあります。権限がない場合は、権限を持つ人物への連絡を優先します。 - 復元したいファイルの優先順位はどこか
全ファイルの一括復元と個別ファイルの手動復元では操作方法が異なる場合があります。まずは業務継続に直結するファイル（契約書・顧客データなど）から着手します。
フェーズ4：復元の実行と業務再開確認
- 優先度の高いファイルから順に、感染前の版を指定して復元を実行します。
- 復元したファイルの内容を、感染していないことを確認した別の端末で開いて確認します。
- 全体の復元が完了したあと、感染した端末のOSをクリーンインストールまたは初期化してから業務ネットワークに再接続します。
- 業務再開後も一定期間、ファイルの異常な変更がないかを監視します。
復元を阻む「3つの盲点」
フローが頭に入っていても、自社の環境に以下の3つの盲点が存在すると、フローどおりには動けません。感染が起きてから気づくのでは遅いため、今の時点で確認しておくべき項目として示します。
盲点①：世代数が少なすぎる・保持期間が短すぎる
クラウドストレージのバージョン管理機能は、サービスやプランによって保持できる世代数や保持期間が異なります。活発に更新されるファイル（日次で複数回変更されるスプレッドシートなど）は、世代数の上限を短期間で使い切ることがあります。現在の設定で「感染から発覚まで平均何日かかるか」を想定したとき、その期間分の版が本当に残るかを確認していない担当者は少なくありません。
盲点②：同期処理が「版を押し出す」リスクを知らない
同期型ストレージは、ランサムウェアによる大量の暗号化を「大量の更新」として処理します。数千ファイルが短時間で暗号化されると、世代数の上限に達した古い版から順次削除されます。「バージョン管理機能をオンにしているから安心」という判断が、この動作を考慮せずに成り立っている場合は再確認が必要です。
盲点③：復元権限が一人の担当者に集中している（または誰も持っていない）
バージョン履歴からのファイル復元は、管理者権限が必要なサービスが多くあります。休日・夜間・担当者不在の状況で感染が発覚したとき、権限を持つ人物と連絡が取れなければ復元作業は止まります。権限の所在が文書化されておらず、「あの人が知っている」という状態は、発覚直後のパニック時に最もリスクが高くなります。
自社環境の自己診断チェックリスト
以下の項目を今日中に確認することで、自社の復元体制にどの程度の備えがあるかを把握できます。上長への報告材料としてもそのまま活用できます。
【バージョン管理機能の設定確認】
- 現在使用しているクラウドストレージでバージョン管理機能が有効になっているか
- 保持できる最大世代数はいくつか（設定画面または管理画面で確認）
- 保持期間の上限は何日か（無制限か、日数制限があるか）
- バージョン履歴の保管領域は、エンドポイント（端末）から直接削除・書き換えができない設計か
【復元権限と体制の確認】
- バージョン履歴からの復元操作を実行できる権限を持つ担当者は誰か（名前と連絡先が文書化されているか）
- その担当者が不在の場合、代理で操作できる人物は存在するか
- 感染疑い発覚時に最初に連絡すべき社内フローが文書として存在するか
【復元シナリオの実効性確認】
- 過去に一度でも、実際にバージョン履歴からファイルを復元したことがあるか（操作手順を把握しているか）
- 業務上最も重要なファイル（契約書・顧客情報・受注データなど）の最終更新頻度と、保持世代数が合致しているか
- 感染から発覚まで一週間かかった場合でも、感染前の版が残る設定になっているか
復元体制を整えるための運用設計ポイント
チェックリストで「できていない」が複数出た場合、その穴を埋めるための運用設計を考える必要があります。技術的な整備と体制的な整備に分けて整理します。
技術的な整備：「版が消えない」設計を確認する
バージョン管理が対策として機能するために最低限確認すべき技術的な設定は、世代数の上限引き上げと保持期間の延長です。活発に更新されるフォルダについては、個別に世代数を多く設定できるサービスもあります。また、バージョン管理の保管領域を通常の同期対象から切り離し、端末から操作できないようにする設計になっているかを、使用しているサービスの仕様で確認します。
たとえば、管理画面から更新履歴の確認や復元を行えるクラウドストレージであれば、感染後の初動でも復旧判断を進めやすくなります。Fleekdriveのように、管理者が履歴を確認・復元できる設計かどうかは、事前に仕様を確認しておきたいポイントです。
体制的な整備：「誰が・いつ・何を判断するか」を文書化する
技術的な設定が整っていても、発覚時に動ける人が一人に集中していたり、連絡フローが口頭での申し送りしかない状態では、夜間・休日・担当者不在時に機能しません。最低限、以下の3点を1枚の文書にまとめておくことが有効です。
- 感染疑い発覚時の初動手順（端末切断→ログ確認→報告先の順番）
- 復元権限を持つ担当者の氏名と連絡先（第一順位・第二順位）
- 優先して復元すべきフォルダ・ファイルのリスト（業務継続に直結する順）
この文書は、情シス専任がいなくても総務担当者が主導して作成できます。フォーマットは問いません。「作ること自体」が体制整備の第一歩になります。
「バージョン管理だけでは守れない」部分をどう補うか
バージョン管理はあくまで「感染後の復元手段」であり、「感染そのものを防ぐ」仕組みではありません。加えて、世代数上限の超過や長期間の発覚遅延には構造的に対応できない側面があります。そのため、バージョン管理と組み合わせる形で、エンドポイントとクラウド保管領域が切り離された独立バックアップ（世代数・保持期間を個別に設定できるもの）を用意しておくことが、一般に望ましい構成とされています。
まとめ：確認すべき3つのポイント
ランサムウェアに感染した後にバージョン履歴で復元できるかどうかは、「機能があるか」ではなく、「感染前の版が保持されているか」「復元権限を持つ人物が発覚時に動けるか」という運用の問いに帰着します。まず確認したいのは、次の3点です。
- 現在のクラウドストレージの管理画面を開いて、バージョン管理の有効・無効と世代数・保持期間を確認する
- 復元権限を持つ担当者の名前と連絡先を確認し、メモに残す
- 上記のチェックリストを使って、対応済み・未対応・不明の3段階で自社環境を仕分けし、上長への報告材料にする
この3点を確認しておくだけでも、感染時に復元できるかどうかを具体的に判断しやすくなります。まずは自社の設定と権限体制を確認し、復元できる条件がそろっているかを可視化しておきましょう。
