Bâtir une stratégie de sauvegarde cloud en laquelle vous pouvez réellement avoir confiance

Toutes les organisations sauvegardent leurs données. Beaucoup moins sont capables de les récupérer sous pression. L’écart entre « nous avons des sauvegardes » et « nous pouvons restaurer nos systèmes dans notre fenêtre de récupération » est là où les entreprises souffrent.

La sauvegarde et la reprise après sinistre cloud-natives changent la donne — mais seulement si vous les concevez de manière intentionnelle.

Le faux confort des sauvegardes par défaut

La plupart des services AWS offrent une forme de sauvegarde intégrée. RDS dispose de snapshots automatisés. Les volumes EBS peuvent être capturés. Les objets S3 peuvent être versionnés. Mais se fier aux paramètres par défaut sans stratégie délibérée crée des lacunes qui ne se manifestent qu’en cas d’incident réel.

Problèmes courants que nous observons :

Snapshots automatisés conservés 7 jours sans archivage à long terme
Aucune copie inter-régions, laissant tout vulnérable à une panne régionale
Les données au niveau applicatif (fichiers de configuration, secrets) non incluses dans les sauvegardes
Des politiques de sauvegarde couvrant la production mais ignorant les environnements de staging et CI/CD
Aucune procédure de récupération documentée — juste une vague hypothèse qu’« on trouvera bien une solution »

Définir vos objectifs de récupération

Toute stratégie de sauvegarde devrait commencer par deux chiffres :

Objectif de point de récupération (RPO) : Combien de données pouvez-vous vous permettre de perdre? Si votre RPO est d’une heure, vous avez besoin de sauvegardes au moins toutes les heures.
Objectif de temps de récupération (RTO) : À quelle vitesse devez-vous être de retour en ligne? Cela détermine si vous avez besoin d’une infrastructure en attente tiède, de configurations en veilleuse, ou de déploiements actif-actif multi-régions complets.

Ces chiffres doivent venir de l’entreprise, pas des TI. Le coût des temps d’arrêt varie considérablement selon la charge de travail — une plateforme de commerce électronique orientée client a des exigences très différentes d’un tableau de bord de rapports internes.

Concevoir pour la restauration, pas pour la sauvegarde

Prendre des sauvegardes est la partie facile. Le vrai test est de savoir si vous pouvez restaurer à partir de celles-ci de manière fiable et dans votre fenêtre de récupération.

Construisez votre stratégie autour du processus de restauration :

Automatisez la planification des sauvegardes avec AWS Backup là où ça s’applique. Il centralise les politiques pour RDS, EBS, EFS, DynamoDB et S3, mais ne couvre pas tous les services — certaines charges de travail nécessitent des scripts de sauvegarde personnalisés en complément.
Copiez les sauvegardes inter-régions. Une sauvegarde qui réside dans la même région que votre infrastructure principale ne vous protège pas des pannes régionales.
Chiffrez tout. Utilisez les clés AWS KMS pour le chiffrement des sauvegardes, et assurez-vous que les clés elles-mêmes sont récupérables.
Versionnez votre infrastructure. Vos données sont inutiles sans l’infrastructure pour les exécuter. Stockez les modèles CloudFormation ou Terraform aux côtés de vos sauvegardes de données.
Étiquetez et organisez. Chaque sauvegarde doit être traçable à une charge de travail, un environnement et une politique de rétention spécifiques.

Testez la récupération régulièrement

Une sauvegarde que vous n’avez jamais testée est une sauvegarde en laquelle vous ne pouvez pas avoir confiance. Planifiez des exercices de récupération au moins trimestriellement :

Restaurez un snapshot de base de données vers une nouvelle instance RDS et vérifiez l’intégrité des données
Déployez un environnement parallèle à partir de modèles d’infrastructure en tant que code et confirmez son bon fonctionnement
Simulez un basculement régional et mesurez le RTO réel par rapport à votre cible
Documentez ce qui n’a pas fonctionné, ce qui a pris plus de temps que prévu et ce qui doit changer

