「バックアップ神話崩壊」ランサム被害の最悪シナリオと現実的な守り方

結論：バックアップがあっても“業務継続が困難になる”最悪シナリオ（全体マップ）

「バックアップを取っているから大丈夫」という安心感は、ランサムウェアの現場では簡単に崩れます。理由はシンプルで、攻撃者は「暗号化で止める」だけでなく「漏えいで追い込む」「復旧を妨害する」までセットで設計してくるからです。さらに厄介なのは、攻撃が始まった時点で“状況が見えない”ことです。どの端末が侵害されたのか、何が持ち出されたのか、バックアップが無事なのか——判断材料が揃わないまま、復旧・対外対応・意思決定が同時進行になります。

このため、バックアップの有無だけを見て「助かる／助からない」を決めるのは危険です。必要なのは、最悪の進行パターンを知り、どこで詰むのか（＝意思決定が止まる地点、復旧が止まる地点、信用が崩れる地点）を先に掴むこと。たとえば「社内の共有フォルダが暗号化された」だけなら、最悪でも業務の一部停止で済むかもしれません。しかし「基幹DBが暗号化され、同時に顧客情報が持ち出され、バックアップが削除されていた」となると、復旧の難易度と対外対応の重さが一気に跳ね上がります。

まずは、どこで詰むのかを“全体マップ”で押さえるのが最短ルートです。全体像を掴んでおくと、初動でやるべき優先順位（隔離→把握→連絡→復旧）をブレさせずに済みます。

最悪の流れ（侵入→横展開→暗号化→情報漏えい脅迫→復旧妨害）

典型的な最悪シナリオは次の順で進みます。

• 侵入：メール添付、脆弱性、認証情報漏えいなどで入口を確保される
• 横展開：侵入後、社内の別端末・サーバへ権限を広げ、管理者権限を奪う
• 暗号化：業務サーバや共有ストレージを一斉に暗号化し、業務を停止させる
• 情報漏えい（暴露）脅迫：盗み出したデータを「公開する」と脅し、追加で圧力をかける
• 復旧妨害：バックアップ削除・暗号化、復旧手順の撹乱、再感染で復旧を遅らせる

ここで重要なのは、「バックアップがある＝復旧できる」ではない点です。バックアップ自体が攻撃対象になっていれば復旧のカードは消え、仮に復旧できても情報漏えいが確定していれば“終わり”になり得ます。

また、現場でよく起きるのが「早く戻したい」気持ちからの悪手です。

• 状況を確かめずにネットワークをつなぎ直し、被害範囲を広げる
• 端末を初期化して証拠が消え、侵入経路が特定できない
• 復旧を急いで“汚染された環境”へ戻してしまい、再感染する

復旧のスピードは重要ですが、再現性のある“回復の型”がないと、速さが逆にリスクになります。特に注意したいのは「復旧の正しさ」を担保する作業です。復旧対象が正しいか、復旧点（世代）が適切か、戻した後に監視やログが再開できるか。こうした確認が抜けると、業務が一度戻っても再び止まる可能性が高まります。

ミニFAQ：身代金は払うべき？（結論と判断の前提だけ）

身代金を「払う／払わない」は、結論だけを先に決められる話ではありません。暗号化解除キーが必ず提供される保証はなく、提供されても復旧が完了するとは限りません。さらに、漏えいデータの削除も証明できません。加えて、支払いが次の攻撃や追加要求の呼び水になる可能性もあります。

判断の前提としては、少なくとも以下を揃えます。

• 何が暗号化され、どこまで業務が止まっているか（停止範囲の確定）
• 何が持ち出された可能性があるか（漏えいの可能性と優先調査対象）
• バックアップが「攻撃者に触られていない」確度（安全な世代の有無）
• 復旧の見込み（時間・コスト・代替手段、外部支援の要否）

この前提がないままの意思決定は、結果として被害を拡大させやすくなります。まずは「止血（隔離）」と「見える化（影響把握）」を優先し、判断を急がないための土台を作ることが重要です。たとえば、重要システムの停止が48時間を超えそうか、漏えいが濃厚か、復旧の最短ルートがどれか——最低限これらが見えてから、次の一手を選びます。

