Chapitre 16. Transit : le chiffrement comme service
Objectifs pédagogiques¶
Expliquer le modèle du chiffrement comme service. Exécuter les opérations de base avec leur encodage. Conduire une rotation sûre en trois temps. Employer le chiffrement d'enveloppe par datakey. Utiliser dérivation, chiffrement convergent, signatures et empreintes à bon escient. Gouverner les clés et énoncer ce que Transit déplace comme risque.
Prérequis¶
Chapitre 6 (rotation et versions de clés, que Transit rejoue côté service), chapitre 11 (le découpage des droits, qui devient ici cryptographique), chapitre 1 (le constat 7, que ce chapitre solde).
Cours¶
16.1 Le problème, et le renversement¶
Toute application qui chiffre affronte le même trio : où vit la clé, qui la voit, comment la changer. L'état des lieux du chapitre 1 a montré la réponse par défaut : dans un script, vue de tous ceux qui lisent le script, jamais changée.
Transit renverse le modèle. Les clés vivent dans Vault et n'en sortent jamais. Les applications envoient les données à chiffrer ou déchiffrer, Vault opère et renvoie le résultat. La clé devient un service, nommé, versionné, gouverné par policies, tracé par l'audit. L'application ne détient plus rien qui vaille d'être volé : son droit d'appeler est porté par son token, avec tout ce que la partie IV sait en faire.
Une propriété de conception définit le moteur : Transit ne stocke pas les données. Il chiffre, il rend, il oublie. Les données chiffrées vivent où l'application les range. C'est ce qui le distingue de KV, un service contre un stockage, et ce qui le rend léger : mille chiffrements ne créent pas mille objets, seulement mille lignes d'audit.
16.2 Les opérations de base, et le piège d'encodage¶
[Laboratoire]
La clé est créée avec le type par défaut aes256-gcm96, le chiffrement authentifié du chapitre 6, ici au service des applications.
# L'API prend le clair en BASE64 -- transport d'octets arbitraires, pas chiffrement
vault write transit/encrypt/billing-data \
plaintext="$(printf '%s' 'FR76 3000 4000 0500 0001 2345 678' | base64)"
# Reponse : ciphertext = vault:v1:8Gq3...
vault write -field=plaintext transit/decrypt/billing-data \
ciphertext="vault:v1:8Gq3..." | base64 -d
Deux lectures obligatoires. Le base64 est un transport, pas une protection : l'API véhicule des octets arbitraires dans du JSON. Le confondre avec du chiffrement est une erreur classique, et l'oublier produit des erreurs ou des doubles encodages silencieux. Le préfixe vault:v1: est structurel : il dit que le chiffrement vient de la version 1 de la clé, et c'est lui qui rend la rotation possible.
Notez enfin ce que la commande implique côté droits : chiffrer et déchiffrer sont deux chemins, donc deux droits séparables.
16.3 La rotation sûre, en trois temps¶
La rotation d'une clé Transit est une commande et une séquence, dont l'ordre est tout.
# Temps 1 : tourner la cle -- v2 devient la version de chiffrement
vault write -f transit/keys/billing-data/rotate
# Temps 2 : re-chiffrer l'existant -- SANS acces au clair
vault write transit/rewrap/billing-data ciphertext="vault:v1:8Gq3..."
# Reponse : vault:v2:...
# Temps 3 : couper le passe -- v1 ne dechiffre plus
vault write transit/keys/billing-data/config min_decryption_version=2
Le temps 1 est indolore : les nouveaux chiffrements partent en v2, les anciens restent déchiffrables. La clé conserve ses versions, exactement comme le keyring du chapitre 6.
Le temps 2 est le joyau du moteur. rewrap re-chiffre sans déchiffrer pour l'appelant : l'opération lit l'ancien chiffré, produit le nouveau, et le clair n'apparaît que dans la mémoire de Vault. La conséquence de policy est remarquable : un worker de migration peut porter le droit de re-chiffrer sans celui de déchiffrer. Il modernise tout le parc chiffré sans jamais pouvoir lire un octet.
Le temps 3 ferme : le plancher de version rend les vieux chiffrés illisibles. C'est le but, pour une version de clé qu'on soupçonne ou un plancher de conformité, et c'est le temps qui ne se joue qu'après le temps 2. Monter le plancher avant d'avoir tout re-chiffré, c'est transformer ses propres données en briques. Tourner, re-chiffrer, couper : la séquence est une question d'examen et un réflexe d'exploitation. Le paramètre jumeau min_encryption_version force les producteurs à la version récente sans toucher au déchiffrement.
16.4 Le datakey : chiffrer les gros volumes sans les faire transiter¶
Envoyer chaque mégaoctet à Vault serait absurde. Le chiffrement d'enveloppe résout le cas en une opération.
vault write -field=plaintext transit/datakey/plaintext/billing-data bits=256
# ...et dans la meme reponse : le champ ciphertext, la MEME cle chiffree par billing-data
L'appel rend une clé de données en deux exemplaires : en clair pour chiffrer localement, et enveloppée par la clé maîtresse pour être stockée à côté des données.
Le protocole applicatif tient en quatre gestes. Obtenir le couple. Chiffrer le gros volume localement avec la clé claire. Jeter la clé claire. Ranger l'enveloppe avec le fichier. Pour lire : présenter l'enveloppe au déchiffrement, récupérer la clé claire, déchiffrer localement, jeter.
Quatre propriétés en découlent. Les données ne transitent jamais par Vault. La clé maîtresse ne sort jamais. Chaque fichier a sa clé, donc une compromission expose un fichier et non le parc. Et la rotation de la clé maîtresse se propage par re-chiffrement des seules enveloppes, quelques kilooctets au lieu de téraoctets. La variante wrapped rend l'enveloppe seule, sans le clair, pour pré-provisionner des clés qu'un autre acteur saura ouvrir.
16.5 Dérivation et chiffrement convergent¶
Deux options de création, pour deux besoins précis, à réserver.
La dérivation exige un contexte à chaque opération, et la clé effective est dérivée de la clé nommée et de ce contexte. On obtient une clé logique par client, par dossier ou par tenant, sans créer mille objets. L'isolement est cryptographique : le contexte A ne déchiffre pas ce que le contexte B a chiffré. Le contexte devient un paramètre à gérer : perdu, les données le sont aussi.
Le chiffrement convergent, qui exige la dérivation, fait que le même clair sous le même contexte produit le même chiffré. Cela permet l'égalité sans déchiffrement, donc de retrouver un enregistrement par son identifiant chiffré ou de joindre deux tables sur une colonne chiffrée. Et cela sacrifie sciemment une propriété du chapitre 6, l'indistinguabilité : un observateur du stockage voit quelles lignes portent la même valeur, compte les doublons, corrèle. Le convergent est un outil d'index, pas un défaut de chiffrement à généraliser. On l'active sur une clé dédiée à ce seul usage, décision écrite, jamais sur la clé de confidentialité générale.
16.6 Signer, vérifier, authentifier¶
Transit dépasse la confidentialité. Avec une clé asymétrique, le moteur signe et vérifie.
vault write -f transit/keys/release-signing type=ed25519
vault write transit/sign/release-signing input="$(sha256sum artefact.tar.gz | cut -d' ' -f1 | base64)" prehashed=true hash_algorithm=sha2-256
vault write transit/verify/release-signing input=... signature="vault:v1:..."
Le cas d'usage du fil rouge est la signature d'artefacts : la CI signe ce qu'elle produit, les machines de déploiement vérifient avant d'installer. C'est la réponse outillée au risque de chaîne d'approvisionnement du chapitre 1, avec une propriété précieuse : la partie publique se lit dans la configuration de la clé, donc la vérification se distribue sans secret. Seul le droit de signer est gardé. Pour l'intégrité symétrique, les chemins d'empreinte à clé complètent la panoplie.
16.7 Gouverner les clés¶
Les paramètres de gouvernance, et les défauts qui sont les bons.
L'export interdit par défaut. Une clé exportable peut quitter Vault, et une clé sortie a perdu la propriété qui justifiait Transit. L'export existe pour les interopérabilités contraintes : il se refuse par principe et s'accorde par exception datée. La sauvegarde d'une clé relève du même régime ; la protection normale des clés Transit est la sauvegarde de Vault lui-même.
La suppression interdite par défaut. Supprimer une clé, c'est rendre illisible tout ce qu'elle protège, partout, pour toujours. Le garde-fou impose de basculer explicitement la configuration avant toute suppression : deux gestes, donc deux occasions de réfléchir.
L'élagage des versions sous le plancher de déchiffrement relève de l'hygiène, une fois la séquence de rotation achevée.
Le vrai contrôle reste les policies découpées par verbe. Le fil rouge écrit trois profils sur les mêmes clés : l'application chiffre et déchiffre, c'est son métier ; le worker de migration ne fait que re-chiffrer, il modernise sans lire ; l'outil de vérification de livraisons ne fait que vérifier, il contrôle sans pouvoir signer. Chaque chemin d'opération est un droit, et le moindre privilège cryptographique s'écrit en HCL ordinaire.
Exemple : deux chantiers d'Astrea, dont un compte à solder¶
Le chiffrement applicatif des données clients. L'application billing stocke des coordonnées bancaires ; la base, ses sauvegardes et ses réplicas les voyaient en clair. À l'écriture, l'application chiffre et range le chiffré versionné en base ; à la lecture, elle déchiffre. La base et ses dumps ne voient plus que des chiffrés. La policy du rôle AppRole s'enrichit des deux chemins Transit, et l'imputabilité s'étend au chiffrement : chaque déchiffrement est une ligne d'audit nominative. La rotation trimestrielle est un job nocturne appliquant la séquence en trois temps, le worker ne portant que le droit de re-chiffrer.
Le constat 7, soldé. Le script de sauvegarde chiffrait avec une clé écrite dans le script : lisible de quiconque lisait le script, jamais changée, sans trace d'usage. Réécriture au datakey : le script s'authentifie par un rôle dédié aux seuls droits de datakey, obtient un couple, chiffre l'archive localement, jette le clair, écrit l'enveloppe en tête de fichier. La restauration porte le seul droit de déchiffrer, tracé. Plus aucune clé dans le script, une clé par archive, une rotation qui ne re-chiffre que des enveloppes.
Et l'exception qui confirme, consignée en gras au dossier : les sauvegardes de Vault lui-même ne peuvent pas dépendre de Vault. Chiffrer les snapshots du chapitre 33 avec Transit créerait le cercle parfait, où restaurer Vault exigerait Vault. Leur protection a ses propres règles, fixées au chapitre 33.
Sécurité : ce que Transit déplace¶
La confidentialité devient une dépendance de disponibilité. Des données chiffrées par Transit sont illisibles quand Vault l'est. Le moteur transforme « qui peut lire » en « Vault répond-il », ce qui est l'argument le plus concret du dossier haute disponibilité et un paramètre de conception applicative.
Le clair transite, sauf en datakey. Chiffrer et déchiffrer font passer les données par le réseau et par la mémoire de Vault. Le pattern datakey garde les volumes chez l'application : le choix entre les deux est aussi un choix d'exposition.
Les droits sont le chiffre. La meilleure clé protégée par une policy en toutes capabilities ne protège rien : qui peut déchiffrer lit tout, qui peut écrire les chemins de clés gouverne les clés. La matrice par verbe est la sécurité effective du moteur.
L'audit voit chaque opération, et c'est un volume. Un déchiffrement par lecture applicative, c'est l'imputabilité rêvée et un journal qui grossit au rythme du trafic. Le dimensionnement de l'audit et les métriques se prévoient avec Transit, pas après.
Erreurs fréquentes¶
Oublier le base64, ou le doubler. L'API refuse le clair brut, ou déchiffre vers du base64 qu'on relit comme du texte : les deux bugs du premier jour (section 16.2).
Monter le plancher avant d'avoir re-chiffré. La séquence à l'envers rend les données illisibles, proprement et définitivement si les versions sont ensuite élaguées (section 16.3).
Rendre une clé exportable au cas où. Elle perd sa propriété fondatrice le jour de sa création, pour un cas qui n'arrivera pas (section 16.7).
Une clé unique pour tous les domaines. Un seul droit de déchiffrement ouvre tout, une seule rotation emporte tout. Une clé par domaine de données (section 16.7).
Le convergent par confort de requête. Activé sur la clé générale, l'égalité fuit sur tout le parc. Il vit sur une clé d'index dédiée (section 16.5).
Croire que Vault stocke les chiffrés. Le moteur est un service : les données chiffrées sont chez vous, avec vos sauvegardes (section 16.1).
Chiffrer les sauvegardes de Vault avec Vault. Le cercle parfait, où la restauration exige ce qu'on restaure (Exemple).
Mise en pratique : la séquence, les droits, l'enveloppe¶
Sur papier ; réponses commentées en fin de partie.
- Rédigez la procédure complète de rotation trimestrielle de
billing-data: commandes, ordre, vérifications entre chaque temps, et le critère qui autorise le temps 3. - Écrivez les trois policies HCL de la matrice de gouvernance, chemins exacts.
- Décrivez, en pseudo-code commenté de dix lignes au plus, le script de sauvegarde réécrit au datakey, en marquant où chaque secret vit, transite et meurt.
Questions de compréhension¶
- Énoncez le renversement de modèle et les deux propriétés de conception qui définissent le moteur.
- Que fait réellement le base64, et quels sont les deux bugs qu'engendre sa mauvaise compréhension ?
- Que signifie le préfixe de version, et quel mécanisme du chapitre 6 retrouve-t-on côté service ?
- Restituez la rotation en trois temps, le rôle exact du re-chiffrement, et la propriété de policy qu'il permet.
- Déroulez le protocole datakey en quatre gestes et ses quatre propriétés, dont l'effet sur le coût d'une rotation.
- Distinguez dérivation et chiffrement convergent : ce que chacun apporte, ce que le second sacrifie, sa règle d'emploi.
- Pourquoi la vérification de signatures se distribue-t-elle sans secret, et quel risque du chapitre 1 cela adresse-t-il ?
- Justifiez les deux défauts de gouvernance et le régime d'exception de chacun.
- Qu'est-ce que Transit déplace comme risque, et pourquoi les sauvegardes de Vault font-elles exception ?
Synthèse¶
Transit fait des clés un service : elles naissent, tournent et meurent dans Vault sans jamais en sortir, et les applications n'y détiennent qu'un droit porté par leur token, découpé par verbe et tracé. Les gestes structurants sont l'encodage de transport, la rotation en trois temps dont le re-chiffrement modernise sans lire, le datakey qui chiffre les volumes chez l'application en ne faisant voyager que des enveloppes, la dérivation pour multiplier les clés logiques, et le convergent réservé aux index et payé en indistinguabilité. Export et suppression sont verrouillés par défaut. Le moteur déplace le risque, la confidentialité devenant dépendance de disponibilité, et connaît sa limite structurelle : les sauvegardes de Vault ne se chiffrent pas avec Vault. Astrea y a gagné le chiffrement de ses données clients et soldé le constat 7.