Aller au contenu principal

Séquestre des clés

Ce que fait le séquestre​

La plateforme crée la clé de chaque dépôt, et elle la garde dans sa base de données. Sans cette clé, personne ne lit le dépôt. Voir Chiffrement et clés.

Le séquestre des clés est une copie de ces clés, hors de la base de données. Il répond à une seule question : que se passe-t-il si la base de données de la plateforme est perdue ? Avec le séquestre, les dépôts restent lisibles. Sans lui, les sauvegardes des clients sont perdues.

Deux copies comptent comme un séquestre :

CopieCe qu'elle contientAvec quoi elle est scellée
La sauvegarde automatique de la plateformeLes clés de tous les dépôts, dans chaque archive de sauvegarde.La phrase secrète de la sauvegarde de la plateforme.
L'export hors ligneLes clés de tous les dépôts à la date de l'export.Une phrase secrète que vous choisissez.

L'export hors ligne reste recommandé. C'est une deuxième copie. Elle protège aussi contre la perte du bucket de sauvegarde, contre la perte de la phrase secrète de la sauvegarde, et contre une attaque sur le serveur de l'instance.

Prérequis​

  • Le rôle Administrateur plateforme, avec une session du portail. Une clé API et un accès MCP ne lisent pas l'état du séquestre. Voir Rôles et droits.
  • Pour exporter les clés : un accès au serveur de l'instance, dans son dossier de déploiement.
  • Une phrase secrète de 20 caractères au moins pour l'export, et un gestionnaire de mots de passe pour la garder.

Sur l'instance hébergée par BaaStide, le séquestre est tenu par BaaStide. Un MSP n'exporte pas les clés. Pour garder seul les clés et leur séquestre, choisissez une instance installée chez vous. Voir Chiffrement et clés.

Lire l'état du séquestre​

  1. Ouvrez le portail avec un compte Administrateur plateforme.
  2. Dans le menu Plateforme, cliquez Vue d'ensemble.
  3. Lisez la carte Séquestre des clés. Elle porte deux blocs.
  4. Lisez le bloc Sauvegarde de la plateforme. Il donne son état, et la date de la dernière sauvegarde avec les clés, avec le nombre de clés.
  5. Lisez le bloc Export hors ligne. Il donne son état, la date du dernier export complet, et le nombre de dépôts créés depuis cet export.

La carte écrit aussi la commande de l'export, et ce rappel : gardez la phrase secrète de la sauvegarde de la plateforme dans votre gestionnaire de mots de passe. Sans elle, la sauvegarde ne peut pas être ouverte.

États du séquestre​

Le bloc Sauvegarde de la plateforme porte un de ces états :

ÉtatCe qu'il veut dire
À jourLa dernière sauvegarde réussie porte la clé de chaque dépôt, et elle n'est pas trop ancienne.
IncomplèteLa sauvegarde ne porte pas toutes les clés : elle est trop ancienne, un dépôt a été créé après elle, ou aucune sauvegarde ne porte encore les clés. L'export hors ligne couvre tous les dépôts.
En dangerLa sauvegarde porte un dépôt sans sa clé, ou aucune des deux copies ne porte toutes les clés.

Le bloc Export hors ligne porte un de ces états :

ÉtatCe qu'il veut dire
À jourL'export porte tous les dépôts, et il a moins de 30 jours.
RecommandéIl n'y a aucun export, ou un dépôt a été créé depuis le dernier, ou le dernier a plus de 30 jours.

Un export Recommandé n'est pas une alerte tant que la sauvegarde de la plateforme porte toutes les clés. Le portail n'affiche alors aucun bandeau.

Le portail affiche un bandeau aux administrateurs de la plateforme quand aucune copie ne porte toutes les clés. Le bandeau nomme la cause :

Phrase du bandeauCe qu'il faut faire
« Aucune sauvegarde de la plateforme ne contient encore les clés des dépôts. »Configurez le bucket de sauvegarde de la plateforme, puis exportez les clés.
« La dernière sauvegarde de la plateforme contient n dépôts sans leur clé. »Un dépôt est sans clé lisible. Appelez le support BaaStide.
« n dépôts ont été créés après la dernière sauvegarde de la plateforme : leurs clés ne sont dans aucune sauvegarde. »Attendez la sauvegarde suivante, ou exportez les clés.
« La dernière sauvegarde de la plateforme avec les clés des dépôts date du date. »La sauvegarde est trop ancienne. Vérifiez le worker et le bucket de sauvegarde.
« Les clés des dépôts n'ont jamais été exportées. »Exportez les clés.
« Le dernier export des clés des dépôts date du date. »Exportez les clés de nouveau.

Exporter les clés hors ligne​

Faites cet export après l'ajout des premières machines, puis après chaque ajout de machines. Un export porte les clés des dépôts qui existent à sa date.

  1. Ouvrez une session sur le serveur de l'instance.

  2. Allez dans le dossier de déploiement de l'instance.

  3. Choisissez une phrase secrète de 20 caractères au moins. Gardez-la dans votre gestionnaire de mots de passe.

  4. Lancez l'export. Donnez l'adresse e-mail d'un administrateur de la plateforme actif :

    read -rsp "Phrase secrète de l'export : " EXPORT_PASSPHRASE && echo
    EXPORT_FILE=baastide-keys-$(date +%F).bkx
    (umask 077 && printf '%s\n' "$EXPORT_PASSPHRASE" |
      docker compose run --rm -T admin export-keys --as admin@exemple.fr --out - > "$EXPORT_FILE")

  5. Lisez la dernière ligne. Elle donne le nombre de clés exportées.

  6. Vérifiez le fichier. Voir « Vérifier un fichier d'export » plus bas.

  7. Effacez la phrase secrète de votre session : unset EXPORT_PASSPHRASE.

  8. Copiez le fichier hors du serveur de l'instance, puis retirez-le du serveur.

