Combien de temps devez-vous conserver les versions de fichiers après une attaque par ransomware ?

Conservez les versions quotidiennes des fichiers pendant au moins 30 à 90 jours comme plage de départ pratique après une attaque par ransomware, mais ne considérez pas cela comme une date universelle de suppression. La rétention doit s'étendre au-delà de la date de compromission plausible la plus ancienne, préserver certains points propres hebdomadaires ou mensuels, et conserver séparément les preuves d'incident jusqu'à ce que la récupération, l'enquête, l'assurance, les aspects juridiques et la conformité soient terminés.

Une plage de départ pratique est de 30 à 90 jours

De nombreuses conceptions de sauvegarde utilisent 30 à 90 jours d'historique immuable quotidien pour la récupération opérationnelle après ransomware. Un aperçu des sauvegardes immuables note que 30 à 90 jours est une plage courante de rétention quotidienne pour la protection contre les ransomwares. Considérez cela comme un point de départ, pas une garantie que la version la plus ancienne conservée est propre.

La limite inférieure n'est raisonnable que lorsque l'infection est détectée rapidement, que les copies plus anciennes sont isolées et qu'une restauration propre a déjà été prouvée.

Commencez le chronomètre avant l'apparition de la note de rançon

L'événement de chiffrement visible peut survenir des jours ou des semaines après l'accès initial. Une stratégie de sauvegarde contre les ransomwares doit prendre en compte le temps de latence entre la compromission initiale et l'événement visible de ransomware. Si la première connexion suspecte, script, utilisation d'identifiants ou modification de fichier a eu lieu 45 jours avant le chiffrement, une fenêtre de versions de 30 jours peut ne contenir aucun point propre.

Utilisez la date de compromission plausible la plus ancienne issue des journaux, alertes des points de terminaison, enregistrements d'identité et conclusions de la réponse aux incidents. Ajoutez ensuite une marge de sécurité pour les preuves incomplètes. La fenêtre de rétention doit couvrir cette date, et non simplement la date à laquelle les utilisateurs ont vu les fichiers chiffrés pour la première fois.

Utilisez une rétention échelonnée au lieu d'une fenêtre glissante unique

Une fenêtre roulante plate peut supprimer tous les anciens points propres selon le même calendrier. La rétention par niveaux conserve des versions récentes denses tout en préservant moins de points de contrôle à long terme.

Une analyse récente de la rétention montre pourquoi certains points de restauration hebdomadaires et mensuels sélectionnés peuvent prolonger la récupération au-delà d’une fenêtre courte compromise. Les niveaux exacts doivent suivre la valeur de vos données, votre budget de stockage et votre capacité de détection.

Conserver les copies de l’époque de l’incident hors de la rotation normale

Ne laissez pas l’élagage normal supprimer les versions, journaux, catalogues de sauvegarde, notes de rançon, échantillons de fichiers affectés et enregistrements de configuration nécessaires pour comprendre l’événement. Créez une mise en attente d’incident ou exportez ces artefacts vers un emplacement protégé avec un accès documenté.

La conservation des preuves d’incident et la rétention des sauvegardes opérationnelles répondent à des besoins différents. L’historique des sauvegardes offre des options de récupération ; la mise en attente d’incident soutient l’analyse de périmètre, l’assurance, la revue juridique et les leçons apprises. Coordonnez la suppression avec les personnes responsables de ces obligations. Cet article est un guide opérationnel, pas un conseil juridique.

Conserver plus longtemps les fichiers à évolution lente et rarement ouverts

Le ransomware peut modifier un fichier longtemps avant que quelqu’un ne s’en aperçoive si ce fichier est rarement ouvert. Les archives, documents fiscaux, ressources de conception, fichiers maîtres de projet, photos de famille et documents historiques nécessitent souvent un historique de versions plus long que les dossiers de travail actifs.

Trouver la dernière version propre avant de supprimer les anciennes

La version la plus récente avant le chiffrement n'est pas automatiquement sûre. La récupération cybernétique nécessite d'identifier un point exempt d'indicateurs de compromission et pouvant fonctionner sans reconnecter l'attaquant. Un flux de travail de récupération doit supposer que la dernière sauvegarde propre est inconnue tant que les points de restauration ne sont pas scannés et validés.

Validez les versions candidates dans un emplacement isolé. Vérifiez la lisibilité des fichiers, les hachages lorsque pertinents, la cohérence des applications, les indicateurs de malware, les permissions utilisateur, et la capacité à ouvrir des fichiers anciens représentatifs. Conservez les versions plus anciennes jusqu'à ce qu'au moins un point propre ait passé ces tests.

Les tests de restauration définissent le véritable seuil de rétention

