Secrets dynamiques et attribution temporaire

Un secret statique est créé une fois puis réutilisé indéfiniment : par exemple, le même mot de passe de base de données que dix services partagent pendant des années. Les secrets statiques sont la norme par défaut et constituent le problème : ils ont une longue durée de vie, sont largement partagés et sont difficiles à renouveler.

Un secret dynamique est généré à la demande, unique pour un seul consommateur et expire automatiquement. Au lieu de stocker un mot de passe, le coffre crée des informations d’identification entièrement nouvelles chaque fois qu’elles sont demandées.

Ce simple changement résout les aspects les plus difficiles de la gestion des secrets : le renouvellement devient automatique et le rayon d’impact d’une fuite est réduit à presque rien.

Les secrets dynamiques exigent que le coffre dispose d’un accès privilégié au système dorsal. Pour une base de données, le déroulement est le suivant :

• Un administrateur configure le coffre avec un identifiant racine de base de données et un modèle de création.
• Une application s’authentifie et demande des informations d’identification.
• Le coffre exécute CREATE USER sur la base de données et renvoie un nom d’utilisateur et un mot de passe nouveaux.
• Lorsque le bail expire, le coffre exécute automatiquement DROP USER.

L’application ne voit jamais de mot de passe à longue durée de vie : elle reçoit un identifiant temporaire lié à son identité et à son bail.

Lorsqu’une application a besoin d’accéder à une base de données, elle demande un identifiant au coffre. La réponse contient un nom d’utilisateur et un mot de passe uniques, fraîchement créés, ainsi qu’un bail indiquant leur durée de validité.

Chaque consommateur reçoit son propre identifiant. Si deux instances du même service démarrent, elles reçoivent deux noms d’utilisateur différents, ce qui permet un audit par consommateur au niveau de la base de données.

Un bail est un contrat qui indique pendant combien de temps ce secret est valide. Chaque secret dynamique possède un TTL (durée de vie) et éventuellement un TTL maximal.

• default_ttl : durée de vie de l’identifiant avant son expiration.
• max_ttl : limite absolue, même en cas de renouvellements.

Lorsque le bail expire, le coffre révoque l’identifiant : il supprime activement l’utilisateur de la base de données. L’expiration n’est pas un simple indicateur : elle déclenche un véritable nettoyage. C’est ce qui rend les secrets dynamiques capables de se réparer seuls après une fuite : un identifiant volé devient inutilisable dans la fenêtre définie par le TTL.

Les applications de longue durée qui survivent à un bail doivent le renouveler avant son expiration. Le renouvellement prolonge le TTL jusqu’au TTL maximal, après quoi l’application doit demander un nouvel identifiant.

Les opérateurs peuvent également révoquer immédiatement un bail : c’est l’interrupteur d’arrêt en cas d’incident. La révocation d’un bail supprime immédiatement l’identifiant sous-jacent, quelle que soit la durée de TTL restante.

Vous pouvez même révoquer tous les baux associés à un préfixe afin de couper instantanément l’accès de tout un service ou environnement.

Les secrets dynamiques ne se limitent pas aux bases de données. Le coffre et les outils similaires génèrent des identifiants à courte durée de vie pour de nombreux systèmes :

• IAM infonuagique : clés d’accès AWS/GCP/Azure temporaires au moyen d’une prise de rôle de type STS.
• SSH : certificats SSH signés et à courte durée de vie au lieu de clés statiques.
• PKI/TLS : certificats délivrés à la demande et dotés d’une courte période de validité.
• RabbitMQ, MongoDB, Consul : identifiants de service éphémères.

Le modèle est partout le même : demander, utiliser brièvement, expirer automatiquement. Les clés infonuagiques statiques à longue durée de vie sont une source fréquente de compromissions : les identifiants IAM dynamiques les éliminent.

Examinons un identifiant compromis dans chacun des modèles :

• Statique : le mot de passe reste valide jusqu’à ce qu’une personne le remarque, le renouvelle et mette à jour chaque consommateur. La fenêtre d’exposition dure plusieurs jours ou plusieurs mois.
• Dynamique : l’identifiant expire dans le délai de son TTL, souvent en quelques minutes ou en une heure, et était limité à un seul consommateur avec des droits minimaux. La fenêtre d’exposition est très courte et les dommages sont circonscrits.

