Gestion des secrets applicatifs distribués avec rotation

Un secret applicatif n’est pas une variable de configuration un peu plus honteuse que les autres. Dans une architecture distribuée, il faut gérer son émission, son usage, son renouvellement, sa révocation et sa traçabilité, sans transformer chaque rotation en exercice collectif de redéploiement.

→ Lire l’explication complète de la marmotte

Identité de service et coffre-fort de secrets

Le patron à retenir est strict : chaque service porte une identité propre, s’authentifie auprès d’un coffre-fort centralisé, puis obtient uniquement les secrets autorisés par une politique déclarative. Une identité partagée entre plusieurs services interdit de distinguer l’appel légitime du composant compromis. Elle transforme aussi une révocation ciblée en interruption générale. Le gain apparent de « simplification » dure exactement jusqu’au premier incident.

L’identité doit être liée à un mécanisme vérifiable par la plateforme : compte de service d’orchestrateur, certificat TLS (Transport Layer Security) mutuel, identité de charge de travail issue d’un fournisseur d’identité, ou attestation matérielle lorsque le niveau de menace le justifie. Un jeton statique livré avec l’image conteneur ne constitue pas une identité de charge de travail. C’est un secret de démarrage déguisé, donc le problème emballé dans un autre problème.

Le coffre-fort centralisé conserve les valeurs sensibles, applique les politiques et journalise les accès. Il ne doit pas devenir le chemin de données applicatif : l’application lit un secret, l’utilise localement et ne repasse pas par le coffre-fort pour chaque requête métier. Une dépendance synchrone par transaction crée un point de rupture inutile et donne au réseau le rôle principal dans l’authentification. Très moderne sur une slide, beaucoup moins pendant une dégradation DNS.

