Gestionnaire de secrets et service de clés : consommer un secret, savoir qui détient la clé racine

Un gestionnaire de secrets vous rend une valeur que votre application utilise, un service de clés refuse de vous rendre la clé et exécute l'opération à votre place ; dans les deux cas, la question à poser est « qui détient la clé racine ? ». Cette leçon vous apprend à consommer un secret sans le copier dans un fichier de configuration, à choisir le bon service entre les deux, et à répondre à la question de la clé racine pour un service donné. Elle s'adresse à qui a lu la leçon sur le chiffrement et la leçon sur les identifiants courts. L'exploitation d'un service de clés (chiffrer par enveloppe, renouveler une clé, révoquer) n'est pas traitée ici : le principe est dans la leçon sur le chiffrement.

Ce que vous allez apprendre

• Distinguer un gestionnaire de secrets d'un service de clés, par ce que chacun rend.
• Décrire le chemin d'une application qui consomme un secret, de son identité jusqu'à la mémoire du processus.
• Épingler une version de secret plutôt que demander la dernière.
• Répondre à « qui détient la clé racine ? » pour un service donné, et reconnaître quand la documentation ne permet pas d'y répondre.

Prérequis

• La leçon Chiffrement cloud : at-rest, in-transit, in-use et gestion des clés : chiffrement par enveloppe, clé maîtresse (KEK) et clé de données (DEK), les quatre modèles de gestion des clés.
• La leçon Identifiants courts d'une machine : identité attachée ou jeton d'amorçage : l'application obtient une identité avant de demander quoi que ce soit, par une identité attachée ou, chez Scaleway, par une clé d'API à expiration courte.

Quelle différence entre un gestionnaire de secrets et un service de clés ?

Un gestionnaire de secrets vous rend la valeur, un service de clés vous rend le résultat d'une opération. Les deux stockent des données sensibles, et c'est la seule chose qu'ils ont en commun. Le tableau compare les deux sur ce qui décide du choix : ce que l'application reçoit, qui effectue le chiffrement, et quelle autorisation on peut accorder. Il s'appuie sur Secret Manager et Key Manager de Scaleway, dont les leçons détaillent les commandes.

	Gestionnaire de secrets	Service de clés
Ce qu'il stocke	n'importe quelle donnée sensible (mot de passe, jeton, certificat)	des clés cryptographiques uniquement
Ce qu'il 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

Glissez pour voir

Le choix découle du besoin. Pour qu'une application se connecte à une base, elle a besoin du mot de passe : c'est un secret. Pour qu'elle protège des données avant de les stocker, elle n'a pas besoin de voir la clé : c'est le métier du service de clés. Les deux détails sont dans Secret Manager Scaleway et Key Manager Scaleway, que cette leçon cite comme illustration sans en faire le modèle universel.

Comment une application consomme-t-elle un secret ?

