DBを消してから身代金を要求する「削除型恐喝」が公表された｜『バックアップはある』が対策にならない理由と復元できるバックアップの6条件

最初に結論を書く。バックアップは「有無」で評価してはいけない。「攻撃者から見えるか」「本当に戻せるか」で評価しなければ、対策として数えてはいけない。

2026年7月9日、引越し業者のネットワーク引越センター(株式会社ネットワークジャパン 引越事業部)が、顧客管理システムのデータベースへの不正アクセスを公表した。公表文によれば、7月2日未明に第三者がデータベースへ侵入し、データベースを削除したうえで、復旧と引き換えに暗号資産を要求する文書を残したという。なお同社の公表文自身はこれを「ランサムウェア事案」と位置づけているが、公表文にファイル暗号化の記載はない。つまり、ファイルを暗号化して人質に取る従来型の形ではなく、先に消してから、金を要求する——削除型もまた身代金要求(ランサム)型攻撃の一形態である。

この事案が中小企業の経営者に突きつけている論点は一つだ。多くの会社のランサムウェア対策は、意識するとしないとにかかわらず「データが暗号化される」前提で組まれている。ウイルス対策ソフトで暗号化の挙動を検知する、暗号化されたらバックアップから戻す——この設計は間違いではないが、攻撃の類型が「削除・破壊」に変わった瞬間、防衛線はバックアップの実効性ただ一つに絞られる。そして、社内のサーバやクラウドの同じ環境に置かれた「攻撃者からも見えるバックアップ」は、本番データベースと一緒に消される。「バックアップは取っています」という報告の中身を、経営者自身が一度も検証していない会社ほど、この類型に弱い。

本記事では、公表された事実関係を確認したうえで、攻撃類型の変化を比較表で整理し、「復元できるバックアップ」の6条件と、経営者がIT担当・保守ベンダーに今週そのまま聞ける質問リストを提示する。読み終えたときに「うちのバックアップは攻撃者から見えるか?」という問いを自社に持ち帰れる状態にすることが目的だ。

この記事を手元に置いてほしい会社

• 顧客管理・受注管理のデータベースを1系統のクラウドまたは社内サーバで運用している会社
• 「バックアップは取っている」とIT担当や保守ベンダーから報告を受けているが、その中身(保管場所・世代・復元可否)を経営層が把握していない会社
• 情シスが兼任1人、またはシステムの面倒は外部の保守ベンダー任せになっている中小企業
• ランサムウェア対策としてウイルス対策ソフトとUTMは入れたが、それ以降の見直しをしていない会社
• 顧客の個人情報を扱っており、データが消えた・漏れた場合の法的義務や公表手順を確認したことがない会社

一つでも当てはまるなら、この事案は「引越し業界のニュース」ではなく「自社の顧客DBで起こり得ること」として読んでほしい。

公表された事実関係——何が起きたのか

株式会社ネットワークジャパンの公表文(2026年7月9日付「お客様情報に関するお知らせとお詫び」)で確認できる事実は次のとおりだ。

• 2026年7月2日午前2時38分頃、第三者が顧客管理システムのデータベースへ不正アクセスした
• 同日午前7時30分頃、同社はシステム障害を認知し、調査・復旧対応を開始した
• データベースは削除されており、攻撃者は復旧と引き換えに暗号資産を要求する文書を設置していた
• 滅失した顧客情報の対象期間は2025年3月26日から2026年5月14日まで(この間に見積り依頼等を行った顧客が対象)で、氏名・住所・電話番号・メールアドレス・引越予定日・家財リストなどが含まれる
• データの持ち出しについては、漏えいのおそれを否定できない状況とされている。クレジットカード情報は同社が保有しておらず、カード番号の漏えいはない
• 同社は不正アクセス経路の遮断、データベースへの外部接続の停止、管理者パスワードの変更などを実施し、7月8日に個人情報保護委員会への報告と警察への相談・届出を行った
• 公表時点で、個人情報が不正利用された事実は確認されていない

なお、復旧の可否や侵入経路の詳細、要求額などは公表されておらず、本記事でも憶測は書かない。付け加えるなら、同社は発生から1週間で発生日時・手口・対象範囲・当局への報告状況までを具体的に開示している。インシデントの公表は遅れがちになるのが通例のなかで、この開示姿勢自体は事後対応の参考例として見るべきもので、被害に遭ったこと自体を責める材料にすべきではない。狙われた側の落ち度を探すより、「同じ攻撃が自社に来たら」を考えることに、この公表情報の価値がある。

「暗号化される前提」の対策はなぜ外れたのか——攻撃類型の変化を整理する