Les politiques doivent exprimer au minimum l’identité appelante, le chemin du secret, les opérations admises et les contraintes temporelles. Autoriser read sur production/* à une famille de services revient à faire de l’arborescence un périmètre de sécurité. Or une arborescence est d’abord un classement. La politique doit viser des noms précis ou des préfixes dédiés à un domaine applicatif, avec séparation entre lecture, écriture, émission et révocation.

Une clé de base de données, un mot de passe de compte technique, une clé privée de signature et un jeton d’API (Application Programming Interface) tierce n’ont pas le même cycle de vie. Les stocker dans le même objet de secret force une rotation au rythme du plus fragile et élargit la fuite au plus sensible. Un secret doit correspondre à une capacité cohérente, pas à un fichier .env reconstitué parce que le format existait déjà.

Les fondations d’identité et de confiance doivent être traitées avant le coffre-fort. La gestion des certificats et des ancres de confiance est décrite dans la section PKI et TLS. La séparation entre secret applicatif et clé cryptographique maître relève, elle, de la cryptographie appliquée.

Injection dynamique et rafraîchissement contrôlé

L’injection au démarrage est préférable au stockage statique dans le dépôt, l’image, la configuration d’orchestrateur ou la variable d’environnement fournie par la chaîne de déploiement. Le secret ne doit ni apparaître dans un manifeste versionné, ni traverser une console d’administration, ni survivre dans une archive de pipeline. Le dépôt Git (Gestionnaire de versions distribué) est un excellent historique. C’est précisément pourquoi il ne doit pas devenir un cimetière de mots de passe.

Mais injecter au démarrage ne suffit pas. Le piège le plus fréquent consiste à écrire le secret dans un fichier temporaire, le lire une fois, puis le garder en mémoire jusqu’à l’arrêt du processus. La rotation côté coffre-fort réussit alors techniquement, tandis que l’application continue d’utiliser l’ancienne valeur. La sécurité obtient un joli événement d’audit ; l’attaquant conserve parfois une fenêtre d’usage indéfinie. Voilà une rotation décorative.

Le processus applicatif doit relire le secret à intervalle régulier ou recevoir une notification de changement, puis remplacer sa ressource cliente sans interruption. Pour un mot de passe de base de données, cela implique de créer de nouvelles connexions avec la nouvelle valeur, de drainer les anciennes et de borner leur durée de vie. Pour une clé de signature, cela impose de charger la nouvelle version avant d’émettre de nouveaux jetons, tout en conservant temporairement la capacité de vérifier les objets signés avec l’ancienne clé si le protocole l’exige.

Le compromis central est là : des secrets courts, renouvelés et rafraîchis réduisent la durée d’exploitation après fuite, mais augmentent les dépendances de disponibilité, les appels au coffre-fort et la complexité applicative. Il faut trancher : pour les identifiants de service, les mots de passe de bases de données et les jetons externes, ce coût est justifié. Une valeur statique ne reste acceptable que pour un secret impossible à faire tourner automatiquement, documenté comme dette et compensé par une rotation planifiée. Pas par optimisme, cette ressource non renouvelable qui alimente tant de comités.

Le délai de rafraîchissement doit être inférieur à la durée de validité, avec marge pour les pannes et la propagation. Un jeton valable quinze minutes peut être relu toutes les cinq minutes avec gigue aléatoire, afin d’éviter que toutes les instances interrogent le coffre-fort au même instant. Le cache local doit avoir une durée maximale explicite. En cas d’indisponibilité du coffre-fort, l’application peut continuer avec la dernière valeur connue seulement jusqu’à cette limite, si le risque métier l’autorise. Au-delà, elle doit échouer fermement ou se mettre en mode dégradé sans opérations sensibles.

Politique déclarative et isolement des accès

Une politique déclarative relie une identité à des droits évaluables : lire secret/data/paiement/api-acquereur, renouveler son propre jeton d’authentification, mais ni lister les chemins voisins ni créer de nouvelles valeurs. Le droit de liste révèle souvent les noms de partenaires, de systèmes internes et de comptes techniques. Les métadonnées ont l’élégance discrète des plans de bâtiment oubliés à l’accueil.

Les secrets dynamiques sont à privilégier quand le système cible permet de créer un identifiant à durée limitée : compte de base de données, certificat client, identifiant cloud ou jeton d’accès. Le coffre-fort émet alors une valeur associée à un bail, puis la révoque à expiration. Les secrets statiques restent nécessaires pour certains services tiers ou équipements anciens, mais ils doivent être versionnés et remplacés selon une procédure atomique : publier la nouvelle valeur, laisser une période de recouvrement, faire adopter la nouvelle version, retirer l’ancienne.

La révocation immédiate n’a de sens que si trois conditions existent. D’abord, le système cible doit refuser l’ancienne valeur. Ensuite, les sessions et connexions ouvertes doivent expirer ou être invalidées. Enfin, l’application doit redemander son secret dans un délai borné. Révoquer un mot de passe ne ferme pas une connexion déjà authentifiée ; révoquer un certificat ne détruit pas une session déjà établie. La révocation n’est pas une gomme magique, même si les démonstrations commerciales lui prêtent parfois des pouvoirs de mammifère mythologique.

Les droits d’administration du coffre-fort doivent être séparés : gestion des politiques, émission des secrets, exploitation des moteurs d’authentification et lecture d’audit ne relèvent pas du même rôle. Une identité capable de modifier sa propre politique peut s’accorder les droits de lecture les plus étendus. Le contrôle d’accès devient alors un formulaire auto-signé, ce qui est rarement la définition recherchée d’une barrière.

Exemple de service avec jeton court et relecture

L’exemple suivant utilise un agent local chargé d’authentifier le service et d’écrire un secret dans un fichier dont le contenu est renouvelé. L’application ne lit pas une variable d’environnement figée : elle recharge le fichier à intervalle borné et reconstruit son pool de connexions lorsque la version change.

# config applicative : aucune valeur secrète dans ce fichier versionné.
secrets:
  database_password_file: /run/secrets/app-db-password
  refresh_interval_seconds: 300 # inférieur au bail de 15 minutes
  max_stale_seconds: 900        # arrêt des écritures après ce délai sans renouvellement

database:
  host: postgres.internal
  username: svc_facturation
  # Le code lit le fichier à chaque cycle de rafraîchissement.
  # Si son empreinte change, il ouvre un nouveau pool, draine l'ancien,
  # puis refuse les nouvelles écritures après max_stale_seconds sans mise à jour.

Le répertoire /run/secrets doit être monté en mémoire, lisible uniquement par l’utilisateur du processus, avec création atomique du fichier par renommage. Écrire directement dans le fichier lu expose une lecture partielle. Sur Linux, l’agent et l’application doivent avoir des comptes distincts si l’agent possède des capacités d’administration supplémentaires. Les mécanismes de service sont détaillés dans systemd et l’isolation des processus.

L’application doit exposer trois signaux : âge de la dernière valeur reçue, succès ou échec du dernier rafraîchissement, et version non sensible actuellement utilisée. Ne jamais placer le secret, son encodage ou son empreinte complète dans les journaux. Les traces et métriques doivent corréler l’identité du service, le chemin logique et le résultat d’accès, sans reproduire la donnée protégée. Les conventions de corrélation relèvent de l’observabilité en architecture cyber.

Exploitation, sauvegarde et reprise du coffre-fort

Le coffre-fort concentre les secrets, donc aussi la pression opérationnelle. Sa haute disponibilité doit couvrir le stockage, le consensus éventuel, les mécanismes d’authentification et les autorités de certification. Répliquer uniquement les données sans répliquer la capacité à déverrouiller le coffre-fort crée une disponibilité théorique, catégorie voisine du parachute dessiné au feutre.

Les clés de chiffrement du coffre-fort doivent être séparées des données chiffrées. Un HSM (Hardware Security Module) ou un service de gestion de clés peut protéger la clé racine, à condition que les procédures de récupération n’exigent pas le même système indisponible. Les fragments de déverrouillage, comptes de secours et clés de récupération doivent être détenus selon une séparation de responsabilités, testés périodiquement et protégés hors du plan d’administration quotidien.

Les sauvegardes doivent inclure les données chiffrées, les politiques, les configurations des moteurs d’authentification, les autorités de confiance et les métadonnées de version. Restaurer seulement les valeurs sans les politiques peut rétablir des secrets accessibles à la mauvaise identité. Restaurer les politiques sans les clés de chiffrement rend les données inutilisables. Une sauvegarde non restaurée est une croyance, pas un contrôle.

La supervision doit alerter sur les échecs d’authentification, l’augmentation des refus de politique, les baux proches d’expiration, les lectures anormales, les changements de politique et l’âge des secrets consommés. L’alerte sur une lecture massive doit être corrélée à l’identité et au périmètre attendu : une rotation légitime peut lire beaucoup, une identité de service qui explore les espaces voisins mérite moins de poésie.

🐝 Ce qui arrive si on s’en passe

Sans coffre-fort ni rotation, un secret divulgué reste valide jusqu’à ce qu’un humain le change à la main, et ce changement exige de redéployer simultanément tous ses consommateurs : la rotation est alors repoussée, y compris après le départ d’une personne qui connaissait la valeur. Un secret intégré à une image survit dans chaque version conservée par le registre et dans chaque clone du dépôt, même après réécriture de l’historique ; un retour arrière vers une ancienne image échoue ou réintroduit la valeur supposée retirée. En l’absence de journal d’accès par identité, aucun élément ne permet d’établir quels composants ont lu la valeur compromise ni depuis quand : le périmètre d’un incident ne peut pas être borné, et la seule remédiation sûre devient le remplacement de tous les secrets voisins.

🦫 Explication de la marmotte 🍫

Une application a parfois besoin d’un mot de passe, d’une clé ou d’un code d’accès pour joindre une base de données ou un service externe. Au lieu d’enregistrer cette valeur dans son code ou dans un fichier distribué avec elle, l’application prouve d’abord son identité à un service central chargé de garder les secrets. Chaque application possède sa propre identité. Ainsi, si une application est compromise, ses droits ne donnent pas accès aux secrets des autres.

Le service central vérifie cette identité et remet seulement la valeur autorisée, pour une durée limitée. L’application la conserve localement pour fonctionner, puis demande régulièrement une version récente. Si la valeur change, elle ouvre de nouvelles connexions avec la nouvelle valeur et ferme progressivement les anciennes. Si le service central retire un accès, la valeur ancienne finit par être refusée par le système concerné.

Le point critique est le renouvellement dans l’application elle-même. Changer une valeur dans le service central ne protège rien si l’application garde l’ancienne en mémoire pendant des jours. Il faut donc fixer une durée maximale d’utilisation et surveiller l’âge de la dernière valeur reçue.

Si le service central devient indisponible, l’application peut fonctionner brièvement avec sa dernière valeur connue, selon le risque accepté. Après cette limite, les opérations sensibles doivent s’arrêter. Les sauvegardes doivent restaurer à la fois les secrets, les règles d’accès et les clés qui permettent de les lire.

Pages voisines

La citent

Gestion des secrets applicatifs distribués avec rotation

Elle cite

Gestion des secrets applicatifs distribués avec rotation

Gestion des secrets applicatifs distribués avec rotation

Identité de service et coffre-fort de secrets

Injection dynamique et rafraîchissement contrôlé

Politique déclarative et isolement des accès

Exemple de service avec jeton court et relecture

Exploitation, sauvegarde et reprise du coffre-fort

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines