Un secret est une information qui prouve une identité ou ouvre un accès, et dont la fuite cause un dommage : un mot de passe, une clé API, un jeton, une clé privée ou un certificat. Il se distingue d'une simple configuration, comme un numéro de port ou une adresse, qui peut être publique sans risque. La règle qui tranche tient en une phrase : si la divulgation de cette donnée fait courir un danger, c'est un secret, et il ne se stocke pas comme le reste. Cette page définit la notion sans aucun prérequis technique, pour des personnes qui découvrent le sujet.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Le mot secret revient partout dans la documentation technique, souvent sans être défini. Cette page pose les bases une fois pour toutes. Concrètement, vous saurez :
- Définir ce qu'est un secret et le reconnaître au premier coup d'oeil.
- Distinguer un secret d'une simple configuration, la confusion la plus fréquente.
- Comprendre pourquoi un secret volé donne un accès direct, et où les secrets fuient en pratique.
- Appliquer la règle qui tranche pour classer n'importe quelle donnée.
- Relier cette notion au cycle de vie d'un secret et au modèle de menaces SOCLE sur les secrets, qui montrent comment un secret naît, vit et se protège.
Qu'est-ce qu'un secret
Section intitulée « Qu'est-ce qu'un secret »Un secret est une information confidentielle qui sert à prouver une identité ou à débloquer un accès à un système. C'est la donnée que vous présentez pour dire « c'est bien moi, laisse-moi entrer ». Tant qu'elle reste connue de vous seul, l'accès est protégé. Dès qu'un tiers la connaît, il peut se faire passer pour vous.
La difficulté, pour un débutant, est de séparer un secret d'une simple configuration. Une configuration est un réglage qui dit à un logiciel comment se comporter ou où trouver quelque chose : un numéro de port (le numéro de la porte réseau sur laquelle un service écoute), une URL (l'adresse d'un service sur le réseau), un nom de base de données, un fuseau horaire. Ces réglages peuvent être écrits en clair, partagés dans l'équipe et versionnés (conservés dans l'historique du code) sans aucun risque.
Un secret, lui, est d'une autre nature. Voici les grandes familles à connaître :
- Un mot de passe : la suite de caractères qui déverrouille un compte.
- Une clé API : un jeton unique (une chaîne de caractères) qu'un programme présente à un service pour être autorisé, sans taper de mot de passe.
- Un jeton (ou token) : un laissez-passer temporaire délivré après connexion, qui vaut preuve d'identité tant qu'il est valide.
- Une clé privée : la moitié secrète d'une paire de clés cryptographiques, par exemple pour se connecter à un serveur en SSH (un protocole d'accès distant sécurisé).
- Un certificat avec sa clé associée : un document qui atteste l'identité d'un site ou d'un service, et dont la partie privée ne doit jamais sortir.
L'analogie la plus parlante est celle de la maison. L'adresse de votre maison est une configuration : vous pouvez l'écrire sur une enveloppe, la donner à un ami, l'afficher sans danger. La clé de votre porte est un secret : quiconque la possède entre chez vous. Personne ne confond l'adresse et la clé dans la vie courante. En informatique, la même rigueur s'impose, mais l'oubli est facile parce que les deux ressemblent à du texte dans un fichier.
La règle qui tranche
Section intitulée « La règle qui tranche »Face à une donnée dont vous ne savez pas quoi faire, une seule question suffit : si cette information fuite, est-ce que cela cause un dommage ? Si la réponse est oui, c'est un secret. Si la réponse est non, c'est une configuration ordinaire. Cette règle unique évite d'hésiter et de discuter au cas par cas.
Prenons deux exemples pour la tester. Le port 5432 sur lequel écoute une base de données PostgreSQL est public par nature : un attaquant qui le connaît ne peut rien en faire sans identifiants. Aucun dommage, donc pas un secret. En revanche, le mot de passe de cette même base ouvre toutes les données clients à qui le détient. Fuite égale dommage, donc secret. La règle a tranché sans ambiguïté dans les deux cas.
Pourquoi les secrets sont une cible
Section intitulée « Pourquoi les secrets sont une cible »Un secret volé ne demande aucun effort supplémentaire à l'attaquant : il donne un accès direct. Contrairement à une faille logicielle qu'il faut découvrir et exploiter, un secret est une clé prête à l'emploi. Celui qui la ramasse se connecte comme un utilisateur légitime, sans alerte, sans bruit. C'est pour cette raison que les secrets figurent parmi les premières cibles recherchées lors d'une attaque.
L'effet de levier aggrave le problème. Une seule clé API peut donner accès à une messagerie, à un service de paiement ou à toute l'infrastructure d'hébergement. Un seul jeton d'administration ouvre parfois l'ensemble d'un système. Voler un secret, c'est souvent obtenir bien plus qu'un simple compte : c'est prendre les commandes.
Encore faut-il savoir où les secrets fuient, car ils s'échappent rarement par la grande porte. Les points de fuite les plus courants sont :
- Le code source : un secret écrit en dur (directement dans un fichier de programme) au lieu d'être fourni de l'extérieur.
- L'historique Git : un secret retiré du code aujourd'hui reste visible dans les versions passées conservées par Git, l'outil qui archive l'historique du code.
- Les journaux (logs, les fichiers où un logiciel note ce qu'il fait) : un secret affiché par erreur dans un message d'erreur ou une trace de débogage.
- Les images de conteneurs : un secret glissé dans une image Docker (le paquet qui embarque une application prête à tourner) et distribué avec elle.
Chacun de ces points de fuite fait l'objet d'un guide dédié, car les parades diffèrent. Pour comprendre pourquoi coller un secret dans le code est un piège de fond, voyez le problème des secrets statiques. Pour le cas précis de Git, voyez les secrets dans le code et l'historique Git. Pour les journaux et les images, voyez les secrets dans les logs et les images.
Le mettre en oeuvre
Section intitulée « Le mettre en oeuvre »Reconnaître un secret n'est que la première étape. Ensuite, deux réflexes pratiques comptent. Le premier est de tenir un inventaire : lister quels secrets existent, où ils se trouvent et qui peut les utiliser. On ne protège bien que ce que l'on connaît, et un secret oublié est un secret non protégé. Le second est de les ranger dans un coffre.
Un coffre à secrets (secrets manager, gestionnaire de secrets) est un logiciel spécialisé qui stocke les secrets de façon chiffrée, contrôle qui y accède et garde une trace des consultations. Plutôt que d'éparpiller des mots de passe dans des fichiers, on les centralise dans ce coffre, et les applications viennent les chercher au moment voulu. C'est le socle de toute gestion des secrets sérieuse.
Le point de départ pratique se trouve dans la section dédiée aux secrets, qui rassemble les guides d'inventaire et de détection. Pour un coffre concret et très répandu, le guide HashiCorp Vault montre l'outil en action. Limiter en plus les droits accordés à chaque secret relève du principe de moindre privilège.
Pièges courants
Section intitulée « Pièges courants »Quelques erreurs reviennent sans cesse chez les débutants, et même chez des équipes expérimentées quand elles vont vite. Les connaître à l'avance évite d'y tomber.
Le piège le plus classique est le secret en dur « temporaire ». On colle un mot de passe directement dans le code « juste pour tester », en se promettant de le retirer plus tard. Ce plus tard n'arrive presque jamais. Le secret part dans l'historique Git, se diffuse aux collègues, et se retrouve parfois publié sans que personne ne s'en aperçoive. Un secret provisoire dans le code est un secret définitivement compromis : mieux vaut ne jamais l'y écrire.
Le deuxième piège concerne les variables d'environnement. Une variable d'environnement est une valeur fournie à un programme au démarrage, souvent utilisée pour transmettre un secret sans l'écrire dans le code. C'est une bonne pratique en soi, mais elle a un angle mort : ces variables sont fréquemment affichées dans les journaux lors d'un plantage ou d'un débogage. Le secret que vous pensiez à l'abri se retrouve alors en clair dans un fichier de log, lisible par tous ceux qui y accèdent.
Le troisième piège est de croire qu'un secret effacé du code est effacé partout. Retirer une clé d'un fichier ne la supprime ni de l'historique Git, ni des journaux, ni des images déjà construites. Un secret exposé doit toujours être considéré comme compromis et remplacé (on parle de rotation), pas simplement caché.
À retenir
Section intitulée « À retenir »-
Un secret prouve une identité ou ouvre un accès : mot de passe, clé API, jeton, clé privée, certificat.
-
Configuration n'est pas secret : un port ou une URL peuvent être publics, une clé jamais. La clé de la maison n'est pas son adresse.
-
La règle qui tranche : si la fuite de l'information cause un dommage, c'est un secret, point.
-
Un secret volé donne un accès direct : pas de faille à exploiter, l'attaquant entre comme un utilisateur légitime.
-
Les secrets fuient par le code, l'historique Git, les journaux et les images : chaque point de fuite a sa parade.
-
Un secret exposé est compromis : le cacher ne suffit pas, il faut le remplacer.
-
La preuve attendue par le socle : tenir un inventaire des secrets à jour (SOCLE-SEC-GEN-1) et les stocker dans un coffre (SOCLE-SEC-GEN-2). Le modèle de menaces SOCLE sur les secrets relie ces exigences aux attaques qu'elles bloquent.