Quand un mot de passe de base de données ne vit que quelques minutes au lieu de mois

Votre équipe fait tourner les mots de passe de base de données tous les trois mois. Vous vous sentez plus en sécurité que les équipes qui ne les font jamais tourner. Mais voici la question inconfortable : que se passe-t-il si un mot de passe fuit deux jours après la rotation ? Ce secret reste valide pendant encore 88 jours. Quiconque le trouve peut accéder à votre base de données de production pendant près de trois mois avant que la prochaine rotation ne le neutralise.

Cette faille n'est pas théorique. Les secrets fuient via les fichiers journaux, les runners CI compromis, les ordinateurs portables des développeurs ou les sauvegardes mal configurées. Un secret statique avec une longue durée de vie offre aux attaquants une large fenêtre. Plus un secret vit longtemps, plus un seul incident de fuite peut causer de dégâts.

C'est là que le concept de secrets à courte durée de vie change la donne. Au lieu de stocker un mot de passe valable des mois, vous générez un identifiant à la demande, l'utilisez pour exactement une tâche, et le laissez mourir immédiatement après.

Ce qui rend un secret dynamique

Un secret dynamique n'est pas une valeur stockée. C'est un identifiant créé au moment où quelqu'un en a besoin, avec une durée de vie mesurée en minutes ou en secondes. Une fois la tâche terminée, l'identifiant disparaît. Personne ne peut le réutiliser plus tard.

Imaginez ce scénario : votre pipeline CI doit exécuter une migration sur une base de données PostgreSQL. Avec un secret statique, le pipeline lit un mot de passe stocké dans un coffre, se connecte à la base de données, exécute la migration et se déconnecte. Ce mot de passe reste valide pour une utilisation future. Si quelqu'un l'extrait des journaux du pipeline, il peut se connecter à la base de données à tout moment jusqu'à la prochaine rotation.

Le diagramme de séquence suivant montre comment ce flux fonctionne :

sequenceDiagram participant CI as Pipeline CI participant V as Coffre participant DB as Base de données CI->>V: Demande accès DB pour migration V->>DB: Créer utilisateur temporaire + mot de passe DB-->>V: Identifiants V-->>CI: Retourne identifiants temporaires CI->>DB: Exécuter migration DB-->>CI: Migration terminée CI->>V: Signaler tâche terminée V->>DB: Révoquer utilisateur temporaire DB-->>V: Confirmé

Avec un secret dynamique, le pipeline envoie une requête à un coffre : "J'ai besoin d'un accès à la base de données pour cette migration." Le coffre crée un tout nouveau nom d'utilisateur et mot de passe, lui accorde des permissions en lecture-écriture sur le schéma de migration, et retourne l'identifiant au pipeline. Le pipeline l'utilise, termine la migration, et le coffre révoque automatiquement l'identifiant. Le nom d'utilisateur et le mot de passe qui ont existé pendant cette fenêtre de cinq minutes sont maintenant morts. Même si les journaux du pipeline fuient, l'identifiant est inutile.

Voici à quoi ressemble cette requête au coffre en pratique :

# Demander un identifiant de base de données dynamique depuis Vault
VAULT_RESPONSE=$(vault read -format=json database/creds/migration-role)

# Extraire le nom d'utilisateur et le mot de passe temporaires
DB_USER=$(echo "$VAULT_RESPONSE" | jq -r '.data.username')
DB_PASS=$(echo "$VAULT_RESPONSE" | jq -r '.data.password')

# Utiliser l'identifiant pour la migration
psql "postgresql://${DB_USER}:${DB_PASS}@db.example.com:5432/production" \
  -f ./migrations/001_initial.sql

# L'identifiant expire automatiquement après son TTL (ex: 5 minutes)
# Aucune révocation manuelle nécessaire

La différence fondamentale : la durée de vie

Les secrets statiques ont une longue durée de vie. Vous les stockez, les faites tourner périodiquement, et espérez qu'ils ne fuient pas entre les rotations. Le risque est proportionnel à la durée de vie. Un mot de passe tourné tous les 90 jours offre à un attaquant une fenêtre potentielle de 90 jours.

Les secrets dynamiques ont une courte durée de vie. Ils sont créés pour un objectif spécifique et détruits une fois cet objectif atteint. La fenêtre d'exploitation passe de mois à minutes. Si un identifiant fuit, il est déjà expiré au moment où quelqu'un le trouve.

Ce changement modifie votre façon de penser la gestion des secrets. Au lieu de demander "qui peut lire ce secret ?", vous demandez "qui peut demander un nouveau secret ?". Le coffre gère le reste.

Comment les secrets dynamiques changent le contrôle d'accès

