Gestion des secrets : réduire les risques

Un développeur commit “temporairement” un mot de passe de base de données. Trois mois plus tard, un attaquant scanne GitHub, trouve ce secret dans l’historique Git et accède à la base de production. Le commit avait été supprimé, mais l’historique Git conserve tout.

Le problème n’est pas seulement la fuite accidentelle. Le vrai problème est l’usage massif de secrets statiques : trop durables, trop partagés, trop difficiles à révoquer. Les architectures modernes cherchent à réduire les secrets persistants au profit de secrets dynamiques et d’identités de workload.

Vocabulaire clé

Avant d’aller plus loin, voici les termes que vous croiserez tout au long de cette page :

Secret statique : accès stocké longtemps (mot de passe, clé API permanente)
Secret dynamique : accès généré à la demande, avec durée de vie limitée
Identité machine : identité cryptographique d’un workload (SPIFFE ID, certificat)
Workload : application, pod, service, job, VM, fonction serverless
Rotation : changement régulier d’un secret pour limiter l’exposition
Bootstrap : processus d’obtention du premier accès au coffre-fort

Pourquoi les secrets sont une cible prioritaire

Qu’est-ce qu’un secret

Un secret est toute information sensible donnant accès à un système :

Mot de passe
Clé API
Token d’authentification
Certificat TLS
Clé SSH
Secret applicatif (JWT secret, encryption key)
Identifiant technique (service account)

Tous ces éléments sont sensibles, mais leur gestion n’obéit pas exactement aux mêmes règles. Un mot de passe, une clé API, une clé privée et un certificat ont des cycles de vie et des contraintes différents. Le NIST SP 800-57 existe justement parce que la gestion des clés cryptographiques a ses propres exigences.

Pourquoi un secret compromis est si dangereux

Contrairement à une vulnérabilité logicielle qui nécessite une exploitation technique, un secret exposé donne un accès immédiat :

Conséquence	Impact
Accès immédiat	L’attaquant entre sans effort
Contournement des contrôles	Authentification légitime, pas de détection
Déplacement latéral	Un secret mène souvent à d’autres systèmes
Difficulté de détection	Activité “normale” avec des credentials valides
Compromission durable	Si le secret ne tourne jamais, l’accès persiste

Où les secrets fuient réellement

Les secrets ne fuient pas que dans le code source. Voici les surfaces réelles d’exposition :

Code source : password = "admin123" en dur dans un fichier
Historique Git : commit supprimé mais toujours accessible via git log
Variables CI/CD : secret affiché dans les logs de pipeline
Fichiers .env : committé “par erreur” ou copié entre environnements
Images Docker : secret visible via docker history
Logs applicatifs : credential affiché en mode debug
Outils de debug : secret capturé dans un dump mémoire ou un core dump
Chat et tickets : secret partagé par Slack, JIRA, email

Secrets dans le code et Git Pourquoi supprimer un commit ne suffit pas

Fuites de secrets : logs, Docker, variables Les fuites invisibles : logs, images Docker, /proc

Qui est concerné par la gestion des secrets

La gestion des secrets n’est pas qu’une affaire de sécurité. Elle concerne toute personne qui touche au code, à l’infrastructure ou aux données. Voici comment chaque rôle contribue à une gestion saine.

Profil	Responsabilité	Priorité
Développeur	Ne jamais commiter de secrets, utiliser l’injection runtime	Quotidienne
Ops / SRE	Configurer les coffres-forts, automatiser rotation et révocation	Critique
DevSecOps	Détecter les secrets exposés, intégrer les scans CI/CD	Continue
RSSI	Politique de gestion des secrets, audit de conformité	Stratégique
Tech Lead	Revue de code, culture équipe, choix des outils	Encadrement

Les principes d’une gestion saine des secrets

Séparer le code et les secrets

Le code source ne doit jamais contenir de secrets. Les secrets sont injectés au runtime depuis une source externe sécurisée.

# ❌ Mauvais : secret en dur
DB_PASSWORD="mon-super-mot-de-passe"

