データ復旧の情報工学研究所

　
株式会社情報工学研究所
お申し込みフォーム
お問合わせフォーム

ランサムウェア時代の「取るべきバックアップ」と「捨てるべきバックアップ」

もくじ

【注意】 ランサムウェア被害が疑われる場合、自己判断で「復旧」や「修理」を進めると、暗号化の拡大・証拠の消失・復旧率の低下につながることがあります。まずは被害拡大の歯止めと安全な初動を優先し、個別状況に応じて株式会社情報工学研究所のような専門事業者への相談をご検討ください。

　

第1章：バックアップはあるのに詰む夜──ランサムは“データ”より先に「書き込み権限」を奪う

「バックアップは取ってます」──それでもランサムウェアの夜に詰むのは珍しくありません。理由は単純で、攻撃者が狙うのは“本番データ”だけではなく、復旧に必要なもの（バックアップ、管理権限、保管先、運用手順）そのものだからです。暗号化は最後の一撃で、その前に“復元できない状態”が静かに作られていきます。

心の会話：
「暗号化されたら復元すればいい、って話じゃなかったっけ？」
──現場の感覚としては当然です。けれど、ランサムウェアは“障害”ではなく“攻撃”なので、障害対応の常識（再起動、切り戻し、手元の管理者権限で復旧）が通用しない局面が増えています。

冒頭30秒でやるべきこと（安全な初動ガイド）

ここでのポイントは「復旧の手を動かす前に、被害最小化と証拠保全を優先する」ことです。環境によって最適解は変わるため、まずは“やってよい安全行動”に絞ります。

症状（見えている事実） 取るべき行動（安全側） 避けるべき行動（事故りやすい）
ファイル拡張子が急に変わる／開けない 対象端末をネットワークから隔離（有線抜線・無線OFF・VLAN隔離）。暗号化の拡大を止める。 むやみに再起動／復号ツール探し／手当たり次第の修復。
多数の共有フォルダが同時に壊れる 共有の書き込み権限を一時停止。該当アカウントの認証を止める（ロック・無効化）。 権限を戻しながら様子見／共有を増やす／別サーバへ同期。
バックアップ先が見えない／削除された形跡 バックアップ保管先のアクセス権を即時見直し（読み取り専用化・隔離）。保管先の監査ログを確保。 「残ってそうな世代」を探して上書き復元を始める。
身代金メモが出た／脅迫文がある 画面・ファイルの状態を記録（スクリーンショット、タイムスタンプ、対象範囲）。関係者連絡を一本化。 犯人と独断で交渉／指示に従ってデータ送付。
ログが消えている／イベントが途切れる 可能ならディスクイメージ／スナップショットで状態保全。ログ転送先（SIEM等）があれば確保。 ログ設定の再構成を先に実施（証拠の上書きになり得る）。

上の表は「自分で直す」ための手順ではありません。目的は、被害を広げない／後で説明できる状態を残すことです。特にBtoBの現場では、復旧の成否だけでなく「いつ何が起き、何を判断して何を実施したか」を説明できるかが、後工程（取引先説明、監査、再発防止）に直結します。

なぜバックアップが“効かない”状況が起きるのか

典型は次の順序です。攻撃者は侵入後、権限を上げ、バックアップやスナップショット、同期先、管理ツールを探索します。そして「復旧に必要な経路」を壊してから暗号化を走らせます。つまり、暗号化が始まった時点で、すでに“復元できない下地”ができていることがあるのです。

  • 管理者権限の奪取（AD/ローカル管理者/特権ID）
  • バックアップ製品や保管先の探索（設定ファイル、管理コンソール、共有フォルダ）
  • 世代削除・スナップショット破壊・バックアップジョブの無効化
  • 最後に暗号化（本番＋共有＋バックアップ周辺）

ここで大事なのは、「バックアップを増やす」より先に、「バックアップが攻撃者に触れられる設計か」を疑うことです。本記事は、取るべきバックアップ（復元できる設計）と、捨てるべきバックアップ（安心感だけが残る設計）を分けていきます。

　

第2章：まず脅威モデルを固定する──暗号化より怖い「削除・改ざん・保管先乗っ取り」

ランサムウェア対策のバックアップ設計は、最初に“敵のやり口”を固定しないとブレます。暗号化だけを想定すると、復元可能な場所が残っている前提に寄ってしまいます。しかし現実には、暗号化は脅迫の見せ場で、その前後に削除・改ざん・流出（恐喝材料）が絡むことがあります。

