AIエージェント型ランサムウェア時代のバックアップ設計は「復元できるか」ではなく「鍵と権限を奪われても戻せるか」

先に結論

AIエージェント型ランサムウェアの時代に、バックアップの確認を「復元できるか」だけで終わらせると、いざというときに戻せません。問うべきは「鍵と権限を奪われても戻せるか」です。

理由はシンプルです。バックアップが本番システムと同じ認証基盤・同じ管理者権限の下に置かれていると、その管理者アカウントが乗っ取られた瞬間に、本番もバックアップも同時に消せる状態になります。攻撃者から見れば、バックアップは「復旧の保険」ではなく「先に潰しておく対象」です。つまり、バックアップを取っていること自体は、戻せることをまったく保証しません。

この記事では、実際に報告された事例を土台に、バックアップを鍵と権限から切り離す設計、復旧演習で必ず見つかる穴、委託先やクラウドに投げるべき確認質問を、順番に整理します。中小企業で「専任のIT担当がいない」「バックアップはベンダー任せ」という状態でも、自分たちの手で点検できるところまで落とし込みます。

この記事を読むべき人

• 情報システムの専任担当がいない、または一人情シス・兼任情シスで運用している経営者・管理部門の方
• バックアップは取っているが、実際に「戻せるか」を試したことがない方
• Microsoft 365やGoogle Workspace、会計SaaS、クラウドを複数使っていて、どこに管理者権限とAPIキーがあるか把握しきれていない方
• ランサムウェアやAIを使った攻撃のニュースを見て、「うちは大丈夫か」と一度立ち止まりたい方
• ベンダーに「バックアップはありますか」以外に何を聞けばよいか分からない方

何が起きているのか：JADEPUFFERで確認できたこと

セキュリティ企業のSysdigは2026年7月、AIエージェントが攻撃の大部分を自動で実行したとみられるランサムウェア事例を「JADEPUFFER」として報告しました。Sysdigはこれを、初期侵入から恐喝までを大規模言語モデル（LLM）が駆動した最初の documented な事例と評価しています。ここで大事なのは、攻撃の派手さではなく、そこから読み取れる設計上の教訓です。事実として確認できる範囲だけを、以下に挙げます。

• 入り口はインターネットに露出した既知の脆弱性でした。 攻撃者はLangflowというツールの脆弱性（CVE-2025-3248）を突いて侵入しています。特別な内部情報ではなく、外から見える弱点が起点でした。
• 攻撃者は認証情報を探し回りました。 SysdigによればエージェントはLLMのAPIキー、クラウドの認証情報、データベースの認証情報などを環境から収集しています。つまり「鍵」を集める動きが自動化されていました。
• 横方向に広がり、権限を上げました。 内部ネットワークを走査し、オブジェクトストレージの初期パスワードを試し、データベースへ管理者を追加するといった手順が観測されています。ひとつの侵入点から、複数のシステムへ広がっていきました。
• 失敗しても自分で直して進みました。 Sysdigの記録では、ログイン失敗から修正版の投入まで31秒という場面がありました。人間が同じ作業をするより速い局面があったことを、Sysdig自身が指摘しています。
• 最終的にデータを暗号化し、原本を消しました。 1,342件の設定情報が暗号化され、元のデータは削除されました。

そして、この記事の主題にとって最も重い事実がこれです。暗号化に使われた鍵は、その場で作られただけで、保存も送信もされていませんでした。 そのため、Sysdigは「被害者は身代金を払っても復号できない」と結論づけています。攻撃者に金を払えば戻る、という前提が成り立たなかった実例です。

一方で、書きすぎないことも同じくらい重要です。Sysdig自身、システムプロンプトやエージェントの構成までは確認できず、人間の関与を完全には否定できないと述べています。被害を受けた企業名、身代金の金額、潜伏していた期間は公表されていません。「AIが完全に自律して、けた違いの速度ですべてをやった」と断定するのは、報告の範囲を超えます。確実に言えるのは、認証情報を集め、複数システムを横断し、失敗を自力で修正する動きが自動化されつつある、ということです。

「復元できる」と「奪われても戻せる」は別の問い