# ✅ Bon : référence à un coffre-fort
DB_PASSWORD=$(vault kv get -field=password secret/db/prod)

Chiffrer, centraliser, tracer

Chiffrer : les secrets sont stockés chiffrés, jamais en clair
Centraliser : un point unique de vérité, pas de copies multiples
Tracer : chaque accès est audité (qui, quand, pourquoi)

Limiter les droits au strict nécessaire

Un secret donne accès au minimum requis. Un token admin “par facilité” est une surface d’attaque maximale.

Prévoir la rotation et la révocation

Un secret doit pouvoir être changé rapidement. Si la rotation est pénible, elle ne sera pas faite.

Automatiser au maximum

L’humain est le maillon faible. Automatisez la génération, la distribution, la rotation et la révocation.

Le cycle de vie d’un secret

Consultez le guide dédié : Cycle de vie d’un secret.

Chaque secret passe par plusieurs étapes. Comprendre ce cycle permet d’identifier les points de contrôle où appliquer les bonnes pratiques.

Étape	Description	Bonnes pratiques
Génération	Créer un secret fort	Aléatoire, longueur suffisante, entropie élevée
Stockage	Persister de façon sécurisée	Coffre-fort chiffré, contrôle d’accès
Distribution	Transmettre à l’application	Injection runtime, jamais en clair dans les configs
Utilisation	Accéder au secret	Accès tracé, durée de vie limitée
Rotation	Changer régulièrement	Automatisée, sans interruption de service
Révocation	Invalider immédiatement	Suppression rapide si compromission suspectée
Audit	Tracer les accès	Logs centralisés, alertes sur anomalies

Le vrai problème : les limites des secrets statiques

C’est le point clé que beaucoup de guides ignorent. Avant de parler d’outils, il faut comprendre pourquoi les secrets traditionnels posent problème.

Ce qu’est un secret statique

Un secret statique est un secret qui :

Existe avant d’être utilisé
Est stocké quelque part (fichier, variable, coffre-fort)
Est souvent partagé entre plusieurs composants
A une durée de vie longue (mois, années)
Nécessite une rotation manuelle ou peu fréquente

Exemples : mot de passe de base de données, clé API permanente, token d’accès stocké dans un coffre-fort puis réutilisé pendant des mois.

Pourquoi les secrets statiques posent problème

Problème	Conséquence
Durée de vie trop longue	Plus de temps pour être découverts et exploités
Duplication dans plusieurs couches	Difficile de savoir où ils sont tous
Difficiles à révoquer partout	Un secret compromis reste actif quelque part
Mal adaptés aux environnements éphémères	Pods Kubernetes, fonctions serverless
Mauvaise attribution	Impossible de savoir quel service a causé un incident

OWASP souligne que les services partageant les mêmes secrets rendent l’identification de la source d’une compromission plus difficile.

Les symptômes d’une mauvaise maturité

Reconnaissez-vous ces situations ?

Mot de passe DB partagé entre plusieurs applications
Token admin utilisé “par facilité” dans un script
Secret stocké dans Kubernetes puis copié dans un .env
Rotation annuelle manuelle (si elle est faite)
Secret jamais supprimé après un incident
Même credential en dev, préprod et prod

Pourquoi les secrets statiques sont un problème Comprendre les limites des credentials persistants

Secrets statiques, secrets dynamiques et identité machine

Cette section est centrale pour comprendre l’évolution de la gestion des secrets.

Secret statique

Un secret créé manuellement, stocké, puis réutilisé :

Mot de passe PostgreSQL défini une fois
Clé API longue durée
Token stocké dans un coffre-fort et réutilisé pendant des mois

Secret dynamique

Un secret généré à la demande, avec une durée de vie limitée :

Généré au moment où l’application en a besoin
Limité dans le temps (TTL)
Lié à un rôle ou une politique
Révoqué automatiquement à expiration

