Les instantanés ne sont pas des sauvegardes : le playbook d’un CTO pour une reprise à l’épreuve des ransomwares

La semaine où un autre registre foncier national a été effacé et où un fournisseur de santé américain a perdu des données « significatives », une vérité s’est faite plus forte : si vos « sauvegardes » résident dans un endroit accessible par votre IAM de production, ce ne sont pas des sauvegardes. Ce sont des jetons de négociation.

Vous n’avez pas besoin d’un énième cours magistral sur les ransomwares. Il vous faut un plan de reprise qui survive à une compromission root sans drame, restaure assez vite pour sauver l’entreprise, et coûte un pourcentage à un chiffre de votre facture infra. Ce post vous donne ce plan.

Le problème : les instantanés se négocient, les sauvegardes non

Les équipes de ransomware ne commencent pas par chiffrer des fichiers. Elles commencent par supprimer les chemins de reprise. Si votre chemin de reprise est basé sur des instantanés EC2/EBS, un jeton admin compromis peut les purger en quelques minutes. Même une réplication inter‑régions ne vous sauvera pas si la même chaîne de fédération peut supprimer là‑bas aussi. Idem pour les volumes persistants Kubernetes, les autosnapshots de bases liés au même plan de contrôle, et les « exports hebdos » posés dans un bucket S3 sur lequel le rôle de votre app peut écrire.

Deux récents gros titres devraient faire réfléchir tout CTO : un attaquant a effacé la base du cadastre d’un pays ; un fournisseur américain desservant des milliers d’hôpitaux a signalé un important vol de données et des perturbations. Dans les deux cas, la continuité dépendait du fait que les sauvegardes soient immutables, isolées et éprouvées par des exercices. La plupart ne le sont pas.

Le cadre de décision : évaluez votre posture de reprise sur cinq axes

Avant d’acheter quoi que ce soit, évaluez votre posture de reprise selon cinq axes. Vous avez besoin des cinq au vert.

1) Mutabilité : un attaquant disposant d’identifiants admin prod peut‑il modifier ou supprimer vos sauvegardes ?

• Acceptable : S3 Object Lock (compliance mode) ou GCS Bucket Lock avec rétention. Azure Immutable Blob with Time‑based Retention.
• Non acceptable : instantanés ou objets supprimables par les mêmes principaux IAM qui opèrent la prod, ou par n’importe quel chemin SSO fédéré utilisé au quotidien.

2) Isolation : vos sauvegardes sont‑elles dans un rayon d’explosion distinct ?

• Acceptable : compte/projet/tenant cloud séparé avec des Service Control Policies (SCP) empêchant toute modification de politiques ou de verrous, chaîne d’admin séparée, KMS racine séparé, MFA et tokens matériels distincts.
• Non acceptable : même compte, même KMS, ou tout « break‑glass » que peut assumer un IdP compromis.

3) Indépendance des clés : pouvez‑vous déchiffrer si votre KMS principal est indisponible ou compromis ?

• Acceptable : clés KMS dédiées dans le compte de sauvegarde, avec matériau de clé et admins non partagés avec la prod. Optionnellement sous séquestre dans un HSM ou via un schéma à connaissance partagée.
• Non acceptable : données de sauvegarde chiffrées uniquement avec les mêmes clés KMS que celles utilisées par la prod.

4) SLO de récupérabilité : avez‑vous un RPO/RTO mesuré ?

• Acceptable : RPO défini et testé ≤ 15 minutes pour les données OLTP primaires ; RTO ≤ 4 heures pour une restauration full‑stack de votre service critique.
• Non acceptable : « On pense pouvoir restaurer en une journée. » Si vous ne l’avez pas chronométré, ça n’existe pas.

5) Couverture : tout ce que vous exécutez et sur quoi vous dépendez est‑il récupérable ?

• Acceptable : bases de données, object stores, état d’infra, images de conteneurs, secrets, artefacts CI, et dépendances SaaS (GitHub, Slack, Google Workspace, Notion) avec automatisation des exports.
• Non acceptable : uniquement des bases de données ou uniquement des instantanés de VM.

L’architecture de référence : des sauvegardes résilientes aux ransomwares sur cloud public

Schéma de base : double compte, objets verrouillés, sauvegardes versionnées

