Key Manager Scaleway : chiffrer sans jamais détenir la clé

Une clé de chiffrement qu'une application peut lire est une clé qui finira dans un journal, un vidage mémoire ou un fichier d'échange. Key Manager règle ce problème en refusant de vous la donner : la clé ne quitte jamais le service, qui exécute les opérations de chiffrement à votre place. Cette leçon construit ce modèle de bout en bout, montre pourquoi il permet d'autoriser une application à chiffrer sans l'autoriser à déchiffrer, et met en évidence les conventions opposées de Key Manager et de Secret Manager, qui coûtent une heure à qui les découvre en production.

Ce que vous allez apprendre

• Créer une clé et vérifier par vous-même qu'aucune commande n'en révèle le contenu.
• Chiffrer et déchiffrer par l'API, dans le format que le service attend réellement.
• Faire une rotation sans rendre illisible ce qui a été chiffré auparavant.
• Choisir entre chiffrement direct et chiffrement par enveloppe.
• Distinguer la suppression programmée de Key Manager de la suppression immédiate de Secret Manager.

Key Manager ou Secret Manager : lequel pour quoi ?

Les deux services stockent des données sensibles, et c'est la seule chose qu'ils ont en commun. La différence tient en une phrase : Secret Manager vous rend la valeur, Key Manager refuse de la rendre.

	Secret Manager	Key Manager
Ce qu'il stocke	n'importe quelle donnée sensible	des clés cryptographiques uniquement
Ce qu'il vous rend	la valeur, que votre code utilise	jamais la clé : le résultat d'une opération
Qui chiffre	votre application	le service
Autorisation possible	lire ou ne pas lire	chiffrer sans pouvoir déchiffrer
Suppression	immédiate	programmée, fenêtre de 7 jours

Glissez pour voir

La dernière ligne du tableau est la propriété qui justifie le service. Avec Secret Manager, une application qui doit chiffrer doit lire la clé, et qui peut lire la clé peut aussi déchiffrer : l'autorisation est indivisible. Avec Key Manager, la clé ne circule pas, donc les deux opérations se distinguent. Une application qui reçoit des données de santé peut être autorisée à les chiffrer avant insertion en base, sans pouvoir relire ce qui y est déjà stocké. C'est ce découpage qui rend le service intéressant, bien plus que le stockage lui-même.

Ce que cette leçon suppose acquis

Vous devez savoir créer une application IAM et lui attacher une politique, puisque c'est elle qui portera le droit de chiffrer ou de déchiffrer. Si ce n'est pas acquis, lisez d'abord IAM : donner le droit minimal à une CI, et le prouver, puis Secret Manager, qui pose le service voisin.

Créer une clé, et vérifier qu'elle ne sort pas

Le premier réflexe utile n'est pas de chiffrer, c'est de chercher la clé et de constater qu'elle est introuvable. C'est ce qui distingue une affirmation commerciale d'une propriété vérifiée.

1. Créez une clé symétrique, l'usage le plus courant.

   scw keymanager key create \
     name=demo-chiffrement \
     usage.symmetric-encryption=aes_256_gcm \
     -o json

   La sortie doit afficher "state":"enabled", "origin":"scaleway_kms" et, c'est le point à remarquer, "protected":true. Notez l'id.

2. Cherchez la clé dans les métadonnées. C'est le contrôle qui prouve le modèle.

   KEY_ID="<l-id-renvoye-ci-dessus>"
   scw keymanager key get key-id="$KEY_ID" -o json

   La sortie doit lister dix-huit champs, dont usage, rotation_count, state et origin. Aucun ne contient de matériel de clé, et il n'existe aucune commande pour en obtenir un. Mesuré le 10 septembre 2026 avec scw 2.62.0.

Une clé protégée dès la naissance

Key Manager crée ses clés protégées par défaut, ce que Secret Manager ne fait pas pour ses secrets. La conséquence se découvre au moment du nettoyage : key delete échoue tant que vous n'avez pas appelé key unprotect.

C'est un réglage par défaut que je trouve juste. Une clé supprimée par inadvertance rend définitivement illisible tout ce qu'elle a chiffré, ce qui est une catégorie de dégât au-dessus d'un secret perdu, lequel se régénère.