落とし穴1：バックアップも暗号化・破壊される（同一権限・同一経路の罠）

ランサムウェアで「バックアップまでやられた」という話は珍しくありません。むしろ攻撃者の視点では、バックアップを壊せば被害者は交渉に傾きやすくなるため、バックアップの無力化は定番の手口です。攻撃者は“復旧の頼みの綱”を潰すことで、被害者の選択肢を狭めます。

特に危険なのは、本番とバックアップが同じ権限・同じネットワーク・同じ管理方法でつながっている状態です。「バックアップの保存先が別サーバだから安全」と思っていても、実際には同じ管理者アカウントで触れたり、同じドメイン配下で到達できたりすれば、攻撃者から見れば“同じ部屋に置いた金庫”になってしまいます。

典型パターン：NAS／バックアップサーバ／スナップショットが狙われる

バックアップの格納先としてよく使われるNASやバックアップサーバは、横展開の到達点になりやすい存在です。攻撃者が管理者権限を得ると、次のようなことが起きます。

• NASの共有フォルダを暗号化（本番の共有データも巻き込む）
• バックアップサーバ上のバックアップデータを暗号化・削除
• スナップショットの削除や、世代管理設定の変更

ここで怖いのは、暗号化そのものだけでなく「復旧できる可能性」を奪われることです。たとえば、バックアップデータは残っていても、

• カタログ（管理DB）が壊れて復元対象を選べない
• バックアップ先のアクセス権限が改ざんされて読めない
• 世代の一部が消され、必要な時点に戻れない

といった形で“使えないバックアップ”が出来上がります。

さらに、攻撃者は「復旧の混乱」を狙います。復旧時にログインできない、復旧の手順書が共有フォルダにあり読めない、バックアップの暗号化で復旧時間が伸びる——これらはすべて“時間を奪う”手口です。

「バックアップは別に取っている」つもりでも、実体としては“同じ社内に置いた別フォルダ”に過ぎない運用だと、攻撃者から見れば守りが薄い場所になります。

権限の連鎖（管理者権限・共有ID・MFA未導入）で一気に崩れる

バックアップが巻き込まれる最大の原因は、権限の連鎖です。

• 本番サーバの管理者が、そのままバックアップ環境にもログインできる
• 共有ID／共有パスワードで運用している
• 多要素認証（MFA）がなく、漏えいした認証情報だけで入れてしまう

こうなると攻撃者は「1つの鍵」でドミノ倒しのように環境を掌握できます。さらに、共有ID運用は「誰がいつ何をしたか」を追えないため、復旧後の再発防止も難しくなります。

バックアップを守るには、まず“同じ鍵で開く扉を増やさない”ことが基本です。具体的には、

• バックアップ専用の管理アカウントを作る
• 本番の管理者権限をバックアップ側に持ち込まない
• 削除・世代変更などの強い権限は最小化し、作業を分離する

といった設計が有効です。加えて、権限設計は「運用で崩れる」ことがあります。緊急対応で権限を付け足したまま戻さない、引き継ぎで共有IDが復活する——こうした“いつの間にか弱くなる”現象も前提にして点検します。

自社点検の観点：バックアップ経路の可視化（どこに・誰が・どう接続）

すぐにできる点検は「バックアップ経路の棚卸し」です。

• どこに保存しているか（機器・場所・クラウドの区別）
• 誰が触れるか（アカウント、権限、共有IDの有無）
• どう接続しているか（常時接続か、バックアップ時だけ接続か）
• 削除や設定変更を誰ができるか（操作の最小化ができているか）

さらに、可能なら「攻撃者の視点で」チェックします。

• ドメイン管理者を奪われたら、バックアップ先まで到達できるか
• 同じパスワードが使い回されていないか
• バックアップ先が“常に見えている共有”になっていないか

“バックアップがあるか”ではなく、“攻撃者が届かない設計か”を確認するのがポイントです。

ここで一歩踏み込むなら、「復旧の最終手段」が何かを決めておきます。オフライン媒体の保管場所、復旧に必要な手順書の印刷物、緊急連絡先（ベンダー、クラウド窓口）——最後の1つを守る設計は、最悪時に効きます。

落とし穴2：情報漏えい（暴露）で復旧しても終わらない（ダブル／トリプル恐喝）