Exemple : Vault génère un utilisateur PostgreSQL temporaire avec un mot de passe unique, valide 1 heure, puis le supprime automatiquement.

Identité machine / workload identity

Un concept différent : la machine ou le workload prouve son identité :

L’application reçoit un document cryptographique court (certificat, token)
Cette identité permet de s’authentifier auprès d’autres services
Pas de secret partagé entre services

Exemple : un pod Kubernetes reçoit un SPIFFE ID (identité cryptographique) qu’il utilise pour s’authentifier auprès d’une base de données, sans mot de passe.

En résumé

Pour simplifier :

Un secret statique est un accès stocké quelque part
Un secret dynamique est un accès créé à la demande puis expiré
Une identité machine permet à un service de prouver qui il est, sans partager un mot de passe durable

Tableau de comparaison

Modèle	Exemple	Avantages	Limites
Secret statique	Mot de passe DB, clé API longue	Simple à comprendre	Fuite durable, rotation difficile
Secret dynamique	Login DB temporaire, credentials cloud TTL court	Révocation automatique, durée de vie réduite	Nécessite une plateforme adaptée
Identité machine	SPIFFE ID, certificat workload, OIDC federation	Évite le secret partagé, meilleure attribution	Plus complexe à concevoir

Secrets statiques vs dynamiques Comparez les trois modèles : statique, dynamique et identité fédérée

Identité machine et workload identity SPIFFE, SPIRE et authentification machine-to-machine

Pourquoi aller vers les secrets dynamiques

Réduire la fenêtre d’exploitation

Les secrets dynamiques n’existent pas avant lecture. Cela réduit le risque de vol. Après usage ou expiration, ils sont révoqués automatiquement.

Faciliter la rotation

Pas de rotation manuelle : chaque accès génère un nouveau secret. L’ancien expire naturellement.

Limiter l’impact d’une compromission

Un secret dynamique compromis est valide quelques minutes ou heures, pas des années.

Donner un secret différent à chaque workload

Chaque pod, chaque job CI, chaque fonction reçoit ses propres credentials. L’attribution d’un incident devient triviale.

Mieux tracer qui accède à quoi

Chaque secret généré est lié à un demandeur spécifique. Les logs d’audit sont précis.

Cas concrets de secrets dynamiques

Credentials dynamiques pour base de données

Vault peut générer des utilisateurs temporaires pour :

PostgreSQL
MySQL / MariaDB
MongoDB
Microsoft SQL Server

L’utilisateur est créé à la demande avec les permissions définies dans un rôle, et supprimé automatiquement après expiration du TTL.

Credentials cloud temporaires

Au lieu de stocker des access keys AWS longue durée :

Vault génère des credentials IAM à la demande
Durée de vie de quelques minutes à quelques heures
Aucun secret persistant dans les pipelines CI/CD

Certificats courts pour mTLS

Le service mesh ou le proxy génère des certificats de courte durée pour le chiffrement inter-services. Rotation automatique toutes les 24 heures ou moins.

Tokens éphémères pour jobs CI/CD

Le workflow s’authentifie via OIDC, récupère un token de courte durée, et n’a jamais besoin de stocker de credentials dans le dépôt.

L’identité machine : au-delà des secrets

Qu’est-ce qu’une identité machine

Ce n’est pas un “mot de passe de machine”. C’est une identité vérifiable cryptographiquement attribuée à un workload :

Une VM
Un pod Kubernetes
Un service
Un agent
Une fonction serverless

Pourquoi ce n’est pas la même chose qu’un secret

Secret	Identité machine
Peut être copié	Délivrée après attestation
Dure longtemps	Généralement courte (certificat temporaire)
Partageable	Liée à un workload spécifique
Difficile à attribuer	Attribution précise

Cas d’usage machine-to-machine (M2M)

Service A appelle service B (API interne)
Pod Kubernetes appelle une base de données
Runner CI appelle un registry d’artefacts
Agent infra appelle une API cloud
Sidecar ou proxy mTLS

Distinguer les trois types de secrets

