Volumes de sauvegarde LUKS2 : changer les clés et restaurer sans écrire

Les fichiers de sauvegarde sont bien enregistrés sur disque et le compte qui les reçoit est isolé. Mais les données présentes sur un disque retiré du service ou dans une copie hors ligne restent-elles directement lisibles ? C’est une autre frontière de sécurité. Le chiffrement de volume protège les données tant que le volume n’est pas déverrouillé ; il ne remplace pas le contrôle des accès en ligne. La rotation des clés permet de révoquer une ancienne phrase secrète, mais ne remédie pas à une fuite de données déjà survenue. Cet article utilise un conteneur fichier indépendant pour tester le changement de clé et la restauration avec LUKS2, sans intervenir sur les disques de données existants.

1. Définir ce que protège le chiffrement

Les serveurs dédiés OnuCloud sont équipés de deux disques NVMe de 1 To, chacun raccordé directement, sans RAID matériel. Le chiffrement de volume, la redondance des disques et la sauvegarde hors site répondent à des besoins distincts : le premier limite la lecture hors ligne, tandis que les deux autres permettent respectivement de faire face à une panne matérielle et de disposer d’une copie indépendante. Chiffrer les deux disques ne crée pas automatiquement une sauvegarde restaurable.

L’exemple suivant repose sur Ubuntu Server 24.04 LTS. Il nécessite des droits d’administration, cryptsetup, e2fsprogs et environ 256 MiB d’espace réellement disponible. Installez d’abord les outils nécessaires à l’aide des paquets de la distribution, puis ouvrez un shell d’administration dédié. Exécutez toutes les commandes suivantes dans ce même shell pour conserver les variables.

Un volume déverrouillé reste lisible par les processus disposant des autorisations nécessaires. Le chiffrement de volume n’empêche pas l’utilisation abusive des droits d’administration et ne rend pas automatiquement cohérente au niveau applicatif la copie d’une base de données en cours d’écriture.

Avant toute mise en production, définissez qui conserve les phrases secrètes, qui peut lire les sauvegardes d’en-tête et comment révoquer les accès lors d’un changement de personnel. N’inscrivez pas les phrases secrètes dans les arguments des commandes, les scripts ou le corps des tickets.

2. Créer un volume de test sans toucher aux disques réels

mktemp crée un répertoire de travail indépendant. Toutes les opérations de formatage ciblent uniquement le nouveau fichier qui s’y trouve. Avant de commencer, vérifiez que le nom de mappage backup-drill n’est pas déjà utilisé. S’il existe, arrêtez-vous et recherchez la cause : ne fermez pas un mappage inconnu. L’exemple utilise une saisie interactive des phrases secrètes ; la phrase secrète initiale occupe l’emplacement 0.

umask 077
work=$(mktemp -d /var/tmp/luks-drill.XXXXXX)
image="$work/backup.img"
mountpoint="$work/mnt"
mkdir "$mountpoint"
truncate -s 256M "$image"
cryptsetup luksFormat --type luks2 --key-slot 0 "$image"
cryptsetup open "$image" backup-drill
mkfs.ext4 /dev/mapper/backup-drill
mount /dev/mapper/backup-drill "$mountpoint"
printf 'backup-recovery-check\n' > "$mountpoint/probe.txt"
(
  cd "$mountpoint"
  sha256sum probe.txt
) > "$work/expected.sha256"
sync
umount "$mountpoint"
cryptsetup close backup-drill

N’exécutez la commande suivante qu’après la réussite de la précédente. En particulier, ne poursuivez jamais le formatage après un échec du déverrouillage et ne remplacez pas le chemin du fichier par un nom de périphérique NVMe sans l’avoir vérifié. La taille apparente d’un fichier creux ne correspond pas à l’espace qu’il occupe réellement ; pendant le test, assurez-vous que le système de fichiers qui l’héberge dispose toujours d’un espace suffisant.

Le fichier des sommes de contrôle est conservé à l’extérieur du conteneur pour permettre une comparaison indépendante lors de la restauration. En production, ce fichier doit lui aussi provenir d’une source fiable. Si les données et les sommes de contrôle peuvent être altérées ensemble, la seule correspondance des empreintes ne prouve pas la fiabilité de leur origine.

3. Valider le nouvel emplacement avant de révoquer l’ancienne phrase secrète

Exécutez d’abord cryptsetup luksDump "$image" pour vérifier que le type est bien LUKS2, que l’emplacement 0 est actif et que l’emplacement 1 est libre. La disposition des emplacements peut être différente sur un volume réel : ne reprenez pas ces numéros sans vérification. Lors de l’ajout ci-dessous, saisissez d’abord l’ancienne phrase secrète pour autoriser l’opération, puis définissez la nouvelle en suivant les invites.

cryptsetup luksAddKey --key-slot 1 "$image"
cryptsetup open --test-passphrase --key-slot 1 "$image"
cryptsetup luksDump "$image"

