Chapitre 33. Sauvegardes et snapshots

Objectifs pédagogiques¶

Décrire le contenu d'un snapshot et démontrer pourquoi il est inutilisable sans le matériel de scellement de son époque. Le produire sous une identité au moindre privilège. Automatiser la production en édition Community. Protéger un snapshot sans le chiffrer avec Vault. Définir une politique de rétention. Tenir l'inventaire par époque. Vérifier une sauvegarde.

Prérequis¶

Chapitre 24 (ce que chaque nœud détient), chapitre 16 (l'exception annoncée), chapitre 21 (les copies passées et leurs époques), chapitre 23 (le gardien, dont l'existence conditionne l'exploitation du snapshot).

Cours¶

33.1 Ce qu'un snapshot contient, et ce qu'il lui manque¶

Un snapshot est l'image complète de l'état du cluster à un instant : tous les montages, tous les secrets, toutes les identités, toutes les policies, tous les baux, la table des tokens, la configuration du seal. Il est produit par le nœud actif, à chaud, sans interruption, et il sort chiffré par la barrière. Ce fichier n'est pas un export lisible, c'est le coffre entier tel qu'il vit sur les disques.

La conséquence gouverne toute la partie : un snapshot ne s'ouvre qu'avec le matériel de scellement de son époque. Le fichier contient le keyring chiffré par la clé racine, elle-même protégée par le seal en vigueur au moment de la prise. Restaurer sur du matériel neuf exige donc, sous Shamir, les parts d'alors ; sous seal automatique, l'accès à la clé d'enveloppe d'alors. Un opérateur qui détient le snapshot mais plus son gardien détient un bloc opaque, et aucun paramètre ne le sauve.

Deux enseignements immédiats. D'abord, la règle du chapitre 5 sur la séparation des sauvegardes et du matériel de scellement décrit exactement ce que doit réunir un attaquant, et exactement ce que doit réunir l'équipe de reprise. Ensuite, sauvegarder Vault, c'est sauvegarder deux choses : les snapshots du core, et de quoi reconstituer le gardien. Une stratégie qui ne couvre que la première moitié produit des fichiers que personne ne pourra jamais ouvrir.

33.2 Produire un snapshot¶

[Laboratoire]

vault operator raft snapshot save /var/backups/vault/astrea-$(date +%Y%m%dT%H%M%SZ).snap
ls -l /var/backups/vault/

La commande s'adresse au nœud actif ; lancée sur un standby, elle est transmise. L'équivalent en API sert à l'automatisation : une lecture sur le chemin de snapshot renvoie le flux du fichier, ce qui permet de le chiffrer et de l'expédier sans jamais l'écrire en clair sur le disque du nœud. Le droit correspondant s'écrit comme un autre.

path "sys/storage/raft/snapshot" {
  capabilities = ["read"]
}

Deux points d'exploitation méritent d'être notés. La prise est cohérente : c'est l'état engagé du journal, pas une copie de fichiers prise pendant que le serveur écrit. La sauvegarde par copie du répertoire de données à chaud produit une image potentiellement incohérente et n'a pas sa place ici ; l'arrêt propre suivi d'une copie à froid reste valide, au prix de l'indisponibilité. Et la prise coûte : un snapshot de plusieurs centaines de mégaoctets mobilise le nœud actif le temps de sa production, ce qui plaide pour une planification hors des pics et pour la surveillance de sa durée.

33.3 Automatiser en édition Community¶

L'édition Enterprise sait planifier des snapshots automatiques et les déposer dans un stockage distant, avec leur rétention. En édition Community, l'automatisation s'écrit, sous une contrainte héritée du chapitre 30 : les nœuds poussent, rien ne vient les chercher.

[Production]

#!/bin/sh
set -eu
# 1. Ne rien faire si ce noeud n'est pas l'actif (ch. 26 : 200 = actif, 429 = standby)
code=$(curl -s -o /dev/null -w '%{http_code}' --cacert "$VAULT_CACERT" "$VAULT_ADDR/v1/sys/health")
[ "$code" = "200" ] || exit 0

# 2. S'authentifier avec le role AppRole dedie "backup" (policy : lecture du snapshot)
TOKEN=$(vault write -field=token auth/approle/login \
          role_id="$ROLE_ID" secret_id="$(cat /run/vault/backup-secret-id)")

# 3. Prendre le snapshot et le chiffrer AU FIL DE L'EAU, jamais de clair sur disque
horodatage=$(date -u +%Y%m%dT%H%M%SZ)
curl -s --cacert "$VAULT_CACERT" -H "X-Vault-Token: $TOKEN" \
     "$VAULT_ADDR/v1/sys/storage/raft/snapshot" \
  | gpg --encrypt --recipient astrea-backup --trust-model always \
  > "/var/backups/vault/astrea-${horodatage}.snap.gpg"

# 4. Empreinte, puis expedition vers le depot en ecriture seule
sha256sum "/var/backups/vault/astrea-${horodatage}.snap.gpg" \
  > "/var/backups/vault/astrea-${horodatage}.sha256"
rsync -a --remove-source-files /var/backups/vault/astrea-${horodatage}.* \
      backup-01.astrea.lab:/depot/vault/

vault token revoke -self >/dev/null 2>&1 || true

Chaque ligne applique un chapitre. Le test de santé évite trois snapshots simultanés et les prend là où ils sont cohérents. L'identité dédiée reprend la chaîne du chapitre 13, avec une policy d'une seule règle. Le chiffrement en flux garantit qu'aucune version en clair ne touche le disque, même transitoirement. L'empreinte détecte la corruption silencieuse, qui existe et se voit tard. Le dépôt reçoit en écriture seule : le compte peut déposer, pas lister ni relire ni supprimer, ce qui borne les dégâts d'un nœud compromis. Enfin, le token meurt en sortie.

Ce flux ajoute une ligne à la matrice du chapitre 29, et c'est l'occasion d'appliquer la doctrine qui y était écrite : une exception nécessaire se promeut au dossier plutôt qu'elle ne s'installe en silence.

33.4 Protéger la sauvegarde sans Vault¶

Le chapitre 16 avait posé la contrainte : les sauvegardes de Vault ne peuvent pas être chiffrées par Vault, sous peine de créer le cercle où restaurer Vault exige Vault. La protection se construit donc avec des moyens autonomes, et le fil rouge en retient trois, cumulés.

Le chiffrement par une clé hors Vault. Une paire dédiée, dont la partie publique est déployée sur les nœuds, ce qui ne permet que de chiffrer, et dont la partie privée vit hors ligne, sur deux supports en coffre, sous double détention. Aucune copie de cette clé privée ne réside sur une machine connectée, et surtout pas sur un nœud Vault : sinon la compromission qui donne le snapshot donne aussi la clé.

La séparation d'avec le matériel de scellement. La clé privée de sauvegarde et les parts de vault-transit-01 ne partagent ni coffre, ni détenteurs, ni procédure. Réunir en un lieu le snapshot, sa clé de chiffrement et le matériel de scellement, c'est fabriquer un Vault portable.

Le contrôle d'accès au dépôt. Il accepte les dépôts des nœuds, refuse la lecture et la suppression à ces mêmes comptes, journalise tout vers la supervision, et sa copie hors site suit le même régime. Le troisième scénario du chapitre 31 rappelle pourquoi : la lecture non autorisée d'un dépôt est un vol de coffre, et aucune commande Vault ne le rattrape.

33.5 La rétention, un arbitrage à deux sens¶

Combien de temps garde-t-on une sauvegarde ? La réponse habituelle regarde la disponibilité : plus on garde, plus loin on peut remonter. Le chapitre 21 impose de regarder aussi dans l'autre sens : chaque snapshot conservé est une copie complète du coffre, ouvrable par le matériel de scellement de son époque. Une rétention de deux ans, c'est deux ans de copies à garder, à inventorier, et à considérer dans chaque analyse de compromission de parts.

Celle d'Astrea, consignée : vingt-quatre snapshots horaires, quatorze quotidiens, six mensuels, puis destruction attestée. Chaque destruction s'inscrit au registre, parce qu'un snapshot n'est réputé disparu que lorsque toutes ses copies le sont, copie hors site comprise.

Deux compléments donnent à la politique sa valeur. L'inventaire par époque relie chaque tranche de snapshots à la génération de parts et à la version de clé d'enveloppe qui l'ouvrent : le jour où un porteur part, la question « quelles sauvegardes son ancienne part ouvrait-elle » a une réponse en une ligne. Et la revue de cet inventaire accompagne chaque rekey, faute de quoi l'organisation accumule des copies dont plus personne ne sait ce qui les protège.

33.6 Vérifier, ou n'avoir rien fait¶

Une sauvegarde non vérifiée n'est pas une sauvegarde, c'est un fichier. La formule paraît triviale jusqu'au jour où l'on découvre que le minuteur produisait depuis quatre mois des fichiers de zéro octet.

Niveau	Fréquence	Ce qu'il vérifie
Superficiel	quotidien, automatique	le fichier existe, taille attendue, empreinte correcte, arrivé au dépôt et hors site
Cryptographique	hebdomadaire	le fichier se déchiffre, ce qui mobilise la clé hors ligne ou un contrôle de chaîne équivalent
Fonctionnel	mensuel	la restauration réelle sur un cluster jetable, avec le matériel de scellement de l'époque

Le niveau superficiel a une subtilité : l'absence de fichier lève une alerte au même titre qu'un fichier anormal. L'alerte qui manque le plus souvent est celle du silence.

Seul le niveau fonctionnel prouve quelque chose, et c'est celui que le TP 15 fait exécuter. Son résultat se consigne avec une donnée que le chapitre 34 réclamera : la durée, mesurée du fichier au service rendu.

Exemple : la première sauvegarde vérifiée¶

Le dispositif est en place depuis une semaine : minuteur horaire sur les trois nœuds, seul l'actif produisant, chiffrement en flux, dépôt en écriture seule, copie hors site quotidienne. La revue porte sur la première restauration d'épreuve.

Le déroulé. Fichier choisi, le snapshot de la veille au soir, 412 mégaoctets chiffrés. Sortie de la clé privée du coffre selon la procédure à deux personnes, déchiffrement sur la machine d'épreuve, empreinte confirmée. Cluster jetable monté pour l'occasion, seal pointant sur la même clé d'enveloppe : le point qui avait fait débat en préparation, et que la section 33.1 avait tranché sur le papier. Restauration en quatre minutes, descellement automatique, annuaire correct, montages présents, lecture de test conforme.

Trois constats au registre. La durée totale, du coffre au service rendu, s'établit à une heure cinquante-cinq, dont quarante minutes pour l'accès au coffre et le déchiffrement : le chapitre 34 en fera un chiffre d'engagement plutôt qu'une estimation. Les baux restaurés ne correspondaient plus au monde réel, le snapshot contenant des credentials que la base ne connaissait plus, question traitée nulle part et qui devient une étape de la procédure du chapitre 35. Et la copie hors site de l'avant-veille était absente : la tâche d'expédition avait échoué en silence pendant deux jours, faute d'alerte sur le silence.

La ligne du registre que l'équipe a retenue : « Nous avons trouvé une sauvegarde manquante en essayant d'en restaurer une autre. »

Sécurité : la sauvegarde comme actif¶

Un snapshot est le coffre. Chiffré, certes, mais entier, daté, transportable. Il se traite au même niveau que les disques des nœuds, avec sa garde, son inventaire, sa destruction attestée.

La clé de sauvegarde ne vit pas avec ce qu'elle protège. Partie publique sur les nœuds, partie privée hors ligne, en double détention, dans un coffre distinct de celui des parts.

Le dépôt en écriture seule borne la compromission. Un nœud compromis dépose ; il ne peut ni relire l'historique ni le supprimer. Sans cette asymétrie, l'attaquant repart avec toutes les époques et efface derrière lui.

La rétention est une décision de sécurité. Garder plus, c'est protéger plus longtemps et exposer plus de copies.

Le silence est une panne. Une chaîne de sauvegarde qui cesse de produire ne déclenche aucune erreur : elle ne fait rien. L'alerte sur l'absence de fichier attendu vaut mieux que dix contrôles sur les fichiers présents.

Erreurs fréquentes¶

Croire qu'un snapshot suffit. Sans le matériel de scellement de son époque, le fichier est opaque (section 33.1).

Chiffrer les snapshots avec Transit. Le cercle parfait, où restaurer Vault exigerait Vault (section 33.4).

Ranger la clé de sauvegarde à côté des parts. Un seul coffre ouvert, et l'attaquant obtient le fichier, sa clé et le moyen d'ouvrir le contenu (section 33.4).

Copier le répertoire de données à chaud. L'image est potentiellement incohérente et donne une fausse assurance (section 33.2).

Automatiser sans vérifier le silence. Le minuteur meurt, les fichiers cessent d'arriver, personne ne le voit avant la restauration (sections 33.3, 33.6).

Confondre déchiffrable et restaurable. Un fichier qui s'ouvre n'a rien prouvé sur son contenu. Seule la restauration fonctionnelle conclut (section 33.6).

Garder sans inventorier. Des dizaines de copies dont plus personne ne sait quelle génération de parts les ouvre, et chaque départ de porteur devient insoluble (section 33.5).

Mise en pratique : produire, protéger, prouver¶

Sur papier ; réponses commentées en fin de partie.

Rédigez la policy complète du rôle de sauvegarde, au moindre privilège strict, et justifiez l'absence de chaque droit que l'on pourrait être tenté d'ajouter.
Une équipe propose de simplifier : les snapshots restent en clair sur le dépôt, protégé par le chiffrement de son volume et un pare-feu strict. Rédigez l'analyse comparée des deux dispositifs, avec la menace que chacun couvre et laisse ouverte.
Concevez le tableau d'inventaire par époque : colonnes, source de chaque information, fréquence de mise à jour, et la question d'audit à laquelle il doit répondre en moins d'une minute.

Questions de compréhension¶

Que contient exactement un snapshot, et sous quelle forme sort-il du serveur ?
Énoncez la condition d'exploitation d'un snapshot, et ce que l'option de forçage contourne ou ne contourne pas.
Pourquoi « sauvegarder Vault » désigne-t-il deux objets et non un seul ?
Comparez la prise par snapshot et la copie du répertoire de données, à chaud puis à froid.
Détaillez la logique du script d'automatisation : pourquoi le test de santé, le chiffrement en flux, le dépôt en écriture seule.
Pourquoi les sauvegardes ne peuvent-elles pas être chiffrées par Transit, et comment se protègent-elles alors ?
En quoi la rétention est-elle un arbitrage à deux sens, et quel principe l'impose ?
Décrivez les trois niveaux de vérification et lequel prouve réellement quelque chose.
Pourquoi l'alerte sur l'absence de fichier est-elle plus importante que les contrôles sur les fichiers présents ?

Synthèse¶

Un snapshot est le coffre entier, cohérent, chiffré par la barrière, produit à chaud par le nœud actif. Il ne s'ouvre qu'avec le matériel de scellement de son époque, ce qui fait de la sauvegarde une affaire à deux moitiés. Son automatisation en édition Community s'écrit avec les moyens du cursus : un minuteur qui ne produit que sur l'actif, une identité d'une seule règle, un chiffrement en flux par une clé autonome dont la partie privée dort hors ligne, un dépôt qui accepte sans jamais rendre. La rétention arbitre entre la profondeur de reprise et le nombre de coffres à garder, avec un inventaire par époque que chaque rekey vient relire. Reste la seule vérification qui conclut : la restauration réelle, mensuelle, chronométrée. Déclenche le TP 14 (énoncé en partie XV).