Quel usage choisir, et pourquoi il est définitif ?

L'usage se fixe à la création et détermine ce que la clé sait faire. Une clé de chiffrement symétrique ne signera jamais, et une clé de signature ne chiffrera jamais : il faut créer une seconde clé.

Le CLI en expose trois, chacun avec ses algorithmes. La commande d'aide reste la façon la plus sûre de voir ce que votre version accepte :

scw keymanager key create -h

Usage	À quoi il sert	Algorithmes proposés en 2.62.0
symmetric-encryption	chiffrer et déchiffrer des charges utiles	aes_256_gcm
asymmetric-encryption	chiffrer avec une clé publique, déchiffrer avec la privée	RSA-OAEP 2048, 3072, 4096, et ML-KEM 768 et 1024
asymmetric-signing	signer et vérifier	EC P-256, P-384, RSA-PSS, RSA-PKCS1, et ML-DSA 44, 65 et 87

Glissez pour voir

Deux familles post-quantiques figurent dans cette liste, et elles ne protègent pas la même chose. ML-KEM relève du chiffrement : c'est un mécanisme d'encapsulation de clé normalisé FIPS 203, qui répond à la menace dite « récolter maintenant, déchiffrer plus tard ». ML-DSA relève de la signature, normalisé FIPS 204 : il ne protège aucune confidentialité, il garantit l'origine d'un message. Les confondre conduit à choisir l'algorithme qui ne traite pas votre risque.

Quel usage pour quel besoin ?

Le tableau ci-dessous se lit par la colonne de gauche : partez de ce que vous devez protéger, et non de l'algorithme qui vous est familier. L'usage étant définitif, une erreur ici se paie par la création d'une seconde clé et la migration de ce qui dépendait de la première.

Besoin	Choix	Pourquoi
Chiffrer des données que vous relirez vous-même	symmetric-encryption en aes_256_gcm	le plus simple et le plus rapide, une seule clé pour les deux sens
Recevoir des données chiffrées par un tiers	asymmetric-encryption	le tiers chiffre avec la clé publique sans rien pouvoir déchiffrer
Prouver l'origine d'un message ou d'un artefact	asymmetric-signing	la signature n'apporte aucune confidentialité, seulement l'authenticité
Anticiper la menace quantique sur la confidentialité	asymmetric-encryption avec ML-KEM	encapsulation de clé FIPS 203, contre la récolte différée
Anticiper la menace quantique sur l'authenticité	asymmetric-signing avec ML-DSA	schéma de signature FIPS 204

Glissez pour voir

Chiffrer et déchiffrer : le format qui piège tout le monde

Le champ plaintext attend du base64, alors que le champ data de Secret Manager attend du texte brut. Deux services voisins, deux conventions opposées, et aucune des deux aides du CLI ne le dit.

1. Encodez la valeur, puis chiffrez.

   CLAIR='donnee-sante-patient-42'
   B64=$(printf '%s' "$CLAIR" | base64 -w0)
   scw keymanager key encrypt key-id="$KEY_ID" plaintext="$B64" -o json

   La sortie doit contenir un champ ciphertext. Sur cet exemple, il faisait 76 caractères pour 23 octets en clair : le chiffré embarque un en-tête, un vecteur d'initialisation et une étiquette d'authentification.

2. Déchiffrez et comparez, ce qui est la seule preuve que l'aller-retour fonctionne.

   CIPHER='<le-ciphertext-renvoye>'
   scw keymanager key decrypt key-id="$KEY_ID" ciphertext="$CIPHER" -o json \
     | python3 -c 'import json,sys,base64; print(base64.b64decode(json.load(sys.stdin)["plaintext"]).decode())'

   La sortie doit afficher donnee-sante-patient-42.

Le message d'erreur qui ne dit pas ce qu'il veut dire

Envoyer du texte brut produit ceci :

Illegal base64 data at input byte 6

Le message parle de données base64 illégales, ce qui laisse croire à un problème d'encodage de votre valeur. C'est l'inverse : c'est l'absence d'encodage qui pose problème. L'octet 6 est simplement le premier caractère que le décodeur n'a pas su interpréter.

