Gestion des clés ZFS : la partie que tout le monde oublie jusqu’au jour du désastre

novembre 13, 2025 • février 3, 2026 • Lecture : 30 min • Views: 10

Cet article vous a aidé ?

Le chiffrement est la partie facile. La gestion des clés est la partie dont vous ne vous rendez compte que lorsqu’elle manque—généralement à 02:13, pendant une panne, avec un manager senior qui demande si « les données sont toujours là » comme si c’était une question philosophique.

Le chiffrement natif de ZFS est solide, rapide et étonnamment simple à activer. Le problème est que « encryption=on » n’est pas un plan. Un plan, c’est : comment les clés sont créées, stockées, chargées, tournées, auditées, sauvegardées et récupérées quand la machine est morte, le pool importé en lecture seule, et que votre gestionnaire de mots de passe est lui aussi sur ce pool. Ceci est un guide pour les personnes qui exploitent réellement des systèmes de production—et qui veulent continuer à le faire.

Ce que vous gérez réellement (et pourquoi c’est plus dur qu’il n’y paraît)

Le chiffrement ZFS n’est pas un simple interrupteur. C’est un ensemble de propriétés attachées aux datasets, plus un ensemble de comportements qui apparaissent aux pires moments possibles : démarrage, import, bascule, restauration, réplication et audits.

À haut niveau, le chiffrement natif ZFS fonctionne ainsi :

Vous créez un dataset chiffré avec encryption=on.
ZFS utilise une clé d’enveloppe dérivée d’une passphrase ou d’un matériau de clé stocké (keyformat) pour protéger une clé de dataset.
Les blocs de données sont chiffrés ; les métadonnées sont partiellement protégées selon les réglages et la réalité sur disque.
Pour monter un dataset chiffré, vous devez généralement charger la clé (déverrouiller), puis monter.

La gestion des clés, c’est tout ce qui entoure ce moment de déverrouillage : d’où vient la clé, qui peut y accéder, comment vous la faites tourner, et comment prouver que vous pouvez récupérer sans improviser.

Une blague, parce que nous en aurons besoin : un chiffrement sans processus de récupération testé est comme un parachute acheté en ligne qu’on n’a jamais essayé—techniquement présent, émotionnellement inutile.

Les trois « plans de réalité » que vous devez aligner

La plupart des catastrophes liées aux clés ZFS surviennent lorsque ces trois plans ne sont pas alignés :

Le plan dataset : propriétés comme encryption, keyformat, keylocation, keystatus, les frontières d’héritage, et si les datasets enfants héritent de la clé.
Le plan hôte : processus de démarrage, initramfs, ordre des services, disponibilité des fichiers de clés, invites de passphrase, consoles qui n’existent pas (bonjour, consoles série cloud), et la réalité que « on la tapera au démarrage » cesse de fonctionner quand vous avez 50 nœuds.
Le plan humain : qui connaît la passphrase, comment elle est stockée, comment la faire tourner sans downtime, comment révoquer l’accès, et comment prouver que ce n’est pas du « théâtre de sécurité » avec un mot de passe partagé dans un canal de chat.

Terminologie ZFS sur les clés à employer avec précision

Dans les conversations ops, les mots « clé » et « mot de passe » se confondent. Pour le chiffrement ZFS, soyez explicite :

Dataset encryption key (DEK) : la clé interne qui chiffre les données. Vous ne la tapez pas ; ZFS la gère.
Wrapping key / key material : ce qui protège la DEK. Ceci est dérivé d’une passphrase ou provient d’un fichier de clé, selon keyformat.
Loaded key : matériau de clé présent en mémoire et utilisable. C’est ce que zfs load-key accomplit.
Rotation de clé : signifie généralement changer la clé d’enveloppe (re-envelopper la DEK) plutôt que de ré-encrypter tous les blocs de données.

Faits et contexte intéressants : comment on en est arrivé là

Les erreurs de gestion des clés ne sont pas un échec personnel. C’est une tradition industrielle. Quelques points de contexte utiles :

