Gestion des secrets : arrêter les mots de passe en clair dans les configurations

Les secrets — mots de passe de service, clés d’interface, chaînes de connexion, certificats — sont le point où la théorie et la pratique divergent le plus. Tout le monde sait qu’ils ne doivent pas être en clair. Ils le sont presque partout.

Où ils se trouvent réellement

Un inventaire honnête en trouve dans au moins six endroits :

• Les fichiers de configuration des applications, sur les serveurs.
• Les dépôts de code, y compris dans l’historique — un secret retiré reste dans les versions antérieures.
• Les scripts d’exploitation et les tâches planifiées.
• Les outils de déploiement et les chaînes d’intégration.
• La documentation interne et les fichiers partagés d’équipe.
• Les messageries, où un mot de passe transmis « pour dépanner » reste indéfiniment.

Ce dernier point est souvent le plus fourni, et le moins traité.

Pourquoi c’est plus grave qu’il n’y paraît

Un secret en clair transforme une compromission limitée en compromission étendue. Un attaquant qui obtient un accès en lecture sur un serveur applicatif récupère les identifiants de la base — sans avoir besoin d’élever ses privilèges.

C’est un raccourci classique dans la phase d’élévation, et il annule l’essentiel du bénéfice du cloisonnement : peu importe la segmentation si les clés du niveau supérieur traînent au niveau inférieur.

Le cas des comptes de service

C’est le plus difficile, et celui qu’on repousse. Un compte de service typique cumule tous les défauts : droits larges accordés « pour que ça marche », secret inchangé depuis des années, connu de plusieurs prestataires, présent dans plusieurs configurations.

Personne n’ose y toucher parce que personne ne sait exactement ce qui l’utilise.

La démarche qui fonctionne, dans cet ordre strict :

1. Inventorier les comptes de service et leurs droits.
2. Observer ce qui les utilise réellement, en journalisant les authentifications pendant plusieurs semaines. C’est l’étape qu’on saute et qui provoque l’incident.
3. Réduire les droits au strict nécessaire, un compte à la fois.
4. Mettre en place la rotation, une fois qu’on sait qui consomme quoi.

Inverser les étapes 2 et 3 garantit une interruption de service et l’arrêt définitif du chantier.

Le coffre-fort de secrets

Le principe : les secrets ne sont plus stockés dans les configurations mais récupérés à l’exécution, par une identité authentifiée, avec traçabilité.

Ce que cela apporte :

• La rotation devient possible sans modifier chaque configuration.
• L’emprunt est tracé : qui a demandé quel secret, quand, pour combien de temps. C’est précisément ce que demande la journalisation des accès à privilèges.
• La révocation est immédiate en cas de départ ou de compromission.

Point de vigilance : le coffre-fort devient un actif critique. Sa compromission donne accès à tout. Il doit être administré depuis un niveau distinct, avec authentification renforcée sans exception, et sa propre stratégie de reprise — voir ce qu’il faut sauvegarder au-delà des machines.

Autre point : le problème de l’amorçage. L’application doit s’authentifier auprès du coffre pour obtenir ses secrets, ce qui suppose un secret initial. Les mécanismes d’identité de plateforme ou de certificats permettent de le résoudre, mais la question doit être traitée explicitement — sinon on a simplement déplacé le mot de passe en clair.

Traiter l’historique des dépôts

Un secret retiré d’un fichier reste accessible dans l’historique des versions. Retirer la ligne ne suffit pas.

La seule réponse fiable est de considérer le secret comme compromis et de le renouveler. La réécriture d’historique est possible mais lourde, et ne garantit pas que personne n’a cloné le dépôt entre-temps.

La prévention est plus efficace que le nettoyage : une détection automatique de secrets à chaque soumission de code, qui refuse la publication. C’est l’une des rares mesures où l’automatisation règle réellement le problème à la source.

Les certificats

Souvent oubliés dans les démarches de gestion des secrets, alors qu’ils posent les mêmes questions : où sont les clés privées, qui y a accès, comment sont-elles renouvelées.

Le risque principal n’est d’ailleurs pas la compromission mais l’expiration, qui produit une indisponibilité totale et immédiate. Un inventaire avec dates et alertes anticipées est le minimum — voir la gestion des certificats en façade.

Ce que demandent les référentiels

ISO/IEC 27002:2022 traite le sujet par les mesures 5.17 (informations d’authentification), 8.24 (utilisation de la cryptographie) et 8.9 (gestion de la configuration).

La mesure 8.9 est l’une des nouveautés de la révision 2022, et elle est régulièrement prise en défaut : une configuration contenant des secrets en clair n’est pas une configuration maîtrisée.

Par où commencer

Sur un existant chargé, l’ordre qui donne le plus de résultat :

1. Détection automatique des secrets dans les dépôts, en bloquant les nouveaux. Cela arrête l’hémorragie avant de traiter le stock.
2. Renouvellement des secrets présents dans les historiques, en priorisant ceux qui donnent accès à des données.
3. Inventaire des comptes de service et de leurs droits.
4. Coffre-fort pour les nouveaux usages, sans chercher à migrer l’existant immédiatement.
5. Migration progressive, application par application, à l’occasion des évolutions.

Vouloir tout migrer d’un coup est le meilleur moyen de ne rien faire pendant deux ans.

Les cinq questions

1. Combien de secrets figurent en clair dans vos dépôts de code, historique compris ?
2. Quand le mot de passe de votre principal compte de service a-t-il changé pour la dernière fois ?
3. Combien de personnes, internes et externes, le connaissent ?
4. Un secret transmis par messagerie il y a deux ans est-il encore valide ?
5. Que se passe-t-il si votre coffre-fort de secrets est indisponible ?

Sources

• ISO/IEC 27002:2022, mesures 5.17, 8.9 et 8.24
• OWASP Top 10 — défaillances cryptographiques et de configuration
• ANSSI — recommandations relatives à l’authentification et à la cryptographie

Aller plus loin

La recherche de secrets exposés fait partie de nos tests d’intrusion et de l’audit 360.