Inventorier et classer ses secrets

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 leçon prolonge la définition d'un secret et ne demande aucun autre prérequis technique.

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 leçon 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, ses consommateurs et sa criticité.
• 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

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 renouvelle 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.

On ne protège bien que ce que l'on connaît. Un registre à jour, alimenté par une découverte régulière et une classification par criticité, est le socle de toute gestion de secrets. Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

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

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'œil 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 renouveler. 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 criticité : le dommage que causerait sa fuite, notion détaillée plus bas dans la partie sur la classification. Elle dit dans quel ordre agir quand plusieurs secrets sont touchés.
• 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.

Une ligne de registre ne contient jamais la valeur du secret, seulement ses métadonnées. Le tableau montre à quoi ressemblent trois lignes, pour un système fictif de commande en ligne :

Secret	Type	Propriétaire	Emplacement	Consommateurs	Criticité
db-commandes	Mot de passe	Équipe plateforme	Coffre	API commandes, worker d'envoi	Critique
cle-api-paiement	Clé API	Équipe paiement	Variable d'environnement	Service de facturation	Critique
jeton-statistiques	Jeton	Équipe données	Fichier de configuration	Tableau de bord interne	Mineure

Glissez pour voir

La deuxième ligne saute aux yeux : une clé critique dans une variable d'environnement, c'est un défaut que le registre rend visible et qu'il faudra corriger en la déplaçant vers un coffre.

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, ceux que la leçon Qu'est-ce qu'un secret en informatique ? a présentés comme points de fuite, au nombre de quatre :

• Les dépôts de code, où un secret traîne en clair dans un fichier de programme.
• Les images de conteneurs, qui peuvent embarquer un secret et le distribuer avec elles.
• 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, qui gardent un secret retiré du code aujourd'hui.

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.

Découvrir avant de subir

Mieux vaut trouver un secret oublié soi-même, tranquillement, que le voir apparaître dans un incident ou un dépôt public. La découverte régulière est une assurance : elle rattrape ce que le registre a manqué avant qu'un attaquant ne le fasse à votre place.

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

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 à secrets, le logiciel défini dans la leçon Qu'est-ce qu'un secret en informatique ?. 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 être renouvelé et quand il doit disparaître. Le registre est la mémoire qui rend possible cette gestion dans la durée. La première étape de ce cycle de vie reprend d'ailleurs ce registre avec une grille de classes de secrets plus fine et un exemple de registre minimal en YAML : la leçon qui la contient se lit après celle-ci, quand on passe de la méthode à l'outillage.

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 renouvelle. 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

1. 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.

2. Les secrets prolifèrent : chaque service crée les siens, formant une dette invisible qu'il faut rendre visible.

3. Le registre note pour chaque secret son type, son propriétaire, son emplacement, ses consommateurs, sa criticité et sa date de rotation.

4. La découverte régulière débusque les secrets oubliés dans le code, les images, les postes et les historiques.

5. La classification par criticité et par type dit lesquels protéger et renouveler en priorité.

6. C'est une boucle continue : un inventaire figé donne une fausse sécurité, et les secrets fantômes sont les plus dangereux.

7. La preuve attendue par le socle : un inventaire à jour avec type, propriétaire, emplacement, consommateurs et criticité (SOCLE-SEC-GEN-1), tenu sous forme de registre (SOCLE-SEC-INV-1), complété par une découverte régulière (SOCLE-SEC-INV-2) et une classification des secrets (SOCLE-SEC-INV-3). Le modèle de menaces SOCLE sur les secrets relie ces exigences aux attaques qu'elles bloquent.

Contrôle de connaissances

Quatre questions sur les trois piliers de l'inventaire : ce que le registre note pour chaque secret, pourquoi la découverte le complète, et ce que la criticité décide pendant un incident. Aucune ne demande de connaissance extérieure à cette leçon.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

4 questions

4 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 →