ZFS est né chez Sun Microsystems au milieu des années 2000 avec une philosophie « tout est checksummé » qui semble toujours futuriste comparée à beaucoup de stacks hérités.
Le chiffrement natif ZFS est arrivé plus tard que beaucoup ne le supposent ; pendant des années, les gens utilisaient GELI (FreeBSD), LUKS/dm-crypt (Linux) ou du chiffrement matériel sous ZFS.
Les premières approches « chiffrer tout le disque » facilisaient parfois la récupération et le démarrage (un seul déverrouillage), mais compliquaient la réplication et le contrôle d’accès granulaire.
Opérationnellement, le chiffrement est passé de niche à par défaut lorsque les régimes de conformité (et les gros titres sur les fuites) ont rendu le chiffrement « at rest » indispensable même pour les systèmes internes.
Le modèle de dataset de ZFS est une lame à double tranchant : il offre des frontières de chiffrement fines, mais il offre aussi 400 façons de créer un héritage incohérent que vous ne remarquerez pas avant le jour de la restauration.
Les échecs de gestion des clés sont souvent des « échecs par succès » : les équipes réussissent à automatiser le déverrouillage par commodité et réussissent accidentellement à supprimer tout contrôle d’accès significatif.
Les systèmes de sauvegarde ont historiquement eu du mal avec les datasets chiffrés parce que les administrateurs confondaient « chiffré sur disque » avec « sûr en transit » ou « sûr dans les sauvegardes », qui sont des problèmes différents.
L’industrie a appris (à plusieurs reprises) qu’un seul exemplaire de la clé stocké sur le stockage chiffré est une forme d’art performance, pas d’ingénierie.

Modèle de menace : ce que le chiffrement ZFS protège (et ne protège pas)

Si vous n’écrivez pas ceci, votre organisation l’inventera plus tard lors d’un post-mortem de fuite.

Ce que le chiffrement natif ZFS protège bien

Disques volés / disques mis au rebut : si quelqu’un s’enfuit avec des disques ou un châssis entier, les datasets chiffrés protègent les données au repos (à condition que les clés ne soient pas stockées avec les disques).
« Oups, on a envoyé le mauvais RMA » : le chiffrement réduit l’impact lorsque du matériel sort de votre garde.
Limites multi-tenant-ish sur un stockage partagé : les clés de dataset peuvent séparer les accès, dans les limites de l’environnement hôte.

Ce qu’il ne protège pas

Logiciels malveillants sur l’hôte : si le dataset est monté et la clé chargée, un ransomware lit/écrit sans problème.
Root sur l’hôte : root peut typiquement lire la mémoire, intercepter le chargement de la clé ou accéder aux fichiers de clés selon votre configuration.
Exfiltration depuis les applications : le chiffrement ZFS se situe sous l’API filesystem ; les applications voient le texte en clair.

Décisions du modèle de menace que vous devez formaliser

Le démarrage sans surveillance est-il requis ? Si oui, votre clé est soit stockée localement (moins sûr) soit récupérée depuis un service réseau (plus de pièces mobiles). Les deux sont valides ; prétendre pouvoir éviter le compromis est faux.
Avez-vous besoin de clés par dataset ? Excellent pour le principe du moindre privilège ; pénible pour l’ops si vous ne standardisez pas les noms et l’héritage.
Quel est votre chemin « casse-z-glace » ? Qui peut déverrouiller lors d’un incident, et comment le fait-il sans fouiller Slack ?

Schémas de conception des clés qui résistent à la réalité

Schéma 1 : Un root chiffré avec héritage pour les enfants (ennuyeux, efficace)

C’est le schéma « je veux dormir ». Vous chiffrez un dataset de niveau supérieur (souvent le dataset racine du pool ou un parent désigné), définissez les enfants pour hériter et gardez le nombre de clés distinctes bas.

Avantages : moins de clés, procédure de déverrouillage plus simple, récupération après sinistre plus facile. Inconvénients : séparation moins granulaire entre les datasets.

Schéma 2 : Plusieurs clés par domaine (sécurité-friendly, coûteux en ops)

Vous regroupez les datasets par sensibilité : par ex., pool/app, pool/db, pool/secrets, chacun avec des clés d’enveloppe séparées. Vous acceptez que le déverrouillage et la récupération exigent une chorégraphie soignée.

Avantages : meilleure isolation. Inconvénients : plus de travail de rotation, plus de dépendances au démarrage, plus de chances d’oublier un dataset jusqu’à ce qu’une restauration échoue.

Schéma 3 : Passphrase vs fichier de clé (choisir selon votre réalité de démarrage)

Passphrase : les humains peuvent la taper, mais les humains sont une infrastructure peu fiable. Idéale pour les portables, moins pour les serveurs sans tête sauf si vous avez une console distante robuste et des procédures.

Fichier de clé : compatible avec l’automatisation, mais vous devez protéger le fichier. Si le fichier de clé vit sur la même machine, vous avez surtout déplacé le problème. S’il est récupéré depuis une source sécurisée au démarrage, vous avez construit un système de distribution de clés—félicitations pour ce nouveau sous-système.

Schéma 4 : keylocation est une interface, pas une stratégie de stockage

ZFS permet de définir keylocation sur prompt ou un chemin de fichier. Ce n’est pas une solution de gestion des clés ; c’est un pointeur. Votre stratégie réelle est : d’où vient ce fichier de clé, comment sont ses permissions, comment il est tourné, et comment il est récupéré si la machine est cramée.