Le contraste avec le service voisin mérite d'être retenu, parce qu'on passe de l'un à l'autre dans la même session :

	Secret Manager	Key Manager
Ce qu'on envoie	valeur brute	valeur en base64
Ce qu'on reçoit	valeur en base64	valeur en base64

Glissez pour voir

Mesuré le 10 septembre 2026 avec scw 2.62.0.

Pourquoi ne pas tout chiffrer directement ?

Parce que le service limite la charge utile à 64 Kio, et que ce n'est pas une limite arbitraire. Scaleway l'explique dans sa documentation cryptographique : la limite réduit le risque de surutilisation d'une clé, et le service se déclare conforme aux recommandations R1, R4 et R12 de l'ANSSI-PA-079 sur le choix d'un chiffrement authentifié, l'unicité des clés et des vecteurs d'initialisation, et la limitation de la taille des charges utiles.

La réponse à un fichier de plusieurs gigaoctets n'est donc pas de découper, c'est le chiffrement par enveloppe. Le principe tient en trois temps :

1. Demandez une clé de données au service. Il vous la rend deux fois : en clair, pour que vous chiffriez localement, et chiffrée par votre clé maîtresse, pour que vous la stockiez.

   scw keymanager key generate-data-key key-id="$KEY_ID" \
     algorithm=aes_256_gcm -o json

   La sortie doit contenir plaintext et ciphertext. Sur cet exemple, 44 caractères pour la version en clair, 88 pour la version chiffrée.

2. Chiffrez vos données localement avec la clé en clair, à pleine vitesse et sans limite de taille, puis effacez-la de la mémoire.

3. Stockez la version chiffrée de la clé à côté des données. Pour relire, vous redemandez au service de déchiffrer cette clé, et vous recommencez.

L'option without-plaintext=true ne renvoie que la version chiffrée, ce qui est utile quand vous préparez une clé destinée à un autre composant : celui-ci demandera lui-même le déchiffrement, et la valeur en clair n'aura jamais transité par votre poste.

Que devient l'existant après une rotation ?

Il reste déchiffrable, et c'est ce qui rend la rotation praticable. Le compteur rotation_count vaut 1 dès la création, puis s'incrémente à chaque appel :

scw keymanager key rotate key-id="$KEY_ID" -o json

La sortie doit afficher "rotation_count":2 et un rotated_at mis à jour. Relancez alors le déchiffrement du texte chiffré avant la rotation : il fonctionne toujours. Vérifié le 10 septembre 2026 avec scw 2.62.0.

La conséquence pratique est importante et souvent mal comprise. Une rotation ne rechiffre rien : elle change la clé utilisée pour les futures opérations, et le service conserve de quoi déchiffrer ce qui l'a été avec les versions précédentes. Si votre objectif est de rendre d'anciennes données illisibles, la rotation n'y suffit pas : il faut les rechiffrer explicitement, en les relisant et en les réécrivant.

Comment une application chiffre-t-elle sans jamais voir la clé ?

Le chemin complet tient en quatre étapes, et c'est lui qui différencie ce service d'un simple coffre. L'application démarre en portant une identité IAM, celle d'une application Scaleway à laquelle une politique donne le droit d'appeler Key Manager sur un Project donné. Quand elle doit protéger une donnée, elle ne demande pas la clé : elle envoie le texte à chiffrer au service, qui vérifie la politique, exécute l'opération avec une clé qui n'a jamais quitté son enceinte, et renvoie le chiffré. L'application stocke ce chiffré où elle veut, y compris dans une base ou un seau accessible à d'autres, puisqu'il est inutilisable sans le service. Pour relire, elle refait le chemin inverse. À aucun moment la clé n'existe dans la mémoire du processus, ni dans sa configuration, ni dans ses journaux, et c'est précisément ce qu'un audit cherchera à vérifier.

Limites, quotas et plafonds

Key Manager n'apparaît pas dans la page des quotas d'Organisation, qui ne couvre que Secret Manager : les valeurs ci-dessous viennent donc de la documentation cryptographique du produit et du lab.

