Une sauvegarde accessible depuis le compte compromis n’est pas une sauvegarde

Presque toutes les organisations sauvegardent. Beaucoup moins peuvent répondre à la question qui compte réellement : depuis le compte le plus susceptible d’être compromis, peut-on effacer ou chiffrer les sauvegardes ?

Quand la réponse est oui — et elle l’est plus souvent qu’on ne le croit — vous n’avez pas une stratégie de reprise. Vous avez une copie supplémentaire des données, rangée dans le même périmètre de confiance que l’original.

Le problème : la sauvegarde hérite du domaine qu’elle doit protéger

La façon dont la plupart des environnements se construisent est parfaitement logique à chaque étape et catastrophique au total.

L’équipe qui exploite les serveurs exploite aussi la sauvegarde — c’est la même compétence, la même astreinte. Le compte de service de la sauvegarde a besoin d’accéder à tout ce qu’il sauvegarde, donc il dispose de droits étendus. La console de sauvegarde s’authentifie contre le même annuaire que le reste, parce que gérer un second annuaire est une corvée. Et la rétention est configurée par une personne qui peut aussi la modifier, puisque c’est son travail.

Chaque décision est raisonnable. Ensemble, elles produisent une situation où un attaquant qui obtient des droits d’administration sur le domaine obtient, dans le même mouvement, la capacité de supprimer votre capacité de restaurer.

C’est exactement le déroulement d’un rançongiciel moderne. Le chiffrement n’est pas la première étape : c’est la dernière. Avant cela, l’attaquant passe des jours ou des semaines à cartographier l’environnement, et la console de sauvegarde figure en tête de liste — parce qu’une organisation capable de restaurer ne paie pas.

Les risques concrets

La suppression des sauvegardes en amont du chiffrement. Le scénario dominant. Rien de sophistiqué : des identifiants valides et une interface d’administration qui fait ce qu’on lui demande.

La rétention silencieusement raccourcie. Plus discret et plus efficace. Personne ne remarque qu’une politique est passée de 90 à 7 jours ; l’absence est constatée le jour de la restauration.

La sauvegarde du problème. Si le maliciel est présent depuis six semaines et que votre rétention en couvre quatre, toutes vos copies contiennent la compromission. La rétention n’est pas qu’une question de coût de stockage : elle détermine jusqu’où vous pouvez remonter avant l’incident.

La restauration jamais essayée. Une sauvegarde non testée est une hypothèse. Les défaillances qu’on découvre en situation réelle sont rarement le stockage — ce sont les dépendances : un secret qui n’était pas dans la portée, une base restaurée sans le service qui la peuplait, un certificat expiré, un ordre de démarrage que personne n’avait documenté.

Le délai de restauration inconnu. Bien des organisations connaissent leur objectif de point de reprise (combien de données on accepte de perdre) et ignorent complètement leur objectif de délai de reprise réel. Restaurer 40 To depuis un stockage d’archives n’est pas une opération de quelques heures. La direction découvre ce chiffre au pire moment possible.

Ce qu’il faut faire, dans l’ordre

1. Rendre les sauvegardes inaccessibles depuis le compte qui pourrait être compromis

C’est le contrôle qui détermine tous les autres. Concrètement :

• Immuabilité — verrouillage de la rétention côté stockage, de sorte que même un administrateur ne puisse pas supprimer avant échéance. La distinction est essentielle : « seuls les administrateurs peuvent supprimer » ne protège de rien, puisque l’attaquant vise précisément ce rôle.
• Séparation de l’identité. Le coffre de sauvegarde ne devrait pas s’administrer avec les mêmes comptes que la production. C’est la mesure la plus impopulaire de cette liste et la plus efficace.
• Suppression réversible activée, avec une fenêtre de récupération que personne ne peut réduire à zéro sans une seconde autorisation.

2. Sortir au moins une copie du périmètre

La règle classique — trois copies, deux supports, une hors site — reste valable, mais dans le nuage elle se traduit mal. « Hors site » ne veut pas dire une autre région du même abonnement, avec les mêmes accès. Une copie doit être hors de portée d’une compromission de votre plan de contrôle : autre abonnement, autre locataire, ou stockage hors ligne selon la criticité.

3. Aligner la rétention sur le temps de détection, pas sur le budget

Choisissez la durée de rétention en fonction de la durée pendant laquelle une compromission pourrait passer inaperçue chez vous. Si vous ne connaissez pas ce délai, prenez-le comme aveu utile : c’est probablement plus long que votre rétention actuelle. La rétention longue durée coûte moins cher que la strate de stockage à laquelle on l’associe généralement.

4. Restaurer pour de vrai, sur un calendrier

Pas une vérification d’intégrité — une restauration complète d’un service réel dans un environnement isolé, avec chronomètre. Une fois par an au minimum, et systématiquement après un changement d’architecture.

Ce test produit deux choses qu’aucun document ne peut fournir : votre délai de reprise réel, et la liste des dépendances que personne n’avait pensé à inclure dans la portée. Cette seconde liste est presque toujours la vraie découverte.

5. Surveiller la sauvegarde comme une cible

Les modifications de politique de rétention, les suppressions, les échecs de tâche et les changements de droits sur le coffre devraient déclencher une alerte dans le même canal que le reste de votre surveillance de sécurité — et être lus par quelqu’un. Une politique de rétention modifiée hors fenêtre de changement est l’un des signaux précoces les plus fiables qui existent, et presque personne ne l’observe.

6. Écrire la procédure en supposant que rien ne fonctionne

Le plan de reprise stocké dans le système qui vient de tomber n’est pas un plan. Idem pour celui qui exige une authentification multifacteur au service d’annuaire indisponible, ou qui suppose que la personne qui l’a rédigé est joignable.

Gardez une copie hors ligne, avec les coordonnées d’escalade, les identifiants de secours en dépôt fiduciaire, et l’ordre de restauration des services. Relisez-la une fois par an ; elle vieillit plus vite que le reste.

La question qui règle le débat

Quand on discute d’investissement en résilience, il y a une question qui tranche plus efficacement que n’importe quel argumentaire :

Si un attaquant obtenait aujourd’hui les droits d’administration sur le domaine, combien de temps lui faudrait-il pour rendre nos sauvegardes inutilisables ?

Si la réponse se mesure en minutes, aucune autre partie du plan de reprise ne compte vraiment. Et c’est la réponse par défaut dans la majorité des environnements — non par négligence, mais parce que chaque décision individuelle qui y a mené était la bonne.