ランサムウェア攻撃後、ファイルのバージョンはどのくらいの期間保持すべきですか?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

ランサムウェア攻撃後、少なくとも30~90日間の日次ファイルバージョンを保持することを実用的な開始範囲として維持しますが、それを普遍的な削除期限とは見なさないでください。保持期間は最も早い妥当な侵害日時を超えて延長し、選択された週次または月次のクリーンポイントを保存し、回復、調査、保険、法務、コンプライアンス作業が完了するまでインシデント証拠を別に保管してください。

実用的な開始範囲は30~90日

多くのバックアップ設計は、運用上のランサムウェア回復のために30~90日間の日次不変履歴を使用します。不変バックアップの概要では30~90日がランサムウェア保護の一般的な日次保持範囲であると述べています。これは出発点として扱い、最も古い保持バージョンがクリーンである保証とはしないでください。

環境 日次バージョン範囲の開始 延長すべきタイミング
迅速な検出とオフラインコピーを備えた家庭用NAS 30~60日 重要な家族ファイル、まれなレビュー、または限定的な復元テスト
小規模事業または共有ファイルサーバー 60~90日 多くのユーザー、報告の遅延、リモートアクセス、または規制対象データ
高価値または変化の遅いアーカイブ 90日間プラス週次/月次のアンカー 長期間の攻撃者滞留、法的保留、季節的作業、またはまれなファイルアクセス

感染が迅速に検出され、古いコピーが隔離され、クリーンな復元がすでに証明されている場合にのみ、下限は妥当です。

ランサムノートが現れる前に時計をスタートする

目に見える暗号化イベントは初期アクセスの数日または数週間後に発生することがあります。ランサムウェアのバックアップ戦略は初期侵害と目に見えるランサムウェアイベント間の滞留時間を考慮すべきです。最も早い疑わしいログイン、スクリプト、資格情報の使用、またはファイル変更が暗号化の45日前に発生した場合、30日間のバージョンウィンドウにはクリーンなポイントが含まれない可能性があります。

ログ、エンドポイントアラート、ID記録、インシデント対応の調査結果から最も早い妥当な侵害日時を使用します。その後、不完全な証拠に対する安全マージンを追加します。保持期間はその日時をカバーすべきであり、ユーザーが初めて暗号化ファイルを見た日時だけではありません。

1つのローリングウィンドウではなく階層化保持を使用する

単純なローリングウィンドウは同じスケジュールで古いクリーンポイントをすべて削除する可能性があります。階層化保持は、密な最近のバージョンを維持しつつ、長期のチェックポイントを少なく保存します。

階層 例:役割 ランサムウェアの価値
毎時または頻繁に 最近の作業と低RPO 急速な暗号化後の細かいロールバック
30~90日間の毎日保持 運用復旧 一般的な検出および調査の期間をカバー
3~6か月間の週次保持 より長いクリーンポイントの検索 すでに侵害された短期ローリングウィンドウを乗り越える
12~13か月間の月次保持 季節的および長期滞留の復旧 毎日のすべてのバージョンを保持せずに古いアンカーを提供

最近の保持分析は、選択された週次および月次の復元ポイントが、侵害された短期のローリングウィンドウを超えて復旧を延長できる理由を示しています。正確な階層は、データの価値、ストレージ予算、検出能力に従うべきです。

通常のローテーション外でインシデント時のコピーを保存する

通常のプルーニングで、イベントを理解するために必要なバージョン、ログ、バックアップカタログ、ランサムノート、影響を受けたファイルのサンプル、構成記録を削除しないでください。インシデントホールドを作成するか、これらのアーティファクトを文書化されたアクセス権のある保護された場所にエクスポートしてください。

インシデント証拠と運用バックアップの保持は異なる問題を解決します。バックアップ履歴は復旧オプションを提供し、インシデントホールドは範囲分析、保険、法的レビュー、教訓のためにサポートします。これらの義務を担当する人々と削除を調整してください。本記事は運用上の指針であり法的助言ではありません。

変化が遅くめったに開かれないファイルは長期間保持する

ランサムウェアは、ファイルがめったに開かれない場合、そのファイルを誰かが気づくずっと前に変更することがあります。アーカイブ、税務記録、デザイン資産、プロジェクトマスター、家族写真、歴史的文書は、アクティブな作業フォルダよりも長いバージョン履歴が必要なことが多いです。

データパターン 保持バイアス 理由
頻繁に編集される作業ファイル より頻繁な最近のバージョン 多くの正当な変更と許容されるデータ損失の窓が狭い場合
めったにアクセスされないアーカイブ より長い週次/月次の履歴 破損や暗号化が気づかれないまま残ることがあります
データベースとアプリの状態 アプリケーション整合性のあるポイントとテスト済みのエクスポート ファイルのバージョンは存在しても使用できない場合があります
規制対象または契約上の記録 ポリシーで定義された保持 運用上の復旧は法的要件の代わりにはなりません

古いバージョンを削除する前に最新のクリーンバージョンを見つける