Limite	Valeur	Source
Charge utile d'une opération de chiffrement	64 Kio	documentation cryptographique, conformité ANSSI-PA-079 R12
Fenêtre de suppression programmée	7 jours	FAQ officielle
Récupération d'une clé programmée	0,01 € par clé	FAQ officielle
rotation_count à la création	1, pas 0	mesuré en lab le 10 septembre 2026
Algorithme symétrique disponible	aes_256_gcm, le seul	aide de scw keymanager key create, 2.62.0

Glissez pour voir

La limite de 64 Kio est celle qui décide de votre architecture. Au-delà, le chiffrement direct n'est pas une option, et c'est l'enveloppe qu'il faut mettre en place dès la conception plutôt qu'en rattrapage.

Ce que ça coûte

La facturation porte sur les versions de clé conservées et sur les opérations effectuées. Une clé qui existe coûte, même inutilisée ; une clé très sollicitée coûte au nombre d'appels.

Le chiffrement par enveloppe a donc un effet secondaire économique qu'on oublie souvent : il réduit le nombre d'appels au service. Là où le chiffrement direct sollicite Key Manager à chaque donnée, l'enveloppe ne l'appelle qu'une fois par clé de données, puis travaille localement. Sur un volume important, l'écart de facture suit l'écart de conception.

La récupération d'une clé programmée pour suppression est facturée 0,01 € par clé, ce qui est symbolique et n'a pas vocation à peser dans une décision : c'est le délai de sept jours qui compte, pas le montant.

Key Manager sous l'angle Well-Architected

Security : qui peut déchiffrer, et l'avez-vous vraiment restreint ?

La question clé : votre politique IAM distingue-t-elle réellement le droit de chiffrer du droit de déchiffrer, ou avez-vous accordé les deux par défaut ?

C'est la propriété qui justifie le service, et c'est aussi celle qu'on n'exploite pas. Attribuer un jeu de permissions large à toutes les applications revient à retrouver le modèle de Secret Manager, avec ses inconvénients et le coût de Key Manager en plus.

La discipline : deux applications IAM distinctes quand les rôles diffèrent, celle qui ingère n'ayant que le droit de chiffrer, et prouver le refus en tentant un déchiffrement depuis l'identité qui ne doit pas l'avoir.

Operational Excellence : que se passe-t-il le jour où la clé disparaît ?

La question clé : si cette clé était supprimée maintenant, que perdriez-vous, et le sauriez-vous ?

Une clé supprimée rend définitivement illisible tout ce qu'elle protège. La fenêtre de sept jours est un filet, mais elle ne se déclenche que si quelqu'un s'aperçoit du problème à temps, ce qui suppose une supervision.

La discipline : laisser la protection en place, qui est le défaut du service, inventorier ce que chaque clé protège, et surveiller l'état scheduled_for_deletion, puisqu'une clé dans cet état disparaît de la liste sans autre signal.

Cost Optimization : payez-vous des appels que l'enveloppe éviterait ?

La question clé : combien d'appels votre application fait-elle au service par seconde, et sont-ils tous nécessaires ?

Le chiffrement direct sur des données nombreuses et petites multiplie les appels sans que rien ne l'annonce, jusqu'à la facture.

La discipline : réserver le chiffrement direct aux valeurs peu nombreuses, et passer à l'enveloppe dès que le volume ou la fréquence augmentent.

Pièges courants

Ces cinq situations ont été provoquées en lab le 10 septembre 2026 avec scw 2.62.0. Les messages sont ceux que le service renvoie.

Symptôme	Cause	Solution
Illegal base64 data at input byte 6	plaintext a reçu du texte brut, alors qu'il attend du base64	encoder avant d'envoyer, à l'inverse de Secret Manager
scaleway-sdk-go: precondition failed: , cannot delete a protected key	la clé est protégée, ce qui est le défaut du service	scw keymanager key unprotect avant de supprimer
scaleway-sdk-go: precondition failed: , cannot act on deleted resource	la clé est déjà programmée pour suppression, on ne peut plus agir dessus	attendre la purge, ou passer par la console pour une récupération
La clé a disparu de key list alors qu'elle existe encore	la suppression programmée retire la clé de la liste sans la détruire	interroger key get avec son identifiant, qui renvoie scheduled_for_deletion
Une rotation ne rend pas les anciennes données illisibles	la rotation ne change que les opérations futures	rechiffrer explicitement les données concernées

