Chiffrer ses backups : age, GPG, et chiffrement côté S3

Un backup passe son temps à quitter le datacenter : il part sur un bucket S3 tiers, sur le NAS Synology du bureau, sur un disque externe que vous emmenez chez vous. À chaque destination, il sort du périmètre que Datacampus protège. Un backup récupéré en clair par le mauvais interlocuteur, c'est toute la base clients, les emails, les mots de passe hashés, les clés API qui partent avec. Cette doc couvre les trois niveaux de chiffrement à connaître, les outils qui tiennent la route en 2026, et surtout le vrai sujet : la gestion des clés.

Les trois niveaux de chiffrement d'un backup

Avant de parler outils, il faut distinguer trois moments où un backup peut être chiffré. Les trois sont complémentaires, pas alternatifs.

1. En transit : pendant le transfert entre votre serveur et la destination. TLS côté HTTPS, SFTP sur SSH, rclone qui parle en HTTPS à un endpoint S3. C'est le minimum, c'est déjà partout, vous n'avez rien à faire sauf vérifier que l'URL commence bien par https:// ou sftp://.
2. Au repos côté stockage : le provider chiffre les blocs sur disque. S3 server-side encryption (SSE-S3, SSE-KMS chez AWS, équivalent chez Scaleway, Backblaze, OVH). Activé par défaut aujourd'hui chez tous les gros providers. Ça protège contre un vol de disque physique, pas contre une fuite de vos identifiants d'accès.
3. Côté client : vous chiffrez le fichier avant de l'envoyer. Le provider ne voit que du binaire opaque. Personne d'autre que vous ne peut lire le backup, même si le bucket fuite en entier. C'est le seul niveau qui vous protège vraiment pour les données sensibles qui sortent du périmètre Datacampus.

age : le choix par défaut en 2026

age est un outil moderne, écrit par un crypto-ingénieur de Google, zéro config, pas de keyring, pas de toile d'araignée de confiance à gérer. Il fait une chose : chiffrer un fichier pour un destinataire, avec une clé publique ou une passphrase.

# Installation
apt install age     # Debian/Ubuntu récents
brew install age    # macOS

# Générer une paire de clés
age-keygen -o ~/.age/backup.key
# Public key: age1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

# Chiffrer un fichier pour cette clé publique
age -r age1xxxx... -o backup.tar.gz.age backup.tar.gz

# Déchiffrer
age -d -i ~/.age/backup.key backup.tar.gz.age > backup.tar.gz

