ランサムウェア対策の要はバックアップ｜中小企業のための3-2-1ルールと復旧手順ガイド

想定読者

専任のIT担当者を置かず、総務や情報システムの業務を兼任しながら社内のセキュリティ対策を担っている中小企業の担当者、または対策にかける予算や人員配分を判断する立場の経営者を想定しています。

要点

ランサムウェア対策は「侵入されない仕組み」だけでなく、「壊れたデータをどう戻すか」という復旧設計まで含めて考える必要があります
3-2-1バックアップルールは、専任担当者がいない体制でも運用し続けられる形に落とし込むことで初めて機能します
バックアップは取得するだけでなく、定期的な復元テストと初動対応フローの仕組み化までセットで整えて意味を持ちます

なぜ中小企業がランサムウェアの標的になるのか

ランサムウェア(身代金要求型のコンピューターウイルス)は、感染した端末やサーバー内のデータを暗号化し、復旧と引き換えに金銭を要求する攻撃です。

大企業だけでなく、中小企業も日常的に標的になっています。理由は単純で、攻撃側にとって「侵入しやすく、対策が手薄」な組織のほうが効率よく攻撃を仕掛けられるためです。

狙われやすい中小企業の共通点

狙われやすい中小企業には、いくつかの共通点があります。

専任のセキュリティ担当者がおらず、OSやソフトウェアの更新が後回しになりがち
社内に複数の管理者権限アカウントが存在し、パスワードが使い回されている
取引先や親会社への侵入経路(踏み台)として利用価値があると見なされている
バックアップの有無や復旧体制が外部から見えず、身代金を払う可能性が高いと判断されやすい

これらはどれも「明日からの運用改善」で対処できる範囲のものであり、大きな投資をしなくても着手できる点が重要です。

感染経路の典型パターン(メール添付・VPN機器・リモートデスクトップ)

感染経路として特に多いのが次の3つです。

メールの添付ファイルやリンクを開いてしまい、端末がマルウェアに感染する
社外から社内ネットワークに接続するためのVPN機器(仮想プライベートネットワーク、拠点間や在宅勤務者の通信を暗号化してつなぐ機器)の脆弱性や設定不備を突かれる
リモートデスクトップ(外部から社内のパソコンを遠隔操作する仕組み)のIDとパスワードが推測されて侵入される

いずれも「入り口対策」だけで完全に防ぎきることは難しく、侵入された後にどこまでダメージを抑えられるかという発想が欠かせません。ここからは、その要となるバックアップ設計を具体的に見ていきます。

バックアップ設計の基本「3-2-1ルール」を実務に落とし込む

ランサムウェア対策の本丸は、侵入を完全に防ぐことではなく、暗号化されたデータを「どこから」「どうやって」元に戻すかという復旧設計にあります。その基本となるのが3-2-1ルールです。

3-2-1ルールの中身と考え方

3-2-1ルールとは、次の3つの条件を満たすようにバックアップを設計する考え方です。

データの複製を合計3つ持つ(本番データ+バックアップ2つ)
2種類の異なる媒体に保存する(例:社内サーバーと外付けHDD、クラウドなど)
少なくとも1つは離れた場所(オフサイト)に保管する

さらに、このうち最低1つを「ネットワークから切り離した、あるいは書き換え不可能な状態」で保管する考え方も広がっています。ランサムウェアは社内ネットワークにつながっているバックアップまで暗号化・削除しようとするため、常時接続の共有フォルダだけに頼る構成はリスクが残ります。

クラウド保存先を選ぶときの注意点

バックアップ先としてクラウドを使う場合、種類によって特性が異なります。用途に応じて組み合わせることが現実的です。

保存先	特徴	注意点
汎用クラウドストレージ	低コストで導入しやすい	本番と同一アカウントは分離必須
バックアップ専用サービス	世代管理・不変性に対応	月額コストがやや高め
外付けHDD・NAS(オフライン)	切断すれば感染を回避	定期接続と保管場所の管理が必要
社内・遠隔地拠点の物理保管	災害時の分散に有効	盗難・劣化対策が別途必要