最低限、想定に入れる3つの攻撃ゴール

  • 暗号化：稼働停止・業務停止を起こす
  • 削除／破壊：復旧手段（バックアップ、スナップショット、構成情報）を消す
  • 流出／恐喝：情報公開を材料に二重・三重の圧力をかける

「うちは個人情報を扱ってないから大丈夫」も危険です。取引先情報、契約書、設計資料、ソースコード、鍵、運用手順書──BtoBで“困るもの”は個人情報だけではありません。バックアップに含まれる範囲が広いほど、流出時の影響も広がります。

依頼判断の考え方：一般論が効かないポイント

バックアップは環境依存が強く、一般論だけで「これが正解」と言い切るのが難しい領域です。なぜなら、同じ3-2-1でも、権限分離・ネットワーク分離・保管先の仕様・監査の有無で“強度”が別物になるからです。

今すぐ相談を検討すべき条件 理由（一般論の限界点）
共有ストレージやNASまで同時に暗号化が進んでいる 影響範囲が広く、切り分け・隔離・復元順の設計を誤ると被害が拡大しやすい。
バックアップ先の世代が消えている／管理コンソールに不審な操作履歴がある 攻撃者が復旧手段を潰している可能性があり、保全・監査・復元戦略が必要になる。
ログが途切れている／EDRが停止している／管理者権限が奪われた疑い 証拠保全が難しく、後で説明不能になりやすい。再発防止も形骸化しやすい。
重要システムが止められない（医療・介護・基幹・生産など） 復旧の順序と“止めない設計”が絡む。復旧手順がシステム要件そのものになる。

相談導線（押し売りではなく、判断のための窓口として）：
問い合わせフォーム：https://jouhou.main.jp/?page_id=26983
電話：0120-838-831

「取るべきバックアップ」を定義する前に、守る対象を棚卸しする

エンジニアが腹落ちしやすい切り口は、「何を復元できれば“事業が戻る”のか」をコンポーネントで分解することです。データだけでは足りません。

  • データ：DB、ファイル、オブジェクト、添付、ログ（必要な範囲は業務次第）
  • 構成：IaC、設定ファイル、K8sマニフェスト、CI/CD、DNS、LB、証明書
  • 認証：AD/IdP設定、MFA、秘密鍵、トークン、サービスアカウント
  • 運用：復元手順、連絡網、判断基準、監査ログ、変更履歴

この棚卸しをして初めて、「取るべきバックアップ」は“量”ではなく“復元可能性”で語れるようになります。

　

第3章：捨てる① 同一ドメイン直結バックアップ──同じ鍵束で守る設計ミス

まず捨てたいのは、「本番と同じ認証基盤・同じ権限体系で触れるバックアップ」です。これは“バックアップを取っている”という事実があっても、攻撃者目線では本番と同じドアに見えます。

心の会話：
「バックアップ用の共有フォルダ、専用サーバに置いてるし大丈夫じゃないの？」
──置き場所だけ分けても、触れる権限が同じなら、攻撃者は同じ鍵で入れます。特権IDが奪われた時点で、バックアップも“改ざん可能なデータ”に落ちます。

同一境界バックアップが弱くなる典型パターン

  • バックアップ保管先がドメイン参加している／同一IdPでSSOできる
  • バックアップ運用が「普段使いの管理者端末」から実行できる
  • 保管先がSMB/NFSで書き込み可能（暗号化プロセスの到達範囲に入る）
  • バックアップソフトの管理コンソールが同一ネットワーク上にあり、同じ権限で操作できる

“分離”はネットワークだけでは足りない（ID・端末・運用の三点セット）

バックアップ強度を上げるとき、分離は3層で考えるのが実務的です。

分離の種類 狙い 最低ラインの実装イメージ
ID分離 奪われた特権IDでバックアップを消せないようにする バックアップ専用アカウント／別MFA／別ロール／最小権限
端末分離 普段使い端末の侵害からバックアップ操作を守る 管理用PAW（特権作業端末）／用途限定／メール閲覧しない
経路分離 暗号化プロセスが到達できる範囲を狭める バックアップネットワーク分離／ファイアウォールで最小ポート

「面倒が増える」と感じるのは自然です。ただ、ここは運用コストとリスクのトレードオフではなく、“バックアップをバックアップとして成立させるための条件”です。侵害前提の時代は、分離がないバックアップは“いつでも攻撃者に書き換えられるストレージ”になり得ます。

捨てる基準：復旧のときに「同じ権限で触れる」なら危ない

