En 2024, une PME sur cinq touchée par un ransomware n’a pas pu restaurer ses données correctement — non pas parce qu’elle n’avait pas de sauvegarde, mais parce que sa sauvegarde n’était pas résiliente. Le fichier de backup était chiffré en même temps que les données de production. Ou la restauration n’avait jamais été testée. Ou les données de la veille étaient disponibles, mais pas celles du trimestre écoulé.

AWS offre les outils pour construire une stratégie de sauvegarde vraiment solide. Encore faut-il les configurer correctement.

La règle 3-2-1-1 : le standard actuel

La règle historique est la 3-2-1 : 3 copies des données, sur 2 supports différents, dont 1 hors site. C’est un bon point de départ — mais face aux ransomwares modernes, ce n’est plus suffisant.

La règle 3-2-1-1 ajoute une quatrième exigence : 1 copie immuable, c’est-à-dire une copie que personne — ni un attaquant, ni un administrateur mal intentionné, ni une erreur humaine — ne peut modifier ou supprimer pendant une durée définie.

Sur AWS, cette copie immuable s’appelle Object Lock.

S3 Object Lock : l’immuabilité comme protection

Amazon S3 Object Lock permet de verrouiller des objets (fichiers) en mode WORM (Write Once, Read Many) pour une durée déterminée. Pendant cette durée, personne ne peut supprimer ou écraser l’objet — même le compte root AWS.

Deux modes existent :

Governance mode : les utilisateurs avec des permissions spécifiques peuvent contourner le verrou. Utile pour les tests.
Compliance mode : aucun utilisateur, y compris root, ne peut supprimer l’objet avant la fin de la période de rétention. C’est ce mode que vous voulez pour vos backups critiques.

Configuration recommandée pour une PME :

Rétention en mode Compliance : 30 jours pour les sauvegardes quotidiennes
Rétention en mode Compliance : 12 mois pour les sauvegardes mensuelles
Bucket dédié aux backups, distinct du bucket de production
Versioning activé sur le bucket source

Le versioning S3 ajoute une couche supplémentaire : même si un fichier est “supprimé”, les versions précédentes sont conservées. Un ransomware qui chiffre et remplace vos fichiers S3 ne détruit pas les versions antérieures.

AWS Backup : la couche d’orchestration

Gérer manuellement des snapshots RDS, des sauvegardes EBS, des exports S3 et des copies DynamoDB est une recette pour les oublis. AWS Backup centralise tout ça en un seul endroit.

Ce que AWS Backup permet de faire :

Définir des plans de sauvegarde avec fréquence, fenêtre de maintenance et rétention
Couvrir automatiquement EC2, EBS, RDS, Aurora, DynamoDB, EFS, FSx, S3
Copier les backups dans une région AWS différente (pour la résilience géographique)
Activer le verrouillage (Backup Vault Lock) sur le coffre de sauvegarde, équivalent de l’Object Lock pour tous les services

Backup Vault Lock est particulièrement important : il empêche la suppression des points de restauration même si un attaquant compromet votre compte AWS avec des droits administrateur. C’est le filet de sécurité ultime.

Exemple de plan de sauvegarde cohérent

Fréquence	Rétention	Copie cross-région
Toutes les 4h	2 jours	Non
Quotidienne	30 jours	Oui (eu-west-1 → eu-central-1)
Hebdomadaire	3 mois	Oui
Mensuelle	1 an	Oui

La copie cross-région protège contre un incident AWS au niveau régional — rare, mais pas impossible.

Le test de restauration : l’étape que tout le monde saute

C’est la règle d’or et la plus ignorée : une sauvegarde non testée n’existe pas.

Il ne suffit pas de vérifier que le job de backup est au vert dans la console AWS. Il faut régulièrement valider que vous êtes capable de restaurer vos données dans un délai acceptable.

Ce que “tester” signifie concrètement :

Test de restauration d’un fichier : restaurer un document précis depuis une version antérieure S3. À faire mensuellement.
Test de restauration de base de données : lancer une restauration de snapshot RDS dans un environnement de test, vérifier l’intégrité des données. À faire trimestriellement.
Test de reprise d’activité complet : simuler la perte totale d’un environnement et mesurer le temps de restauration réel (RTO). À faire annuellement.

AWS propose AWS Backup Restore Testing pour automatiser une partie de ces tests et générer des rapports de conformité.

Les erreurs fréquentes à éviter

Sauvegarder dans le même compte AWS que la production. Si le compte est compromis, le backup l’est aussi. Idéalement, les sauvegardes critiques vont dans un compte AWS dédié (AWS Organizations le facilite).

Ne pas chiffrer les backups. AWS Backup chiffre par défaut avec les clés AWS gérées. Pour aller plus loin, utilisez vos propres clés KMS — vous gardez ainsi le contrôle total, même si AWS est compromis.

Confondre “archivage” et “sauvegarde”. S3 Glacier est peu coûteux mais les délais de récupération vont de quelques minutes à 12 heures selon la classe. Si votre RTO est de 2 heures, Glacier Deep Archive n’est pas adapté à vos backups opérationnels.

Ne pas surveiller les échecs de backup. AWS Backup peut envoyer des alertes SNS en cas d’échec. Si personne ne reçoit ces alertes, un backup qui échoue depuis 3 semaines passe inaperçu.

Ce que ça coûte

Pour une PME avec 500 Go de données à sauvegarder en région Paris (eu-west-3) :

S3 Standard pour les backups chauds (30 jours) : ~12€/mois
S3 Glacier Instant Retrieval pour les backups froids (1 an) : ~4€/mois
AWS Backup (orchestration) : pas de surcoût, vous payez le stockage sous-jacent
Copie cross-région : ~2-3€/mois supplémentaires

Total : moins de 20€/mois pour une stratégie de backup conforme à la règle 3-2-1-1. C’est le coût d’une heure de prestation IT.

Vous voulez évaluer la solidité de votre stratégie de sauvegarde actuelle, ou mettre en place AWS Backup from scratch ? C’est exactement ce genre de mission que je réalise pour les PME et collectivités de la région parisienne. Le premier échange est gratuit.

Sources : AWS Documentation — S3 Object Lock, AWS Backup ; ANSSI — Guide ransomware ; Cloud Security Alliance.