Les rançongiciels modernes attaquent d’abord les sauvegardes. PowerProtect DD sait les rendre immuables — mais la plupart des applications de sauvegarde ne savent pas piloter Retention Lock. Voici comment l’automatiser sans dépendre de votre logiciel de sauvegarde.
Le maillon faible : le serveur de sauvegarde lui-même
Un attaquant qui compromet le serveur de sauvegarde peut, avec les privilèges de l’application, supprimer ou chiffrer les copies avant de frapper la production. Toute protection pilotée par l’application tombe avec elle. La seule parade structurelle est une immuabilité appliquée par la plateforme de stockage, hors du chemin de l’application : c’est le rôle de Retention Lock sur PowerProtect DD.
Governance ou Compliance : choisir le bon mode
Retention Lock existe en deux modes. Governance protège contre la suppression accidentelle ou malveillante ordinaire : un officier de sécurité DD peut, par procédure exceptionnelle, intervenir — c’est le mode d’exploitation courant. Compliance supprime toute possibilité de révocation avant l’échéance, pour les exigences réglementaires strictes : à réserver aux cas où la réglementation l’impose, car l’erreur de configuration s’y paie jusqu’à l’échéance.
L’architecture à deux MTree
Le montage qui rend Retention Lock compatible avec n’importe quelle application de sauvegarde repose sur deux MTree distincts :
- Le MTree primaire — l’application de sauvegarde y écrit normalement, sans rien savoir de l’immuabilité. Veeam, NetBackup, Commvault ou autre : aucun prérequis côté application.
- Le MTree Retention Lock — configuré avec ses périodes (rétention minimale et maximale, rétention automatique, délai de verrouillage). Chaque nuit, une copie protégée du contenu primaire y est créée par fastcopy — une opération de métadonnées, rapide et économe en espace grâce à la déduplication.
Une fois le délai de verrouillage écoulé, la copie devient immuable : ni l’application, ni un administrateur pressé, ni un attaquant maître du serveur de sauvegarde ne peuvent la modifier avant l’échéance. Les copies expirées sont purgées automatiquement — le MTree protégé ne grossit pas sans fin.
Le jour où tout va mal : la restauration
Le scénario de reprise est simple parce qu’il a été prévu : on identifie dans l’inventaire la copie protégée antérieure à la compromission, on la rend accessible à l’application de sauvegarde (au besoin sur un serveur reconstruit), et la restauration suit le chemin habituel de l’application. L’attaquant a chiffré la production et le serveur de sauvegarde ? Les copies verrouillées, elles, sont restées intactes — c’était le but.
Les points de vigilance
- Testez la restauration avant l’incident — une copie immuable jamais restaurée est une hypothèse, pas une protection.
- Dimensionnez la rétention à votre fenêtre de détection réelle : 14 jours d’immuabilité ne servent à rien si une compromission met trois semaines à être découverte.
- Verrouillez l’accès administratif au mécanisme lui-même : comptes dédiés, adresses IP autorisées, double authentification.