Une politique de rétention n'est utile que si les versions peuvent être restaurées. Les recommandations de planification de la récupération conseillent des tests de restauration programmés pour prouver que la récupération des fichiers est réellement possible.

Testez au moins trois points : une version récente, une proche de la limite de compromission suspectée, et une ancre hebdomadaire ou mensuelle plus ancienne. Si seul le point le plus récent est testé, vous ne savez pas si les versions à long terme nécessaires à la récupération après ransomware sont complètes, déchiffrables et correctement indexées.

Assurez-vous que les versions plus anciennes survivent à la voie d'attaque

Une rétention longue sur un partage modifiable ne garantit pas une protection à long terme si le même compte compromis peut la supprimer. Les versions plus anciennes doivent être séparées par permissions, compte de stockage, domaine administratif, chemin réseau ou rotation hors ligne. L'immuabilité empêche la suppression anticipée pendant une période configurée, tandis que les copies hors ligne éliminent la voie d'attaque en direct.

Le guide ZimaSpace sur la protection des plans de contrôle des sauvegardes et des copies de récupération immuables explique pourquoi les paramètres de rétention, les dépôts, les identifiants et les consoles de sauvegarde doivent être protégés ensemble.

Vérifiez si le stockage peut soutenir le plan de rétention

Estimez la capacité à partir du taux de changement quotidien, pas seulement de la taille des fichiers actifs. Un modèle de planification simple est :

Capacité de version requise ≈ copie de base + modifications quotidiennes conservées + ancres hebdomadaires/mensuelles + espace temporaire de restauration et de vérification.

Mesurez la croissance réelle du dépôt pendant plusieurs semaines. Incluez la compression, la déduplication, le renouvellement de la base de données, la rétention des fichiers supprimés, les périodes de verrouillage immuables et l'espace de travail nécessaire pour les fusions ou les tests de restauration. Si la capacité est trop faible, réduisez la fréquence des versions pour les dossiers à faible valeur avant de raccourcir toute la fenêtre des points propres.

Réduisez la rétention uniquement après que des conditions spécifiques sont remplies

Vous pouvez envisager de réduire l'historique dense quotidien après que toutes les conditions suivantes sont remplies :

• La date la plus ancienne plausible de compromission a été établie avec une confiance raisonnable.
• Au moins un point de récupération propre a été validé en isolation.
• Les preuves de l'incident ont été préservées en dehors de la rotation normale des sauvegardes.
• Les systèmes et fichiers critiques ont été restaurés et vérifiés par leurs propriétaires.
• Les parties prenantes en sécurité, juridique, assurance et conformité ont autorisé la suppression normale.
• Les points d'ancrage hebdomadaires et mensuels couvrent toujours la découverte tardive et les données saisonnières.

Si une condition n'est pas résolue, conservez les points plus anciens. La pression sur le stockage n'est pas une raison sûre pour supprimer les seules versions pouvant précéder l'attaque.

Agissez rapidement lorsque les versions sont stockées par un service de synchronisation cloud

Les fenêtres d'historique des fichiers et de la corbeille dans le cloud peuvent être plus courtes que votre politique de sauvegarde, et les modifications dues aux ransomwares peuvent se synchroniser dans le cloud. Les conseils de récupération avertissent que les versions plus anciennes des fichiers et les éléments supprimés peuvent disparaître à l'expiration d'une limite de rétention de service.

Depuis un appareil propre, suspendez la synchronisation si nécessaire, préservez le compte, exportez les versions critiques et documentez le point propre le plus ancien disponible. Ne supposez pas que le fournisseur cloud conserve un historique illimité.

Questions fréquemment posées

Quand peut-on supprimer des versions qui peuvent contenir des fichiers chiffrés ?

Supprimez-les uniquement après avoir compris l'étendue de l'incident, restauré et testé des versions propres, préservé les preuves et levé toute retenue légale ou d'assurance. Isolez les versions suspectes plutôt que de les réintégrer en production.

Plus de versions sont-elles toujours plus sûres ?

Non. Plus de versions n'aident que si elles sont complètes, protégées contre la suppression, indexées, déchiffrables et régulièrement testées. Des centaines de versions contrôlées par le même compte compromis peuvent toujours échouer ensemble.

Les instantanés et les sauvegardes indépendantes doivent-ils utiliser la même période de rétention ?

Habituellement non. Les instantanés locaux sont utiles pour des retours en arrière denses à court terme, tandis que les sauvegardes indépendantes ou immuables doivent couvrir des périodes plus longues contre les ransomwares et les catastrophes. Utilisez différents niveaux de rétention afin qu'une défaillance de stockage ou une compromission de compte n'efface pas tous les points de récupération.