Gestion des secrets
Sécurité
Discipline qui encadre toute la vie d'un secret d'infrastructure (mot de passe, clé d'API, jeton, certificat, chaîne de connexion), de son inventaire jusqu'à sa révocation. Elle décrit des pratiques ; l'outil qui stocke et délivre ces secrets relève du gestionnaire de secrets.
Inventaire et stockage : Tout commence par savoir quels secrets existent, à quoi ils servent et qui les détient. On les crée et on les range hors du code et des fichiers de configuration versionnés, dans un gestionnaire de secrets.
Distribution au plus juste : Un secret ne va qu'au service qui en a besoin, et seulement au moment où il en a besoin, de préférence sous forme d'identifiant à courte durée de vie rattaché à une identité gérée par l'IAM. Moins un secret circule, moins il y a d'endroits où il peut fuiter.
Rotation et révocation : La rotation périodique remplace un secret avant qu'il ne fuite ; la révocation le coupe immédiatement après une fuite ou le départ d'une personne qui le connaissait. La rotation est la vraie épreuve, parce qu'elle révèle les dépendances que personne n'avait documentées : le mot de passe de base de données « utilisé par un seul service » sert aussi, on le découvre le jour de la bascule, à un script de sauvegarde, à un tableau de bord et à une tâche planifiée que plus personne n'ose toucher.
Détection des fuites : On scanne l'historique Git et les couches des images de conteneur : supprimer un fichier dans un nouveau commit ne l'efface ni de l'historique ni d'une couche antérieure. Un secret détecté se révoque d'abord ; le nettoyage vient ensuite.
Ce qui arrive si on s'en passe
Sans gestion des secrets, aucun inventaire ne dit quels secrets existent ni où ils se trouvent : mots de passe et clés d'API finissent copiés dans le code source, les fichiers de configuration ou l'historique Git, lisibles par quiconque accède à ces emplacements. Un secret qui n'expire jamais reste exploitable tant qu'il n'est pas révoqué, y compris après le départ des personnes qui le connaissaient. Faute d'inventaire, une fuite ne peut pas être circonscrite : on ignore quels systèmes dépendent du secret compromis, si bien que sa révocation casse des services imprévus ou n'est jamais faite. Un identifiant partagé entre plusieurs services ou personnes empêche aussi d'attribuer une action dans les journaux. Enfin, sans rotation régulière, la révocation d'urgence reste une opération lente et risquée au moment précis où elle s'impose.
Explication de la marmotte
Imagine un immeuble avec plein de portes et plein de clés. Gérer les secrets, c'est tenir le registre de toutes ces clés : savoir lesquelles existent et qui en a un double, ne jamais les laisser sous le paillasson, et n'en prêter une qu'à la personne qui doit ouvrir cette porte précise, seulement le temps nécessaire. De temps en temps, on change les serrures, par prudence. Si quelqu'un perd son trousseau ou déménage, on les change tout de suite. Et le jour où on change une serrure, on découvre souvent que le voisin du troisième s'en servait aussi, sans l'avoir dit à personne.
Où ce terme est utilisé
- Extraire les données d'entraînement de ChatGPT : l'attaque poem (3 occurrences)
- OWASP Kubernetes Top 10 2025 : les dix risques d'un cluster (2 occurrences)
- AI Act : exactitude, robustesse et cybersécurité d'une IA à haut risque (article 15) (1 occurrence)
- Apprentissage automatique et réseaux de neurones, attaques du modèle (1 occurrence)
- Attaques par canaux auxiliaires et secrets (1 occurrence)
- Ce qui n’est pas écrit n’a pas été décidé (1 occurrence)
- Certificats SSH et risques de l’agent forwarding (1 occurrence)
- CICD-SEC-6 : hygiène des identifiants insuffisante (1 occurrence)
- Comment dire non en comité de sécurité sans perdre sa crédibilité (1 occurrence)
- Comment lire un rapport OWASP Top 10 (1 occurrence)