Schéma 5 : Règle « deux contrôles » pour les datasets de production

En pratique : ne laissez pas le gestionnaire de mots de passe du portable d’un seul admin être le seul chemin pour déverrouiller les données de production. Utilisez soit un séquestre partagé (avec audit) soit un processus de double-contrôle. Vos auditeurs aimeront. Votre commandant d’incident adorera.

Tâches pratiques avec commandes (et ce que la sortie signifie)

Les commandes ci-dessous supposent OpenZFS sur Linux, exécutées en root sauf indication contraire. Les sorties sont représentatives ; vos champs exacts peuvent varier.

Task 1: Inventory encryption state across a pool

cr0x@server:~$ zfs list -r -o name,encryption,keyformat,keylocation,keystatus,mounted pool
NAME                 ENCRYPTION  KEYFORMAT  KEYLOCATION     KEYSTATUS  MOUNTED
pool                 off         -          -               -          yes
pool/system           aes-256-gcm  passphrase prompt          available  yes
pool/system/var       aes-256-gcm  passphrase prompt          available  yes
pool/data             aes-256-gcm  raw        file:///etc/zfs/keys/pool.data.key  available  yes
pool/data/backups     aes-256-gcm  raw        file:///etc/zfs/keys/pool.data.key  available  yes
pool/archive          aes-256-gcm  passphrase prompt          unavailable no

Interprétation : keystatus=unavailable signifie que le dataset est verrouillé (clé non chargée). Si mounted=no et keystatus=available, vous avez un problème de montage, pas de clé.

Task 2: Confirm which datasets inherit a key vs have their own

cr0x@server:~$ zfs get -r -o name,property,value,source keylocation pool/system
NAME             PROPERTY     VALUE    SOURCE
pool/system      keylocation  prompt   local
pool/system/var  keylocation  prompt   inherited from pool/system

Interprétation : Les frontières d’héritage sont l’endroit où commence la prolifération des clés. La colonne source vous dit où vous êtes accidentellement passé en « local » et avez bifurqué votre gestion des clés.

Task 3: Create an encrypted dataset with passphrase prompt

cr0x@server:~$ zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt pool/secure
Enter passphrase:
Re-enter passphrase:

Interprétation : Ceci crée le dataset et le configure pour exiger une passphrase lors du chargement des clés. Bon pour des workflows de déverrouillage interactifs ; risqué pour des démarrages sans surveillance.

Task 4: Create an encrypted dataset using a key file

cr0x@server:~$ install -d -m 0700 /etc/zfs/keys
cr0x@server:~$ head -c 32 /dev/urandom > /etc/zfs/keys/pool.app.key
cr0x@server:~$ chmod 0400 /etc/zfs/keys/pool.app.key
cr0x@server:~$ zfs create -o encryption=on -o keyformat=raw -o keylocation=file:///etc/zfs/keys/pool.app.key pool/app

Interprétation : keyformat=raw attend des octets de clé. Les permissions comptent ; le fichier est maintenant un joyau de la couronne. S’il est lisible par des utilisateurs non autorisés, votre chiffrement est surtout décoratif.

Task 5: Lock and unlock a dataset (and verify)

cr0x@server:~$ zfs unmount pool/app
cr0x@server:~$ zfs unload-key pool/app
cr0x@server:~$ zfs get -o name,property,value keystatus pool/app
NAME      PROPERTY  VALUE
pool/app  keystatus unavailable

cr0x@server:~$ zfs load-key pool/app
cr0x@server:~$ zfs mount pool/app
cr0x@server:~$ zfs get -o name,property,value keystatus pool/app
NAME      PROPERTY  VALUE
pool/app  keystatus available

Interprétation : Démontez d’abord, puis déchargez la clé. Si vous déchargez pendant que c’est monté, ZFS refusera généralement parce que la clé est en cours d’utilisation.

Task 6: Import a pool without mounting, then unlock deliberately

cr0x@server:~$ zpool import -N pool
cr0x@server:~$ zfs load-key -a
cr0x@server:~$ zfs mount -a

Interprétation : -N importe sans monter, ce que vous voulez pour une récupération contrôlée : importer d’abord, déverrouiller ensuite, monter enfin. Ça rend les échecs évidents et plus sûrs.

Task 7: Identify why a dataset won’t mount (key vs mountpoint vs busy)

cr0x@server:~$ zfs mount pool/archive
cannot mount 'pool/archive': encryption key not loaded

cr0x@server:~$ zfs load-key pool/archive
Enter passphrase for 'pool/archive':

