Aller au contenu

Sauvegardes chiffrées

Le coffre de sauvegardes chiffrées vous permet de stocker des dumps de base de données et des archives de fichiers sur votre serveur Quiet Guard sous forme de blobs chiffrés opaques que le serveur ne peut jamais lire. Il s'appuie sur la même paire de clés par équipe que le stockage chiffré.

Fonctionnalité payante. Les sauvegardes sont conditionnées à la fonctionnalité de plan backups et à un quota de stockage par plan : Indie inclut 5 Go et Studio 20 Go ; Free et Solo n'en incluent aucun. Voir Facturation et plans.

Zéro-connaissance par conception

Le serveur ne stocke que du chiffré et des métadonnées (type, nom, taille, somme de contrôle, horodatages). Il ne détient jamais la clé de chiffrement et ne peut pas déchiffrer vos sauvegardes. Le flux est le suivant :

  1. Le client chiffre l'archive localement avec une clé de données aléatoire, puis scelle cette clé avec la clé publique de votre équipe.
  2. Le blob scellé est téléversé vers le serveur.
  3. Pour restaurer, le client télécharge le blob, désenveloppe votre clé privée localement à partir de la phrase secrète d'équipe, et déchiffre.

À aucun moment le serveur ne voit votre phrase secrète ni la clé désenveloppée.

Quota de stockage

Chaque plan accorde un quota de sauvegarde en gigaoctets. Le serveur suit le total des octets stockés sur toutes les sauvegardes de vos projets. Lorsqu'un téléversement dépasserait le quota, il est rejeté avec un 413 Request Entity Too Large :

json
{
  "message": "Backup storage quota exceeded.",
  "used_bytes": 5012345678,
  "limit_bytes": 5000000000
}

Supprimez d'anciennes sauvegardes pour libérer de l'espace.

Gérer les sauvegardes dans l'interface

Lorsque votre plan autorise les sauvegardes, le projet affiche un onglet Sauvegardes dans le panel /app. La liste ne comporte que des métadonnées : date, type, nom, taille, somme de contrôle, et l'identifiant, copiable, qui est ce que monitor:restore attend en argument. Le contenu, lui, reste scellé.

Deux boutons par ligne, et la différence entre les deux est le coeur du sujet.

Déchiffrer télécharge le blob et le déchiffre dans votre navigateur, avec la clé privée de votre équipe désenveloppée depuis votre phrase secrète. Ce que vous enregistrez est l'archive en clair, directement utilisable. Le serveur n'y participe pas : il envoie le chiffré qu'il détenait, et la clé qui l'ouvre n'a jamais existé de son côté. Déverrouillez d'abord ce navigateur sur la page Chiffrement : c'est le seul endroit où la phrase secrète se saisit, et la dérivation Argon2id y est faite une fois pour la session de l'onglet.

Télécharger rend le blob scellé tel quel, un fichier .enc que rien n'ouvre sans votre clé. C'est la sortie de secours : archiver le chiffré ailleurs, ou le déchiffrer depuis la ligne de commande avec monitor:restore --file=<fichier> sur la machine où le SDK est installé.

Points d'entrée serveur

Le coffre est piloté par une API à clé de projet (détails complets dans la référence de l'API d'ingestion) :

  • GET /api/v1/encryption-key: sert la clé publique + la clé privée enveloppée + le sel au client authentifié.
  • GET /api/v1/backups: liste les sauvegardes.
  • POST /api/v1/backups: téléverse un blob chiffré (multipart/form-data avec type, name facultatif et file). type vaut database ou files.
  • GET /api/v1/backups/{uuid}: télécharge le blob chiffré.
  • DELETE /api/v1/backups/{uuid}: supprime une sauvegarde.

Commandes client

Vous n'appellerez pas ces points d'entrée à la main. Le client Laravel fournit trois commandes :

  • monitor:backup: construit une archive (copie SQLite, mysqldump / pg_dump, ou un tar d'un dossier), la chiffre avec la clé publique de l'équipe et la téléverse. --keep=N supprime toutes les sauvegardes du même type sauf les N plus récentes une fois l'envoi réussi, ce qui empêche une planification nocturne de remplir l'allocation.
  • monitor:backups: liste ce que le coffre contient pour le projet, la plus récente d'abord, avec l'identifiant dont monitor:restore a besoin.
  • monitor:restore: récupère le matériel de clé, désenveloppe la clé privée localement à partir de votre phrase secrète, télécharge le blob, le compare au checksum publié par la liste, puis le déchiffre. Un blob qui ne correspond pas est refusé avec un message qui lui est propre : un téléchargement abîmé ne se confond donc plus avec une mauvaise phrase secrète. --file=<fichier> déchiffre un blob que vous avez déjà téléchargé depuis le dashboard, sans le redemander au serveur.
Consultez la documentation du SDK Laravel pour les options des commandes et des exemples, partez de la documentation du SDK Laravel.

Vous lisez la documentation Quiet Guard v1.0.