Glissez pour voir

Antipatterns à éviter

Ces cinq erreurs ont un point commun : elles ramènent Key Manager au rang de coffre-fort, alors que son intérêt est ailleurs. Payer un service qui refuse de rendre la clé pour ensuite lui demander une clé de données à chaque opération revient à en supporter le coût sans en tirer la propriété.

Antipattern	Conséquence	Discipline
Donner le droit de chiffrer et de déchiffrer à toutes les applications	l'asymétrie d'autorisation, seule raison d'être du service, disparaît	une identité par rôle, et prouver le refus
Chiffrer directement des données volumineuses	la limite de 64 Kio bloque, souvent en production	concevoir l'enveloppe dès le départ
Appeler le service à chaque donnée	le nombre d'appels suit le trafic, et la facture aussi	une clé de données par lot, réutilisée localement
Retirer la protection « pour simplifier les scripts »	une suppression accidentelle rend illisible tout ce que la clé protégeait	garder la protection, et l'ôter explicitement au moment de supprimer
Compter sur la rotation pour invalider d'anciennes données	les anciennes données restent déchiffrables	rechiffrer, ou détruire la clé en connaissance de cause

Glissez pour voir

Nettoyer

Une clé protégée résiste à la suppression, et une clé supprimée disparaît de la liste sans être détruite. Ces deux comportements font échouer un nettoyage naïf, dans un sens comme dans l'autre.

1. Retirez la protection, qui est active par défaut.

   scw keymanager key unprotect key-id="$KEY_ID"

   La sortie doit afficher "protected":false.

2. Supprimez la clé.

   scw keymanager key delete key-id="$KEY_ID"

   La sortie doit afficher « Key has been successfully deleted. »

3. Vérifiez l'état réel, car la liste ne suffit pas ici.

   scw keymanager key list -o json
   scw keymanager key get key-id="$KEY_ID" -o json

   La liste doit être vide. Le get, lui, renvoie encore la clé avec "state":"scheduled_for_deletion" et un deletion_requested_at renseigné : c'est normal, la purge définitive intervient au terme des sept jours.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• La clé ne sort jamais du service : key get ne renvoie aucun champ de matériel, et aucune commande n'en expose.
• Key Manager crée ses clés protégées par défaut, contrairement à Secret Manager : key delete échoue tant qu'on n'a pas appelé key unprotect.
• plaintext attend du base64, à l'inverse du champ data de Secret Manager qui attend du brut. Le message d'erreur Illegal base64 data at input byte 6 désigne l'absence d'encodage, pas un mauvais encodage.
• La charge utile est plafonnée à 64 Kio, limite justifiée par les recommandations ANSSI-PA-079 sur la surutilisation des clés.
• Au-delà, c'est le chiffrement par enveloppe : le service rend une clé de données en clair et chiffrée, vous chiffrez localement et ne stockez que la version chiffrée.
• Une rotation ne rechiffre rien : rotation_count passe de 1 à 2, et l'ancien chiffré reste déchiffrable. Pour invalider d'anciennes données, il faut les rechiffrer.
• La suppression est programmée sur 7 jours, alors qu'elle est immédiate dans Secret Manager. La clé passe en scheduled_for_deletion et disparaît de key list.
• Aucune commande de restauration dans le CLI 2.62.0 : key enable répond cannot act on deleted resource sur une clé programmée.

Pour aller plus loin

• Terraform : provisionner, et surtout détruire : déclarer une clé dans du code pose la question de ce qu'un destroy détruit vraiment quand la suppression est programmée.
• Ansible au quotidien : exploiter ce qui existe déjà : la rotation d'une clé est une opération de Day-2, à automatiser et à tracer.

Ressources externes

• Documentation Key Manager : les concepts, les guides et la référence de l'API.
• Différences entre Key Manager et Secret Manager : la page officielle qui tranche le choix entre les deux services.
• Détails cryptographiques de Key Manager : les algorithmes, la dérivation des clés importées et les limites de charge utile.
• Recommandations ANSSI-PA-079 sur le choix des mécanismes cryptographiques : le référentiel auquel Scaleway se déclare conforme.

×

📖 Voir la documentation →