判断はシンプルです。侵害が起きたと仮定して、攻撃者が奪ったであろう権限と同じ権限でバックアップを削除できるなら、そのバックアップは“捨てるべき設計”です。保管先が増えていても、構造が同じなら同時に倒れます。

　

第4章：捨てる② “成功ログだけ”のバックアップ──復元テスト未実施は未完成品

バックアップ運用で最も多い落とし穴が、「ジョブが成功しているから安心」という思い込みです。ランサムウェア時代は、復元できるかどうかが全てです。復元テストをしていないバックアップは、仕様が未確定のまま本番投入されたプロダクトと同じ状態になります。

なぜ“成功”しているのに復元できないのか

  • 対象範囲がズレていた（DBは取れているが鍵や設定がない／逆もある）
  • 整合性が崩れていた（アプリ整合性・トランザクション・依存関係）
  • 復元手順が属人化していた（担当者しか手順を知らない／手順が古い）
  • 復元先の容量・権限・ネットワーク要件が満たせない（いざという時に詰む）
  • 攻撃者により世代が“静かに”破壊されていた（気づいた時には遅い）

エンジニア向けの腹落ちポイント：「復元SLO」を持つ

“RPO/RTO”はよく聞きますが、運用に落ちない理由は、測れていないからです。おすすめはバックアップを「保険」ではなく「復元プロダクト」と見て、復元SLO（Service Level Objective）として置くことです。たとえば以下のように、実測できる形にします。

指標 例 意味
復元成功率 月1回のサンプル復元で 99% 以上 「成功ログ」ではなく「復元の成功」を見る
復元所要時間 重要DBは 4時間以内に読み取り可能 “戻るまでの時間”を運用で担保する
手順の再現性 担当外でも手順書だけで復元できる 属人化が最大のボトルネックになるのを防ぐ

この指標があると、投資判断も現場の説明も一気に楽になります。「バックアップ容量を増やしました」ではなく、「復元SLOを達成できる状態にしました」と言えるからです。

最低限の復元テスト設計（やり過ぎず、でも逃げない）

  1. 対象を絞る：最重要の1系統（例：顧客DB＋設定＋鍵）から始める
  2. 隔離環境で実施：本番ネットワークに戻さず、検証用に復元して動作確認
  3. チェック項目を固定：起動、認証、主要API、データ整合性（サンプル）
  4. ログを残す：実施日時、所要時間、詰まった点、改善点
  5. 手順を更新：詰まったところを“次の人が詰まらない形”に直す

復元テストは、危機のときのためだけではありません。平時にやっておくことで、構成の負債（鍵の所在、設定の属人化、依存関係のブラックボックス）が表に出ます。これはランサムウェア以前に、システム運用の健全性そのものを上げます。

　

第5章：捨てる③ スナップショット信仰──世代・保持・隔離がないと巻き添えで消える

スナップショットは強力です。けれど、ランサムウェア時代に「スナップショットがあるから大丈夫」は危険です。スナップショットは多くの場合、同一ストレージ／同一権限／同一管理面の中に存在します。つまり、攻撃者が管理権限に到達した場合、“巻き添え”になる可能性があります。

スナップショットとバックアップの違い（誤解が起きやすい点）

観点 スナップショット バックアップ（理想形）
主目的 高速な巻き戻し（近い過去） 長期保管と復元（災害・攻撃を含む）
隔離 同一管理面になりがち 別境界・別権限・改ざん耐性を持たせられる
耐攻撃性 管理権限が奪われると弱いことがある イミュータブル／WORM等で“消せない”を作りやすい

スナップショットは「復元の第一手」として優秀ですが、それ単体では“最終防衛線”になりません。ここを混同すると、実際の被害時に「スナップショットが消えている」「世代が浅い」「戻したら再暗号化した」などの詰まり方をします。

捨てる基準：スナップショットが“攻撃者の到達範囲”にある

チェックポイントは次の通りです。

  • 管理コンソールが侵害されたら、スナップショット削除が可能か
  • 同一権限（同一IdP/同一特権ID）で操作できるか
  • 世代保持が短く、発見が遅れたら戻せない設計になっていないか
  • “戻す”操作が本番を直接書き換えるため、検証なしで反映してしまう運用になっていないか

現実解：スナップショットは前段、最終は「消せない保管」

スナップショットを捨てるのではなく、役割を正しく置きます。

  • 前段（高速復旧）：スナップショットで短期の巻き戻し
  • 後段（最終防衛）：別境界のバックアップ＋改ざん耐性（消せない・書けない）

この二段構えにすると、「現場の復旧スピード」と「攻撃に対する強度」を両立しやすくなります。次章以降で、“取るべきバックアップ”として、改ざん耐性と隔離をどう作るかに踏み込みます。

　