近年のランサムウェアは、暗号化だけでなく情報漏えい（暴露）を組み合わせることが一般化しています。復旧ができても「公開されたら困る情報」を握られている限り、被害は続きます。ここが「バックアップがあるから安心」を崩す最大の要因です。

漏えい型の恐喝では、

• 「公開する」
• 「取引先にも連絡する」
• 「第三者に販売する」

といった圧力が重ねられ、時間が経つほど選択肢が狭まります。つまり、暗号化への備え（復旧）だけでなく、漏えいへの備え（対外対応・法務対応）が必要になります。

ここでの怖さは「復旧が進むほど脅しが強くなる」ケースがあることです。復旧が見えた段階で、攻撃者が“公開のカウントダウン”を始めるなど、心理的な圧迫を加えます。復旧作業と同時に、対外対応の型を回せるかが鍵になります。

何が失われるか（顧客・取引先・従業員・機密）と二次被害

漏えいで問題になるのは“データそのもの”だけではありません。

• 顧客情報：信頼低下、問い合わせ対応、補償、契約解除
• 取引先情報：共同案件の停止、取引条件の見直し
• 従業員情報：個人情報保護の観点での対応が必要
• 機密情報：価格、設計、ソースコード、営業資料などの競争力低下

さらに、漏えいが起点となってフィッシングやなりすまし、二次攻撃が発生することもあります。暗号化は“止まる”被害、漏えいは“広がる”被害です。

特に「取引先を巻き込む」二次被害は深刻です。自社が復旧できても、

• 取引先からの接続遮断
• 共同環境（共有フォルダ、SaaS連携）の停止
• 監査・説明要求の増加

が起きると、売上や契約更新に長期的な影響が残ります。

また、従業員情報や顧客情報が絡むと、問い合わせや通知対応が長期化します。「技術的復旧は終わったのに、問い合わせ対応が終わらず現場が疲弊する」という形で、事業に尾を引くケースもあります。

暴露を前提にした初動“3点”（証拠保全／影響推定／対外コミュニケーション）

初動はスピードが命ですが、焦って誤ると後で取り返しがつきません。暴露を前提に、最低限次の3点を押さえます。

• 1. 証拠保全：ログや端末状態を保存し、原因究明や法的対応に備える
• 2. 影響推定：どのシステムが侵害され、どのデータが対象になり得るかを整理する
• 3. 対外コミュニケーション：社内外の連絡経路、説明の責任者、暫定アナウンス方針を決める

ここで“よくある落とし穴”も押さえておくと、初動がブレにくくなります。

• 情報が確定しないのに断定して発信し、後で訂正が必要になる
• 連絡窓口が分散し、取引先へ回答がバラバラになる
• 証拠保全より先に復旧を進めて、漏えい範囲の特定が難しくなる

「まず復旧」だけに走ると、証拠が消えたり、漏えいの評価ができないまま判断を迫られて混乱します。

初動を強くするコツは「型に落とす」ことです。状況が不確実でも、

• 事実（確認済み）
• 推定（可能性）
• 未確認（要調査）

を切り分けて記録しておくと、説明がブレにくくなります。

法務・広報・経営判断が必要になる分岐点

漏えいが疑われる時点で、技術担当だけでは回りません。

• 法務：契約条項、通知義務、対応の適法性の確認
• 広報：風評・取引先・顧客対応の一貫性
• 経営：事業継続、予算、外部支援（専門家）投入の意思決定

この分岐点を事前に想定し、誰が決めるのか（意思決定の型）を用意しておくことが、被害の長期化を防ぎます。加えて「判断の場」を決めておくと、復旧と対外対応が衝突しにくくなります。

• いつ（何時間以内に）意思決定を集約するか
• どの情報が揃ったら次の判断に進むか
• 外部支援を投入する条件は何か

さらに、取引先や顧客への連絡の「優先順位」も決めておくと混乱が減ります。重要顧客、共同案件、個人情報が絡む範囲——この順に対応の深さとスピードが求められます。

落とし穴3：復旧の「時間」と「コスト」で事業が止まる（RTO/RPOの現実）