Pour clarifier votre gestion, distinguez :

Secrets humains : mots de passe utilisateurs, MFA
Secrets applicatifs : clés API, tokens, credentials DB
Identités machine : certificats workload, SPIFFE ID, tokens OIDC

Pour approfondir l’identité machine : Identité machine et workload identity.

Vers des architectures moins dépendantes des secrets

Réduire les secrets persistants autant que possible

L’objectif n’est pas d’éliminer tous les secrets, mais de réduire les plus risqués :

Fédération d’identité (OIDC, SAML)
Workload identity (SPIFFE, cloud IAM)
Secrets dynamiques (Vault, cloud secrets engines)
Certificats courts (cert-manager, SPIRE)
Accès temporaires pour CI/CD

Quand un secret statique reste nécessaire

Dans certains cas, un secret statique est inévitable :

Équipements legacy sans support moderne
Intégrations tierces imposant une clé API
Outils ne supportant pas l’identité fédérée
Bootstrap initial (le premier secret pour accéder au coffre-fort)

L’objectif réaliste

Ne pas chercher à tout remplacer d’un coup, mais supprimer progressivement les credentials les plus durables, les plus partagés et les plus critiques.

Exemple d’architecture moderne

Application web sur Kubernetes

Le pod reçoit une identité de workload (SPIFFE ID ou service account token)
Cette identité permet d’obtenir un credential DB dynamique depuis Vault
Le credential expire automatiquement après 1 heure
Aucun mot de passe permanent n’est embarqué dans l’image

Pipeline CI/CD

Le workflow s’authentifie via OIDC (GitHub Actions, GitLab CI)
Il récupère un token temporaire pour accéder au registry ou au cloud
Aucun token longue durée n’est stocké dans les secrets du dépôt

Communication service à service

mTLS avec identités de workload
Autorisation basée sur l’identité du service (SPIFFE ID)
Pas de secret partagé entre microservices

Secrets Kubernetes Secrets natifs, External Secrets Operator, CSI Driver

Secrets CI/CD GitHub Actions, GitLab CI et OIDC

Gouvernance et ownership

Les outils ne suffisent pas. Une gestion saine des secrets nécessite une gouvernance claire et des processus organisationnels.

Inventaire des secrets

Savez-vous exactement :

Combien de secrets existent dans votre organisation ?
Où chaque secret est utilisé ?
Quelle est sa date d’expiration ou de rotation attendue ?
Qui est le propriétaire responsable ?

Sans inventaire, la réponse à incident est aveugle.

Ownership

Chaque secret doit avoir un propriétaire identifié :

Qui décide de le créer ou de le révoquer ?
Qui est alerté en cas de compromission ?
Qui valide les accès ?

Processus de réponse à incident

Que faites-vous quand un secret fuite ?

Détecter : alerting sur exposition GitHub, logs anormaux
Révoquer : invalidation immédiate du secret
Tourner : nouveau secret pour tous les consommateurs légitimes
Analyser : comprendre comment c’est arrivé
Améliorer : corriger le processus pour éviter que ça se reproduise

Testez-vous régulièrement cette procédure ? Une procédure non testée est une procédure qui échouera en conditions réelles.

Pièges courants

Les erreurs suivantes sont fréquentes dans les organisations, même celles qui utilisent un coffre-fort. Chaque piège a un impact direct sur la posture de sécurité et nécessite une action corrective.

Piège	Conséquence	Solution
Secret statique partagé entre services	Impossible d’attribuer un incident	Identité ou secret distinct par workload
Rotation manuelle rare	Secret valide trop longtemps	Secrets dynamiques ou rotation automatisée
Kubernetes Secrets comme seul coffre-fort	Faux sentiment de sécurité	Chiffrement etcd + RBAC + External Secrets
Token cloud long terme dans CI/CD	Compromission durable	OIDC, accès temporaires, workload identity
Secrets via variables d’environnement uniquement	Exposition dans logs, `/proc`, dumps	Injection contrôlée, durée de vie minimale
Même secret dev/staging/prod	Compromission dev = compromission prod	Secrets séparés par environnement
Commiter “temporairement”	L’historique Git conserve tout	Pre-commit hooks avec Gitleaks