第6章：取る① 3-2-1を“権限分離”まで拡張する──別ID・別境界・別監査

3-2-1は、バックアップの基本原則として広く使われています。一般に「データを3つ持つ（本番＋コピー2つ）」「媒体を2種類に分ける」「うち1つはオフサイトに置く」という考え方です。ここまでは“災害”や“障害”への強さを上げますが、ランサムウェア時代はここにもう1段、設計条件を足す必要があります。攻撃者が奪った権限で触れないことです。

心の会話：
「3-2-1は満たしてる。クラウドにも置いてる。なのに不安って何？」
──不安の正体は、コピーの“置き場所”ではなく、コピーに到達する“鍵”です。本番の管理者権限が奪われたら、同じ鍵でバックアップが消える・暗号化される・世代が破壊される。これが起きる限り、3-2-1は形式上の条件でしかありません。

拡張版3-2-1（ランサムウェア前提）の設計チェック

次の3点を同時に満たすと、「置いてある」から「復元できる」に寄ります。

  • 別ID：バックアップ保管先に“本番の特権ID”でログインできない
  • 別境界：本番ネットワークから直接到達できない、または到達面が最小化されている
  • 別監査：削除・保持変更・ロック解除などの操作が監査ログとして残り、改ざんされにくい

よくある「分離したつもり」の失敗例

やりがち 何が問題か 改善の方向
バックアップ先を別サーバにした 同じドメイン参加・同じ管理者権限で触れると“同じ鍵束”になる バックアップ専用ID／別MFA／別ロール／特権分離
クラウドに置いた 本番と同一テナント・同一IAMで操作できると削除や保持変更が可能 別アカウント／クロスアカウントレプリケーション／削除防止
スナップショットで戻せる 管理面が侵害されると世代ごと破壊される可能性がある スナップショットは前段、後段に改ざん耐性保管を持つ

実装イメージ：権限分離を“運用”まで落とす

「別ID」はアカウントを分けるだけでは足りません。運用で“境界を越えにくい形”にするのがポイントです。

  • バックアップ専用アカウント：本番の管理者とは別のID体系。可能なら別のID基盤や別テナント。
  • 最小権限：書き込みはバックアップジョブだけ、読み出し（復元）は別ロール・別承認。
  • 特権作業端末（PAW）：バックアップの設定変更・ロック解除は用途限定端末からのみ。
  • 二人承認・時間制限：保持期間変更や削除許可は、申請→承認→短時間だけ有効などにする。

こうした設計は「手間を増やす」ためではなく、攻撃者の横移動の歯止めをつくるためです。侵害は起き得る前提で、侵害後も“最後に残る道具”を守る。これが、取るべきバックアップの最初の条件になります。

設計のゴール：復元の道筋を“残す”

ランサムウェア対応で詰みやすいのは、「データはあるのに、戻す権限・戻す経路・戻す手順が消えている」ケースです。拡張版3-2-1は、その詰みを減らします。次章では、この考え方をさらに強くするための“消せない保管”に進みます。

　

第7章：取る② イミュータブル／オブジェクトロック──「消せない保存」を設計に入れる

ランサムウェア時代に「取るべきバックアップ」の中核は、改ざん耐性です。改ざん耐性の代表が、イミュータブル（不変）やWORM（Write Once Read Many）に近い性質を持つ保管です。ポイントは、削除・上書き・世代破壊を“権限があっても”できない／しにくい状態を作ることです。

心の会話：
「結局、強い権限があったら消されるんじゃないの？」
──ここで狙うのは、“強い権限”を奪われても一撃で消えない構造です。保持期間（retention）やロックを使い、削除の難度と痕跡性を上げます。攻撃者は時間がかかる作業を嫌いますし、管理面での破壊行為は監査痕跡を残しやすくなります。

イミュータブル保管で守りたい3つの要素

  • データ本体：バックアップデータ（フル／増分／差分）
  • メタ情報：世代管理、インデックス、カタログ、復元点の情報
  • 鍵・構成：復元に必要な鍵や設定（暗号化バックアップなら特に重要）

本体だけ不変でも、カタログが壊れれば探せません。鍵がなければ復号できません。ここを分けて保護する発想が、復元可能性を上げます。

運用設計：保持期間を「発見遅延」に合わせる

ランサムウェアは、侵入から暗号化まで時間差がある場合があります。また、暗号化が始まっても“気づくまで”に時間がかかることがあります。保持期間（何日分を消せない状態で残すか）は、ここに合わせます。

