ランサムウェアに対抗できるバックアップ2025（435号）

前回は、ランサムウェアの復旧に時間がかかるということを４つの視点からお話しました。

　素朴な疑問：ランサム復旧が長期化するワケ？(434号）
　https://note.com/egao_it/n/ne01d45c1425b

今回は、前回の話を踏まえ、データ復旧についてもう少し深耕します。


1. ランサムウェアからの復旧が大変な理由（おさらい）

ランサムウェアからの完全復旧には、以下の課題解消が必要になります。

　1. データ復旧
　　 →暗号化データの復旧だけでなく、整合性チェックも必要

　2. 再発防止
　　 →どこから侵入されたのか？を調査し、他の弱点もつぶす

　3. 人と組織
　　 →意思決定、外部連携をスピード感をもって進める

　4. 安全宣言
　　 →何をもって安全と言うのか？非存在の証明は難しい

前回は全体像を浅く広くお話しましたが、今回は、データ復旧について、詳しくお話をします。


2. 中小企業にとってのバックアップ

暗号化されたデータをいかに戻すか。
これだけを聞きますと、何らかのバックアップが残っていれば、戻すだけで済みそうに思います。

小規模な事業所なら、システムもシンプルですから、単純にバックアップさえ残っていれば、復旧できるケースもあります。

特にオフラインバックアップ ―― バックアップする時だけ装置に装着するタイプのバックアップ ―― はランサムウェア対策としては最強の部類です。

ですが、オフラインバックアップは、「面倒臭い」という弱点があります。
人手でテープやディスクといったメディア交換が必要ですから。

ランサム攻撃を行う側は、攻撃に先立って、バックアップの破壊を試みます。
バックアップが活きていると身代金を払ってもらえないからです。

逆に言えば、ネットからは絶対手出しできないオフラインバックアップは中小企業にとっての最強のランサムウェア対策です。
ぜひ、「当番制で毎週末にオフラインバックアップを取る」を実践してください。


3. 大企業にとってのバックアップ

中小企業にとってベストソリューションとも言えるオフラインバックアップですが、大企業にとっては非常に採用しづらい選択です。

この理由は大きく２つ。
一つは、大企業の場合、夜間や早朝も工場や倉庫は稼動するのが通常です。作業をするにはシステムを止められない、言い換えればバックアップしようにもオフライン（停止状態）にできないのです。
データベースがいつ更新されるかわからない状態では、停止ができません。（稼動中にバックアップを取る技法については、ここでは触れません）

もう一つの理由は大企業では扱うデータ量が大きすぎる点です。
大企業が持つデータ量は、最低でも数十TB（テラバイト）、多ければ数PB（ペタバイト。テラバイトの千倍）にもなります。
こんな大容量のバックアップが取れるメディア（テープやディスク）は存在しません。

そんな中で、最近注目を浴びているのが、WORM（Write Once Read Many）という考え方の記憶装置です。ずっと以前には、DVD-Rのような一度だけ書き込める光メディアがありましたが、考え方はあれと同じです。
要は、一度書き込んだら、削除も変更もできないという特殊なストレージです。
テストの答案が回収された後は、書き換えられないのと同じです。

最近は、これがランサムウェア対策として、バックアップやログの保管に最適ということで採用されるケースが増えてきています。


4. バックアップがあれば完璧か？

ここからが、ランサムウェア対策の難しいところです。

中小企業であれば、バックアップがキチンと保全できていれば、復旧は容易なケースもありますが、油断大敵です。

バックアップから戻すというのは、明らかに非日常的な業務です。
非日常的な業務を確実にこなすには、やはり訓練が必要です。

また、組織として統制の取れた行動、ルールに従った行動が必要です。
各担当者が思いつくままに行動を取ってなんとかなるような事態ではないのです。

つまり「バックアップがあるから大丈夫」ではなく、そのバックアップを利用するための訓練、組織全体の統制、といった組織運営の仕組みが必要です。


5. 大企業はさらに複雑

大企業の場合は、単純にバックアップがあれば大丈夫、とは言えません。

前回も少し書きましたが、何百もあるシステムの全てのデータベースを整合させないといけないからです。

仮にバックアップがあったとしても、その採取のタイミングはシステムの都合によって、異なります。
同じように３日前のバックアップがあるとしても、あるシステムでは朝の6時、別のシステムでは、夜の22時かもしれません。
その間に生じたデータベースへの変更は、考慮できていません。

機器の故障で、バックアップからの復元が必要となっ場合、バックアップ以降の変更は手作業で入れなおすのが一般的です。

ですが、この復旧方法は他のシステムが全て正常稼動していることを前提としています。
ランサムウェアのような同事多発的な障害の場合、手作業でエントリをしようにも他のシステムも動かないために、エントリそのものができない事態が発生します。

バックアップがあっても、そのバックアップを活かした、復旧ができません。

実は、これが最も恐ろしいランサムウェア被害なのです。

例えば、在庫管理システムがランサムウェアにやられたので、データベースを再構築した。
次に、最新の数値を合わせるため、入庫管理システム、出庫管理システム、注文管理システムなどからデータを取ってこようとしても、それらのシステムも壊れていて数値が参照できないわけです。

これでは、何を入力していいのかわかりません。
いわゆる「詰んだ」状態です。

この場合、他システムの安定稼動を前提とする、復旧手順書は役に立ちません。
結局、手探りで、全てのシステムを最初から組み立て直す作業が必要となります。

つまり、復旧という名の「再構築」です。


6. データだけに着目されがちですが...

一般に、復旧というとデータばかりが着目されますが、実はシステム（プログラム）の復元というのも、一筋縄ではいきません

ちなみに、多くのシステムは、WindowsやOfficeソフトのようなキレイなインストーラがないことが通常です。
というのは、業務システムというのは、初期バージョンから改修を重ねて機能アップや使い勝手の向上を図るのですが、その一つ一つは、その前バージョンの存在が前提となります。
つまり、100回の改修を経たシステムを再構築するには、最初期バージョンをインストールした後に、100回分の改修版を上書きインストールすることになります。

もっとも、ここまでひどいのは古い話で、2010年あたりからはバージョン管理ソフト（Gitなんてのがあります）を用いて、いつでも最新バージョンを取り出せるような運用が一般的です。
とはいえ、システムに必要な全てがバージョン管理対象と含まれるとは限りません。実は動作に必須の設定ファイルが入ってない！なんてのは非常によくある話です。

また、そのソフトウェアには含まれないが、ないと動かないモノ（データベース設定、事前導入が必要なソフトウェアなど）も、これまた「あるある」です。


7. ランサムウェアの攻撃法もいろいろ

ランサムウェアでは、ファイルの暗号化を行います。

ところが、暗号化には一つの問題があります。
暗号化はコンピュータにとっても重い処理で時間がかかります。
また、その間はかなりのパワーが必要となります。

一般に、大企業で重要なサーバには負荷監視という仕組みを導入します。
これは、トラブルなどで想定以上の使われ方となった場合に、担当者が介入できる仕組みです。
これは、ランサムウェアで暗号化を仕掛ける側からすると、やっかいな存在です。
へたに暗号化にパワーを使うと、被害発生前にバレる可能性があるからです。

そのため、ランサムウェアの中には、準備段階で、重要データをコピーした上で少しづつ暗号化を進めておき、バレにくいようにする手法があります。

いざ、攻撃のタイミングには、暗号化ではなく、対象の重要データを消しちゃいます。
これなら、一瞬で終わりますから、負荷監視にもひっかかりません。

これなら、暗号化したデータは残るので、ランサムウェアとして成立します。

攻撃側もいろいろと工夫を重ねているのですね。


8. まとめ

今回は、データ復旧という視点でいくつかのお話をしました。

大企業でのランサムウェア対策の大変さを少しでもわかっていただければ、嬉しいです。
きっと、アサヒグループの方もアスクルの方も本当に必死の対応を続けておられると思います。一日も早い復旧を願っています。

次回は、今回の続きとして、再発防止のお話をします。
これもまた、非常に奥の深い、やっかいな点がたくさんあるお話です。

余談ですが、今回の記事は、2022年11月に配信したものと同じタイトルです。書いてから気付きました。
3年前とは随分と内容が違っています。比べてみると時間の流れを感じます。

　No284 ランサムウェアに対抗できるバックアップ
　https://note.com/egao_it/n/n80431c1f80b6

次回もお楽しみに。

今日からできること：
　・中小企業にとって、オフラインバックアップは最強です。
　　→週に一度でも、オフラインバックアップを取りましょう。
　・ランサムウェア対策には組織としての取組が必要です。
　　→まずは組織内で話題にしてみましょう。

（本稿は 2025年12月に作成しました）