Outils à connaître

Détection des secrets

Gitleaks Détection de secrets dans les dépôts Git

TruffleHog Scanner de secrets avec vérification active

Coffres-forts et chiffrement

HashiCorp Vault Gestion centralisée + secrets dynamiques + PKI

Mozilla SOPS Chiffrement de fichiers de configuration

Infisical Plateforme moderne de gestion des secrets

Passbolt Gestionnaire de mots de passe pour équipes

Secrets dynamiques et identités machine

Le marché propose plusieurs solutions, chacune avec ses forces. HashiCorp Vault reste la référence établie, mais le changement de licence (BSL) en 2023 a conduit la communauté à créer OpenBao, un fork communautaire open source de Vault sous gouvernance ouverte (Linux Foundation / OpenSSF).

Outil	Spécialité
HashiCorp Vault	Secrets statiques, dynamiques, PKI, transit encryption
OpenBao	Fork open source de Vault, stockage sécurisé, secrets dynamiques
SPIFFE / SPIRE	Identités de workload, attestation, mTLS
AWS IAM Roles Anywhere	Workload identity pour ressources hors AWS
GCP Workload Identity	Identité pour pods GKE sans service account key
Azure Workload Identity	Identité pour pods AKS avec federation OIDC
External Secrets Operator	Synchronisation secrets externes → Kubernetes
Secrets Store CSI Driver	Montage de secrets depuis providers externes

Choisir la bonne approche selon le besoin

Pour un humain

Gestionnaire de mots de passe (Bitwarden, Passbolt)
MFA obligatoire
Partage contrôlé avec audit
Rotation régulière

Pour une application simple

Coffre-fort central (Vault, Infisical)
Injection runtime (pas de .env committé)
Rotation programmée

Pour une plateforme cloud-native

Secrets dynamiques (Vault database secrets engine)
Workload identity (SPIFFE, cloud IAM)
Certificats courts (cert-manager, SPIRE)
mTLS inter-services
Accès temporaires CI/CD (OIDC)

Pour du legacy

Secret statique, mais fortement contrôlé
Rotation la plus fréquente possible
Monitoring des accès
Moindre privilège strict

À retenir

Le code source ne doit jamais contenir de secrets — c’est la règle de base
Un secret statique doit être l’exception, pas la norme — visez les secrets dynamiques
Un secret dynamique est préférable à un secret longue durée — réduisez la fenêtre d’exploitation
Pour le machine-to-machine, pensez identité avant mot de passe — SPIFFE, workload identity
La bonne stratégie consiste à réduire progressivement les secrets persistants — pas tout d’un coup

Guides spécialisés

Pourquoi les secrets statiques sont un problème Comprendre les limites des credentials persistants

Cycle de vie d'un secret De la génération à la révocation en passant par le stockage, la distribution et la rotation

Fondamentaux et détection

Secrets statiques vs dynamiques Comparez les trois modèles : statique, dynamique et identité fédérée

Détecter les secrets exposés Gitleaks, TruffleHog, Trivy : stratégie combinée

Identité machine et workload identity SPIFFE, SPIRE et authentification M2M

Ce que cette page ne couvre pas

Cette page pivot pose les bases. Elle ne traite pas en profondeur :

PKI et gestion des certificats — Architecture PKI, chaînes de confiance, automatisation avec cert-manager
Design des politiques d’autorisation — RBAC, ABAC, OPA, admission controllers
Procédures d’incident complètes — Playbooks de réponse, forensics, communication de crise

Les guides enfants détaillent ces sujets.

Ressources externes

OWASP Secrets Management Cheat Sheet — recommandations OWASP
HashiCorp Vault Documentation — secrets statiques et dynamiques
SPIFFE / SPIRE — identités de workload
NIST SP 800-57 - Key Management — gestion des clés