ランサムウェア対策の教科書的な説明は「データが暗号化されて使えなくなるので、バックアップから復旧できる体制を作る」というものだ。この説明自体は今も有効だが、注意すべきは、攻撃側の手口が「暗号化」一本ではなくなっていることだ。現時点で企業が想定すべき恐喝型攻撃は、大きく4類型に分けられる。

類型を並べると、見落とされがちな事実が3つ浮かび上がる。

第一に、4類型のうち3つで、バックアップの実効性が復旧の生命線になる。暗号化型・削除型・二重恐喝のいずれでも、攻撃者に金を払わずに事業を再開できるかどうかは「戻せるバックアップが残っているか」で決まる。つまりバックアップは数ある対策の一つではなく、恐喝型攻撃に対する最後の防衛線である。

第二に、削除型は攻撃者にとって「安上がり」だという構造を理解する必要がある。大量のデータを暗号化するには時間がかかり、その間に検知されるリスクを攻撃者は負う。一方、データベースの削除は一瞬で終わる。復旧手段を持たない企業が相手なら、丁寧に暗号化しなくても、消して「復元してやる」と言うだけで金銭要求は成立してしまう。防御側のバックアップが弱い会社ほど、攻撃者は雑で速い手口を選べる——守りの弱さが、攻撃のコストを下げているという関係にある。

第三に、削除型では「支払っても戻らない」可能性を暗号化型以上に織り込む必要がある。暗号化型なら攻撃者の手元に復号鍵があるが、削除型で攻撃者が本当にデータの複製を保持しているかは確認しようがない。支払いは復旧を保証しないうえ、犯罪組織への資金提供にもなる。だからこそ、支払い以外の復旧手段——すなわち自社のバックアップ——の実効性が、交渉の余地すら生まない唯一の備えになる。

なお、攻撃の入口という観点では、警察庁の統計でもVPN機器やリモートデスクトップ経由の侵入が大半を占めており、盗まれた認証情報の悪用が主要な入口になっている。だからこそ、AIエージェントの利用環境まで含めた認証情報と権限の管理は別の論点として整理が必要だ。この点はAIエージェント型ランサムウェアを題材にした認証情報・権限・バックアップ設計の解説で扱っているので、AI活用を進めている会社はあわせて確認してほしい。本記事は、AIの有無にかかわらずすべての会社が持っている「基幹の顧客データベース」の守り方に絞る。

バックアップを「攻撃者の視点」で棚卸しする

ここからが本題だ。「バックアップは取っています」という社内報告を、攻撃者の視点で問い直してみてほしい。問いはシンプルで、**「本番システムに侵入した攻撃者から、そのバックアップは見えるか。消せるか」**である。

攻撃者から見える(=一緒に消される)バックアップの典型例を挙げる。

• 本番サーバ内の別フォルダへのコピー。サーバごと侵入されれば当然消される。
• 同じネットワークに常時接続されたNAS・ファイルサーバ。本番の管理者権限を握った攻撃者は、ネットワーク越しにバックアップ先へも到達できる。
• 本番と同じ管理者アカウントで操作できるクラウドのスナップショット。クラウドの管理コンソールを乗っ取られれば、スナップショットの削除は数クリックだ。同じアカウント・同じ認証情報で本番とバックアップの両方を消せる構成は、系統としては1系統である。
• バックアップソフトの管理画面が本番と同じ認証基盤(同じID/パスワード、同じActive Directory)にぶら下がっている構成。攻撃者は本番を消す前に、まずバックアップを消しに行く。恐喝型攻撃の実務では、バックアップの破壊は攻撃の「前工程」に組み込まれている。

逆に、攻撃者から見えないバックアップとは、ネットワークから切り離されている(オフライン)、または書き換え・削除が技術的にできない(イミュータブル)、あるいは本番とは別の認証でしか触れない保管先を持つものだ。ここで重要なのは、これは「高価な製品を買う」話ではなく「構成と権限の設計」の話だという点である。同じクラウド費用でも、アカウント分離とオブジェクトロックを設定しているかどうかで、削除型攻撃への耐性はまったく変わる。自社の構成がどちら側にあるかを外部の目で確認したい場合は、GXOのセキュリティ対策・診断サービスでバックアップ実効性を含む評価を行っている。

「復元できるバックアップ」の6条件チェックリスト

バックアップを「対策」として数えてよいかどうかは、次の6条件で判定できる。IT担当・保守ベンダーとの会話でそのまま使えるよう、各条件に確認方法を添えた。