Les secrets statiques vous obligent à gérer l'accès aux valeurs stockées. Vous configurez qui peut lire un mot de passe particulier, et vous espérez que ce mot de passe n'est pas copié ou partagé. Si un développeur a besoin d'un accès en lecture seule à une base de données, vous créez soit un identifiant statique séparé, soit vous lui donnez le même identifiant que tout le monde.

Les secrets dynamiques vous permettent de définir des politiques d'accès au niveau de la requête. Lorsqu'un pipeline a besoin d'un accès à la base de données, le coffre crée un identifiant avec exactement les permissions dont ce pipeline a besoin. Un pipeline en lecture seule obtient un identifiant en lecture seule. Un pipeline de migration obtient un accès en écriture à des tables spécifiques. Un pipeline d'analyse obtient un accès select-only à certains schémas.

Cette granularité rend l'audit simple. Chaque identifiant est lié à une requête spécifique, un pipeline spécifique et une fenêtre temporelle spécifique. Vous pouvez retracer exactement ce qui s'est passé, quand et avec quelles permissions.

Quand les secrets dynamiques ne conviennent pas

Les secrets dynamiques sont puissants, mais ils ne remplacent pas universellement les secrets statiques. Certaines situations nécessitent encore des identifiants à longue durée de vie.

Les applications qui maintiennent des connexions persistantes à la base de données ne peuvent pas utiliser des identifiants qui expirent en minutes. Un serveur web qui maintient un pool de connexions a besoin d'un identifiant qui reste valide pendant la durée de vie de la connexion. Dans ce cas, vous pouvez utiliser un secret statique avec une période de rotation plus courte, ou implémenter un pooling de connexions qui peut rafraîchir les identifiants sans interrompre les connexions actives.

Les systèmes externes qui ne prennent pas en charge la création automatisée d'identifiants posent également problème. Si vous devez vous authentifier auprès d'une API tierce qui émet des jetons via un processus d'enregistrement manuel, vous ne pouvez pas générer d'identifiants dynamiques pour celle-ci. Vous êtes coincé avec des jetons statiques, et vous devez gérer leur rotation avec soin.

Certains systèmes hérités manquent des API nécessaires pour l'approvisionnement dynamique d'identifiants. Si votre base de données ne prend pas en charge la création d'utilisateurs par programmation, ou si votre fournisseur cloud nécessite la création manuelle de rôles IAM, les secrets dynamiques ne sont pas une option.

Outils qui gèrent les secrets dynamiques

HashiCorp Vault est l'outil le plus courant pour la gestion des secrets dynamiques. Il prend en charge la génération d'identifiants pour PostgreSQL, MySQL, MongoDB, AWS, GCP et de nombreux autres systèmes. Lorsqu'un client demande un identifiant, Vault le crée, lui attribue un bail avec une durée de vie, et le révoque automatiquement à l'expiration du bail.

D'autres outils comme CyberArk Conjur et AWS Secrets Manager offrent également des capacités de secrets dynamiques, bien que l'implémentation varie. La fonctionnalité clé à rechercher est la création et la révocation automatiques des identifiants sans intervention manuelle.

Une liste de contrôle pratique avant d'adopter les secrets dynamiques

Avant de remplacer tous les secrets statiques par des secrets dynamiques, parcourez cette liste de contrôle :

  • Le système cible prend-il en charge la création programmatique d'identifiants ? Vérifiez si votre base de données ou votre fournisseur cloud dispose d'une API pour créer des utilisateurs ou des rôles temporaires.
  • Votre application peut-elle gérer l'expiration des identifiants ? Si votre application maintient des connexions de longue durée, vous avez besoin d'une stratégie pour rafraîchir les identifiants sans interrompre les connexions.
  • Vos pipelines demandent-ils des identifiants à la demande ? Les secrets dynamiques fonctionnent mieux lorsque chaque exécution de pipeline demande son propre identifiant plutôt que de réutiliser un identifiant mis en cache.
  • Votre infrastructure de coffre est-elle fiable ? Si le coffre tombe en panne, personne ne peut demander de nouveaux identifiants. Prévoyez une haute disponibilité.
  • Avez-vous audité quels pipelines ont réellement besoin de secrets dynamiques ? Certains pipelines s'exécutent si rarement qu'un secret statique avec une courte période de rotation est plus simple à gérer.

L'essentiel à retenir

Les secrets statiques avec une longue durée de vie créent une faille de sécurité qui grandit chaque jour entre les rotations. Les secrets dynamiques comblent cette faille en rendant les identifiants valides uniquement pour la durée d'une seule tâche. Le compromis est la complexité : vous avez besoin d'un coffre qui prend en charge l'approvisionnement dynamique, d'applications qui gèrent des identifiants à courte durée de vie, et de systèmes capables de créer des utilisateurs à la demande. Mais pour tout identifiant utilisé dans un pipeline automatisé ou un processus de courte durée, les secrets dynamiques font la différence entre une fuite qui compte et une fuite qui ne compte pas.