Un éditeur de logiciel installé en Haute-Savoie nous a confié l'audit de son infrastructure après un incident. Ses sauvegardes de bases de données étaient déposées chaque nuit dans un espace de stockage objet chez son fournisseur cloud, la tâche se terminait correctement et le rapport quotidien arrivait par courrier électronique. Un matin, un script de nettoyage écrit deux ans plus tôt par un ancien développeur s'est déclenché avec un paramètre erroné et a supprimé le contenu du répertoire de destination. La suppression a été traitée normalement, répliquée sur les trois sites du fournisseur et confirmée sans message d'erreur. Le rapport du lendemain annonçait une sauvegarde réussie, puisque le fichier de la nuit avait bien été déposé.
Le stockage objet est un excellent outil, présent dans presque toutes nos architectures. Le malentendu porte sur ce que garantit sa durabilité. Nos missions AWS commencent par ce point, et le raisonnement vaut pour l'équivalent chez Google Cloud ou chez Microsoft Azure : le nom du produit change, la règle non.
Ce que la durabilité d'un stockage objet protège vraiment
Quand un fournisseur annonce une durabilité très élevée, il décrit la probabilité qu'un fichier déposé disparaisse à cause d'une défaillance de son matériel. Chaque objet est découpé et copié sur plusieurs équipements, souvent dans plusieurs bâtiments, et le service reconstruit automatiquement une copie perdue. Cette promesse est tenue et précieuse : vous n'avez plus à craindre le disque qui claque ni le serveur de sauvegarde noyé par une fuite d'eau.
Cette promesse ne couvre rien d'autre. Elle ne dit rien de vos droits d'accès, de vos scripts, de vos erreurs de manipulation ni d'un attaquant qui aurait obtenu vos clés. Un stockage répliqué protège du défaut matériel, il ne protège ni d'une suppression, ni d'un chiffrement malveillant, ni d'une erreur humaine. Dans ces trois cas, la réplication travaille contre vous, puisqu'elle propage fidèlement l'opération destructrice.
Il faut donc séparer deux mots que le langage courant confond. La durabilité désigne la conservation de ce que vous avez déposé. La sauvegarde désigne votre capacité à revenir à un état antérieur à un incident. Un espace rempli de copies récentes offre la première sans offrir la seconde.
Les quatre chemins par lesquels un espace de stockage perd son contenu
Nous rencontrons ces quatre chemins régulièrement, et aucun ne relève d'une panne du fournisseur.
- Une commande ou un script supprime le contenu. Une synchronisation réglée pour refléter un répertoire d'origine efface dans la destination ce qui a disparu à la source. Un nettoyage automatique se déclenche avec un mauvais préfixe. L'opération est autorisée, donc elle réussit.
- Un compte compromis efface délibérément les copies. Les attaquants savent que détruire les sauvegardes précède le chiffrement. Des clés d'accès inscrites en clair dans un fichier de configuration ou dans un dépôt de code leur suffisent, et ces clés disposent souvent de droits bien plus larges que nécessaire.
- Une règle de cycle de vie supprime avant l'échéance métier. Ces règles effacent automatiquement les objets anciens. Une règle réglée sur quelques semaines coexiste très bien avec une obligation comptable de plusieurs années, jusqu'au jour où quelqu'un cherche une pièce ancienne.
- La copie était corrompue depuis le début. Une base de données sauvegardée à chaud sans mise en cohérence produit un fichier de la bonne taille, déposé sans erreur et inutilisable à la restauration. Personne ne s'en aperçoit tant que personne ne restaure.
Un facteur aggravant s'y ajoute : dans la majorité des cas que nous reprenons, l'espace de stockage se trouve dans le même compte cloud que la production, avec les mêmes administrateurs et les mêmes clés. Une compromission unique emporte alors les deux. Savoir qui détient le compte principal est inséparable du sujet, et nous le traitons dans notre article sur le compte racine d'un environnement cloud.
Les trois réglages qui changent la nature de l'espace de stockage
Un espace de stockage objet peut devenir une véritable destination de sauvegarde, à condition de poser trois choses explicitement. Aucune n'est active par défaut et aucune ne s'applique rétroactivement, ce qui rend le moment de la décision déterminant.
Le premier réglage est la conservation des versions. Lorsqu'elle est active, une suppression ne détruit pas l'objet mais pose un marqueur, et l'écrasement d'un fichier conserve la version précédente : vous pouvez revenir à l'état antérieur à l'incident. Deux conditions l'accompagnent. Elle doit être activée avant le sinistre, ce qui constitue le regret le plus fréquent de nos audits, et sa profondeur doit dépasser votre délai réaliste de détection, car conserver les versions quelques jours ne sert à rien si vos incidents se découvrent au bout de trois semaines. Ces versions occupent de l'espace, et cet arbitrage relève de la démarche décrite dans notre article sur une facture cloud qui augmente.
Le deuxième réglage est le verrouillage de conservation, qui empêche la suppression ou la modification d'un objet pendant une durée fixée, y compris par un administrateur. C'est le seul dispositif qui résiste à un compte compromis, et celui qui distingue une destination de sauvegarde d'un simple dossier distant. Il exige un cadrage sérieux : trop longue, la durée vous empêchera d'effacer une donnée que vous devez retirer ; trop courte, elle ne protège pas grand-chose. Nous la réglons sur vos obligations de conservation.
Le troisième point est la séparation des comptes. La destination de sauvegarde doit vivre dans un compte distinct de la production, avec ses propres identités, et l'écriture doit s'y faire avec des droits limités : déposer, oui, effacer, non. C'est la traduction dans le cloud de la règle des trois copies sur deux supports dont une hors site, détaillée dans notre article sur la sauvegarde 3-2-1 appliquée à une PME. Deux espaces de stockage dans le même compte, avec le même administrateur, ne font pas deux lieux.
La restauration est le seul test qui prouve quelque chose
Un rapport de sauvegarde vert indique que l'écriture a réussi. Il ne dit pas que le fichier est exploitable, que vous savez le retrouver, ni combien de temps prendra la remise en service. Ces trois informations ne s'obtiennent qu'en restaurant réellement.
Nous distinguons deux exercices. La restauration ponctuelle consiste à récupérer un fichier ou une base et à vérifier son contenu, ce qui se fait vite et doit être répété. La restauration complète consiste à remonter le service à partir de la seule copie, en mesurant le temps écoulé et en le comparant au temps de reprise visé, que le vocabulaire technique appelle le RTO. Ce second exercice révèle presque toujours quelque chose : un mot de passe absent de la procédure, une dépendance oubliée, ou un volume dont l'extraction demande plus de temps que prévu.
Ce dernier point mérite attention avec les classes de stockage dites d'archivage : elles conservent les données à moindre frais, mais leur relecture demande un délai de mise à disposition et un coût de sortie. Ce compromis convient à une archive légale, et pas à la sauvegarde dont vous aurez besoin dans l'heure. Nous répartissons donc les données selon l'usage attendu, pas selon la seule ligne de dépense.
Comment nous cadrons un stockage objet de sauvegarde
Nous commençons par vérifier que rien n'est accessible publiquement, ce qui reste la surprise la plus courante, héritée d'un accès ouvert le temps d'un test et jamais refermé. Nous relevons ensuite les droits accordés, en remplaçant les clés à durée illimitée inscrites dans les applications par des identités réduites au strict nécessaire, et en séparant l'écriture de la suppression.
Nous activons la conservation des versions et le verrouillage sur une profondeur validée avec vous, nous mettons en place la copie vers un compte distinct pour les données qui le justifient, et nous relisons les règles de cycle de vie au regard de vos obligations de conservation. Nous exécutons enfin une restauration réelle, dont nous consignons la date et le résultat, avant de replanifier l'exercice. Le raisonnement vaut aussi pour les données confiées à un éditeur, avec ses spécificités, que nous traitons dans notre article sur la manière de sauvegarder un service en ligne hors de l'éditeur.
Ces interventions se conduisent en mission à 1000 HT / jour, avec le même montant hors taxes en euros et en francs, à distance dans toute la France et en Suisse.
Si vos sauvegardes atterrissent dans un espace hébergé par le même compte que votre production, avec les mêmes clés et sans verrouillage, transmettez-nous la configuration. Nous vous dirons ce qu'il faut ajouter pour en faire une sauvegarde, ou pourquoi il vaut mieux cesser de l'appeler ainsi.