「バックアップから戻せばいい」と言うのは簡単ですが、実際の復旧は時間も費用も想像以上にかかります。特に、復旧の目標（RTO：復旧までの許容時間、RPO：許容されるデータ損失）を決めずに運用していると、復旧フェーズで“詰み”が発生します。

ここでのポイントは、復旧は「データ転送」ではなく「業務再開」だということです。データが戻っても、認証が動かない、端末が使えない、業務フローが回らない——こうした“最後の1マイル”が想像以上に重い負担になります。

さらに、復旧は「戻す」だけでなく「安全に戻す」ことが必要です。侵入経路が塞がっていない、管理者権限が残っている、監視が止まっている——この状態で戻すと、再感染・再侵入のリスクが高まります。

復旧が長期化する原因（帯域・容量・依存関係・人手不足）

復旧が伸びる代表要因は次の通りです。

• 帯域不足：大量データの戻しに回線が耐えず、何日もかかる
• 容量・形式：バックアップはあっても、展開先の容量や形式が合わない
• 依存関係：あるサーバだけ戻しても、認証やDBが戻っておらず動かない
• 人手不足：深夜対応、手順作成、確認作業が集中し、通常業務が回らない

加えて、復旧中は「通常の運用」が崩れがちです。

• 監視が止まり、異常検知ができない
• パッチ適用やアカウント管理が後回しになり、再侵入の隙が生まれる
• ドキュメントが古く、手順の確認に時間が溶ける

バックアップは「データの保管」であり、「復旧の自動保証」ではありません。

ここに「現場の混雑」も乗ります。問い合わせ対応、取引先対応、社内説明、復旧作業が同時に走ると、担当者が燃え尽きやすい構造になります。復旧の長期化は、技術的問題だけでなく“人的な限界”でも起こります。

復旧順の設計がないと起きること（基盤→業務→周辺の詰まり）

復旧には順番があります。基盤（認証・ネットワーク・監視）→主要業務（基幹・受発注）→周辺（ファイル共有・端末）のように、前提が整わないと次が動きません。

復旧順が決まっていないと、次の失敗が起きます。

• 先に戻したい業務システムが、認証基盤未復旧で動かない
• 優先度の低いデータを戻して回線・ストレージを圧迫し、肝心の復旧が遅れる
• 何度も手戻りが発生し、復旧の見通しが立たない

さらに「復旧の合格基準」がないと、戻した後の確認で時間が消えます。

• どの画面が表示されたら復旧完了か
• どの帳票が出れば業務再開とみなすか
• 誰が最終確認するか

この基準は、平時に決めておくほど効果があります。

一歩進めるなら「段階復旧」の考え方も有効です。完璧に戻す前に、最低限の機能で一部業務を回す（受付だけ、照会だけなど）。この発想を持つと、復旧の目標が現実的になります。

表で整理：見落としがちな費用（代替環境／外部支援／残業／逸失利益）

復旧コストは「機器代」だけではありません。見落とされがちな費用を整理すると、経営判断が速くなります。

バックアップがあっても、復旧の“体力”が足りなければ事業は止まり続けます。復旧に必要な「人」「時間」「判断」のリソースまで含めて備えるのが、実務としてのランサム対策です。

ここでのコツは、費用を「緊急費」と「改善費」に分けて考えることです。緊急時に必要な支出（外部支援、代替環境）を見積もれると、意思決定が速くなります。

バックアップを“使える状態”にする守りの鉄則（設計・保護のチェックリスト）

バックアップ対策の核心は「攻撃者が届かない」「消されない」「戻せる」を同時に満たすことです。ここでは、設計・保護に絞って、現場で点検できる形に落とします。

重要なのは、“対策を増やす”より“弱点を減らす”発想です。バックアップの強化は、派手なツール導入よりも、権限・接続・保持の基本設計で差がつきます。言い換えると、

• 触れない（到達できない）
• 消せない（保持が崩れない）
• 戻せる（復元が回る）

の3点が揃った時に初めて「使えるバックアップ」になります。

3-2-1＋オフライン／イミュータブル（改ざん耐性）の要点

基本は3-2-1です。

• 3：コピーを3つ持つ（本番＋バックアップ2系統）
• 2：異なる媒体に保存する（同一機器・同一方式に偏らない）
• 1：オフサイト（別拠点・別アカウント・別環境）を1つ持つ

