Stratégies de sauvegarde : règle 3-2-1 et sauvegardes immuables

Les sauvegardes ne sont pas seulement une question opérationnelle pour le service informatique — elles constituent un contrôle de sécurité CRITICAL qui permet directement de reprendre l’activité après une attaque par rançongiciel, une suppression accidentelle, une défaillance matérielle ou un sabotage interne. Sans sauvegardes testées et fiables, les opérateurs de rançongiciels détiennent tout le pouvoir : payer ou perdre vos données. Avec des sauvegardes robustes et protégées, les organisations peuvent reprendre leur activité sans payer de rançon. L’examen Security+ inclut explicitement la stratégie de sauvegarde parmi les exigences de continuité d’activité et de protection des données.

La règle de sauvegarde 3-2-1 constitue la référence de base du secteur en matière de résilience des sauvegardes. 3 copies des données doivent exister (l’originale + 2 sauvegardes). 2 types différents de supports de stockage doivent être utilisés (par exemple, un disque Local et une bande, ou un NAS Local et le Cloud). 1 copie doit être conservée hors site ou dans une Location géographiquement distincte. Cette configuration garantit qu’aucune défaillance unique — panne de disque, sinistre sur le site ou vol — ne supprime toutes les copies des données. La règle 3-2-1 est la référence absolue en matière de sauvegarde depuis deux décennies.

Les rançongiciels ont mis en évidence les faiblesses de la règle classique 3-2-1 : si les trois copies sont accessibles par le Network, un rançongiciel les chiffre toutes. La règle améliorée 3-2-1-1-0 ajoute les exigences suivantes : une copie doit être OFFLINE ou isolée physiquement du Network (déconnectée du Network et physiquement isolée), et il doit y avoir zéro erreur de sauvegarde (toutes les sauvegardes doivent être testées, sans aucun échec lors des tests de Restore). La copie OFFLINE garantit qu’un rançongiciel — même avec un accès d’administrateur de domaine — ne peut pas atteindre et chiffrer toutes les copies de sauvegarde.

Les sauvegardes immuables sont stockées de manière à rendre toute modification ou suppression impossible pendant une période de Retention définie — même pour des administrateurs disposant d’un accès complet. Les fournisseurs de Cloud mettent en œuvre l’immuabilité au moyen de politiques de verrouillage d’objets (WORM — Write Once, Read Many). AWS S3 Object Lock, Azure Blob immutable storage et des fonctionnalités similaires empêchent tout appel d’API de supprimer ou d’écraser des objets avant l’expiration de la période de Lock. Les groupes de rançongiciels qui obtiennent un accès d’administrateur de domaine ne peuvent pas supprimer les sauvegardes immuables, même avec le niveau le plus élevé d’identifiants Cloud.

Trois types de sauvegardes permettent de trouver un équilibre entre exhaustivité, coût de stockage et durée de la fenêtre de sauvegarde. Une sauvegarde Full copie toutes les données à chaque fois : elle permet la Restore la plus rapide, mais consomme le plus de stockage. Une sauvegarde Incremental copie uniquement les données modifiées depuis la dernière sauvegarde, quel qu’en soit le type : elle est la plus rapide à créer et nécessite le moins de stockage, mais sa Restore exige la dernière sauvegarde Full ainsi que toutes les sauvegardes Incrementals. Une sauvegarde Differential copie toutes les données modifiées depuis la dernière sauvegarde Full : la croissance du stockage est moyenne et la Restore nécessite uniquement la dernière sauvegarde Full et la Differential la plus récente.

Les fichiers de sauvegarde doivent être chiffrés — les bandes de sauvegarde envoyées dans un stockage hors site et les sauvegardes Cloud sont des cibles pour les attaquants qui recherchent des données sensibles. Utilisez le chiffrement AES-256 pour les données de sauvegarde au repos. Point CRITICAL : les clés de chiffrement des sauvegardes doivent être stockées séparément des sauvegardes elles-mêmes : chiffrer des sauvegardes avec une clé également sauvegardée au même endroit annule l’objectif de cette protection. Stockez les clés de chiffrement dans un Hardware Security Module (HSM) ou dans un service de gestion des clés indépendant du système de sauvegarde.