1. Créez un compte « Backup » dédié avec son propre root, MFA et des clés de sécurité matérielles. Pas de fédération depuis votre IdP corporate pour l’accès root. Appliquez des SCP interdisant toute modification des réglages Object Lock, la suppression de clés KMS, et les modifications de rôles sauf via une procédure de secours « break‑glass » contrôlée.
2. Approvisionnez des buckets S3 avec Object Lock activé en compliance mode, versioning activé, et une rétention par défaut (ex. 30 jours). Le mode Governance ne suffit pas ; le mode Compliance empêche même root de retirer la rétention avant expiration.
3. Utilisez la réplication inter‑comptes depuis un bucket « Staging Vault » dans votre compte prod vers les buckets verrouillés par Object Lock dans le compte Backup. La réplication doit être unidirectionnelle et initiée par un rôle de réplication dédié dans le compte de sauvegarde, pas depuis la prod. Le bucket de destination applique l’Object Lock à l’écriture.
4. Chiffrez avec une clé KMS du compte de sauvegarde (SSE‑KMS) sans délégation aux rôles de prod. Placez les admins de clé dans un groupe de sécurité distinct avec tokens matériels et contacts d’urgence hors bande.
5. Hiérarchisez le stockage : 30 jours en S3 Standard‑IA pour des restaurations rapides ; des « fulls » mensuels en Glacier Deep Archive pendant 12 mois. Object Lock s’applique aux versions et classes de stockage.

Outils de transfert de données : spécifiques aux apps, incrémentaux, vérifiables

• Postgres : utilisez pgBackRest ou WAL‑G pour expédier les sauvegardes de base et les WAL vers le Staging Vault, puis répliquez vers le bucket verrouillé. Configurez l’archivage continu vers un préfixe « append‑only » qu’un rôle applicatif de prod ne peut ni lister ni supprimer. Exécutez des jobs quotidiens de restore‑verify qui démarrent une instance temporaire, rejouent les WAL jusqu’à un horodatage cible, exécutent CHECKPOINT et lancent un jeu de requêtes de cohérence logique.
• MySQL : XtraBackup full + incrémental, expédition des binlogs, et vérification de restauration quotidienne.
• MongoDB : capture continue de l’Oplog avec mongod snapshot périodique et rejeu ; validez les comptes et hachages des collections après restauration.
• Blob stores : ne mirorez pas le bucket entier chaque heure. Générez des bundles adressés par contenu avec manifestes et hachages (par ex., tarballs zstd compressés par partition/jour) pour rendre l’intégrité vérifiable et la restauration parallélisable.
• État d’infra : backend distant pour l’état Terraform avec versioning et Object Lock, plus des snapshots périodiques vers le bucket verrouillé. Conservez des AMI ou des instantanés d’images pour l’OS de base « golden » dans le compte de sauvegarde.
• Secrets : export nocturne et rechiffrement des éléments Vault/Secrets Manager dans le compte de sauvegarde sous le KMS de sauvegarde. À la restauration, tout faire pivoter.

Dépendances SaaS : automatisez les exports fastidieux

• GitHub : miroitez les dépôts vers des remotes de sauvegarde en lecture seule dans le compte de sauvegarde ou vers un miroir Gitea neutre ; exportez chaque semaine les issues et métadonnées de PR.
• Slack : API d’export Enterprise pour les canaux publics et privés ; appliquez une politique de rétention légale. Stockez les exports sous Object Lock.
• Google Workspace/Microsoft 365 : utilisez les exports Vault/Compliance pour le mail et Drive ; mensuels pour les équipes non réglementées, hebdos pour les équipes régulées.
• CI/CD : snapshot du cache de build et des artefacts essentiels ; conservez les digests d’images Docker et une copie des images critiques dans le registre de sauvegarde.

Les chiffres qui comptent : taille, vitesse et coût

Ancrons cela avec un profil raisonnable de startup :

• Postgres OLTP primaire : 4 TB
• Données objet : 12 TB
• Infra/config/secrets/autres : équivalent 4 TB
• Total primaire : ~20 TB

Supposez un taux de changement quotidien de 2 % sur les jeux de données et 40 % de compression/déduplication sur les sauvegardes.

• Empreinte de stockage : ~8 TB de base full + ~400 GB/jour d’incrémentaux. Fenêtre chaude de 30 jours ≈ 8 TB + (0,4 TB × 30) = ~20 TB en S3 Standard‑IA.
• Coût mensuel du stockage chaud (us‑east‑1) : ~20 TB × 0,0125 $/GB ≈ 250 $. Doublez pour la réplication inter‑comptes ≈ 500 $. Ajoutez une marge requêtes/extractions : disons 700–900 $/mois.
• Archive froide : conservez un full mensuel en Glacier Deep Archive pendant 12 mois : 8 TB × 12 ≈ 96 TB × ~0,001 $/GB ≈ 100 $/mois.
• Débit de restauration : ciblez 1 TB/heure par base et 2–3 TB/heure pour les extractions parallèles de données objet. Votre base de 4 TB revient en 4 heures ; les blobs en ~4–6 heures.