汎用クラウドストレージを使う場合は、本番システムと同じ認証情報でアクセスできる状態にしないことが最低限の条件です。

同じアカウントが乗っ取られると、バックアップごと暗号化・削除される恐れがあります。オフラインの外付けHDDやNASは、ふだんはネットワークから切り離しておき、バックアップ取得時だけ接続する運用にすると、常時接続型の共有フォルダより安全性が高まります。

バックアップ自体を暗号化・アクセス権分離で守る理由

攻撃者は本番データだけでなく、バックアップそのものを暗号化・削除の対象にすることを前提に行動します。

そのため、バックアップ用のアカウントは本番システムの管理者アカウントと分け、バックアップの書き込みや削除ができる権限を最小限の担当者に絞ることが重要です。

加えて、バックアップデータ自体を暗号化して保管すれば、万が一保存先が外部に流出しても内容を読み取られにくくなります。

多要素認証(パスワードに加えてスマートフォンの承認などを求める仕組み)をバックアップ管理用のアカウントに設定しておくことも、有効な対策のひとつです。

感染を疑ったときの初動対応フロー

どれだけ備えていても、感染の疑いが生じた瞬間の対応スピードが被害の大きさを左右します。ここでは、担当者がその場で動けるチェックリスト形式でまとめます。

ネットワーク隔離までの初動チェックリスト

不審な挙動(急激な処理の重さ、見慣れないファイル拡張子、身代金要求のメッセージなど)に気づいたら、次の順番で対応します。

感染が疑われる端末のLANケーブルを抜く、または無線LANをオフにする(電源は切らない)
同じネットワーク内の他の端末・サーバーも順次ネットワークから切り離す
社内共有フォルダやNASへの接続を全端末で確認し、必要なら共有自体を停止する
バックアップ用の外付け機器を、まだ接続していなければ絶対に接続しない
対応状況と発見時刻、気づいた経緯を時系列でメモに残し始める
あらかじめ決めておいた社内の連絡先(責任者・情報システム委託先など)に第一報を入れる

電源を切ると、被害範囲の調査に必要な情報(メモリ上のデータなど)が失われる場合があるため、まずはネットワークからの切り離しを優先します。

社内・取引先への連絡テンプレート

初動の混乱を防ぐには、文面をあらかじめ用意しておくことが有効です。

社内向け第一報:「〇月〇日〇時頃、社内システムで不審な挙動を確認したため、該当端末をネットワークから切り離しました。原因調査中につき、社内共有フォルダ・メールの利用を一時停止してください」
取引先向け第一報:「弊社システムにおいて情報セキュリティ上の懸念事象を確認し、現在調査を行っております。詳細が判明次第、改めてご連絡いたします。ご迷惑をおかけし申し訳ございません」
事実確認後の詳細連絡:影響範囲(対象データ・対象取引先の有無)、原因、復旧見込み時期、再発防止策の4点を明記する

取引先への連絡は、事実関係が不確かな段階で断定的な表現を使わないことが重要です。「調査中」であることを明確にしつつ、初動を取ったという事実は速やかに伝えます。

復旧の優先順位づけと段階的な業務再開

初動対応と並行して考えておく必要があるのが、どのシステムから復旧するかという優先順位です。

復旧の優先順位づけ(基幹システムから戻す考え方)

すべてのシステムを同時に復旧しようとすると、かえって作業が滞ります。事業継続への影響度を基準に、あらかじめ優先順位を決めておくと初動が早くなります。

優先度1:受発注・会計・生産管理など、止まると事業が直接止まる基幹システム
優先度2:顧客情報・取引履歴など、対外的な信用に関わるデータ
優先度3:社内メール・スケジュールなど、業務効率に影響するが代替手段があるもの
優先度4:過去の議事録や資料など、緊急性の低いデータ