ここに「オフライン」または「イミュータブル（一定期間変更・削除できない）」を組み合わせます。攻撃者が管理者権限を得ても、最後の1つが触れない設計が生命線です。

現場での判断としては、次の問いが有効です。

• ドメイン管理者を奪われても、最後のバックアップを消せないか
• “保持期間中は削除できない”ルールが技術的に担保されているか
• オフサイトは同一アカウント／同一資格情報で操作できないか

さらに「戻す先（復旧先）」も考えます。バックアップがあっても、復旧先の基盤が壊れていると戻せません。復旧先の候補（別クラウド、別基盤、最小構成）を用意できると、復旧の現実味が上がります。

権限分離（本番と同じ管理者で触らない）とアクセス最小化

バックアップ環境は“本番の延長”にしないのが鉄則です。

• バックアップ専用の管理アカウントを用意する
• 本番管理者がバックアップの削除・設定変更をできないようにする
• バックアップ先へのアクセスは必要最小限、可能ならバックアップ時のみ
• 重要操作（削除・世代変更）は承認を要する運用にする

さらに「緊急時だけ使う権限（ブレークグラス）」を分けておくと、平時の漏えいリスクを下げられます。

「誰でも触れる便利さ」は、攻撃者にとっての“復旧阻止ボタン”になり得ます。

現場でよくあるのが「運用都合で権限が広がる」問題です。便利さと安全性はトレードオフになりやすいので、

• 平時は触れない
• 作業時だけ触れる
• 触ったら戻す

を運用ルールとして定着させるのが効果的です。

世代管理・保管期間・“消されない”設定（削除保護）の勘所

世代管理は「何日前まで戻れるか」を決めるだけでは不十分です。攻撃者は設定変更で世代を短縮し、古い世代を消しにきます。

• 世代の最短確保日数（例：30日・90日など）を明確化
• 世代設定の変更権限を限定
• 削除保護や保持ロックなど、消せない仕組みを活用

また、世代の設計は「気づくまでの遅れ」とセットで考えます。侵入が先行し、数日〜数週間後に暗号化されるケースでは、短い世代だと健全な復旧点が残りません。

「復旧したい時に、戻れる世代が残っている」ことが目的です。

一歩踏み込むなら、重要データは「週次・月次で長期保管」を組み合わせます。日次は短く、週次は長く、月次はさらに長く——このように段階設計すると、コストを抑えつつ“健全な復旧点”を残せます。

監視（失敗通知）と定期点検（成功率・容量・異常増加）

バックアップは“失敗していても気づきにくい”のが厄介です。

• 失敗通知が確実に届く（メールだけに頼らず複数経路）
• 成功率、バックアップ時間、対象容量の推移を定点観測
• 容量が急増したら要注意（暗号化でファイルが増えるケースもある）

加えて、通知が届くとしても「誰が見るか」「見た後に何をするか」が決まっていないと、失敗が放置されがちです。

• 通知の受信者（当番）を決める
• 失敗時の一次対応（再実行／原因調査／エスカレーション）を決める
• 月次で“成功率のレポート”を簡単に回す

「取っているつもり」を「取れている」に変えるのが監視です。

さらに、監視はバックアップだけでなく「削除・設定変更」も対象にできると強いです。世代の短縮や保持設定の変更があったら通知する——この仕組みは、攻撃だけでなく人的ミスにも効きます。

表で自己点検：チェック項目（導入状況／不足／次の一手）

現状把握のために、まずは簡易チェックで穴を見つけます。表の「×」から埋めるだけでも、復旧できる確率は大きく上がります。

表の「×」から埋めるだけでも、復旧できる確率は大きく上がります。現状が「△」の項目は、“次の一手が1つに決まる”ように具体化しておくと改善が進みます。

ここにもう一列足すなら「担当（オーナー）」です。誰が改善をやるかが決まると、机上で終わりにくくなります。

復旧を成功させる「回復プロセス」設計（手順・訓練・判断基準）

バックアップを守っても、復旧手順が回らなければ意味がありません。復旧は“作業”ではなく“プロセス”です。誰が、どの順で、どの基準で判断し、何を復旧するのかを、最低限の形にしておくことが重要です。

