Le problème de la prolifération des secrets

La prolifération des secrets est la dispersion incontrôlée d’informations d’accès sensibles au sein d’une organisation. Un secret est tout élément qui permet d’accéder à un système : clés d’API, mots de passe de bases de données, jetons OAuth, clés privées TLS, clés SSH et clés de chiffrement.

La prolifération se produit lorsque ces secrets se retrouvent dispersés dans des endroits où ils ne devraient jamais se trouver :

• Code source et fichiers de configuration
• Chaînes d’intégration et de déploiement continus et variables d’environnement
• Images de conteneurs et infrastructure sous forme de code
• Messages de discussion, wikis et systèmes de gestion des demandes

Dès qu’un secret existe à de nombreux endroits, vous perdez la capacité de le suivre, de le renouveler ou de le révoquer de manière fiable.

La cause fondamentale la plus courante est le secret codé en dur, un identifiant écrit directement dans le code source. Cela semble pratique pendant le développement, mais devient une vulnérabilité permanente.

Voici à quoi ressemble un mot de passe de base de données codé en dur dans le code de l’application :

Toute personne disposant d’un accès en lecture à ce fichier possède désormais le mot de passe de production. Cela inclut chaque développeur, chaque exécuteur d’intégration continue et toute personne qui clone ensuite le dépôt.

Un danger critique des secrets codés en dur est l’historique du contrôle de version. Même si vous supprimez un secret dans une validation ultérieure, il reste définitivement dans l’historique Git de chaque clone.

Vous pouvez récupérer un secret divulgué dans l’historique à tout moment :

C’est pourquoi supprimer un secret de la dernière validation ne remédie pas à la fuite. Le secret doit être considéré comme compromis et renouvelé immédiatement.

Lorsqu’un dépôt contenant des secrets codés en dur est envoyé vers un hébergeur public comme GitHub, des robots automatisés l’aspirent en quelques secondes à quelques minutes.

Les conséquences concrètes comprennent :

• Explosions de factures de services en nuage des clés AWS divulguées utilisées pour lancer des flottes de minage de cryptomonnaies, générant des dizaines de milliers de dollars de frais en une nuit.
• Fuites de données des identifiants de base de données exposés entraînant l’exfiltration complète des données.
• Déplacement latéral un jeton divulgué utilisé pour pénétrer plus profondément dans l’infrastructure.

Les fournisseurs de services en nuage et GitHub utilisent désormais l’analyse des secrets, qui détecte automatiquement et parfois révoque automatiquement les clés divulguées, mais vous ne pouvez pas compter sur cette protection.

Les conteneurs introduisent un vecteur de prolifération insidieux. Les secrets intégrés à une image lors de sa construction sont stockés dans les couches de l’image et envoyés à chaque registre et hôte qui récupère l’image.

Une erreur courante consiste à copier un fichier de secret, puis à le supprimer dans une couche ultérieure : le secret existe toujours dans la couche précédente :

Toute personne qui récupère l’image peut extraire cette couche et lire la clé. Utilisez des secrets de construction ou une injection à l’exécution.

Sortir les secrets du code pour les placer dans des variables d’environnement constitue une amélioration, mais ce n’est pas une solution complète. Les variables d’environnement résolvent le problème du codage en dur, mais introduisent de nouvelles voies d’exposition :

• Divulgués dans les vidages sur incident et les traces de pile d’erreurs
• Visibles par d’autres processus via /proc/<pid>/environ sous Linux
• Consignés par des outils de débogage qui affichent l’environnement complet
• Stockés en texte brut dans des fichiers .env validés par accident

Les variables d’environnement conviennent à une configuration peu sensible, mais les secrets de grande valeur doivent être placés dans un gestionnaire de secrets dédié, avec contrôle des accès et audit.

La prolifération rend la réponse aux incidents presque impossible. Lorsqu’un secret se trouve partout, deux questions deviennent impossibles à résoudre :

• Où se trouve-t-il ? Vous ne pouvez pas renouveler ce que vous ne pouvez pas trouver.
• Qui l’a utilisé ? Sans journaux d’accès centralisés, vous ne pouvez pas délimiter l’étendue d’une compromission.