Interprétation : ZFS vous dit poliment la cause réelle. Quand il dit « key not loaded », n’allez pas tuner l’ARC et écrire des post-mortems de performance.

Task 8: Rotate a wrapping key (passphrase change) without re-encrypting data

cr0x@server:~$ zfs change-key pool/secure
Enter new passphrase:
Re-enter new passphrase:

Interprétation : Cela change la clé d’enveloppe pour la racine de chiffrement de ce dataset. C’est rapide parce que ça re-enveloppe le matériau de clé, sans réécrire tous les blocs.

Task 9: Rotate key material for a keyfile-managed dataset

cr0x@server:~$ head -c 32 /dev/urandom > /etc/zfs/keys/pool.app.key.new
cr0x@server:~$ chmod 0400 /etc/zfs/keys/pool.app.key.new
cr0x@server:~$ zfs set keylocation=file:///etc/zfs/keys/pool.app.key.new pool/app
cr0x@server:~$ zfs change-key pool/app
cr0x@server:~$ mv /etc/zfs/keys/pool.app.key.new /etc/zfs/keys/pool.app.key

Interprétation : Mettez à jour keylocation, puis change-key. Gardez l’ancienne clé jusqu’à ce que vous vérifiiez le déverrouillage après reboot/import. Oui, c’est un piège si vous supprimez trop tôt.

Task 10: Find the encryption root and confirm hierarchy

cr0x@server:~$ zfs get -o name,property,value -r encryptionroot pool/data
NAME             PROPERTY        VALUE
pool/data        encryptionroot  pool/data
pool/data/backups encryptionroot pool/data

Interprétation : Les datasets enfants héritent des clés depuis l’encryption root. Si vous voyez des enfants avec des encryption roots différents, votre procédure de déverrouillage doit en tenir compte.

Task 11: Validate that keys are not accidentally stored on the encrypted pool

cr0x@server:~$ zfs get -o name,property,value keylocation pool/data
NAME      PROPERTY     VALUE
pool/data keylocation  file:///etc/zfs/keys/pool.data.key

cr0x@server:~$ findmnt /etc/zfs/keys
TARGET        SOURCE    FSTYPE OPTIONS
/etc/zfs/keys /dev/sda1 ext4   rw,relatime

Interprétation : Le fichier de clé vit sur /dev/sda1 (probablement le disque OS), pas sur pool. Si /etc est sur le pool chiffré que vous essayez de déverrouiller, vous avez construit une porte verrouillée avec la clé scotchée de l’autre côté.

Task 12: Check boot-time unlock failures via systemd journal

cr0x@server:~$ journalctl -b -u zfs-import-cache -u zfs-mount -u zfs-load-key --no-pager
-- Journal begins at ...
systemd[1]: Starting Load ZFS keys...
zfs-load-key[1023]: cannot open 'file:///etc/zfs/keys/pool.data.key': No such file or directory
systemd[1]: zfs-load-key.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start Load ZFS keys.
systemd[1]: Dependency failed for ZFS mount.

Interprétation : Ce n’est pas un bug ZFS ; c’est un problème d’ordre ou de disponibilité de système de fichiers. Le chemin de clé n’existait pas au moment où le service s’est exécuté.

Task 13: List loaded keys quickly (at scale)

cr0x@server:~$ zfs list -H -o name,keystatus -r pool | awk '$2=="unavailable"{print $1}'
pool/archive
pool/secrets/hr

Interprétation : C’est la vue « qu’est-ce qui est encore verrouillé ? ». Utile pendant la récupération ou lorsqu’un reboot a laissé des datasets indisponibles.

Task 14: Verify that an encrypted dataset is actually encrypted on disk

cr0x@server:~$ zfs get -o name,property,value encryption,keyformat pool/secure
NAME        PROPERTY   VALUE
pool/secure encryption aes-256-gcm
pool/secure keyformat  passphrase

Interprétation : encryption montre le mode de chiffrement. Si c’est off, vous n’avez pas de chiffrement ; vous avez de l’optimisme.

Task 15: Export/import cycle test (the closest thing to a fire drill)

cr0x@server:~$ zfs unmount -a
cr0x@server:~$ zfs unload-key -a
cr0x@server:~$ zpool export pool

cr0x@server:~$ zpool import -N pool
cr0x@server:~$ zfs load-key -a
cr0x@server:~$ zfs mount -a
cr0x@server:~$ zfs list -o name,mounted,keystatus -r pool | head
NAME         MOUNTED  KEYSTATUS
pool         yes      -
pool/system  yes      available
pool/data    yes      available

Interprétation : C’est le test opérationnel que vous devriez exécuter avant de faire confiance à toute stratégie de clés. C’est une douleur contrôlée qui prévient des douleurs incontrôlées plus tard.