多くの会社で、バックアップの確認はこう行われています。「バックアップは取れていますか」「復元テストはしましたか」。これ自体は正しい確認ですが、前提がひとつ抜けています。その復元は、攻撃者に権限を奪われていない平時を想定しているのです。

現実のランサムウェア被害は平時ではありません。攻撃者は本番システムだけでなく、バックアップも消しにきます。バックアップが本番と同じ管理コンソール、同じ管理者アカウント、同じAPIキーの支配下にあると、次のことが同時に起きます。

• 本番データが暗号化される
• バックアップが削除される、または同じ鍵で暗号化される
• 復旧を承認する管理者アカウント自体が乗っ取られている

この状態では、いくら復元テストで「戻せました」と確認していても、本番では戻せません。復元手順は生きていても、それを実行する権限と鍵が敵の手にあるからです。

だから問いを変える必要があります。「復元できるか」ではなく、「管理者アカウントを奪われた前提でも戻せるか」。言い換えると、バックアップは保存の問題ではなく、侵害後に手元へ引き戻せる権限の問題です。JADEPUFFERの事例が示したように、原本を消され、鍵も残らなければ、復元という言葉自体が成立しません。守るべきは「戻すための独立した経路」です。

鍵と権限を分ける設計：それぞれ何を防ぐか

では、どう分ければよいのか。抽象論ではなく、防げるものを一つずつ対応させて考えます。中小企業でも、いきなり全部でなくてよいので、効くところから手を付けます。

1. バックアップの保管先を別アカウント・別権限にする

本番環境を管理するアカウントと、バックアップを操作できるアカウントを分けます。クラウドであれば別アカウント・別プロジェクト、オンプレであれば本番と切り離した保管先にします。

これが防ぐのは、管理者アカウント一つの乗っ取りで全滅することです。本番を握られても、バックアップ側の権限が別なら、そちらまでは一手で消せません。攻撃者にとって「もう一段、別の鍵を破る」必要が生まれ、その手間と時間が、こちらの検知と対応の余地になります。

2. 削除に多要素認証または時間差を要求する

バックアップの削除を、ワンクリックでできないようにします。削除操作に追加の多要素認証を必須にする、あるいは「削除予約から実際の消去まで一定期間待つ」時間差を設けます。

これが防ぐのは、盗んだ認証情報だけで即座に消し去られることです。多要素を挟めば、パスワードやトークンを盗んだだけでは削除まで届きません。時間差を設ければ、誤操作や不正な削除に気づいて取り消す猶予が生まれます。復旧の最後の砦を、一瞬で失わないための仕組みです。

3. 書き換え不可（イミュータブル）にする

一定期間、誰であっても上書き・削除できないバックアップを持ちます。クラウドストレージの多くには、期間を指定して変更を禁止する機能があります。

これが防ぐのは、管理者権限を奪われても、その世代だけは壊せない状態を残すことです。イミュータブルに設定した世代は、たとえ最上位の権限を持つアカウントからでも、期限が来るまで消せません。JADEPUFFERのように原本を消してくる攻撃に対して、「消せない一世代」があるかどうかは、戻せるか戻せないかの分かれ目になります。

3つを組み合わせる意味

この3つは、それぞれ別の攻撃段階に効きます。別アカウント化は「一手での全滅」を、多要素・時間差は「盗んだ鍵での即時削除」を、イミュータブルは「最上位権限での破壊」を止めます。攻撃側から見ると、突破すべき関門が段階的に増えます。一つでも入れれば、バックアップが本番と運命を共にする状態からは抜け出せます。優先するなら、まずイミュータブルな世代を一つ確保することをおすすめします。最悪でも、そこには戻れるからです。

セキュリティ対策のどこから手を付けるべきか自社だけで決めきれない場合は、セキュリティ対策の優先順位を短時間で整理するところから始めると、投資の順番を見誤りにくくなります。

AIエージェントが攻撃側に立つと何が変わるか

「AIが攻撃側に回ると何が変わるのか」は、煽らずに考える必要があります。誇張は判断を鈍らせるからです。