1. オフラインまたはイミュータブルな世代を持っているか 少なくとも1世代は、ネットワークから切り離された媒体、または削除・上書きが技術的に不可能な保管方式(オブジェクトロック等)で保持しているか。すべての世代がオンラインで、本番から到達可能なら、それは削除型攻撃に対しては0世代と同じだ。

2. バックアップ系統の認証が本番と分離されているか バックアップの削除・変更に、本番システムとは別のアカウント・別の認証情報(できれば多要素認証)が必要か。本番の管理者パスワード1つでバックアップまで消せる構成は、鍵を1本しか持っていないのと同じである。

3. 定期的な復元試験をしているか 直近1年以内に、バックアップから実際にデータを戻し、業務システムとして動くところまで確認したか。「取得のログは毎日成功している」は復元できる証明にならない。取得が成功していても、復元して初めて壊れていたと分かるケースは珍しくない。復元試験を一度もしていないバックアップは、対策ではなく祈りである。

4. RTO・RPOについて経営が合意しているか 全部消えた場合に何日で業務を再開するか(RTO)、最大で何日分のデータ喪失まで許容するか(RPO)を、IT担当ではなく経営が決めているか。「毎晩バックアップ」は裏を返せば「最悪1営業日分の受注・顧客データは消える」という経営判断である。決めた覚えがないなら、それは判断していないのではなく、無自覚に受け入れているだけだ。

5. バックアップの削除・改ざんを検知できるか バックアップが消された・世代が減った・容量が急変したことを、誰かが翌朝までに気づける仕組みがあるか。前述のとおり攻撃者はバックアップを先に消しに来る。本番が無事なうちにバックアップだけ静かに消され、数週間後に本番を消される——という順序を想定すると、バックアップ側の監視は本番と同格の重要度を持つ。

6. データが消えた・漏れた場合の公表・報告の準備があるか 個人情報保護法上、報告義務の対象は「漏えい」だけではない。個人データの滅失・毀損も、不正アクセスなど不正の目的によるおそれがある場合等の要件に該当すれば、個人情報保護委員会への報告と本人への通知が求められる。「データが消えただけで漏れていないから公表不要」という理解は誤りになり得る。誰が判断し、何日以内に、どの窓口へ報告するかの手順を平時に文書化しているか。今回の事案でも、発生から6日で当局報告、7日で公表という時系列が公表されており、この速度は準備なしには出ない。初動対応の全体像はインシデント対応サービスの解説を参照してほしい。

6条件のうち、1・2・3のいずれかが欠けている場合、削除型攻撃に対する復旧手段は実質的に存在しないと評価すべきだ。4・5・6の欠落は、復旧はできても「何日止まるか」「法的対応でつまずくか」を運任せにしている状態を意味する。

経営者がIT担当・保守ベンダーに今週聞くべき質問

チェックリストを経営者自身が技術的に検証する必要はない。次の質問を投げ、回答の具体性を見ればよい。

1. 「うちのバックアップは、どこに、何世代あるか。そのうち、本番に侵入した攻撃者が消せない世代はどれか」
2. 「本番の管理者パスワード(または管理者アカウント)が盗まれた場合、そのパスワードでバックアップも削除できるか」
3. 「最後にバックアップからの復元試験をしたのはいつか。何を、どこまで戻したか」
4. 「顧客DBが今夜全部消えた場合、何日で業務を再開でき、何日分のデータが失われるか」
5. 「バックアップが削除されたら、誰が、いつ気づくか」
6. 「顧客情報が消えた・漏れたおそれがある場合、個人情報保護委員会への報告と顧客への通知は、誰がどの手順で行うことになっているか」

回答を評価する軸も添えておく。日付・場所・手順が即答できるかが第一の軸だ。「大丈夫です」「取ってあります」という形容詞だけの回答は、検証されていないことのサインである。第二の軸は質問2への回答で、ここで言葉に詰まる、あるいは「同じアカウントで管理しています」という回答なら、削除型攻撃への耐性はないと判断してよい。第三に、保守ベンダーが「契約範囲外です」と答えた場合、それはベンダーの怠慢ではなく契約の欠落であり、責任分界を書面で確認し直すべき経営マターだ。バックアップの設計・監視・復元試験が、自社とベンダーのどちらの責任にも入っていない「空白地帯」になっている会社は多い。

この質問リストは1回で終わらせるものではなく、復元試験(質問3)と検知(質問5)は継続的な運用そのものだ。社内に運用を担う人がいない場合は、セキュリティ顧問(リテイナー)サービスのように外部の専門家が継続的に伴走する形も選択肢になる。

よくある質問(FAQ)