La phrase secrète passe par un tube, jamais dans la ligne de commande : la liste des processus et l'historique du shell gardent une ligne de commande. umask 077 rend le fichier lisible par vous seul.

Gardez le fichier et la phrase secrète dans deux endroits différents. Le fichier ne porte aucune clé en clair.

Vérifier un fichier d'export​

La vérification lit le fichier sans la base de données. Faites-la à chaque export, et une fois par an sur le fichier gardé.

  1. Ouvrez une session sur le serveur de l'instance, dans son dossier de déploiement.

  2. Mettez le fichier d'export dans ce dossier.

  3. Lancez la vérification. Donnez le nom du fichier d'export :

    EXPORT_FILE=baastide-keys-2026-11-05.bkx
    read -rsp "Phrase secrète de l'export : " EXPORT_PASSPHRASE && echo
    printf '%s\n' "$EXPORT_PASSPHRASE" |
      docker compose run --rm -T --no-deps -u "$(id -u):$(id -g)" -v "$PWD:/escrow:ro" \
        admin import-check "/escrow/$EXPORT_FILE"
    unset EXPORT_PASSPHRASE

  4. Lisez l'en-tête : l'identifiant de l'instance, l'identifiant de l'export, sa date et le nombre de clés.

  5. Lisez la liste. Elle donne une ligne par dépôt : l'agent, le pool, le chemin du dépôt, le MSP, le client et le nom de la machine.

  6. Cherchez la mention NO KEY. Elle signale un dépôt listé sans sa clé.

Une phrase secrète fausse, ou un fichier modifié, donne le même message : cannot decrypt: wrong passphrase, or the file was changed.

La même commande ouvre aussi le séquestre d'une archive de sauvegarde de la plateforme. La phrase secrète est alors celle de la sauvegarde.

Restaurer sans la plateforme​

Suivez cette procédure quand la plateforme est perdue et que vous devez lire un dépôt. Elle demande les identifiants de votre stockage objet.

  1. Ouvrez le fichier d'export en clair :

    EXPORT_FILE=baastide-keys-2026-11-05.bkx
    read -rsp "Phrase secrète de l'export : " EXPORT_PASSPHRASE && echo
    printf '%s\n' "$EXPORT_PASSPHRASE" |
      docker compose run --rm -T --no-deps -u "$(id -u):$(id -g)" -v "$PWD:/escrow" \
        admin import-check "/escrow/$EXPORT_FILE" --decrypt-to "/escrow/cles.json"
    unset EXPORT_PASSPHRASE

  2. Trouvez le dépôt de la machine voulue. Chaque entrée donne le nom de la machine, le MSP, le client, l'adresse du stockage, le bucket, le chemin du dépôt et sa clé.

  3. Ouvrez le dépôt avec restic, le moteur de sauvegarde de BaaStide. Le chemin du dépôt est <bucket>/<identifiant de l'agent> :

    restic -r s3:<adresse du stockage>/<bucket>/<identifiant de l'agent> snapshots

  4. Collez la clé de ce dépôt quand restic demande le mot de passe du dépôt.

  5. Restaurez les fichiers voulus avec restic.

La lecture du fichier d'export demande l'image du service BaaStide, pas la base de données. Gardez donc le paquet d'installation de l'instance avec le fichier d'export et sa phrase secrète.

Le fichier en clair porte toutes les clés de l'instance. Mettez-le sur un poste de confiance, effacez-le après la restauration, et ne le gardez jamais à côté du fichier d'export.

Limites et précautions​

  • L'export couvre tous les dépôts de l'instance. Il n'y a pas d'export par MSP, et un MSP ne demande pas d'export.
  • Un dépôt déjà purgé n'est pas dans l'export.
  • Une clé que la plateforme ne peut pas lire n'est dans aucune copie. L'export liste ce dépôt avec la mention NO KEY, et le portail passe la carte En danger.
  • Sans la phrase secrète, le fichier d'export est inutilisable. Personne ne l'ouvre à votre place.
  • La phrase secrète fait de 20 à 1 024 caractères. La commande lit la première ligne de ce que vous lui donnez.
  • La commande n'écrase jamais un fichier existant. Elle s'arrête et écrit <fichier> exists: not overwritten.
  • Chaque export part dans le journal d'audit, sous l'action Clés exportées. L'entrée garde le nombre de dépôts, le compte du système et le nom d'hôte de l'export. Elle ne garde aucune clé. Voir Journal d'audit.
  • L'adresse e-mail de --as doit être celle d'un administrateur de la plateforme actif. Sinon la commande s'arrête.
  • L'état du séquestre se lit avec une session du portail d'un administrateur de la plateforme. Une clé API et un accès MCP ne le lisent pas.
  • La sauvegarde de la plateforme ne compte comme copie des clés que lorsqu'elle réussit. Vérifiez aussi la carte Sauvegarde de la plateforme de la même page.
  • Le séquestre ne remplace pas les tests de restauration. Voir Tester ses restaurations.
  • Vous ne changez pas la clé d'un dépôt depuis le portail. Un export reste donc valable pour les dépôts qu'il porte.