設計観点 考え方 実務の要点
発見遅延 「侵入〜発見」までを見込む EDR/SIEMの検知・休日・夜間対応の遅れも含めて考える
復元ウィンドウ 戻せる世代の幅を残す 短すぎると“気づいた時点で戻れない”
コスト 保持と容量のバランス 重要データだけ保持を厚くし、全部を同じ強度にしない

落とし穴：保持変更・ロック解除が“同じ管理者”でできる

イミュータブルを採用しても、保持期間の短縮やロック解除を、日常の管理者が即時にできる設計だと弱くなります。ここでも第6章の“権限分離”が効きます。

  • 保持期間の変更は別ロール・別MFA・別承認にする
  • 緊急時の解除手順は作るが、普段は触れないようにする（アクセス経路を限定）
  • 解除の実行は監査ログとセットにし、後から説明できる状態を担保する

復元の現実：不変でも「戻し方」を誤ると再暗号化する

不変保管は“最後の砦”になり得ますが、復元の手順が雑だと再び被害を広げます。たとえば、侵害が残った環境にそのまま戻すと、復元した直後に再暗号化が走ることがあります。復元は、次の順で被害最小化を優先するのが安全側です。

  1. 侵害範囲の切り分け（どこが感染源・侵入口になったか）
  2. 隔離環境で復元検証（復元点が“汚れていない”か）
  3. クリーンな基盤を用意してから復元（OS・認証・ネットワークの再構成を含む）

この手順は、一般論だと “どこまでやるべきか” がブレます。業務停止許容、構成規模、クラウド／オンプレ、法令・契約要件で最適解が変わるため、個別案件では株式会社情報工学研究所のような専門家に相談し、復元の道筋と説明責任まで含めて設計する方が安全です。

　

第8章：取る③ オフライン／エアギャップ──最後の砦は“人の手で切る”運用

オンラインの仕組みをいくら固めても、攻撃者が長時間居座り、権限を奪い続けるケースでは、オンラインで到達できる資産が徐々に削られる可能性があります。そこで意味が出るのが、オフライン／エアギャップです。ここでの狙いは明快で、攻撃者が到達できない時間帯・到達できない形を作ることです。

心の会話：
「オフラインって、古い運用に戻る感じで嫌だな…」
──気持ちは分かります。ただ、オフラインは“過去に戻る”のではなく、オンラインの弱点（到達可能性）を補うための層です。全てをオフラインにする必要はなく、重要データの最終世代だけでも残す価値があります。

オフラインの選択肢（どれが正解かは要件次第）

方式 強み 注意点
テープ保管 物理的に切れる／長期保管に向く 復元時間、運用手順、保管・搬送の管理が必要
取り外し可能ストレージ 導入しやすい／特定データの最終世代に使える 紛失対策、暗号化、ラベル・台帳・持ち出し管理が必須
オフライン保管用サーバ（短時間のみ接続） 自動化しやすい／接続時間を最小化できる 接続時に到達されるリスク、運用ミスで常時接続になる危険

運用の肝：ローテーションと台帳（チェーン・オブ・カストディに近い発想）

オフラインは「置いたら安心」ではなく、「いつ、何を、どこに、誰が、どういう手順で」を残して初めて強度になります。BtoBでは、復元の可否だけでなく説明責任が重要です。

  • ローテーション：週次・月次などで世代を回し、最新だけに偏らせない
  • 台帳：保管媒体ID、作成日時、対象範囲、ハッシュ（可能なら）、保管場所、担当者
  • 暗号化：媒体紛失を想定し、鍵管理とセットで設計する
  • 復元訓練：オフラインから実際に戻せるか、年に数回でも確認する

よくある事故：オフラインが“形だけ”になっている

次の状態は、オフラインの強みを失います。

  • 取り外し媒体が常に接続されたまま（到達可能資産になっている）
  • 保管場所が固定で、災害・盗難・内部不正の想定が薄い
  • 台帳がなく、どの世代がどこにあるか分からない（いざという時に探す時間が発生）
  • 暗号化鍵が本番と同じ場所・同じ権限で管理されている

オフラインは、最後の砦としての価値が高い一方、運用の雑さがそのまま弱点になります。ここも一般論だけでは詰まりやすく、重要システム・重要データほど、業務要件（RTO/RPO）と整合する形で設計する必要があります。個別案件で悩む場合は、株式会社情報工学研究所のような専門家に相談し、「どこまでをオフラインにし、どの頻度で、どの粒度で戻すか」を決めるのが現実的です。

　