Q. クラウドサービスを使っていれば、バックアップはクラウド事業者がやってくれるのではないか。 役割分担(責任共有モデル)を確認する必要がある。クラウド事業者が守るのは基盤の可用性であり、利用者のアカウントが乗っ取られて利用者自身の権限でデータが削除された場合、それは原則として利用者側の責任範囲になる。事業者標準のスナップショットが本番と同じアカウントから消せる構成なら、削除型攻撃への耐性としては不十分だ。クラウド利用でも、アカウント分離・別リージョンや別アカウントへの退避・オブジェクトロックといった設計は利用者側の仕事である。

Q. 身代金を支払えばデータは戻るのか。 戻る保証はどこにもない。特に削除型では、攻撃者が本当に復元可能な複製を保持しているか確認する手段がなく、支払っても何も返ってこない可能性を織り込むべきだ。加えて、支払いは犯罪組織への資金供給となり、再攻撃の標的リストに載るリスクや、支払先によっては制裁規制上の問題も指摘されている。「支払うかどうかの判断」を迫られる状況に陥らないこと——つまり自力で復元できる状態を平時に作ることが、唯一筋の良い答えである。

Q. 従業員数十名の会社が、わざわざ狙われるのか。 「狙われる」という言葉のイメージを修正した方がよい。この種の攻撃の多くは、特定企業を選んで仕掛けるのではなく、露出したVPN機器や漏えいした認証情報を機械的に走査し、入れたところに入る。つまり規模ではなく「入りやすさ」で選ばれる。警察庁の統計でも、ランサムウェア被害の報告件数の過半を中堅・中小企業が占める傾向が続いている。むしろ中小企業は、復旧体制が弱く支払いに追い込まれやすいという意味で、攻撃者から見て「効率の良い」相手になり得る。

Q. まず何から着手すべきか。予算はどの程度必要か。 最初の一歩は投資ではなく現状把握だ。本記事の質問リスト6問をIT担当・保守ベンダーに投げることは今週、費用ゼロでできる。その回答で6条件のどこに穴があるかが見えたら、優先順位は「認証分離(条件2)→オフライン/イミュータブル世代(条件1)→復元試験(条件3)」の順を推奨する。認証分離と復元試験は既存環境の設定・運用変更で対応できる部分が大きく、大きな投資の前にやれることから潰すのが正しい順序だ。

GXOに相談すべきサイン

次のいずれかに当てはまる場合は、自社だけで結論を出す前に第三者の評価を入れることを勧める。

• 質問リストを投げたが、回答が形容詞ばかりで、6条件のどこが満たされているのか判断できない
• バックアップの責任が自社と保守ベンダーのどちらにあるのか、契約書を見ても分からない
• 復元試験をやりたいが、本番影響が怖くて手順を組める人が社内にいない
• RTO・RPOを決めろと言われても、事業への影響額を算定する枠組みがない
• 過去に「バックアップから戻せなかった」経験があるが、原因を検証しないままになっている
• 顧客情報が消えた・漏れた場合の報告・公表手順が文書化されていない

GXOは、開発会社としてシステムの中身とインフラ構成の両方を読める立場から、バックアップの実効性評価を含むセキュリティ診断、有事のインシデント対応、平時の運用を支えるセキュリティ顧問を提供している。「うちのバックアップは攻撃者から見えるか」という問いに社内で答えが出ないなら、その状態を放置しないことが今回の事案から持ち帰るべき教訓だ。相談窓口はこちらから、現状の構成が分かる範囲の情報だけで初回の壁打ちができる。

参考ソース

• 株式会社ネットワークジャパン 引越事業部「お客様情報に関するお知らせとお詫び」(2026年7月9日・一次ソース) https://www.happiness-to-everyone.com/news/731/
• セキュリティ対策Lab「ネットワーク引越センター、ランサムウェア被害で情報の滅失・漏えいの恐れ-データベース削除後に暗号資産を要求」(二次報道) https://rocket-boys.co.jp/security-measures-lab/network-hikkoshi-db-deletion-extortion/
• 個人情報保護委員会「漏えい等の対応とお役立ち資料」(漏えい・滅失・毀損の報告義務の整理) https://www.ppc.go.jp/personalinfo/legal/leakAction/
• 警察庁「サイバー空間をめぐる脅威の情勢等」統計ページ(各年次報告にランサムウェア被害の企業規模別統計を収載) https://www.npa.go.jp/publications/statistics/cybersecurity/index.html

※事案の事実関係は同社公表文で確認できた範囲を記載した。侵入経路・要求額・復旧可否など未公表の事項には触れていない。攻撃類型の整理・6条件・質問リストはGXOによる一般的な解説であり、同社の対策状況について述べたものではない。