Les secrets dynamiques transforment le renouvellement, auparavant un projet manuel pénible, en une propriété automatique et continue du système.

Les secrets dynamiques sont puissants, mais ils exigent que le coffre détienne un identifiant racine hautement privilégié pour chaque système dorsal dans lequel il peut créer les utilisateurs correspondant aux identifiants qu’il délivre. Le risque se trouve ainsi concentré dans le coffre.

Mesures d’atténuation :

• Renouvelez l’identifiant racine lui-même afin que même le coffre ne conserve pas le mot de passe administrateur d’origine.
• Limitez le compte racine exactement aux droits nécessaires pour créer et supprimer des utilisateurs, sans rien de plus.
• Isoler et surveillez rigoureusement l’hôte du coffre, puisqu’il constitue désormais une cible de grande valeur.

Le coffre peut renouveler son propre identifiant racine afin qu’après la configuration, aucun humain ne le connaisse.

Les applications doivent être écrites de manière à s’attendre à ce que les identifiants changent. Avec les secrets statiques, le code lit un mot de passe une fois au démarrage. Avec les secrets dynamiques, le code doit :

• Récupérer un identifiant et noter le TTL de son bail.
• Renouveler le bail ou récupérer un nouvel identifiant avant l’expiration.
• Rétablir proprement la connexion lorsqu’un ancien identifiant est révoqué.

Un modèle courant consiste à utiliser un agent compagnon qui gère le cycle de vie du bail et réécrit un fichier local de secret, afin que l’application se contente de recharger sa configuration. Les réservoirs de connexions doivent également être actualisés pour ne pas rester attachés à un identifiant expiré.

Tous les secrets ne peuvent pas être dynamiques. Certaines interfaces de programmation tierces fournissent une seule clé à longue durée de vie qui ne peut pas être générée à la demande. Pour ces secrets statiques, appliquez des mesures compensatoires :

• Stockez-les dans le coffre, jamais dans le code.
• Limitez-les au moindre privilège.
• Renouvelez-les selon un calendrier (voir la prochaine leçon).
• Surveillez leur utilisation pour détecter les anomalies.

La règle générale : préférez le dynamique ; lorsque le statique est imposé, renouvelez-le et auditez-le sans relâche.

Les pipelines d’intégration et de déploiement continus (CI/CD) constituent un cas d’utilisation idéal. Traditionnellement, un pipeline conserve des clés de déploiement à longue durée de vie, ce qui en fait une cible très intéressante. Avec les secrets dynamiques, le pipeline :

• S’authentifie auprès du coffre au moyen de son identité OIDC (par exemple, le jeton OIDC de GitHub Actions).
• Demande des identifiants infonuagiques à courte durée de vie, valides uniquement pendant l’exécution de la tâche.
• Les laisse expirer automatiquement lorsque la tâche se termine.

Aucune clé de déploiement à longue durée de vie n’existe jamais. Un journal de pipeline compromis divulgue un identifiant déjà inutilisable au moment où quelqu’un le lit.

Testez votre compréhension des baux et des secrets dynamiques.

Vous avez appris comment les identifiants à courte durée de vie et à expiration automatique transforment la gestion des secrets.

• Les secrets dynamiques sont générés à la demande, uniques pour chaque consommateur et expirent automatiquement, contrairement aux secrets statiques réutilisés.
• Un bail définit un TTL et un TTL maximal ; à l’expiration, le coffre révoque l’identifiant et effectue un véritable nettoyage.
• Les baux peuvent être renouvelés par les applications de longue durée ou révoqués instantanément comme interrupteur d’arrêt en cas d’incident.
• Les secrets dynamiques fonctionnent pour les bases de données, l’IAM infonuagique, SSH, PKI et bien d’autres systèmes, réduisant le rayon d’impact et automatisant le renouvellement.
• Le compromis consiste à conserver un identifiant racine privilégié dans le coffre : renouvelez-le et limitez strictement ses droits.
• Les applications et les pipelines CI/CD doivent être conçus pour gérer l’expiration ; préférez les secrets dynamiques et renouvelez les secrets statiques lorsqu’ils sont inévitables.

Ensuite, nous verrons comment renouveler les clés et détecter les fuites lorsqu’elles surviennent.