Elle s'authentifie d'abord, puis demande une valeur précise, qu'elle garde en mémoire pour la durée de son processus. Le chemin tient en quatre étapes et il est identique quel que soit le langage : l'application porte une identité (la leçon sur les identifiants courts a montré comment l'obtenir sans clé de longue durée : identité attachée, ou, avec Secret Manager Scaleway seul, une clé d'API d'application à expiration courte, limitée en lecture au secret visé), elle appelle le gestionnaire en désignant le secret et sa version, le service vérifie la politique d'accès et renvoie la valeur sur une connexion chiffrée, puis l'application la garde en mémoire sans l'écrire dans un fichier ni dans ses journaux. La différence avec un fichier de configuration est là : la valeur n'a existé que dans la mémoire du processus qui en avait besoin, et le service sait exactement qui l'a demandée et quand.

Chez Scaleway, la lecture d'une révision précise s'écrit ainsi (commande documentée par la leçon Secret Manager ; SECRET_ID est l'identifiant du secret visé) :

REVISION=1
scw secret version access secret-id="$SECRET_ID" revision="$REVISION" -o json

La valeur est renvoyée encodée en base64 dans le champ data : l'application la décode avant de s'en servir. Cette asymétrie (valeur brute à l'écriture, base64 à la lecture) est un piège que la leçon Secret Manager détaille.

Faut-il demander la dernière version ou une version précise ?

Sur un secret critique, épinglez un numéro de révision, comme dans la commande ci-dessus, plutôt que de demander la dernière (revision=latest). Un secret est un contenant : sa valeur vit dans ses versions, et une ancienne version reste lisible après l'ajout d'une nouvelle. Une application qui demande latest change donc de valeur au moment où quelqu'un ajoute une version : c'est parfait pour une rotation voulue, et redoutable si l'ajout était une erreur. En épinglant une révision dans la configuration, vous changez de valeur délibérément, et vous pouvez désactiver l'ancienne version (sans la supprimer) une fois que plus rien ne la lit.

Ce que le gestionnaire ne fait pas

Il ne protège pas un secret que l'application affiche ou journalise, ni un secret que quelqu'un copie dans un fichier après l'avoir lu. Il déplace le problème vers l'identité de l'application : qui peut lire quel secret se règle par la politique d'accès, au moindre privilège. Un secret lisible par toute l'organisation est un secret dans un fichier partagé, avec un meilleur journal.

Qui détient la clé racine de vos données ?

Le chiffrement par enveloppe repose sur une hiérarchie de clés, et la clé tout en haut est détenue par quelqu'un : la question est de savoir qui. Dans un service de clés, la clé de données (DEK) chiffre vos données ; elle est chiffrée par une clé maîtresse (KEK) que le service garde ; et dans certains services, cette KEK est elle-même protégée par une clé racine que le fournisseur détient. Répondre à « qui détient la clé racine » revient à dire qui peut, techniquement, aboutir au déchiffrement de vos données.

Un exemple documenté. Chez Scaleway, Key Manager suit trois niveaux : une clé racine par région (REK), détenue par Scaleway et stockée dans ses locaux selon sa documentation ; les clés de Key Manager (KEK), qui ne quittent jamais le service ; et les clés de données (DEK), générées à la demande et renvoyées chiffrées par la KEK. Le fournisseur détient donc la clé racine, et vous détenez la KEK au sens logique, sans accès à son matériel.

Question	Ce que la documentation permet de dire
Qui détient la clé racine du service de clés ?	Scaleway Key Manager : le fournisseur (clé racine régionale)
Puis-je apporter ma propre clé ?	Scaleway : import de clé possible (BYOK) ; la clé est alors dans le service
Puis-je garder la clé hors du fournisseur ?	Modèle HYOK : voir la leçon sur le chiffrement ; non relevé dans la documentation Scaleway consultée
Outscale ?	Aucun service de clés courant n'est décrit dans la documentation publique : une version bêta d'un ancien service (OKMS) figure dans la politique de fin de vie d'Outscale, avec une fin de vie au 8 février 2021

Glissez pour voir

Pour Outscale, la bonne réponse à « qui détient la clé racine du service de clés » est donc : la documentation ne permet pas de répondre, parce qu'aucun service courant n'y est décrit. Ne la remplacez jamais par une supposition ; une preuve sur ce point exigerait de vérifier auprès du fournisseur. Les enjeux de juridiction qui en découlent sont traités dans Souveraineté technologique de la stack.

Que faire de cette réponse ?

La réponse sert à décider, pas à rassurer. Si le fournisseur détient la clé racine, vos données sont protégées contre un voisin ou un vol de disque, pas contre une obligation légale qui s'impose au fournisseur. Si cette exposition n'est pas acceptable pour une catégorie de données, il faut passer à un modèle où la clé reste chez vous (BYOK puis HYOK), avec le coût opérationnel que la leçon sur le chiffrement détaille. Pour les autres données, le modèle du fournisseur reste un défaut raisonnable.

À retenir

• Un gestionnaire de secrets rend la valeur ; un service de clés rend le résultat d'une opération et refuse de rendre la clé.
• Une application consomme un secret en s'authentifiant puis en demandant une valeur précise, qu'elle garde en mémoire sans l'écrire sur disque ni dans ses journaux.
• Épinglez un numéro de révision sur un secret critique : latest change de valeur dès qu'une version est ajoutée. Désactivez l'ancienne version avant de la supprimer.
• Le gestionnaire déplace le problème vers l'identité : la politique d'accès, au moindre privilège, décide qui lit quoi.
• Chez Scaleway, la clé racine (REK) est détenue par le fournisseur, et vous détenez la KEK au sens logique.
• Chez Outscale, aucun service de clés courant n'est documenté : « qui détient la clé racine » reste sans réponse documentée, et aucune supposition ne la remplace.
• Opérer un service de clés (enveloppe, rotation, révocation) sort du périmètre : le principe est dans la leçon sur le chiffrement, et celle-ci s'arrête à consommer un secret et à nommer le détenteur de la clé racine.

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

×

📖 Voir la documentation →