Réplication avec datasets chiffrés : send/receive sans douleur

La réplication est l’endroit où les bonnes intentions vont mourir. Les gens chiffrent des datasets, puis supposent que la réplication « fonctionnera » comme avant. Ça peut—mais vous devez choisir ce que vous répliquez : en clair, en chiffré, ou un mélange.

Les trois modes de réplication à comprendre

Envoyer en clair (le récepteur ré-encrypte) : les données sont déchiffrées côté envoi et reçues comme flux en clair ; le récepteur peut chiffrer avec sa propre clé. Acceptable sur un réseau de confiance, mais c’est une histoire de sécurité différente.
Envoyer brut (ciphertext) : le récepteur reçoit des blocs chiffrés et (souvent) la même structure de clé de dataset. Cela préserve le chiffrement de bout en bout mais change le comportement des clés et propriétés.
Workflows hybrides : envoyer brut pour les archives, en clair pour les datasets opérationnels, selon conformité et besoins de restauration.

Task 16: Send an encrypted dataset as a raw stream

cr0x@server:~$ zfs snapshot -r pool/data@replica-001
cr0x@server:~$ zfs send -w -R pool/data@replica-001 | zfs receive -uF backup/data

Interprétation : -w envoie un flux brut (garde le chiffrement). -u reçoit sans monter. C’est ainsi que vous évitez le chaos d’auto-montage sur une cible de sauvegarde. Après la réception, vous avez toujours besoin des clés pour monter si vous voulez lire.

Task 17: Receive and set a different key on the destination (when not sending raw)

cr0x@server:~$ zfs snapshot pool/app@replica-001
cr0x@server:~$ zfs send pool/app@replica-001 | zfs receive -o encryption=on -o keyformat=passphrase -o keylocation=prompt backup/app

Interprétation : Ceci ré-encrypte à la destination avec un contrôle de clés local. Utile quand l’environnement de backup a des exigences d’accès différentes.

Piège de réplication : « raw send » peut répliquer vos erreurs

Si vous avez utilisé la même hiérarchie de clés partout, le raw send la préserve joyeusement. Cela peut être exactement ce que vous voulez—ou exactement ce qui rend votre « environnement de sauvegarde » pas significativement séparé de la production.

Trois mini-récits du monde de l’entreprise

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (« Ça nous demandera une passphrase au démarrage »)

Ils avaient une flotte propre : une douzaine de nœuds de base de données et quelques serveurs applicatifs lourds de stockage. Quelqu’un a activé le chiffrement ZFS pour la « conformité », choisi les invites de passphrase, et a dit que c’était fini. Ça marchait en labo parce qu’il y avait toujours une personne à la console.

Puis est venu le déclencheur banal : une mise à jour du kernel et un redémarrage coordonné. La moitié des hôtes étaient en colocation avec du personnel distant ; l’autre moitié étaient des instances cloud avec une console série techniquement disponible mais pratiquement inutilisable sous pression temporelle. Le processus de démarrage attendait une saisie de passphrase que personne ne pouvait fournir à grande échelle.

Le on-call a fait ce que font les on-call : improviser. Ils ont tenté de monter les datasets manuellement, puis ont réalisé que les datasets n’étaient même pas déverrouillés. Ils ont essayé de charger des clés, mais les bonnes passphrases étaient éparpillées entre quelques personnes et un vault de gestionnaire de mots de passe—stocké sur un dataset chiffré qui était, bien sûr, verrouillé sur l’un des hôtes tombés.

La panne a duré assez longtemps pour devenir un incident inter-équipes. Personne n’avait fait de drill de reboot avec le chiffrement activé. La mauvaise hypothèse n’était pas technique ; elle était organisationnelle : ils avaient supposé qu’une invite humaine était une dépendance de production acceptable.

Par la suite, ils ont adopté une approche mixte : passphrases pour le dataset le plus sensible tolérant un déverrouillage manuel, et fichiers de clé récupérés sur le réseau pour le reste, avec des contrôles d’accès stricts. La leçon n’était pas « ne jamais utiliser les invites ». C’était : ne construisez pas un chemin critique qui dépend d’un humain calme à une console.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (« Rendons le déverrouillage totalement automatique »)

Un autre site est allé dans l’autre sens. Ils détestaient les invites au démarrage, alors ils ont automatisé complètement le déverrouillage en stockant des fichiers de clé sur le système racine de chaque serveur. Ils ont mis des permissions strictes, utilisé la gestion de configuration et même tourné les clés trimestriellement. Ça semblait mature.