第9章：取る④ 復旧を自動化する──IaCと手順のコード化でRTOを測れる状態にする

バックアップ設計が“復元できる”側に寄っても、復旧が遅ければ事業は止まったままです。ランサムウェア対応で現場が苦しくなるのは、復元そのものよりも「どの順番で、どこまで戻し、どこで安全確認を挟むか」が属人化しているときです。復旧を速くする近道は、復旧手順を気合で回すことではなく、手順のコード化と再現性を高めることです。

心の会話：
「結局、非常時は人が頑張るしかないでしょ？」
──非常時に人が動くのは現実です。ただ、動く内容が“判断”と“例外処理”に寄るほど、復旧は遅くなります。定型部分はコードに寄せ、非常時の人間は“判断が必要なところだけ”に集中できる構造にすると、RTOは現実的に縮みます。

復旧のコード化で対象にすべきもの（データ以外が詰まりやすい）

  • 基盤：OSイメージ、ネットワーク、DNS、LB、証明書、鍵配布
  • ミドル：DB初期化、ストレージマウント、キュー、キャッシュ、監視
  • アプリ：デプロイ手順、環境変数、シークレット、スキーマ適用
  • 運用：復旧順序、責任分担、連絡手順、判断条件、記録テンプレ

バックアップがあっても、基盤の立ち上げに時間がかかれば復旧は進みません。ここをIaC（Infrastructure as Code）や構成管理で再現できる形にしておくと、復旧は「思い出す作業」から「手順を実行する作業」に寄ります。

復旧パイプラインの基本形（安全確認を挟む）

ランサムウェア対応では、復元の速さと同じくらい「戻したものが安全か」が重要です。復元後に再暗号化が走れば、復旧が振り出しに戻ります。復旧パイプラインは、次のように“検証の関門”を入れるのが安全側です。

  1. 隔離環境の準備：本番ネットワークから切った検証用の復元先を用意
  2. 復元点の選定：世代の中から候補を絞り、まずはサンプル復元
  3. 整合性チェック：アプリ起動・主要API・DB整合（最小チェックセット）
  4. 侵害痕跡の確認：不審なタスク、永続化、権限設定、管理者追加などの確認
  5. 本番復旧：クリーンな基盤へ移し替える形で復旧

RTOを測れる状態にする（“戻るまで”を実測する）

復旧の速さは、設計と運用の両方に依存します。ここを改善するには、定期的に「どれくらいで戻れるか」を実測するのが一番確実です。大規模な訓練が難しければ、重要システムを絞って小さく回します。

測る対象 やること 得られるもの
復元時間 隔離環境へ復元し、起動確認までの所要時間を記録 RTOの現実値、ボトルネックの可視化
手順の再現性 担当外の人でも手順書で復元できるか検証 属人化の発見、手順改善の材料
判断の迷い 復元点選定・切替条件・連絡手順で迷った箇所をメモ 判断基準の整備、運用テンプレ化

個別案件で詰まりやすい論点（一般論の限界が出る場所）

復旧自動化は有効ですが、環境によって“危険な近道”にもなります。たとえば、認証基盤が侵害されている可能性があるのに、同じ権限体系で復旧パイプラインを回すと、復旧が速いぶん再侵害も速くなります。クラウド／オンプレ混在、業務停止許容、委託先の責任分界、法令・契約要件などが絡むと、どこまで自動化し、どこで人の承認を挟むかは一律に決められません。

こうした具体的な案件・契約・システム構成で悩む段階では、株式会社情報工学研究所のような専門家に相談し、復旧の道筋（技術）と説明責任（運用）をセットで設計する方が、安全とスピードの両方を取りやすくなります。

　

第10章：帰結：バックアップは保険ではなくプロダクト──「復元SLO」で設計し、捨てるべきものを捨てる

ランサムウェア時代の帰結はシンプルです。バックアップは“取っているか”ではなく、“攻撃後に復元できるか”で評価されます。そして復元できるかどうかは、世代や容量の多さよりも、権限分離・改ざん耐性・隔離・復元テスト・復旧手順の再現性で決まります。これらが揃って初めて、バックアップはプロダクトとして成立します。

取る／捨てるの最終チェック（判断に迷ったらここに戻る）

ここまでの内容を、最終的に“判断できる形”に落とします。