Sysdigの報告から確実に言えるのは、次の3点です。第一に、認証情報の探索が自動化されていました。環境変数や設定ファイルから鍵を機械的に集める動きは、人手より網羅的になりえます。第二に、横展開が続けられました。内部の別システムへ次々と手を伸ばす動作が観測されています。第三に、失敗からの復旧が速い局面がありました。ログイン失敗から修正投入まで31秒という記録は、人間が同じ判断をするより速いと、Sysdig自身が評価しています。

一方で、「AIだから常にけた違いに速い」と一般化するのは避けます。今回確認されたのは一つの事例であり、Sysdigも完全な自律動作を証明したとは述べていません。過大評価はかえって「うちには関係ない特別な脅威」という誤解を生み、基本的な対策を後回しにさせます。

実務にとって重要な含意はむしろ静かなものです。Sysdigは、攻撃を回すのに必要なスキルの下限が下がったと指摘しています。かつては熟練した人間を必要とした手順を、モデルが肩代わりできるようになりつつある、という見立てです。これは、攻撃の高度さより、攻撃の数と幅が増えることを意味します。だとすれば、防御側が取るべきは特別な魔法ではなく、「認証情報を集められても致命傷にならない構造」「一つのアカウント乗っ取りで全滅しない構造」という、地味で確実な設計です。速い相手に対しては、速さで張り合うのではなく、そもそも一手で崩れない配置で応じるのが定石です。

AIエージェント自体に与える権限をどう絞るかは、監視ログだけでは足りません。停止条件と権限剥奪をどう設計するかは、AIエージェント監視はログでは足りない：停止条件と権限剥奪の設計で別途整理しています。

復旧演習で必ず見つかる穴

設計を紙の上で整えても、実際に戻せるかは別問題です。一度でも復旧演習をやると、ほぼ確実に次のような穴が見つかります。これらは特殊なケースではなく、多くの会社で共通して出てくるものです。

• バックアップからデータは戻せるが、認証基盤が戻っていない。 データを書き戻しても、それにアクセスするためのID管理（Active DirectoryやSSO）が壊れたまま、あるいは乗っ取られたままでは、業務は再開できません。データと「そのデータを使うための鍵」は別に守る必要があります。
• 復旧手順書が、止まったサーバの中にしかない。 手順書を社内ファイルサーバやSaaSに置いていて、その基盤ごと暗号化されると、手順書自体が読めません。復旧の地図が、燃えている建物の中にある状態です。
• 鍵を担当者一人しか知らない。 復旧に必要なパスワードや暗号鍵、管理者アカウントを特定の担当者しか把握しておらず、その人が不在・退職・連絡不能だと、正しいバックアップがあっても開けません。
• 復旧に必要なライセンスやサポート契約が切れている。 いざ復元しようとしたら、ソフトウェアのライセンスが期限切れ、あるいは保守契約が失効していて、復旧作業そのものが止まる。演習をして初めて気づく典型例です。
• バックアップの世代が浅く、暗号化前まで遡れない。 攻撃者は暗号化の前に、しばらく潜伏していることがあります。世代が数日分しかないと、汚染された状態のバックアップしか残っていない、という事態が起こりえます。

これらは「バックアップを取っているか」というチェックでは絶対に出てきません。実際に戻す動作をして初めて表面化します。逆に言えば、演習は失敗を安全な場所で先に起こすための手段です。本番で初めて穴に気づくのが最悪であり、演習で気づくのが最善です。

「戻せるか」を検証する手順

演習は大掛かりである必要はありません。中小企業なら、年に一度、次の順番で「実際に戻す」ところまでやれば十分に価値があります。頭の中の想定ではなく、手を動かして時間を測ることが肝心です。

1. 何を戻すか決める。 全部ではなく、止まると売上や顧客対応に直結する重要システムを1〜2個選びます。会計、受発注、顧客管理など、自社にとっての中核から始めます。
2. どの環境へ戻すか用意する。 本番とは別の隔離した環境（検証用のクラウド環境や別サーバ）を用意します。本番に上書きしないことが安全のうえでも重要です。
3. 本番管理者を使わずに戻せるか試す。 あえて「普段の管理者アカウントが使えない」前提で、バックアップ用の別権限だけで復元できるかを確認します。ここで詰まれば、それが平時に直すべき設計上の穴です。
4. どれくらいの時間がかかったか記録する。 復元開始から業務再開の目安が立つまで、実際に何時間・何日かかったかを測ります。この実測値が、経営判断（どこまで止められるか）の基礎になります。
5. 途中で足りなかったものを書き出す。 手順書、鍵、ライセンス、連絡先――演習中に「これがなくて止まった」ものを全部リスト化し、平時のうちに埋めます。