特にランサム対応は「情報が増えるほど判断が変わる」ため、固定の正解はありません。だからこそ、判断を支える“型”（優先順位・連絡網・復旧基準）を持っておくと、混乱を減らせます。復旧は“技術力”だけでなく、“段取り”で差がつきます。

最低限の復旧計画（優先順位／代替手段／関係者／連絡網）

最低限、次を紙1枚に落とします。

• 優先順位：最初に戻す業務、次に戻す業務、後回しにするもの
• 代替手段：手作業運用、別システム、外部サービスなどの代替
• 関係者：判断者（経営）、復旧責任者、連絡担当、外部窓口
• 連絡網：夜間・休日でも連絡がつく経路

ここに「復旧の合格基準」も添えると、現場の迷いが減ります。

• どの状態になったら“業務再開”とするか
• どの帳票・処理が回れば最低限の継続が可能か

「誰が決めるか」を決めるだけで、復旧の速度は段違いになります。

一歩進めるなら「意思決定の頻度」を決めます。状況報告のタイミング、判断の更新タイミング（例：3時間ごと、半日ごと）を設けると、情報が錯綜しにくくなります。

復元テストのやり方（粒度：ファイル／VM／DB、頻度、所要時間測定）

復元テストは“やった気”になりやすい領域です。重要なのは、復元できたかではなく「どれくらいの時間で、どれくらいの手間で戻せたか」です。

• 粒度を決める：ファイル復元、仮想マシン（VM）復元、データベース復元
• 頻度を決める：四半期／半年など、継続できる周期にする
• 所要時間を測る：復元に何時間かかるかを実測し、RTOと照合する

さらに、テストの質を上げるなら「依存関係まで含める」のがコツです。

• DBを戻したらアプリは動くか
• 認証と権限が復旧後に整合するか
• 復旧手順が特定の担当者に依存していないか

測って初めて、バックアップは“計画”になります。

ここでの実務ポイントは「テストの成果物」を残すことです。復元にかかった時間、詰まったポイント、必要だった権限や手順。これが溜まると、復旧計画が現実に近づきます。

再感染を防ぐ再構築（クリーンな環境に戻す考え方）

復旧で最も避けたいのは「戻した直後に再感染する」ことです。感染端末や侵入経路が残ったままだと、復旧が無限ループになります。

• まず隔離：感染疑いの端末・サーバをネットワークから切り離す
• クリーンな基盤：認証や管理系は安全な環境で再構築する
• 復旧は“清潔な場所”へ：汚染の疑いがある環境に戻さない

加えて、復旧後の“監視の再開”もプロセスに含めます。

• 管理者アカウントの棚卸しと強制パスワード変更
• MFAの強制、不要アカウントの無効化
• 侵入経路の封鎖が確認できるまで、段階的に復旧する

復旧は「元に戻す」ではなく「安全な状態に戻す」作業です。

現場で効くのは「復旧より先に塞ぐもの」を決めることです。たとえば、外部公開の入口、VPN、管理者権限の付与経路など。入口を塞がずに復旧を進めると、復旧が早いほど再侵入のチャンスを増やします。

ケース別：よくある失敗と、今すぐ直す1手（表で早見）

状況別に、ありがちな誤解と改善の一手をまとめます。自社に近いものから手を付けるのが効果的です。ここは“読み物”というより“行動の入口”として使えるように、あえて短く整理します。

NASに全部置いている／クラウド同期＝バックアップだと思っている

「同期」は利便性の仕組みであり、「復旧」は別の目的です。復旧の目的があるなら、保持期間・削除保護・権限分離まで含めて設計します。

「同期」は利便性の仕組みであり、「復旧」は別の目的です。復旧の目的があるなら、保持期間・削除保護・権限分離まで含めて設計します。

ここでの着眼点は「同じ場所に戻る設計になっていないか」です。同期は“同じ場所に反映する”仕組みなので、暗号化がそのまま追随することがあります。復旧は“別の安全な場所から戻す”発想が必要です。

成功通知だけ見て安心（復元未検証）

通知が来ていても、復元に必要な権限・媒体・手順が揃っていないと“実戦で使えない”ことがあります。小さくても復元の習慣があると、穴が早期に見つかります。