La clé publique peut vivre en clair sur le serveur qui fait les backups (elle ne sert qu'à chiffrer). La clé privée reste au chaud ailleurs, jamais sur la machine qui produit les backups. Comme ça, même si le serveur est compromis, l'attaquant ne peut pas déchiffrer les backups existants.

Mode passphrase (plus simple, moins sûr)

# Chiffrer avec un mot de passe au lieu d'une clé
age -p -o backup.tar.gz.age backup.tar.gz
# Enter passphrase: ...

# Déchiffrer
age -d backup.tar.gz.age > backup.tar.gz

Pratique pour du ponctuel. Pour du backup automatisé, la paire de clés reste meilleure : pas de passphrase à stocker en clair dans un cron.

GPG : le classique

GPG est plus ancien, plus verbeux, plus bavard sur ses erreurs, mais compatible avec tout ce que vous croiserez. Utile si vous avez déjà une infra PGP en place ou si vous voulez signer vos backups en plus de les chiffrer.

# Chiffrement symétrique (passphrase)
gpg --symmetric --cipher-algo AES256 backup.tar.gz
# Produit backup.tar.gz.gpg

# Déchiffrement
gpg -d backup.tar.gz.gpg > backup.tar.gz

# Chiffrement asymétrique vers un destinataire
gpg --encrypt --recipient backup@exemple.fr --cipher-algo AES256 backup.tar.gz

Pour un nouveau projet en 2026, age est plus simple et tout aussi solide cryptographiquement. GPG garde sa place quand vous avez besoin de signatures ou d'interopérabilité avec des outils plus anciens.

restic : l'outil de backup qui chiffre déjà

# Installation
apt install restic

# Initialiser un repo chiffré sur S3
export AWS_ACCESS_KEY_ID=xxx
export AWS_SECRET_ACCESS_KEY=yyy
export RESTIC_PASSWORD='une-passphrase-longue-et-solide'
restic -r s3:s3.fr-par.scw.cloud/mon-bucket init

# Premier backup
restic -r s3:s3.fr-par.scw.cloud/mon-bucket backup /var/www /etc

# Lister les snapshots
restic -r s3:s3.fr-par.scw.cloud/mon-bucket snapshots

# Restaurer un snapshot
restic -r s3:s3.fr-par.scw.cloud/mon-bucket restore latest --target /tmp/restore

# Politique de rétention : garder 7 quotidiens, 4 hebdo, 6 mensuels
restic -r s3:... forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Le repo restic est chiffré de bout en bout avec RESTIC_PASSWORD. Le provider S3 ne voit que des blobs. La dédup fait que le stockage croît très lentement même avec un backup quotidien.

Exemple concret : backup MySQL chiffré vers S3

Script à poser dans un cron quotidien sur votre VPS. Dump MySQL, compression, chiffrement age, upload vers un bucket S3 via rclone, rétention 30 jours.

#!/usr/bin/env bash
set -euo pipefail

DATE=$(date +%Y-%m-%d_%H%M)
DB=ma_base
AGE_RECIPIENT=age1xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
RCLONE_REMOTE=scaleway-backups
BUCKET=backups-exemple
BACKUP_NAME="${DB}-${DATE}.sql.gz.age"

# Dump + gzip + chiffrement + upload, en un seul pipe (zéro fichier temporaire)
mysqldump --single-transaction --quick --routines "${DB}" \
  | gzip -9 \
  | age -r "${AGE_RECIPIENT}" \
  | rclone rcat "${RCLONE_REMOTE}:${BUCKET}/${BACKUP_NAME}"

# Rétention : supprimer les backups de plus de 30 jours
rclone delete --min-age 30d "${RCLONE_REMOTE}:${BUCKET}/"

echo "Backup ${BACKUP_NAME} OK"

Points importants :

• Le pipe évite d'écrire le dump en clair sur le disque. Rien de sensible ne touche le FS, ne serait-ce qu'une seconde.
• La clé publique age vit en variable dans le script, c'est safe : elle ne sert qu'à chiffrer.
• La clé privée n'est pas sur ce serveur. Elle est ailleurs, dans un vault.
• Les credentials rclone sont dans ~/.config/rclone/rclone.conf, mode 0600, idéalement avec un chiffrement de config rclone par passphrase.

Gestion des clés : le vrai sujet

Le chiffrement est la partie facile. Les algos sont solides, les outils matures. Le problème, c'est : où vit la clé, qui y a accès, et que se passe-t-il si vous la perdez.

Règles de base

• Jamais la clé à côté du backup chiffré. Un bucket S3 qui contient les backups et la clé privée, c'est comme mettre la clé du coffre sur la porte du coffre.
• Jamais la clé sur la machine qui produit les backups. Sinon un attaquant qui prend la machine prend aussi tout l'historique.
• Toujours une sauvegarde de la clé. Imprimée, dans un coffre physique, ou chez un co-fondateur. Sérieusement.

Où stocker la clé

• Petite équipe, usage léger : un gestionnaire de secrets partagé (1Password Business, Bitwarden organization, Vaultwarden auto-hébergé chez Datacampus). Un item dédié, accès restreint à deux ou trois personnes de confiance.
• Équipe tech, volumes plus sérieux : un KMS (Scaleway KMS, AWS KMS, ou HashiCorp Vault). La clé ne sort jamais du KMS, vous demandez au KMS de chiffrer/déchiffrer à la volée.
• Critique (données vitales pour la boîte) : schéma Shamir Secret Sharing, la clé est découpée en N parts dont K suffisent à la reconstruire (3 parts sur 5 par exemple). Chaque part va à une personne différente. Personne seul ne peut tout lire, mais on survit à la perte de deux parts.

Rotation

Une fois par an, ou après un départ de personne qui avait accès. Pour age/restic, on chiffre un nouveau backup avec la nouvelle clé, on garde l'ancienne clé tant que les vieux backups sont encore dans la rétention, puis on la détruit.

Tester la restauration

Un backup chiffré qui n'a jamais été restauré n'est pas un backup, c'est un espoir. Les modes de défaillance sont nombreux : clé récupérable mais passphrase oubliée, fichier corrompu en transit, archive tar mal formée, version d'age trop récente pour lire un vieux format. La seule façon de savoir : tester.

1. Une fois par trimestre, prenez un backup au hasard.
2. Téléchargez-le depuis le stockage externe sur une machine de test (pas le serveur de prod).
3. Déchiffrez avec la clé privée récupérée depuis le vault.
4. Décompressez, restaurez le dump SQL dans une base temporaire, lancez l'appli dessus.
5. Vérifiez que les données des deux derniers jours sont bien là.

Si une étape échoue, c'est maintenant qu'il faut le savoir, pas le jour du ransomware.

Récapitulatif

1. Trois niveaux de chiffrement : transit (TLS), repos (SSE côté provider), client (vous, avant upload). Les trois à la fois.
2. Pour ce qui sort de Datacampus : chiffrez côté client. age pour du simple, restic si vous partez de zéro, GPG si vous avez déjà une infra PGP.
3. La clé privée ne vit jamais sur la machine qui fait les backups ni à côté des backups.
4. Sauvegardez la clé séparément. Une clé perdue = backup mort, sans recours.
5. Testez la restauration une fois par trimestre. Notez-le dans un calendrier récurrent.