Puis un compte de sous-traitant a été compromis. L’attaquant n’a pas eu besoin d’exploits kernel ou d’une magie crypto. Il a obtenu assez de privilèges pour lire le fichier de clé sur un sous-ensemble d’hôtes. À partir de là, les datasets ZFS chiffrés ont été juste un ralentissement, pas une barrière.

Le post-mortem a été gênant parce que personne n’avait fait quelque chose de « mal » au sens habituel. L’équipe avait optimisé pour la disponibilité et l’opérabilité, et y était parvenue. L’échec a été d’avoir optimisé au-delà du modèle de menace : le chiffrement était censé protéger contre la perte de disques et les fuites de matériel, mais la direction croyait aussi que cela protégerait contre la compromission d’hôte.

La correction n’a pas été de retirer l’automatisation ; c’était de mettre en place une vraie séparation des responsabilités. Ils ont déplacé les clés hors-hôtes, exigé une récupération authentifiée au démarrage et réduit qui pouvait accéder au mécanisme de récupération. Ils ont aussi introduit un signal de monitoring « clés chargées » : si des datasets étaient déverrouillés en dehors des fenêtres normales, cela déclenchait une investigation.

Deuxième blague, parce qu’on l’a mérité : la seule chose pire qu’une clé introuvable est une clé que tout le monde trouve.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (la « répétition de restauration » que personne ne veut)

Une entreprise du secteur financier avait un rituel : une fois par trimestre, elle faisait une répétition de restauration chiffrée. Ce n’était pas glamour. Ça prenait du temps. Ça agaçait les équipes. C’était aussi la raison pour laquelle ils n’ont pas eu d’incident qui ruine des carrières.

La répétition était simple : choisir un dataset, exporter et importer sur un hôte propre, charger les clés via la méthode documentée, monter en lecture seule, vérifier l’intégrité des données et documenter chaque écart. Le but n’était pas « peut-on le faire éventuellement » ; le but était « peut-on le faire fatigué, sous pression et pendant un gel des changements ».

Un trimestre, la répétition a échoué. Pas à cause de ZFS lui-même, mais parce que le processus d’escrow des clés avait dérivé. Une rotation avait eu lieu, et le matériau de clé mis à jour n’avait jamais été placé dans l’escrow hors ligne. Ils l’ont détecté lors d’un test planifié, pas lors d’un ransomware.

Ils ont corrigé le processus et ajouté une règle : une rotation de clé n’est pas complète tant que la répétition de restauration ne réussit pas. Les gens se sont plaints. Puis, une étagère de stockage a grillé de façon imprévue et ils ont dû reconstruire depuis la réplication et les sauvegardes. Déverrouiller et monter ont été les parties les moins excitantes de la récupération—ce qui est exactement le but.

Playbook de diagnostic rapide : quoi vérifier en premier, deuxième, troisième

Ceci est pour le moment où les datasets chiffrés ne montent pas et tout le monde vous regarde comme si vous aviez personnellement égaré les lois des mathématiques.

Premier : déterminez si c’est un problème de clé ou de pool

cr0x@server:~$ zpool status -x
all pools are healthy

cr0x@server:~$ zpool import
   pool: pool
     id: 1234567890
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.

Interprétation : Si le pool ne peut pas être importé ou est dégradé, réparez cela d’abord. Les clés n’aident pas si le pool n’est pas en ligne.

Second : vérifiez l’état des clés et l’encryption root

cr0x@server:~$ zfs list -r -o name,keystatus,encryptionroot,mounted pool | sed -n '1,25p'
NAME                 KEYSTATUS     ENCRYPTIONROOT  MOUNTED
pool                 -             -              yes
pool/system          available     pool/system     yes
pool/archive         unavailable   pool/archive    no

Interprétation : Si keystatus=unavailable, ne perdez pas de temps à optimiser le point de montage. Votre prochaine action est zfs load-key.

Troisième : validez la disponibilité de keylocation et l’ordre des services

cr0x@server:~$ zfs get -o name,property,value keylocation pool/archive
NAME         PROPERTY     VALUE
pool/archive keylocation  file:///etc/zfs/keys/pool.archive.key

cr0x@server:~$ ls -l /etc/zfs/keys/pool.archive.key
ls: cannot access '/etc/zfs/keys/pool.archive.key': No such file or directory

Interprétation : Fichier de clé manquant est la panne la plus courante au démarrage. S’il existe, vérifiez les permissions. S’il n’existe pas, vérifiez s’il réside sur un système de fichiers qui n’a pas encore été monté.

Quatrième : essayez un import et un déverrouillage contrôlés

cr0x@server:~$ zpool export pool
cr0x@server:~$ zpool import -N pool
cr0x@server:~$ zfs load-key -a