この5ステップを一度回すだけで、「バックアップがある」から「実際に戻せる、しかも何時間で戻せる」へと、確信の質が変わります。理想を言えば毎年、少なくとも重要システムの構成を大きく変えたタイミングで、繰り返す価値があります。復旧の実測時間を持っている会社は、被害時に「払うか、戻すか」を数字で判断できます。持っていない会社は、パニックの中で払う方向に流れがちです。

万一すでに侵害の兆候がある、あるいは今まさに動いているかもしれない場合は、演習より先に初動です。インシデント発生時の初動対応支援のように、順序と役割を決めておくことが被害の大きさを左右します。

委託先・クラウドに確認する質問

バックアップをベンダーやクラウドに任せている場合、「バックアップはありますか」で止まってはいけません。任せていること自体は問題ありませんが、丸投げして中身を知らないのは危険です。次の6つを、具体的に聞いてください。

• 保管場所はどこですか。 本番と同じ環境・同じアカウント内ですか、それとも物理的・論理的に分離されていますか。同じ場所なら、一緒に消される前提で考える必要があります。
• 削除できるのは誰ですか。 バックアップを消せる権限を持つのは誰で、その操作に多要素認証や時間差、承認は挟まっていますか。
• 世代はいくつありますか。 何日分・何世代を保持していますか。潜伏期間を考えると、直近数日分だけでは足りない場合があります。
• 書き換え不可の世代はありますか。 一定期間、誰にも消せないイミュータブルなバックアップが含まれていますか。
• 復旧にどれくらいかかりますか。 実際に戻す場合、目標とする復旧時間はどれくらいで、その数字は実測に基づいていますか。
• こちらから取り出せますか。 ベンダーが対応できない状況でも、自社が直接データを取り出せる手段はありますか。ベンダー依存が単一障害点になっていないかの確認です。

これらの答えが曖昧なら、それ自体がリスクです。契約書やSLAに書いてある文言と、実際に運用されている中身が一致しているかまで確認すると、より確実です。委託先まで含めた運用の穴を継続的に点検したい場合は、月次で棚卸・判定・対応まで伴走するセキュリティ運用のような、任せきりにしない体制も選択肢になります。

よくある誤解

最後に、バックアップと復旧をめぐってよく耳にする誤解を、事実に照らして正します。どれも「善意で信じているが、いざというとき裏切られる」タイプの思い込みです。

• 「クラウドだからバックアップは自動で安心」。 クラウド事業者が保証するのは多くの場合インフラの可用性であって、あなたが誤って消したデータや、暗号化されたデータの復旧までは標準では守られないことがあります。SaaSのデータ保護範囲は必ず契約で確認してください。責任分界点を知らないまま「クラウドだから大丈夫」と考えるのが、最も危険な思い込みです。
• 「バックアップを取っているから復旧できる」。 本記事で述べたとおり、取っていることと戻せることは別です。同じ権限下にあれば一緒に消され、演習をしていなければ穴に気づけません。「取得」と「復元」の間には、鍵・権限・手順・時間という埋めるべき距離があります。
• 「暗号化されても身代金を払えば戻る」。 これは実例で覆されています。JADEPUFFERの事例では、復号鍵がその場限りで保存されておらず、Sysdigは払っても復号できないと結論づけました。攻撃者に技術力や誠実さを期待する前提は成り立ちません。払うことは復旧手段ではなく、戻せる構造を平時に作るしかありません。
• 「うちは小さいから狙われない」。 JADEPUFFERの入り口は、インターネットに露出した既知の脆弱性でした。攻撃の自動化が進むほど、標的は「価値の高い大企業」から「入りやすいところ全部」へ広がります。規模の小ささは、もはや盾になりません。むしろ、対策が薄い分だけ入られやすい対象になりえます。

GXOの確認ポイント（早見表）