観点 取るべき設計の方向 捨てるべき兆候
権限 バックアップは別ID・別MFA・別ロールで操作 本番の管理者権限で世代削除・保持変更が可能
改ざん耐性 不変保管、保持期間、削除防止、監査ログ 世代が短い／削除が容易／ログが残らない
隔離 到達面を最小化、必要ならオフライン層 常時接続、共有経由で到達可能、管理面が同一
復元性 定期的な復元テスト、復元点の整合性検証 ジョブ成功ログだけで安心、手順が属人化
復旧速度 IaC、手順のコード化、RTOの実測 復旧は“勘”と“記憶”、担当者不在で詰む

なぜ「捨てる」が重要か（バックアップは増やすほど安全、ではない）

バックアップは増やせば増やすほど運用が重くなり、権限・経路・保管先が広がります。つまり、管理面の攻撃対象も増えます。さらに、復旧時の判断（どれを戻すか、どこまで戻すか）も複雑になり、RTOが伸びる要因になります。だからこそ、「弱いバックアップを残して安心しない」ことが重要です。弱いバックアップは、非常時に判断を鈍らせるだけでなく、攻撃者にとっても到達しやすい資産になり得ます。

終盤の現実：一般論だけでは決められない境界がある

バックアップ設計は、技術だけで完結しません。たとえば次のような論点は、個別の事情で最適解が変わります。

  • 業務停止の許容（どこまで止められるか）と復旧順序
  • 委託先・取引先・クラウド事業者との責任分界
  • 監査・法令・契約（保存期間、ログ、説明責任、個人情報・機密の扱い）
  • クラウド／オンプレ／SaaS混在の境界設計
  • 復旧時に“安全確認”をどこまで挟むか（速さと安全のバランス）

この境界に入った時点で、テンプレの正解を探すより、設計の前提（守る資産、脅威モデル、RTO/RPO、権限体系）を揃えて、現実的な落とし所を作る方が早く、事故も減ります。具体的な案件・契約・システム構成で悩むときは、株式会社情報工学研究所のような専門家に相談し、バックアップを“復元できるプロダクト”として成立させる支援を受けることをご検討ください。

次の一歩（相談の使い方）

「今の構成だと何が弱いのか」「どこから直すのが費用対効果が高いのか」「復元テストをどう設計すべきか」──こうした問いは、システムの規模と境界で答えが変わります。自社だけで抱え込むより、第三者視点で脅威モデルと復元計画を点検した方が、結果として移行コストや二度手間を減らせます。

問い合わせフォーム：https://jouhou.main.jp/?page_id=26983
電話：0120-838-831

　

付録：現在のプログラム言語各種でバックアップ／復旧自動化を組むときの注意点

バックアップや復旧の自動化は、実装言語の選択よりも「設計（権限分離・改ざん耐性・監査・再現性）」が重要です。そのうえで、言語ごとにハマりやすい注意点があります。以下は一般的に起きやすいリスクと、実務での対策観点です。

共通の注意点（言語に依存しない）

  • 資格情報の扱い：コードや設定ファイルに平文で置かない。秘密情報は専用の保管方式とローテーションを前提にする。
  • 削除の危険性：世代削除やクリーンアップ処理は最も危険。二重確認、ドライラン、対象範囲の固定、監査ログを必須にする。
  • 暗号化と鍵：暗号化バックアップは鍵が命。鍵の所在・復元手順・権限分離までセットで設計する。
  • 検証の自動化：バックアップ成功ログではなく、復元テスト（最小の起動確認）を自動化の対象にする。
  • 観測性：実行ログ、監査ログ、メトリクス（所要時間・成功率）を残し、改ざんされにくい場所へ送る。

Python

  • 依存関係：仮想環境や依存バージョン差で非常時に動かない事故が起きやすい。requirementsの固定とビルド再現性が重要。
  • エラー処理：例外の握りつぶしは復旧を遅らせる。失敗時に止まる条件とリトライ条件を明確に分ける。
  • 並列実行：並列化で速度は出るが、削除や上書きの誤爆も高速化する。破壊的操作は直列・承認付きに寄せる。

Java / Kotlin（JVM系）

  • 長時間ジョブ：メモリ消費やGCの癖で長時間処理が不安定になることがある。ストリーミング処理とリソース制限を意識する。
  • 例外設計：リトライ可能／不可の区別が曖昧だと、誤った再試行で二次被害が出る。エラー分類を先に設計する。
  • 設定管理：環境差（プロパティ、証明書、プロキシ）が復元時に表面化しやすい。設定の外部化と監査が重要。

JavaScript / Node.js

  • 非同期の落とし穴：await漏れや同時実行で、世代削除やアップロードが順不同になる事故が起きやすい。破壊的操作は順序保証を入れる。
  • 依存供給：依存パッケージの更新で挙動が変わりやすい。ロックファイルと検証環境での復元テストをセットにする。
  • 権限の散り方：CI/CDや実行環境にトークンが散らばりやすい。秘密情報の置き場を統一し、用途別に最小権限へ分割する。