Interprétation : Les séquences contrôlées réduisent les surprises. Si load-key échoue, le message d’erreur est généralement exploitable (mauvaise passphrase, fichier manquant, URI invalide).

Cinquième : si toujours bloqué, collectez des preuves avant d’improviser

cr0x@server:~$ zfs get -r -o name,property,value,source encryption,keyformat,keylocation,keystatus,encryptionroot pool > /root/zfs-encryption-audit.txt
cr0x@server:~$ journalctl -b --no-pager > /root/boot-journal.txt

Interprétation : Cela préserve l’état pour une analyse ultérieure, et ça empêche l’équipe de « réparer » le problème en le transformant en mystère.

Erreurs courantes : symptômes et corrections

Mistake 1: Key file stored on the encrypted pool

Symptôme : après un reboot, zfs load-key échoue parce que le chemin du fichier de clé n’existe pas ; les datasets restent verrouillés ; situation poulet-œuf.

Correction : stockez le matériau de clé sur un filesystem racine non chiffré, un média amovible ou un mécanisme de récupération réseau disponible avant le montage ZFS. Retestez avec zpool import -N et zfs load-key.

Mistake 2: “We used encryption, so backups are safe”

Symptôme : les sauvegardes sont des streams chiffrés bruts mais les clés ne sont pas séquestrées ; la restauration échoue quand l’hôte original est parti.

Correction : séquestrez les clés (ou passphrases) nécessaires pour déverrouiller les réplicas, et effectuez des répétitions de restauration. Si vous utilisez raw send, assurez-vous que le côté receveur peut déverrouiller indépendamment de l’émetteur.

Mistake 3: Key rotation done without a reboot/import test

Symptôme : tout marche jusqu’au prochain reboot ; puis les datasets ne se déverrouillent pas parce que keylocation pointe vers une clé tournée qui n’a pas été déployée partout.

Correction : après rotation, exécutez un test export/import (Task 15) dans une fenêtre de maintenance ou sur un hôte canari. Considérez la rotation comme incomplète tant qu’elle ne passe pas le test.

Mistake 4: Inheritance drift creates “mystery keys”

Symptôme : certains datasets enfants exigent des clés différentes ; l’automatisation de déverrouillage charge la plupart des clés, mais un dataset reste verrouillé et une application échoue de façon étrange.

Correction : auditez encryptionroot et les sources de keylocation. Standardisez une stratégie d’encryption-root et appliquez-la via revue de code ou contrôles de politique.

Mistake 5: Unattended boot enabled with locally stored keys, then declared “secure”

Symptôme : l’audit de conformité demande « qui peut déverrouiller les données ? » et la réponse honnête est « quiconque a root sur l’hôte », ce qui n’est pas ce que la direction croyait.

Correction : alignez le modèle de menace. Si vous avez besoin d’une protection contre la compromission d’hôte, les clés locales ne suffiront pas. Déplacez la récupération hors-hôte et réduisez qui peut accéder aux chemins de récupération.

Mistake 6: Confusing pool import failures with key failures

Symptôme : les ingénieurs lancent zfs load-key en boucle mais le pool n’est pas importé ou est en lecture seule à cause d’erreurs.

Correction : commencez par zpool status et zpool import. Remettez d’abord le pool en santé/importé ; puis déverrouillez.

Mistake 7: Forgetting about snapshots and replication access

Symptôme : le système de sauvegarde reçoit des datasets chiffrés mais ne peut pas les monter pour vérification ; ou les montages de vérification exposent du texte en clair dans des environnements non prévus.

Correction : décidez si la cible de sauvegarde est autorisée à déchiffrer. Si oui, gérez les clés là-bas. Si non, vérifiez via checksum/contrôles de métadonnées et gardez-les verrouillées par défaut.

Listes de contrôle / plan étape par étape

Checklist 1: Design decisions (before you type commands)

Écrivez votre modèle de menace : disques volés ? admin véreux ? hôte compromis ? case conformité ?
Décidez de la politique de démarrage sans surveillance par classe de système (nœuds de base de données vs archivage vs portables).
Choisissez la granularité des clés : racine d’encryption unique vs par-domaine vs par-dataset.
Définissez l’escrow/casse-glace : qui peut déverrouiller, comment, et où résident les secrets quand le système principal est hors service.
Définissez la cadence de rotation et ce que « rotation complète » signifie (indice : import/déverrouillage testé).

Checklist 2: Build an encrypted dataset hierarchy safely

Créez un dataset racine d’encryption pour un domaine (par ex. pool/data).
Configurez les datasets enfants pour hériter des clés sauf s’il existe une séparation justifiée.
Documentez les encryption roots et keylocations dans votre repo d’infra (pas dans la tête de quelqu’un).
Effectuez un drill export/import (Task 15) avant la mise en production.

