Aller au contenu

RestoreProof

Une sauvegarde qui existe n'est pas une sauvegarde qui se restaure.

Le job de sauvegarde tourne toutes les nuits. Il finit en vert. Le fichier est là, il pèse à peu près le bon poids, la supervision est silencieuse. Personne ne le restaure jamais — restaurer prend une demi-journée, il faut une machine libre, et rien ne presse tant que rien n'a brûlé.

Le jour où il faut vraiment restaurer, on découvre :

  • le dump s'arrête au milieu d'une table, parce que le tar a été pris sur une base vivante ;
  • il manque un schéma, ajouté six mois plus tôt et jamais inclus dans le job ;
  • l'arborescence est passée de douze mille fichiers à quarante, un chemin ayant changé sans que personne ne s'en aperçoive ;
  • tous les fichiers sont présents, et tous vides ;
  • l'annuaire recharge ses comptes mais pas les empreintes de mots de passe : plus personne n'entre ;
  • l'application refuse d'ouvrir un fichier pourtant intact, parce que la version ne correspond plus.

Aucun de ces cas ne se voit dans un job de sauvegarde vert. Tous se voient en restaurant.

Ce que fait RestoreProof

RestoreProof restaure vos sauvegardes, en vrai, à la fréquence que vous choisissez, et vérifie les données restaurées.

Un agent — le runner — tourne sur votre infrastructure. À chaque exécution, il télécharge la sauvegarde, la décompresse, démarre un bac à sable jetable (une base, un service), y restaure les données, puis lance des sondes qui posent des questions vérifiables : cette table contient-elle au moins autant de lignes ? ce compte peut-il encore se connecter ? ce certificat est-il encore valide et signé par la bonne autorité ? l'application redémarre-t-elle sur ces données ? Chaque sonde s'exécute dans son propre conteneur, détruit ensuite, comme le bac à sable et son espace de travail.

Le résultat part vers le control plane sous forme d'un rapport signé.

Ce qui ne quitte jamais votre infrastructure

C'est la contrainte d'architecture, pas une option de configuration.

Reste chez vous Arrive au control plane
Les données de sauvegarde Le verdict de chaque sonde
Les identifiants de vos sources (S3, base, NFS) Les mesures : nombre de fichiers, de lignes, d'octets
Les mots de passe des bacs à sable Des journaux assainis
Le contenu restauré La signature du rapport

Les secrets d'un plan ne sont jamais des valeurs : ce sont des références (env://, file://, vault://, sops://) que le runner résout dans son propre environnement. Une référence qui ne se résout pas fait échouer la sonde avec le nom de la clé en cause, jamais sa valeur.

Conséquence pratique : compromettre notre SaaS ne donne accès ni à vos sauvegardes ni à vos accès. Il n'y a rien à y prendre. C'est aussi ce qui rend le produit adoptable par une équipe qui n'a pas le droit de sortir ses données.

Ce que vaut une preuve signée

Chaque rapport est signé en Ed25519 par le runner qui l'a produit, avec une clé qui n'existe que chez vous. Le rapport est téléchargeable, et vérifiable par un tiers — auditeur, assureur, équipe sécurité d'un client — sur la page publique /verify de l'application.

Deux niveaux, et il faut les distinguer :

  1. La vérification hors ligne. Elle se fait entièrement dans le navigateur du lecteur, sans rien nous envoyer et sans appeler notre API. Elle établit que le fichier est intact et cohérent depuis sa signature. La page ne montre comme prouvé que ce que la signature couvre réellement ; les champs lisibles qu'elle ne couvre pas sont affichés comme non signés.
  2. L'attestation. La vérification hors ligne ne peut pas dire qui a signé : la clé publique voyage dans le fichier, donc n'importe qui peut fabriquer une paire de clés, signer ce qu'il veut, et obtenir un fichier qui se vérifie. Le lecteur peut donc, s'il le souhaite, demander à notre API une seule chose : l'empreinte de clé qu'il a sous les yeux est-elle bien celle enregistrée pour ce rapport au moment où nous l'avons reçu ? Cet appel n'est jamais automatique, et il ne divulgue aucun contenu de rapport.

Un rapport dit donc : à telle date, cette sauvegarde a été restaurée sur telle infrastructure, ces contrôles ont été exécutés, voici leurs mesures — et cela n'a pas été retouché depuis.

Ce que RestoreProof ne fait pas

  • Il ne sauvegarde rien. Vos jobs de sauvegarde restent les vôtres.
  • Il ne restaure pas votre production. Le bac à sable est jetable et isolé.
  • Il ne stocke aucun de vos secrets, donc il ne peut pas vous les redonner.
  • Il ne devine pas vos seuils : c'est un essai réel qui les mesure (la calibration).

Par où commencer