自社の状態をざっと点検するための一覧です。「はい」と即答できない項目が、優先して埋めるべき穴です。

FAQ

Q. バックアップを毎日取っていれば、ランサムウェア対策は十分ですか。 不十分です。取得頻度が高くても、そのバックアップが本番と同じ権限下にあれば、管理者アカウントを奪われた時点で一緒に消されます。頻度よりも、鍵と権限を分けているか、書き換え不可の世代があるかが本質です。

Q. 中小企業でも、別アカウントやイミュータブルまで必要ですか。 規模より、止まると困るシステムがあるかで判断します。会計や受発注が止まると事業が回らないなら、最低でも「消せない一世代」を確保する価値があります。全部を一度に整える必要はなく、最も止められない業務から始めれば十分です。

Q. AIエージェント型ランサムウェアは、従来型と対策が違うのですか。 守りの基本は変わりません。認証情報の分離、権限の最小化、消せないバックアップ、復旧演習――どれも従来から有効な対策です。変わるのは攻撃の数と幅が増える可能性で、だからこそ「一手で全滅しない構造」の重要度が上がります。

Q. 身代金を払えば、暗号化されたデータは戻りますか。 戻る保証はありません。Sysdigが報告したJADEPUFFERの事例では、復号鍵が保存されておらず、払っても復号できないと結論づけられています。払うことを復旧計画の前提にするのは危険で、平時に戻せる構造を作るしかありません。

Q. クラウドやSaaSに保存していれば、バックアップは自動で守られますか。 事業者が保証する範囲は契約によって異なり、多くはインフラの可用性が中心です。あなたが消したデータや暗号化されたデータの復旧が標準で含まれるとは限りません。データ保護の範囲と、自社で取り出せる手段の有無を、契約で必ず確認してください。

Q. 復旧演習は、どれくらいの頻度でやればよいですか。 最低でも年に一度、加えて重要システムの構成を大きく変えたタイミングでの実施をおすすめします。全システムでなくてよいので、止まると困る中核システムを実際に別環境へ戻し、所要時間を測ることに意味があります。

Q. 委託先に任せている場合、何を確認すればよいですか。 保管場所、削除権限と多要素・時間差の有無、世代数、書き換え不可の世代の有無、復旧の所要時間、自社で取り出せるか――この6点を具体的に確認してください。契約書の文言と実際の運用が一致しているかまで見ると、より確実です。

Q. まず何から手を付ければ最も効果がありますか。 一つ選ぶなら、書き換え不可（イミュータブル）な世代を一つ確保することです。最上位の権限を奪われても、その世代だけは期限まで壊せないため、最悪でもそこには戻れます。そのうえで、重要システムで一度、戻せるかの演習を回すのが次の一手です。

関連するGXOナレッジ

• AIエージェント型ランサムウェアから考える、認証情報・権限・バックアップ設計
• AIエージェント監視はログでは足りない：停止条件と権限剥奪の設計
• 企業向けAIエージェント導入前に見るべきNemoClaw型のガバナンス要件
• BSides Bangaloreから考える、AI時代のセキュリティ人材はツール運用より攻撃ライフサイクル理解が必要

相談したいとき

鍵、権限、バックアップ、復旧演習を一体で点検したいとき、どこから手を付けるべきかを短時間で整理したい場合は、セキュリティ対策の優先順位整理（30分）が入り口になります。緊急の脆弱性が自社にどう影響するかを確かめたいときは緊急脆弱性・CVEの影響診断、すでに侵害の疑いがあるならインシデント対応支援へ。継続的に運用を任せきりにしない体制を作りたいなら、セキュリティ事業の全体像もあわせてご覧ください。

参考・出典

• Sysdig「JADEPUFFER: Agentic ransomware for automated database extortion」: https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion （確認日：2026-07-10、本記事の事実主張はこの一次レポートに基づく）
• Business Insider（二次報道）: https://www.businessinsider.com/ai-ransomware-attack-sysdig-jade-puffer-2026-7 （確認日：2026-07-10、直接取得できず本文の事実主張には使用していない）
• OWASP GenAI Security Project: https://genai.owasp.org/ （確認日：2026-07-10）
• NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework （確認日：2026-07-10）