Les systèmes de sauvegarde doivent être isolés du Network de Production. Si les serveurs de sauvegarde sont joints au domaine Active Directory utilisé par les serveurs de Production, un rançongiciel disposant d’identifiants d’administrateur de domaine peut atteindre le stockage des sauvegardes et le chiffrer. Bonnes pratiques : placer les serveurs de sauvegarde sur un segment de Network distinct, sans accès depuis les serveurs de Production, utiliser des identifiants de sauvegarde dédiés qui ne sont pas des comptes d’administrateur de domaine, mettre en œuvre la MFA sur le serveur de sauvegarde pour les accès administratifs et envisager un domaine de sauvegarde distinct, sans relation d’approbation avec le domaine de Production.

Les services de sauvegarde Cloud fournissent un stockage hors site avec des options d’immuabilité et simplifient la mise en œuvre de la règle 3-2-1. AWS Backup, Azure Backup et Google Cloud Backup and DR s’intègrent aux services Cloud et offrent une gestion centralisée des politiques. Des services tiers comme Veeam, Rubrik et Cohesity proposent des sauvegardes natives du Cloud avec des référentiels immuables, des copies de coffres isolées du Network et une détection des rançongiciels qui analyse les données de sauvegarde à la recherche d’anomalies d’entropie liées au chiffrement — et émet une alerte avant la fin d’une attaque complète par rançongiciel.

De nombreuses organisations découvrent lors d’un incident de rançongiciel que leurs sauvegardes sont corrompues ou impossibles à restaurer — une découverte catastrophique au pire moment. Les tests de sauvegarde doivent être planifiés et réalisés régulièrement. Les approches comprennent : la vérification automatisée de Restore (restaurer chaque jour un échantillon de fichiers et vérifier les sommes de contrôle), les Restores complets périodiques dans un environnement de test isolé (Restore trimestrielle d’une base de données et test de démarrage de l’application) et les exercices de DR, durant lesquels l’équipe suit le DRP, depuis la sauvegarde jusqu’à l’exécution de la Production sur une infrastructure de secours. Documentez le résultat de chaque test.

Le schéma de Retention Grandfather-Father-Son (GFS) organise la conservation des sauvegardes selon différents horizons temporels. Les sauvegardes Son sont Daily (conservées pendant 1 semaine, puis écrasées). Les sauvegardes Father sont des sauvegardes Full hebdomadaires (conservées pendant 1 mois). Les sauvegardes Grandfather sont des sauvegardes Full Monthly (conservées pendant 1 an ou plus). GFS permet de restaurer les données d’hier, de la semaine dernière ou du mois dernier, en conciliant la souplesse de reprise et le coût de stockage. De nombreux référentiels de conformité exigent une Retention de type GFS à des fins de piste d’audit.

Les échecs de sauvegarde sont des catastrophes silencieuses : un travail de sauvegarde qui échoue silencieusement pendant des semaines signifie qu’aucune protection n’existe lorsqu’elle est le plus nécessaire. La surveillance des sauvegardes doit suivre : la réussite de chaque travail de sauvegarde planifié, le fait que la taille de la sauvegarde se situe dans la plage attendue (une sauvegarde anormalement petite peut indiquer un échec partiel), la réussite de l’accès à la clé de chiffrement de la sauvegarde et le fait que la sauvegarde a été transférée vers toutes les destinations requises (Local + hors site). Des alertes doivent être déclenchées immédiatement pour tout travail ayant échoué, avec une escalade si les échecs persistent au-delà d’une seule tentative. Traitez une sauvegarde échouée comme un incident de priorité 2.

Vérifiez votre compréhension des concepts de CompTIA Security+ (SY0-701) abordés dans cette leçon.

Dans cette leçon, vous avez appris que la règle 3-2-1 exige 3 copies sur 2 types de supports, dont 1 hors site, que la règle améliorée 3-2-1-1-0 ajoute une copie OFFLINE/immuable et exige zéro échec de Restore, et que le stockage immuable/WORM empêche les rançongiciels de détruire les sauvegardes, même avec des identifiants administratifs complets. Nous allons maintenant étudier les tests de basculement au moyen d’exercices Tabletop et d’exercices de DR, afin de vérifier que les plans de reprise fonctionnent en pratique.