Les tests de récupération ne sont pas optionnels. C’est la seule façon de savoir que votre stratégie fonctionne avant d’en avoir besoin.

Cycle de vie et gestion des coûts

Les sauvegardes s’accumulent rapidement et les coûts de stockage s’additionnent. Mettez en place des politiques de cycle de vie dès le premier jour :

Snapshots quotidiens conservés pendant 30 jours
Snapshots hebdomadaires conservés pendant 90 jours
Snapshots mensuels transférés vers le stockage froid et conservés pendant un an
Archives de conformité déplacées vers S3 Glacier Deep Archive pour la rétention à long terme

Le verrouillage de coffre AWS Backup peut imposer des politiques de rétention que même les administrateurs ne peuvent pas contourner — utile pour les exigences réglementaires, mais le mode conformité est irréversible. Configurez mal la période de rétention et vous paierez du stockage que vous ne pouvez pas supprimer. Testez rigoureusement vos politiques de cycle de vie avant de les verrouiller.

Protéger la porte arrière

Une stratégie de sauvegarde qui peut être vaincue par la même attaque qui met hors service vos systèmes de production n’est pas vraiment une stratégie. Les opérateurs de rançongiciels ciblent de plus en plus les sauvegardes en premier — s’ils peuvent chiffrer ou supprimer vos points de récupération, vous n’avez plus aucun levier.

Superposez vos défenses :

Coffres logiquement isolés. AWS Backup prend en charge des coffres isolés de vos comptes principaux. Même si un attaquant obtient un accès administrateur à la production, il ne peut pas atteindre les sauvegardes stockées dans une organisation de récupération distincte.
Approbation multipartite. Pour vos sauvegardes les plus critiques, l’approbation multipartite d’AWS Backup exige que plusieurs personnes de confiance autorisent l’accès au contenu des coffres isolés. Aucune information d’identification compromise ne peut à elle seule déverrouiller vos données de récupération.
Verrouillage de coffre en mode conformité. Le verrouillage de coffre AWS Backup impose des politiques de rétention qui ne peuvent pas être contournées — ni par les administrateurs, ni par root. Une fois verrouillé, les sauvegardes ne peuvent pas être supprimées avant l’expiration de leur période de rétention.
Copies inter-comptes. Copiez les sauvegardes vers un compte de sauvegarde dédié avec ses propres frontières IAM. Utilisez les politiques de contrôle des services (SCP) pour empêcher quiconque dans vos comptes de production de modifier ou supprimer les copies inter-comptes.
Moindre privilège sur les opérations de sauvegarde. Séparez qui peut créer des sauvegardes de qui peut les supprimer. Le principal IAM qui exécute votre tâche de sauvegarde nocturne ne devrait jamais avoir les permissions backup:DeleteRecoveryPoint.

Chacune de ces couches ajoute de la complexité opérationnelle et peut ralentir la récupération légitime — l’approbation multipartite exige que des approbateurs soient disponibles pendant un incident, et les coffres isolés nécessitent une organisation de récupération distincte à gérer. Le compromis en vaut la peine pour vos données les plus critiques, mais n’appliquez pas la protection maximale uniformément. Classez vos sauvegardes par impact métier et adaptez les contrôles au risque.

Vos sauvegardes sont la dernière ligne de défense. Traitez-les en conséquence — supposez que votre environnement principal est compromis et concevez les contrôles d’accès aux sauvegardes à partir de ce point de départ.

Commencez avant d’en avoir besoin

Le pire moment pour concevoir un plan de reprise après sinistre est pendant un sinistre. Construisez votre stratégie de sauvegarde tôt, automatisez-la rigoureusement, testez-la régulièrement et traitez-la comme une infrastructure qui nécessite le même soin et la même attention que vos systèmes de production. Le jour où vous en aurez besoin, vous serez content de l’avoir fait.