Le rayon d’impact d’un seul identifiant divulgué augmente avec la prolifération. Un mot de passe partagé et réutilisé dans dix services signifie qu’une seule fuite les compromet tous. La centralisation et les secrets uniques à courte durée de vie réduisent considérablement ce rayon.

Le moyen le moins coûteux d’empêcher une fuite est de l’arrêter avant qu’elle n’entre dans le contrôle de version. Les analyseurs de secrets de prévalidation inspectent les modifications indexées et bloquent les validations contenant des motifs d’identifiants.

Parmi les outils libres à code source ouvert populaires figurent gitleaks, trufflehog et detect-secrets. Un crochet de prévalidation typique s’exécute localement :

Associez cette vérification à une analyse côté serveur dans l’intégration continue afin qu’un développeur qui contourne le crochet local soit tout de même détecté.

Si un secret arrive à un endroit où il ne devrait pas se trouver, suivez cet ordre. Le renouvellement passe en premier ; le nettoyage de l’historique est secondaire, car des copies peuvent déjà exister.

• 1. Renouvelez révoquez le secret divulgué et émettez-en immédiatement un nouveau.
• 2. Auditez examinez les journaux d’accès pour détecter toute utilisation non autorisée pendant la période d’exposition.
• 3. Purgez supprimez le secret de l’historique, par exemple avec git filter-repo, puis effectuez un envoi forcé.
• 4. Prévenez ajoutez une analyse et déplacez le secret dans un gestionnaire afin d’éviter que cela ne se reproduise.

Ne sautez jamais l’étape 1. Un secret qui a été exposé publiquement est compromis, sans exception.

La prolifération est aggravée lorsque les secrets disposent de privilèges excessifs et sont partagés excessivement. Appliquer le principe du moindre privilège limite les dégâts lorsqu’une fuite se produit :

• Donnez à chaque service son propre identifiant, jamais un identifiant partagé.
• Limitez chaque secret à la portée minimale nécessaire, par exemple lecture seule ou administration.
• Privilégiez les identifiants à courte durée de vie qui expirent automatiquement.
• Séparez les secrets par environnement : les clés de développement ne doivent jamais accorder l’accès à la production.

Ces habitudes transforment une compromission catastrophique en incident circonscrit et récupérable.

Les outils seuls ne résolvent pas la prolifération ; c’est la culture qui s’en charge. Une organisation mature considère la gestion des secrets comme une discipline continue :

• Position par défaut : aucun secret dans le code source, jamais.
• Centralisez le stockage dans un coffre-fort géré, avec contrôle des accès et journaux d’audit.
• Automatisez l’analyse à chaque étape : avant la validation, dans l’intégration continue et dans le registre.
• Faites du renouvellement une routine, et non une mesure réservée aux urgences.
• Formez chaque ingénieur à reconnaître et à signaler les expositions sans chercher de coupable.

Le but est de mettre en place un système où il est difficile de divulguer un secret et facile de se remettre d’une fuite.

Vérifiez votre compréhension des raisons pour lesquelles supprimer un secret divulgué ne suffit pas.

Vous avez appris pourquoi les secrets dispersés et codés en dur constituent l’une des faiblesses de sécurité les plus courantes et les plus dommageables.

• La prolifération des secrets est leur propagation incontrôlée dans le code, les chaînes de traitement, les images et les conversations.
• Les secrets codés en dur persistent à jamais dans l’historique Git ; les supprimer ne remédie pas à une fuite.
• Les dépôts publics sont aspirés en quelques minutes, ce qui entraîne des explosions de factures de services en nuage et des fuites de données.
• Les variables d’environnement et les couches d’image laissent fuir les secrets ; ce ne sont pas des espaces de stockage sûrs.
• La prolifération augmente le rayon d’impact et rend le renouvellement ainsi que la réponse aux incidents impossibles.
• La solution : analyser avant la validation, renouveler d’abord en cas de fuite, centraliser dans un coffre-fort et appliquer le principe du moindre privilège.

Ensuite, nous centralisons correctement les secrets à l’aide de coffres-forts et de gestionnaires de secrets.