通知が来ていても、復元に必要な権限・媒体・手順が揃っていないと“実戦で使えない”ことがあります。小さくても復元の習慣があると、穴が早期に見つかります。

復元テストのコツは「結果をメモする」ことです。戻せた／戻せないだけでなく、どこで詰まったか（権限不足、容量不足、手順不明）を残すと改善につながります。

退職者アカウント放置・共有ID運用

“入口を減らす”だけでも、被害の確率は大きく下がります。バックアップ強化と並行して、認証周りの基本整備は最優先の土台です。

“入口を減らす”だけでも、被害の確率は大きく下がります。バックアップ強化と並行して、認証周りの基本整備は最優先の土台です。

ここは短期で効果が出やすい領域です。棚卸しを月次で回す、退職・異動の手続きにアカウント停止を組み込むなど、運用に埋め込むと戻りにくくなります。

FAQ：現場が迷うポイントを短く回収

最後に、現場で判断に迷いがちな点を短く整理します。ここでの目的は“方向性を定める”ことで、細部は自社の要件に合わせて設計します。

クラウドのスナップショットは安全？

スナップショットは有効ですが、「管理権限を奪われたら削除される」可能性がある点は同じです。安全性は“どの権限で削除できるか”“保持ロックなどの保護があるか”で決まります。クラウド側の保護機能と権限設計まで含めてバックアップと捉える必要があります。

また、クラウドでは「アカウント侵害」が最大のリスクになりがちです。管理者権限の保護（MFA、条件付きアクセス、権限の最小化）とセットで考えると、スナップショットの価値が上がります。

迷ったら「削除できる人が誰か」を確認します。削除できる人が多いほど、攻撃にもミスにも弱くなります。

バックアップの保管期間はどれくらい？

一概に正解はありませんが、「気づくまでの遅れ」を考慮します。侵入から暗号化までに時間がある攻撃もあり、短すぎる保管期間だと“健全な世代”が残りません。最低限、運用上現実的に確保できる期間を決め、重要システムは長めに確保するのが基本です。

迷ったら、

• 重要業務：長め（健全な復旧点が残ることを優先）
• 周辺データ：短めでもよい（容量・コストとのバランス）

のように“重要度で分ける”と設計しやすくなります。

さらに、保管期間は「復旧テストの結果」で見直します。テストでRTOが満たせないなら、保管期間より先に復旧方法（粒度や優先順位）の再設計が必要になることもあります。

どこまでをバックアップ対象にすべき？

対象は「復旧に必要なもの」から逆算します。データだけでなく、設定・構成情報（ネットワーク、認証、アプリ設定、ライセンス情報）も復旧に不可欠です。優先順位（最初に戻す業務）に紐づけて、対象と粒度を決めます。

現場では「データはあるのに動かない」が起きがちなので、復旧に必要な“周辺情報”を漏らさないのがコツです。

ここは“棚卸し”が有効です。復旧に必要な情報（設定ファイル、構成図、証明書、管理画面のURL、連絡先）を一覧化しておくと、復旧時の迷いが減ります。

まとめ：バックアップは「保険」ではなく「回復プロセス」の一部

バックアップは重要ですが、それだけで守れる時代ではありません。攻撃者はバックアップを壊し、情報漏えい（暴露）で追い込み、復旧を妨害してきます。

• バックアップが巻き込まれない設計（オフライン／イミュータブル、権限分離）
• 戻せることを証明する運用（監視、世代管理、復元テスト）
• 復旧を回すためのプロセス（優先順位、連絡網、再感染防止の再構築）

この3点が揃って初めて、バックアップは“保険”ではなく“回復プロセスの一部”として機能します。まずは自社のバックアップ経路を可視化し、消されない最後の1つと、復元テストの習慣から始めてください。小さな改善でも、積み重なるほど「最悪のシナリオ」から遠ざかれます。

最後に、今日できる最小アクションを3つ挙げます。

• バックアップの保存先と権限を図にする（どこに・誰が・どう接続）
• 削除できない最後の1つ（オフライン／イミュータブル）を確保する
• 重要データを1つ選び、サンプル復元して所要時間を測る

この3つだけでも、「バックアップがあるから安心」を「バックアップが機能するから回復できる」に近づけられます。