Conclusion : une posture résiliente aux ransomwares pour ce profil représente largement moins de 1–2 % d’une facture cloud de 50–100 k$ par mois. Le vrai coût, c’est la discipline d’ingénierie pour l’exercer en drill.

Des runbooks qui fonctionnent vraiment (et comment le prouver)

Définissez des SLO avant d’écrire les étapes

• RPO : ≤ 15 minutes pour l’OLTP, 1 heure pour les blobs.
• RTO : ≤ 4 heures jusqu’au service visible par l’utilisateur, ≤ 24 heures pour les données de longue traîne.

Ordre des opérations de restauration

1. Confinement : verrouillez l’IdP, faites pivoter le break‑glass. Geler les comptes prod. Préservez la forensique : mémoire, disques et logs vers un bucket de preuves WORM séparé de vos buckets de sauvegarde.
2. Reconstruisez d’abord les fondations : identité (Okta/AD), primitives réseau, KMS dans le compte sain.
3. Secrets et images : remontez Vault/Secrets Manager depuis la sauvegarde. Faites pivoter immédiatement clés, tokens et mots de passe de bases après restauration.
4. Bases de données : restaurez la base, rejouez WAL/binlogs jusqu’à la cible RPO, validez schéma, comptes et hachages. Promouvez en lecture seule, puis basculez en primaire.
5. Blob/object stores : restauration en parallèle par partition/jour. Validez manifestes/hachages.
6. Apps/services : déployez à partir d’images « golden » ; bloquez strictement les AMI inconnues et les conteneurs non signés.
7. Trafic : basculement progressif derrière un feature flag ou d’abord en mode lecture seule, puis trafic d’écriture complet.

Cadence des exercices et métriques

• Mensuel : drill de restauration partielle de 2 heures (sous‑ensemble de DB + un service) pendant les heures ouvrées. Succès = RPO/RTO tenus, données validées, étapes du runbook horodatées.
• Trimestriel : journée complète, tabletop assisté par red team + restauration live dans un VPC isolé. Incluez les imports d’exports SaaS. Succès = les utilisateurs peuvent se connecter et effectuer une transaction réelle.
• Suivez : temps de restauration médian/95e, échecs de vérification, dépendances manquantes et surprises. Votre dossier pour le conseil d’administration doit montrer un SLO de reprise réellement tenu.

Anti‑patterns à éliminer ce trimestre

• « Le provider nous couvre » : les snapshots EBS, sauvegardes automatisées RDS et snapshots de PV GKE sont dans le même plan de contrôle. Pratiques pour restaurer, pas pour se défendre contre les ransomwares.
• KMS partagé : chiffrer les sauvegardes avec les mêmes clés ou les mêmes admins que la prod signifie un seul rayon d’explosion.
• « On misera sur le versioning » : S3 versioning sans Object Lock est supprimable par un admin.
• Posture tout‑chaud : une fenêtre chaude de 30 jours sans archive froide vous laisse exposé aux altérations à longue latence.
• Blobs invérifiables : des copies d’objets aléatoires sans manifestes ni hachages rendent les promesses d’intégrité performatives.

Et le hors ligne ?

Le véritable air‑gap reste l’or massif. Pour la plupart des startups, c’est ingérable opérationnellement. Un entre‑deux pragmatique :

• Instantané hors ligne trimestriel : exportez des fulls trimestriels vers des volumes LUKS chiffrés sur SSD amovibles, stockés hors site en sécurité avec journal de chaîne de garde. C’est votre copie « chute de météorite ».
• Variante cloud « air‑gap » : un compte de sauvegarde avec Object Lock + SCP, sans peering réseau permanent vers la prod, et une authent admin qui n’est pas fédérée depuis votre IdP corporate. Ce n’est pas un air‑gap littéral, mais ça brise la plupart des chaînes de compromission.

Juridique et forensique que vous serez heureux d’avoir

• Preuves WORM : écrivez les logs d’audit, la télémétrie EDR et les snapshots des systèmes compromis dans un bucket WORM séparé avec 1 an de rétention. Gardez‑le isolé logiquement et administrativement de votre volume de sauvegarde.
• Prêt en 72 heures : beaucoup de régimes exigent une notification d’incident sous 72 heures. Préparez à l’avance modèles, contacts, et une checklist factuelle de ce que vous pouvez attester (fenêtres de rétention, chiffrement au repos/en transit, IDs d’Object Lock).
• Couverture des tiers : documentez quels vendeurs vous fournissez pour la continuité et quelle est leur posture WORM/immutabilité. Incluez dans les MSA des clauses sur l’immutabilité des sauvegardes et les drills de reprise.