Checklist 3: Operational runbook for reboot and recovery

Importer les pools sans monter : zpool import -N.
Charger les clés : zfs load-key -a.
Monter : zfs mount -a.
Vérifier que les datasets critiques sont montés et que les clés sont disponibles.
Vérifier la santé des applications seulement après confirmation du stockage.

Checklist 4: Key rotation step-by-step (safe version)

Annoncer une fenêtre de maintenance et identifier le périmètre impacté (encryption roots concernés).
Générer le nouveau matériau de clé (politique de passphrase ou octets de fichier clé).
Déployer le matériau de clé sur tous les nœuds concernés (ou système de récupération), mais ne supprimez pas l’ancien matériel.
Changer la clé : zfs change-key sur les encryption roots.
Effectuer un test export/import contrôlé sur un hôte canari.
Seulement après un reboot/import réussi : supprimer l’ancien matériel des emplacements actifs, garder l’escrow conformément à la politique.

FAQ

1) Si je chiffre un dataset parent, les enfants sont-ils automatiquement chiffrés ?

Si des enfants sont créés sous un dataset chiffré, ils hériteront typiquement du chiffrement. Mais l’héritage peut dériver si quelqu’un définit des propriétés localement ou crée des datasets dans des endroits inattendus. Confirmez avec zfs get -r encryption,encryptionroot.

2) `zfs change-key` ré-encrypte-t-il toutes mes données ?

Non, il ré-enveloppe généralement le matériau de clé (rapide). C’est néanmoins risqué opérationnellement car vous pouvez vous verrouiller hors du dataset si vous gérez mal keylocation ou l’escrow. Traitez-le comme un changement à tester.

3) Quelle est la différence entre `keyformat=passphrase` et `keyformat=raw` ?

passphrase dérive le matériau de clé d’un secret saisi par un humain. raw attend des octets de clé (souvent stockés dans un fichier). Raw est compatible avec l’automatisation et peut être de haute entropie, mais augmente l’importance de la protection du fichier de clé.

4) Puis-je déverrouiller un dataset sans le monter ?

Oui. zfs load-key déverrouille (charge la clé en mémoire) ; le montage est séparé. Utile pour la récupération contrôlée et pour éviter de monter dans le mauvais environnement.

5) Si un dataset est chiffré, le pool est-il chiffré ?

Le chiffrement ZFS est au niveau dataset. Un pool peut contenir des datasets chiffrés et non chiffrés. Vos audits doivent vérifier la hiérarchie des datasets, pas supposer que « le pool est chiffré ».

6) Puis-je répliquer des datasets chiffrés vers un site de sauvegarde et les garder chiffrés de bout en bout ?

Oui, avec des raw sends (par ex. zfs send -w). Mais vous devez alors garantir que le site de backup a un moyen indépendant et testé de déverrouiller—ou accepter qu’il reste verrouillé et utiliser d’autres méthodes de vérification.

7) Pourquoi mon système a démarré mais les services ont échoué, alors que le pool s’est importé correctement ?

Fréquemment : le pool s’est importé, mais les clés n’ont pas été chargées, donc les datasets chiffrés ne se sont pas montés. Vérifiez zfs list -o name,keystatus,mounted et les logs système pour des échecs zfs-load-key.

8) Est-il sûr de stocker des fichiers de clé sur le disque OS ?

Ça dépend de votre modèle de menace. C’est pratique opérationnellement et protège contre le vol des disques de données, mais cela ne protège pas contre un attaquant ayant root sur l’hôte. Si vous avez besoin de garanties plus fortes, utilisez une récupération hors-hôte et des contrôles d’accès plus stricts.

9) Comment prouver aux auditeurs (et à moi-même) que la récupération fonctionne ?

En effectuant un drill import/unlock/mount sur un système propre, en n’utilisant que des procédures documentées et des secrets séquestrés. Enregistrez la sortie de zfs get et les étapes que vous avez suivies. Répétez selon un calendrier.

Conclusion : la routine l’emporte sur l’héroïsme

Le chiffrement ZFS est une bonne ingénierie. Mais le coup gagnant n’est pas de l’activer—c’est de l’opérationnaliser. Votre futur vous ne veut pas d’une configuration astucieuse ; il veut une configuration qui survive aux reboots, aux restaurations, aux changements d’équipe et au moment embarrassant où votre « système sécurisé » est inaccessible parce que la clé était stockée quelque part… sécurisé.

Si vous ne retenez qu’une habitude : exécutez le drill export/import + load-key avant d’en avoir besoin. Le jour du désastre se moque que le design ait été propre sur un diagramme. Il se contente de savoir si la personne de garde peut déverrouiller les données sans deviner.