この優先順位は平時のうちに部署ごとにヒアリングして決めておき、年に一度は見直すことをおすすめします。有事の最中に優先順位を議論していては、時間を浪費してしまいます。

段階的な業務再開とクリーン環境での検証

復旧作業では、感染したネットワークにそのままバックアップを戻さないことが鉄則です。

まず隔離した別ネットワークやテスト環境でバックアップからの復元を行い、ウイルス対策ソフトでのスキャンや不審なファイルの有無を確認します。

問題がないと確認できた範囲から、本番ネットワークへ段階的に接続を戻していきます。この手順を踏まずに急いで復元すると、感染したファイルごと復元してしまい、被害が再発するおそれがあります。

バックアップを機能させ続けるための復元テスト

バックアップは「取得していること」と「復元できること」は別問題です。実際に復元してみて初めて、設定ミスや世代管理の漏れに気づくケースは少なくありません。

復元テストの頻度と実施方法

復元テストは、次のような頻度・体制で無理なく続けられる仕組みにすることが現実的です。

月1回、担当者が任意の1ファイル・1フォルダを別の場所に復元し、内容が正しく開けるか確認する
四半期に1回、基幹システムのデータを丸ごと復元する訓練を行い、所要時間を計測する
年1回、初動対応フローと合わせた総合訓練を実施し、経営層も含めて手順を確認する
担当者は情報システム関連の業務を兼任する社員を主担当・副担当の2名体制にし、異動や休職時も引き継げるようにする
テスト結果(成功・失敗、所要時間、気づいた課題)は簡単な記録表に残し、次回の改善につなげる

「忙しくて毎月は無理」という場合でも、最低限四半期に1回の復元テストは死守することをおすすめします。テストの頻度を下げるほど、いざというときに復元できないリスクが高まります。

よくある失敗パターン(世代管理漏れ・権限設定ミスなど)

実際に復元テストを行うと、次のような失敗が見つかることがよくあります。

世代管理(過去の複数時点のバックアップを残す仕組み)の設定漏れで、暗号化された後の状態しか残っていなかった
バックアップ先の容量が上限に達し、古いバックアップから自動的に上書きされていた
アクセス権限の設定ミスで、バックアップ担当者以外もデータを削除できる状態になっていた
一部のシステムやフォルダだけがバックアップ対象から漏れていた
バックアップは取れていたが、復元先の環境(ソフトウェアのバージョンなど)が古く、正常に開けなかった

これらはいずれも、実際に復元してみるまで気づきにくい問題です。

定期テストを仕組み化する最大の目的は、こうした「取っているつもりのバックアップ」を早期に発見することにあります。

低コストで始めるツール選びと外部委託の判断基準

専任担当者がいない体制では、すべてを自社だけで完結させる必要はありません。予算と社内リソースに応じて、外部の力を借りる判断も選択肢に入れます。

選択肢	向いている規模	注意点
自社運用(クラウド+外付け)	数名〜数十名規模	手順の属人化を防ぐ工夫が必要
クラウドバックアップサービス	IT担当が1〜数名の企業	復元手順の把握が前提条件
MSP等への外部委託	社内に運用担当が置けない企業	復旧の役割分担を契約で明確化

自社運用は初期コストを抑えやすい一方、手順が特定の担当者しかわからない「属人化」に陥りやすいため、マニュアル化と複数人での運用が欠かせません。

クラウドバックアップサービスは設定の自動化やサポートが受けられる分、月額コストがかかりますが、復元テストまで含めて運用できるかを契約前に確認しておくべきです。

社内に運用担当を置くこと自体が難しい場合は、MSP(情報システムの運用を代行する事業者)への委託も現実的な選択肢です。

その際は、平時の運用だけでなく、感染発生時の初動対応や復旧作業まで契約範囲に含まれているかを必ず確認してください。