Open source, agents et l’incrémental partout

Deux tendances valent d’être notées dans la tech de cette semaine. D’abord, les bibliothèques de calcul incrémental sont désormais assez bonnes pour rendre la vérification continue peu coûteuse. Appliquez cet état d’esprit aux sauvegardes : calculez des sommes de contrôle et des requêtes de vérification en continu plutôt qu’en gros jobs du week‑end. Ensuite, la vague d’outils d’IA rend tentant de déléguer la discipline Ops à des « agents ». Ne le faites pas. Utilisez des agents pour générer des manifestes de restauration et valider des enregistrements, mais gardez‑leur hors de portée l’autorité de supprimer ou de déverrouiller. En cas de brèche, l’agence appartient aux humains.

Qui porte le sujet et comment le doter

• Un responsable unique : nommez un SRE Staff+ comme Recovery Owner. Sa fiche d’objectifs, ce sont les SLO RPO/RTO et le taux de réussite des drills.
• Budget : prévoyez 1–2 % de la dépense cloud. L’essentiel est du stockage ; le reste, du temps de drill.
• Heures opérationnelles : utilisez un pod nearshore pour mener les drills mensuels et maintenir les runbooks. Avec 6–8 heures de chevauchement avec les US, les drills n’explosent pas votre astreinte et vous gardez une couverture pour les incidents tôt le matin.

Points de départ pratiques pour les 30 prochains jours

1. Activez Object Lock dans un nouveau compte de sauvegarde dédié. Si vous ne pouvez pas, créez un nouveau bucket ; on ne peut pas l’activer rétroactivement sur des buckets existants.
2. Séparez le KMS dans ce compte de sauvegarde et retirez tous les principaux de prod. Documentez le break‑glass.
3. Câblez un outil de transfert de bout en bout : par ex., pgBackRest base + WAL vers Staging Vault, répliqué vers le bucket verrouillé. Prouvez une restauration en 4 heures sur un sous‑ensemble de 500 GB.
4. Exportez un SaaS dont vous dépendez (GitHub ou Slack) et stockez‑le sous Object Lock. Chronométrez l’opération.
5. Bloquez votre premier drill au calendrier et invitez le juridique. S’il n’est pas planifié, il n’existe pas.

Arbitrages et réalités

• Immutabilité vs agilité : Object Lock en mode compliance vous mordra quand vous ferez des erreurs. C’est le but. Utilisez des buckets de staging pour rattraper les erreurs avant verrouillage.
• Coût vs RTO : Glacier est bon marché mais lent. Conservez une fenêtre chaude de 30 jours en IA pour tenir le RTO ; poussez l’ancien en Deep Archive.
• Sécurité vs opérabilité : des comptes et clés séparés impliquent plus de cérémonie. Écrivez la cérémonie et entraînez‑vous, sinon vous inventerez des raccourcis pendant un incident.
• Humains vs outils : la meilleure architecture ne vous sauvera pas si la seule personne connaissant les étapes de restauration est en vacances. Faites de la polycompétence et enregistrez des walkthroughs en capture d’écran.

Si vous ne faites qu’une seule chose

Si vous ne faites qu’une seule chose ce trimestre, rendez un jeu de données réellement immuable et testez une restauration chronométrée. Vous apprendrez plus dans cet exercice que dans dix tabletop. Et vous ne confondrez plus jamais instantanés et sauvegardes.

Points clés

• Les instantanés ne sont pas des sauvegardes. Si l’IAM de prod peut supprimer votre chemin de reprise, un attaquant le peut aussi.
• Utilisez Object Lock/Bucket Lock dans un compte séparé avec des clés KMS séparées et des SCP.
• Fixez et mesurez RPO ≤ 15 minutes et RTO ≤ 4 heures pour votre chemin critique.
• Faites des drills mensuels (partiels) et trimestriels (complets). Si ce n’est pas testé, ça n’existe pas.
• Sauvegardez les dépendances SaaS, pas seulement l’infra : GitHub, Slack, Google/Microsoft, CI.
• Visez 1–2 % de la dépense cloud pour des sauvegardes résilientes ; le reste, c’est de la discipline.
• Nommez un Recovery Owner et utilisez un pod nearshore pour garder les runbooks frais avec 6–8 heures de chevauchement.