Saisissez la nouvelle phrase secrète pour la deuxième commande. La validation n’est réussie que si le code de sortie est 0. L’option --test-passphrase teste uniquement le déverrouillage, sans créer de mappage ; elle ne modifie donc pas l’état de montage du système de fichiers. Ajouter un emplacement ne revient ni à changer la clé du volume ni à rechiffrer l’ensemble des données.

Une fois que vous avez confirmé que la nouvelle phrase secrète est conservée de manière sûre par les personnes autorisées, supprimez l’emplacement 0. Dans cet exercice, autorisez la suppression avec la nouvelle phrase secrète, celle qui sera conservée :

cryptsetup luksKillSlot "$image" 0
cryptsetup open --test-passphrase "$image"

Pour la dernière commande, saisissez d’abord l’ancienne phrase secrète : le test doit échouer. Relancez ensuite la commande avec la nouvelle phrase secrète : le test doit réussir. Ne masquez pas les échecs par des tentatives automatiques et ne déclarez pas la rotation terminée à la seule lecture de la liste des emplacements. Les preuves de validation doivent inclure les changements d’emplacements et les résultats des deux tests, jamais les phrases secrètes elles-mêmes.

4. La sauvegarde d’en-tête est aussi un élément d’accès sensible

L’en-tête LUKS contient les métadonnées essentielles au déverrouillage. Si la zone de données est intacte mais que l’en-tête est endommagé, sa sauvegarde peut être indispensable à la restauration. Ce n’est pas une copie des données, et elle ne doit surtout pas être perdue en même temps que l’unique volume de données. Après la réussite de la rotation, exportez l’en-tête actuel :

cryptsetup luksHeaderBackup "$image" \
  --header-backup-file "$work/header-current.bin"
chmod 600 "$work/header-current.bin"
cryptsetup luksDump "$image" > "$work/luks-layout.txt"

Les permissions du répertoire et des fichiers ne limitent que les accès locaux. En production, les copies d’en-tête doivent être conservées dans un emplacement indépendant à accès contrôlé. Consignez le volume concerné, le lot de rotation et les personnes autorisées, et établissez une correspondance explicite avec les copies de données. N’envoyez pas un fichier d’en-tête comme une simple pièce jointe de diagnostic.

Les versions historiques nécessitent une attention particulière : un ancien en-tête peut contenir des emplacements révoqués, et sa restauration peut réactiver une ancienne phrase secrète. Supprimer l’ancien emplacement sur le volume actuel ne révoque donc pas nécessairement les possibilités d’accès contenues dans tous les éléments historiques. Si la menace concerne une fuite de la clé du volume, changer uniquement la phrase secrète ne suffit pas : il faut prévoir séparément un rechiffrement ou une migration.

5. Vérifier le contenu des fichiers lors de la restauration en lecture seule

Le volume de test ayant été démonté proprement, vous pouvez créer un nouveau mappage en lecture seule, puis monter le système de fichiers ext4 en lecture seule, sans rejouer le journal. Ces deux restrictions encadrent respectivement le comportement du périphérique bloc et celui du système de fichiers.

cryptsetup open --readonly --key-slot 1 "$image" backup-drill
mount -t ext4 -o ro,noload /dev/mapper/backup-drill "$mountpoint"
findmnt -no SOURCE,FSTYPE,OPTIONS "$mountpoint"
(
  cd "$mountpoint"
  sha256sum -c "$work/expected.sha256"
)
touch "$mountpoint/should-not-exist"

Après la saisie de la nouvelle phrase secrète, les options de montage doivent inclure ro, la vérification des sommes de contrôle doit réussir et la dernière tentative d’écriture doit échouer. Si l’écriture réussit, interrompez immédiatement la validation et vérifiez la cible réellement montée ; ne considérez pas cela comme une anomalie sans rapport avec le test. L’option noload ne doit pas servir à masquer l’état d’un système de fichiers qui n’a pas été démonté proprement. Face à une telle copie, préservez d’abord l’original, puis évaluez les réparations sur une copie de travail.

Une fois le test terminé, démontez le répertoire, puis fermez le mappage. Vérifiez qu’il ne reste aucun montage ni mappage avant de traiter le répertoire de test. Les éléments de production doivent, eux, être gérés selon les règles de conservation établies, sans être mêlés au nettoyage des fichiers temporaires.

Le compte rendu final doit répondre à quatre questions : la nouvelle phrase secrète permet-elle à elle seule de déverrouiller le volume ? L’ancienne est-elle devenue inopérante ? La copie d’en-tête est-elle conservée de manière contrôlée ? Les fichiers restaurés correspondent-ils aux sommes de contrôle de confiance ? Ce n’est qu’une fois ces quatre points validés que l’exercice de changement de clé et de restauration peut être considéré comme vérifiable a posteriori.

Questions fréquentes