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.
Un inventaire honnête en trouve dans au moins six endroits :
Ce dernier point est souvent le plus fourni, et le moins traité.
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.
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 :
Inverser les étapes 2 et 3 garantit une interruption de service et l’arrêt définitif du chantier.
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 :
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.
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.
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.
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.
Sur un existant chargé, l’ordre qui donne le plus de résultat :
Vouloir tout migrer d’un coup est le meilleur moyen de ne rien faire pendant deux ans.
La recherche de secrets exposés fait partie de nos tests d’intrusion et de l’audit 360.
La virtualisation a simplifié la sauvegarde au point de créer une illusion de sécurité. Prendre une image complète d’une machine en quelques minutes donne le sentiment d’être couvert. Trois caractéristiques ...
1-3 Rue d’Enghien
75010, Paris
France
Recevez les actualités du site Cyberdian.