暗号化前の最新バージョンが自動的に安全とは限りません。サイバー復旧では、侵害の兆候がなく、攻撃者と再接続せずに実行可能なポイントを特定する必要があります。復旧ワークフローは復元ポイントをスキャンして検証するまで最新のクリーンバックアップは不明であると想定すべきです。

候補バージョンを隔離された場所で検証してください。ファイルの読み取り可能性、意味のある場合はハッシュ、アプリケーションの整合性、マルウェアの指標、ユーザー権限、代表的な古いファイルを開けるかをチェックします。少なくとも1つのクリーンポイントがこれらのテストに合格するまで古いバージョンを保持してください。

復元テストが実際の保持閾値を設定する

保持ポリシーはバージョンが復元可能でなければ意味がありません。復旧計画のガイダンスでは、ファイル復元が実際に可能であることを証明するための定期的な復元テストを推奨しています。

少なくとも3つのポイントをテストしてください:最近のバージョン、疑わしい侵害境界付近のバージョン、そして古い週次または月次アンカーのバージョンです。最新のポイントだけをテストすると、ランサムウェア回復に必要な長期バージョンが完全で、復号可能で、正しくインデックスされているか分かりません。

古いバージョンが攻撃経路を生き延びることを確認する

書き込み可能な共有上での長期保持は、同じ侵害されたアカウントが削除できる場合、長期的な保護にはなりません。古いバージョンは、権限、ストレージアカウント、管理ドメイン、ネットワークパス、またはオフラインローテーションで分離する必要があります。不変性は設定期間中の早期削除を防ぎ、オフラインコピーはライブ攻撃経路を排除します。

ZimaSpaceのバックアップ制御プレーンと不変の復旧コピーの保護ガイドでは、保持設定、リポジトリ、認証情報、バックアップコンソールを一緒に保護する必要がある理由を説明しています。

ストレージが保持計画を維持できるか確認する

容量はアクティブファイルのサイズだけでなく、日次変更率から見積もってください。シンプルな計画モデルは次の通りです:

必要なバージョン容量 ≈ ベースラインコピー + 保持された日次変更 + 週次/月次アンカー + 一時的な復元および検証スペース。

数週間にわたり実際のリポジトリ成長を測定してください。圧縮、重複排除、データベースの変動、削除ファイルの保持、不変ロック期間、マージや復元テストに必要な作業領域を含めます。容量が不足している場合は、全体のクリーンポイント期間を短縮する前に、価値の低いフォルダのバージョン頻度を減らしてください。

特定の条件が満たされた後にのみ保持期間を短縮してください

以下のすべてが真である場合に限り、密な日次履歴の削減を検討できます:

  • 最も早い妥当な侵害日時が合理的な確信をもって確定されています。
  • 少なくとも1つのクリーンな復旧ポイントが隔離環境で検証されています。
  • インシデントの証拠は通常のバックアップローテーション外で保存されています。
  • 重要なシステムとファイルは所有者によって復元・検証されています。
  • セキュリティ、法務、保険、コンプライアンスの関係者が通常の削除を承認しています。
  • 週次および月次のアンカーは遅延発見や季節データをカバーします。

未解決の条件がある場合は、古いポイントを保持してください。ストレージの圧迫は攻撃前の唯一のバージョンを削除する正当な理由ではありません。

バージョンがクラウド同期サービスに保存されている場合は迅速に対応してください

クラウドのファイル履歴やごみ箱の保持期間はバックアップポリシーより短い場合があり、ランサムウェアの変更がクラウドに同期されることもあります。復旧ガイダンスでは、サービスの保持期限が切れると古いファイルバージョンや削除済みアイテムが消える可能性があると警告しています。

クリーンなデバイスから、適切な場合は同期を停止し、アカウントを保持し、重要なバージョンをエクスポートし、最も古い利用可能なクリーンポイントを記録してください。クラウドプロバイダーが無制限の履歴を保持しているとは限りません。

よくある質問

暗号化ファイルを含む可能性のあるバージョンはいつ削除できますか?

インシデントの範囲が理解され、クリーンなバージョンが復元・テストされ、証拠が保存され、法的または保険上の保留が解除された後にのみ削除してください。疑わしいバージョンは本番環境に混ぜ戻すのではなく、隔離しましょう。

より多くのバージョンは常に安全ですか?

いいえ。より多くのバージョンが役立つのは、それらが完全で、削除から保護され、インデックス化され、復号可能で、定期的にテストされている場合のみです。同じ侵害されたアカウントで管理されている数百のバージョンも一緒に失敗する可能性があります。

スナップショットと独立したバックアップは同じ保持期間を使うべきですか?

通常はそうではありません。ローカルスナップショットは短期間の密なロールバックに便利ですが、独立した不変のバックアップはより長期のランサムウェアや災害対応期間をカバーすべきです。異なる保持階層を使用して、1つのストレージ障害やアカウント侵害で全ての復旧ポイントが消去されないようにしましょう。

サポートとヒント

もっと読む

Plexは別のDockerコンテナとGPUを共有できますか?
Aug 17, 2026

Plexは別のDockerコンテナとGPUを共有できますか?

Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.