Stratégie de Sauvegarde
Une stratégie de sauvegarde résiliente est la dernière ligne de défense contre la perte de données causée par les ransomwares, les pannes matérielles, les catastrophes naturelles, les erreurs humaines, la corruption de données ou les attaques malveillantes qui détruisent les systèmes de production : sans sauvegardes adéquates, un incident qui pourrait être résolu par une restauration de quelques heures peut se transformer en perte permanente de données critiques, en interruption de service de plusieurs jours ou semaines, et potentiellement en faillite de l'entreprise. La règle fondamentale 3-2-1 (3 copies des données, sur 2 types de supports différents, avec 1 copie hors site) reste valable mais doit être étendue aux environnements modernes avec des concepts tels que la sauvegarde immuable pour la protection anti-ransomware (des sauvegardes qui ne peuvent être ni supprimées ni modifiées, même par les administrateurs, pendant la période de rétention), des tests de restauration réguliers pour valider que les sauvegardes fonctionnent réellement lorsque c'est nécessaire (de nombreuses organisations découvrent que leurs sauvegardes sont corrompues uniquement lorsqu'elles en ont besoin en cas d'urgence), une définition claire du RPO (Recovery Point Objective : quelle quantité de données nous pouvons perdre, mesurée en temps depuis la dernière sauvegarde) et du RTO (Recovery Time Objective : combien de temps nous pouvons rester hors ligne jusqu'à ce que le système soit restauré), la séparation des identifiants de sauvegarde du domaine principal pour empêcher qu'un attaquant qui compromet Active Directory ne détruise également toutes les sauvegardes, et l'automatisation des processus de sauvegarde avec surveillance et alertes pour garantir que les sauvegardes se déroulent comme prévu. Une erreur courante consiste à traiter la sauvegarde comme « set and forget » : les sauvegardes nécessitent une attention continue, une validation, une mise à jour des procédures à mesure que l'infrastructure évolue et, surtout, une culture organisationnelle qui valorise la protection des données autant que la production de nouvelles fonctionnalités.
Règle 3-2-1 : Fondements de la Redondance
La règle 3-2-1 établit que vous devez conserver 3 copies de vos données (production + 2 sauvegardes), sur 2 types de supports de stockage différents, avec 1 copie hors site géographiquement séparée. Par exemple : données de production sur un SAN (Storage Area Network), sauvegarde primaire sur un NAS (Network Attached Storage) dans le même datacenter, et sauvegarde secondaire sur un stockage cloud (S3, Azure Blob) dans une région différente. La diversité des supports protège contre les pannes spécifiques à une technologie : si vous avez toutes vos sauvegardes sur des bandes magnétiques et que vous découvrez que votre tape drive a cessé de fonctionner, vous pourriez être dans l'incapacité de restaurer même en possédant les bandes. La copie hors site protège contre les catastrophes localisées (incendie, inondation, vol, attaque physique du datacenter) : si toutes les sauvegardes se trouvent dans le même bâtiment qui a brûlé, vous avez tout perdu. L'évolution moderne du 3-2-1 est le 3-2-1-1-0 : 3 copies, 2 supports, 1 hors site, 1 immuable, 0 erreur (validé par des tests de restauration). Pour la mise en œuvre : configurez le logiciel de sauvegarde (Veeam, Commvault, Bacula, Acronis, AWS Backup, Azure Backup) pour créer des snapshots quotidiens des systèmes critiques, répliquez ces sauvegardes vers un stockage local (première copie), envoyez une copie vers le cloud (deuxième copie hors site) et marquez les copies cloud comme immuables avec Object Lock (S3) ou Immutable Blobs (Azure). Calculez le stockage nécessaire en fonction de : taille des données × période de rétention × taux de changement : si vous avez 10TB de données, que vous souhaitez conserver les sauvegardes pendant 30 jours et que 10 % des données changent quotidiennement, vous aurez besoin d'environ 10TB + (10TB × 0,1 × 30) = 40TB de stockage pour les sauvegardes. Utilisez la déduplication et la compression pour réduire les coûts, mais méfiez-vous du crypto ransomware qui peut faire apparaître les données comme aléatoires et réduire l'efficacité du dedupe.
Sauvegarde Immuable Anti-Ransomware
Le ransomware moderne ne se contente pas de chiffrer les données de production : il recherche et détruit activement les sauvegardes pour maximiser la pression sur la victime afin qu'elle paie la rançon. Les attaquants utilisent des identifiants administratifs compromis pour supprimer des snapshots, désactiver les services de sauvegarde, corrompre les backup catalogs et même chiffrer les sauvegardes elles-mêmes. La sauvegarde immuable (aussi appelée WORM - Write Once Read Many, ou air-gapped backup) empêche cela en rendant les sauvegardes impossibles à supprimer ou modifier pendant le retention period défini, même par des administrateurs disposant des privilèges maximaux. Implémentations : AWS S3 Object Lock en mode Compliance (même la root account ne peut pas supprimer les objets avant l'expiration date), Azure Blob Immutable Storage avec legal hold ou time-based retention policies, sauvegardes sur bande physiquement retirées et conservées dans un vault hors site, et backup appliances avec WORM mode (Dell EMC Data Domain, Cohesity). Configurez un retention period approprié, généralement de 30 à 90 jours selon votre RPO et la durée pendant laquelle vous devez conserver des versions historiques. IMPORTANT : l'immuabilité empêche la suppression mais n'empêche pas la création de nouvelles sauvegardes corrompues : si un attaquant compromet un système pendant des semaines avant de déclencher le ransomware, vos sauvegardes immuables peuvent contenir des données déjà infectées. Solution : conservez plusieurs versions de sauvegardes (pas seulement la plus récente), utilisez une backup validation qui détecte les anomalies dans les données (une augmentation soudaine de l'entropie peut indiquer un encryption) et envisagez un « air gap » physique où les sauvegardes sont périodiquement copiées vers un stockage complètement déconnecté du réseau. Testez régulièrement la récupération des sauvegardes immuables, car certains systèmes présentent des bugs où l'immuabilité empêche même les legitimate restore operations.
Tests de Restauration et Validation
Une sauvegarde non testée est une sauvegarde non fiable : il existe d'innombrables cas documentés d'entreprises qui effectuaient des sauvegardes religieusement pendant des années et qui ont découvert lors du disaster recovery que leurs sauvegardes étaient corrompues, que la configuration était erronée, que le support était dégradé ou que le processus de restauration ne fonctionnait tout simplement pas. Mettez en place un programme formel de backup testing : restauration complète de la production dans un environnement de test mensuellement (full system restore), restauration des VMs/bases de données critiques hebdomadairement (partial restore) et validation des backup job logs quotidiennement (vérifier que les sauvegardes se sont terminées sans erreur). Automatisez les tests à l'aide de scripts qui : démarrent une restauration dans un environnement isolé, vérifient l'intégrité des données restaurées (checksums, database consistency checks), mesurent le temps de restauration (valide si vous pouvez respecter le RTO) et génèrent des reports avec des métriques. Pour les bases de données, utilisez la backup restore validation du SGBD lui-même : SQL Server RESTORE VERIFYONLY, MySQL mysqlcheck, PostgreSQL pg_restore --list. Pour les sauvegardes d'applications, restaurez et exécutez des smoke tests automatisés qui vérifient les fonctionnalités critiques. Documentez chaque test : date, systèmes testés, résultat (succès/échec), temps écoulé, problèmes rencontrés et actions correctives. Traitez les échecs de restore tests comme des P0 incidents : si un test de sauvegarde échoue, vous supposez que vous n'avez pas de sauvegarde fonctionnelle jusqu'à correction. Envisagez de réaliser des « surprise restore drills » où vous prévenez l'équipe sans préavis qu'elle doit restaurer le système X en Y heures, simulant une véritable urgence. En plus de valider les sauvegardes, ces drills entraînent l'équipe aux procédures de recovery et identifient les gaps dans la documentation ou l'automatisation.
RPO et RTO : Définir les Objectifs de Recovery
Le RPO (Recovery Point Objective) est la quantité maximale de données que vous pouvez perdre, mesurée en temps : si votre RPO est de 4 heures, vous devez effectuer des sauvegardes au moins toutes les 4 heures, et en cas de catastrophe, vous pouvez perdre jusqu'à 4 heures de transactions. Le RTO (Recovery Time Objective) est le temps maximal pendant lequel un système peut rester hors ligne jusqu'à sa restauration : si votre RTO est de 2 heures, vous disposez de 2 heures entre la détection de l'incident et le retour du système en fonctionnement. Le RPO et le RTO doivent être définis selon les business requirements (quelle quantité de données perdues et quel downtime l'entreprise tolère) et déterminent l'architecture de sauvegarde : les applications tier-1 critiques peuvent exiger RPO=0 (zéro perte de données via réplication synchrone) et un RTO de quelques minutes (high availability cluster), les applications tier-2 peuvent tolérer RPO=1h (sauvegardes incrémentielles horaires) et RTO=4h, les applications tier-3 peuvent avoir RPO=24h (sauvegardes nocturnes) et RTO=8h. Calculez coût vs. risque : un RPO plus faible nécessite des sauvegardes plus fréquentes (plus de stockage, plus d'overhead de performance), un RTO plus faible nécessite des systèmes de recovery plus sophistiqués (hot standby, automated failover). Exemple d'architecture pour différents tiers : Tier-1 (ERP, Payment Processing) - réplication synchrone vers un DR site + snapshots de 15 min + sauvegarde quotidienne immuable, RPO inférieur à 15 min, RTO inférieur à 1h ; Tier-2 (CRM, Email) - sauvegardes incrémentielles de 1h + sauvegarde full quotidienne, RPO=1h, RTO=4h ; Tier-3 (File Shares, Logs) - sauvegarde quotidienne, RPO=24h, RTO=8h. Documentez le RPO/RTO de chaque système dans le Disaster Recovery Plan, obtenez le sign-off des business stakeholders (pour garantir l'alignement des attentes) et surveillez si vous pouvez atteindre les objectifs définis (track des actual recovery times lors des incidents).
Séparation des Identifiants de Sauvegarde
Un attaquant qui compromet Active Directory avec des privilèges Domain Admin peut potentiellement accéder à toutes les sauvegardes et les détruire si le backup system utilise des identifiants du même AD : c'est un vecteur courant dans les attaques de ransomware où l'attaquant établit d'abord une persistance dans l'AD, puis cartographie toute l'infrastructure de sauvegarde et détruit finalement les sauvegardes avant de déclencher l'encryption. Atténuez ce risque par la ségrégation des identifiants : créez un domaine séparé ou un workgroup standalone pour la backup infrastructure, utilisez des service accounts locaux plutôt que des domain accounts lorsque c'est possible, configurez les backup appliances avec leur propre authentification indépendante de l'AD, implémentez le MFA pour l'accès à la backup console et au stockage, et utilisez des API keys avec des permissions restreintes pour les sauvegardes cloud plutôt que des identifiants à large accès. Pour les environnements Veeam, implémentez un « hardened Linux repository » où le backup server est sous Linux (en dehors de l'AD Windows), accessible uniquement via SSH avec une key-based auth et sans possibilité de supprimer des sauvegardes via la Veeam console (immutability enforced au niveau du Linux filesystem). Pour les sauvegardes AWS, utilisez un cross-account backup vault où les sauvegardes sont envoyées vers une AWS account séparée, contrôlée par une équipe différente avec des identifiants non partagés, et configurez Vault Lock pour empêcher la suppression. Appliquez le principe de least privilege : le compte qui effectue les sauvegardes n'a besoin que d'un read access en production et d'un write access sur le backup destination, il n'a pas besoin de delete permissions. Surveillez les accès à la backup infrastructure comme des high-value targets : toute tentative d'accès en dehors des fenêtres de sauvegarde ou depuis des IPs inattendues doit générer une alerte de sécurité. Dans les cas extrêmes, envisagez un « offline backup admin » où les identifiants d'administration des sauvegardes n'existent pas sous forme numérique : ils sont stockés dans un vault physique et accessibles uniquement en cas d'urgence.