On ne protège bien que ce que l'on connaît. Inventorier ses secrets, c'est dresser la liste complète des mots de passe, clés API et jetons qui existent dans votre système, savoir où ils se trouvent et qui les utilise. Cela repose sur trois piliers : un registre qui note chaque secret et ses informations, une découverte régulière qui débusque les secrets oubliés, et une classification par criticité qui dit lesquels protéger en priorité. Ce n'est pas une tâche que l'on fait une fois : c'est une boucle continue, car de nouveaux secrets apparaissent sans cesse. Cette page pose la méthode sans aucun prérequis technique.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »Beaucoup d'équipes protègent quelques secrets connus tout en ignorant des dizaines d'autres oubliés dans des fichiers, des images ou de vieux dépôts. Cette page vous donne la méthode pour ne plus être dans ce cas. Concrètement, vous saurez :
- Comprendre pourquoi l'inventaire est le point de départ de toute protection des secrets.
- Tenir un registre qui note pour chaque secret son type, son propriétaire, son emplacement et ses consommateurs.
- Organiser la découverte régulière pour retrouver les secrets oubliés dans le code, les images et les postes.
- Classer vos secrets par criticité et par type, afin de savoir lesquels protéger en premier.
- Relier cette démarche à la détection des secrets exposés et au modèle de menaces SOCLE sur les secrets.
Pourquoi inventorier ses secrets
Section intitulée « Pourquoi inventorier ses secrets »La sécurité obéit à une règle simple : on ne protège bien que ce que l'on connaît. Un secret dont vous ignorez l'existence est un secret que personne ne surveille, que personne ne fait tourner et que personne ne révoque le jour où il fuite. L'inventaire est donc le tout premier geste de la gestion des secrets : avant de choisir un coffre ou une règle de rotation, il faut savoir ce que l'on a en main.
Le problème, c'est que les secrets prolifèrent naturellement. Chaque nouveau service, chaque intégration, chaque déploiement crée sa clé API, son mot de passe ou son jeton. Personne ne tient le compte, et cette accumulation silencieuse forme une dette : des secrets créés « pour tester », copiés dans un fichier de côté, laissés dans un ancien dépôt. Ce sont autant de clés qui traînent, souvent avec des droits larges, sans que personne ne s'en souvienne.
Cette dette est d'autant plus dangereuse qu'elle est invisible. Une équipe peut penser gérer proprement ses dix secrets connus tout en laissant fuiter les cinquante qu'elle a oubliés. L'inventaire rend visible cette masse cachée. Il transforme un « on ne sait pas trop » en une cartographie claire, condition indispensable pour agir.
Le registre : ce qu'on note pour chaque secret
Section intitulée « Le registre : ce qu'on note pour chaque secret »Le premier pilier est le registre des secrets : un document, un tableau ou un outil qui recense chaque secret existant avec les informations utiles pour le gérer. Peu importe la forme au début, ce qui compte c'est de noter pour chaque secret les mêmes rubriques, afin de savoir en un coup d'oeil de quoi il s'agit et ce qui en dépend.
Voici les informations à consigner pour chaque secret :
- Le type : la nature du secret (mot de passe, clé API, jeton, clé privée, certificat). Le type détermine comment le secret se protège et se remplace.
- Le propriétaire : la personne ou l'équipe responsable de ce secret. C'est elle qu'on prévient s'il fuite et c'est elle qui décide de le faire tourner. Un secret sans propriétaire est un secret que personne ne gère.
- L'emplacement : où le secret est stocké (dans un coffre, une variable d'environnement, un fichier de configuration). Savoir où il vit permet de le retrouver et de le sécuriser.
- Les consommateurs : les applications, services ou personnes qui utilisent ce secret. Cette information est cruciale : le jour où vous devez remplacer un secret, elle vous dit exactement quoi mettre à jour pour ne rien casser.
- La date de rotation : la dernière fois que le secret a été remplacé par un nouveau. Un secret jamais renouvelé depuis des années est un risque, car plus il vit longtemps, plus il a eu d'occasions de fuiter.
L'intérêt du registre apparaît le jour d'un incident. Si une clé API fuite, le registre vous dit immédiatement qui en est responsable, où elle est stockée et quels services l'utilisent. Sans lui, vous partez à l'aveugle, à chercher dans la panique quels systèmes vont tomber si vous révoquez la clé. Le registre transforme une urgence en une opération maîtrisée.
La découverte : trouver les secrets oubliés
Section intitulée « La découverte : trouver les secrets oubliés »Un registre ne vaut que s'il est complet. Or personne ne pense à y noter les secrets « temporaires », ceux collés dans un vieux fichier ou hérités d'un ancien projet. C'est le rôle du deuxième pilier : la découverte de secrets, qui consiste à fouiller activement votre système pour débusquer les secrets que le registre ne connaît pas encore.
La découverte cible les endroits où les secrets se cachent le plus souvent :
- Les dépôts de code : un secret écrit en clair dans un fichier de programme au lieu d'être fourni de l'extérieur.
- Les images de conteneurs : un secret glissé dans une image (le paquet qui embarque une application prête à tourner) et distribué avec elle.
- Les postes de travail : des mots de passe et des clés stockés dans les fichiers de configuration des machines des développeurs.
- Les historiques : un secret retiré du code aujourd'hui mais toujours visible dans les versions passées conservées par les outils qui archivent l'historique.
La découverte n'est pas un geste manuel : des outils spécialisés parcourent ces sources et signalent tout ce qui ressemble à un secret. Chaque secret trouvé rejoint alors le registre, ou déclenche une action s'il n'aurait jamais dû se trouver là. Pour la mise en pratique de ce balayage, avec les outils et la méthode, voyez la page dédiée à la détection des secrets exposés.
La classification : par criticité et par type
Section intitulée « La classification : par criticité et par type »Une fois vos secrets recensés, tous ne se valent pas. Le troisième pilier est la classification : ranger vos secrets par importance afin de concentrer les efforts là où le risque est le plus fort. On ne protège pas de la même manière le mot de passe d'un outil interne sans données et la clé qui ouvre l'ensemble de votre infrastructure.
Le premier axe est la criticité : quel dommage causerait la fuite de ce secret. Un secret critique ouvre un accès étendu ou touche des données sensibles ; sa fuite serait grave. Un secret mineur donne un accès limité, sans conséquence majeure. Classer par criticité permet de dire clairement quels secrets doivent être protégés en priorité, surveillés de près et renouvelés le plus souvent.
Le second axe est le type de secret. Un mot de passe, une clé API et un certificat ne se remplacent pas de la même façon et n'ont pas la même durée de vie. Classer par type aide à organiser la rotation, c'est-à-dire le remplacement régulier d'un secret par un nouveau, en appliquant à chaque famille la règle qui lui convient.
Cette double classification, par criticité et par type, guide toutes les décisions suivantes. Elle indique où placer le peu de temps et de vigilance dont dispose une équipe : les secrets critiques passent dans un coffre solide avec rotation fréquente, tandis que les moins sensibles suivent un traitement plus léger. Sans classification, on protège tout pareil, donc mal, faute de moyens.
Le mettre en oeuvre
Section intitulée « Le mettre en oeuvre »En pratique, l'inventaire se construit en deux mouvements complémentaires. Le premier est la découverte : lancer un balayage de vos dépôts, images et postes pour dresser une première liste de ce qui existe réellement. C'est le point de départ concret, décrit dans la page détecter les secrets exposés, qui montre comment repérer ces secrets là où ils se cachent.
Le second mouvement est la centralisation dans un coffre. Un coffre à 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. Une fois vos secrets recensés et classés, les ranger dans un coffre transforme votre registre en un système vivant, où chaque secret a une place unique et surveillée. Le guide HashiCorp Vault présente un coffre concret et très répandu, mis en action.
L'inventaire alimente aussi le cycle de vie d'un secret : savoir ce que l'on a, c'est pouvoir décider quand chaque secret doit tourner et quand il doit disparaître. Le registre est la mémoire qui rend possible cette gestion dans la durée.
Pièges courants
Section intitulée « Pièges courants »L'inventaire des secrets échoue toujours de la même manière, et connaître ces pièges à l'avance évite de les reproduire.
Le piège le plus fréquent est l'inventaire fait une fois puis jamais mis à jour. Une équipe consacre une semaine à recenser tous ses secrets, produit un beau tableau, puis l'oublie. Six mois plus tard, ce tableau ne décrit plus la réalité : de nouveaux secrets sont apparus, d'autres ont disparu. Un inventaire figé donne une fausse sécurité, celle de croire qu'on maîtrise alors que la carte est périmée. C'est pourquoi l'inventaire est une boucle continue et non un projet ponctuel : registre, découverte et classification tournent en permanence.
Le deuxième piège est celui des secrets fantômes : des secrets qui existent et fonctionnent toujours, mais que le registre ignore. Ce sont les plus dangereux, car personne ne les surveille ni ne les fait tourner. Ils survivent souvent au départ de la personne qui les avait créés, sans propriétaire pour s'en soucier. Seule une découverte régulière permet de les rattraper avant qu'ils ne deviennent une porte d'entrée.
Le troisième piège est de classer trop finement dès le départ. Vouloir dix niveaux de criticité au premier jour paralyse la démarche. Mieux vaut deux ou trois catégories simples appliquées à tous les secrets qu'une classification savante que personne ne tient à jour. La simplicité est ce qui fait vivre l'inventaire dans le temps.
À retenir
Section intitulée « À retenir »-
On ne protège bien que ce que l'on connaît : l'inventaire est le point de départ obligatoire de toute gestion des secrets.
-
Les secrets prolifèrent : chaque service crée les siens, formant une dette invisible qu'il faut rendre visible.
-
Le registre note pour chaque secret son type, son propriétaire, son emplacement, ses consommateurs et sa date de rotation.
-
La découverte régulière débusque les secrets oubliés dans le code, les images, les postes et les historiques.
-
La classification par criticité et par type dit lesquels protéger et faire tourner en priorité.
-
C'est une boucle continue : un inventaire figé donne une fausse sécurité, et les secrets fantômes sont les plus dangereux.
-
La preuve attendue par le socle : tenir un registre des secrets à jour (SOCLE-SEC-INV-1), organiser leur découverte (SOCLE-SEC-INV-2) et les classer (SOCLE-SEC-INV-3). Le modèle de menaces SOCLE sur les secrets relie ces exigences aux attaques qu'elles bloquent.