Go

  • 単体バイナリの利点：非常時に実行環境を作りやすい一方、設定・資格情報の外部化が甘いと危険。バイナリに埋め込まない設計が必須。
  • 並行処理：高速だが、同時削除・同時書き込みの誤爆も起きやすい。対象範囲の固定と排他を明確にする。
  • タイムアウト：ネットワークI/Oのタイムアウト設計が弱いと、ジョブが中途半端に止まり復旧点が不明になる。期限と再試行戦略を設計する。

Rust

  • 安全性：メモリ安全は強みだが、I/Oや権限設計のミスは防げない。破壊的操作のガード（承認・二段階）を入れる。
  • ビルド環境：非常時にビルドが必要だと詰みやすい。実行物の配布・署名・検証を運用に含める。
  • エラー表現：詳細なエラー設計が可能な分、分類が不十分だと運用が複雑化する。運用で使う分類に絞る。

C / C++

  • 安全性：性能は出るが、例外処理・境界・入力検証の事故コストが高い。バックアップ運用は安全側の実装が最優先。
  • ライブラリ：暗号・TLS・ストレージ周りの実装ミスは致命的になりやすい。信頼できる実装と設定監査が重要。
  • 運用更新：非常時に再ビルド・再配布が必要な設計は復旧を遅らせる。配布形態とロールバックを決めておく。

C# / .NET

  • Windows連携：イベントログや権限体系と相性が良い一方、AD権限に寄り過ぎるとバックアップも同一境界に入りやすい。権限分離を最優先にする。
  • 証明書：TLS/証明書ストア依存で、環境差が復元時に出やすい。証明書の更新・配布・監査を運用に含める。
  • サービス化：常駐サービスは侵害時に悪用されやすい。実行権限、実行ホスト、ネットワーク到達性を最小化する。

PHP

  • 運用環境依存：実行環境の拡張・設定差が出やすい。バックアップ・復旧の中核ロジックは再現性の高い形にする。
  • Web露出：管理画面やアップローダがあると攻撃面が増える。復旧ツールをWebに露出させる場合は厳格な制御が必須。
  • 権限：ファイル権限が雑だと、バックアップ保管先が“書ける場所”として巻き込まれやすい。読み書きの境界を明確にする。

Ruby

  • 依存管理：Gemの更新で挙動が変わりやすい。ロックと検証、復元テストを運用に組み込む。
  • ジョブ基盤：ジョブ再実行で二重書き込み・二重削除が起きない設計（冪等性）が重要。
  • 例外処理：例外を拾って継続する設計は便利だが、部分失敗が見えなくなる。失敗の可視化が必須。

Shell（bash等）

  • 誤爆：変数未定義・ワイルドカード・パス解釈で破壊的な誤爆が起きやすい。削除は特に危険で、二重防御が必要。
  • エラー検知：コマンドの戻り値が曖昧だと成功判定が壊れる。失敗時即停止とログの整備が必須。
  • 監査：実行履歴が残りにくい。実行ログと監査ログの保存先を別境界に置く。

PowerShell

  • 権限：管理者権限で実行されがちで、同一境界問題を起こしやすい。実行権限を用途別に分ける。
  • リモート実行：便利だが、侵害時に横移動手段にもなる。実行経路の制限と監査が必須。
  • ログ：実行ログの保存と改ざん耐性（転送・保持）をセットにする。

SQL（DB手続き・スクリプト）

  • 整合性：論理バックアップは整合性要件が強い。トランザクション、スナップショット、ロック戦略を理解して設計する。
  • 権限：DB権限が広いと、バックアップ操作自体が攻撃面になる。用途別ロールと監査を徹底する。
  • 復元検証：復元後のスキーマ・権限・拡張の差で詰む。検証環境での復元テストを前提にする。

設計を最終的に固めるポイント

自動化は、速さを生みます。その速さが「安全な復旧」を加速するのか、「再侵害」を加速するのかは、権限分離と復元手順の設計で決まります。具体的な案件・契約・システム構成に合わせて、どこまでを不変にし、どこをオフラインにし、どこをコード化し、どこで承認を挟むかを決める段階では、株式会社情報工学研究所のような専門家に相談し、復旧計画と説明責任まで含めて設計することをご検討ください。

問い合わせフォーム：https://jouhou.main.jp/?page_id=26983
電話：0120-838-831

このページと関連する記事：