Aller au contenu principal

Les secrets et les identités

Résumé : les secrets — clés d'API, mots de passe de bases de données, jetons, certificats — sont la cible la plus rentable pour un attaquant, et la source d'incidents la plus banale. Cette leçon explique pourquoi un secret dans Git est compromis définitivement, comment fonctionne un coffre-fort de secrets, et pourquoi l'approche la plus moderne consiste à supprimer purement et simplement les secrets de longue durée.

1. Le problème du secret dans le dépôt​

Le point à retenir absolument : un secret qui est passé par Git est compromis définitivement, même si vous l'avez retiré, même si le dépôt est privé, même si vous avez réécrit l'historique. Les clones locaux, les caches de plateformes et les sauvegardes peuvent en conserver une copie.

La seule réponse valable est la révocation. Générez une nouvelle clé, révoquez l'ancienne, et considérez l'ancienne comme publique.

Précision sur les dépôts privés : ils réduisent le risque mais ne l'éliminent pas. Un dépôt privé peut devenir public par erreur, un compte avec accès peut être compromis, et un ancien collaborateur conserve son clone local.

2. Où NE PAS mettre ses secrets​

Le cas 3 surprend souvent et mérite une explication. Une image de conteneur est constituée de couches empilées. Si une instruction copie un secret et qu'une instruction suivante le supprime, la couche intermédiaire contient toujours le secret. Il suffit d'inspecter l'historique de l'image pour le récupérer.

Le cas 5 est particulièrement insidieux parce qu'il est involontaire. Une instruction de journalisation qui affiche un objet de requête complet peut inscrire des jetons d'authentification dans des logs conservés plusieurs semaines et consultables par toute l'équipe. Configurez systématiquement une liste de champs à masquer dans votre bibliothèque de journalisation.

3. Le coffre-fort de secrets​

La fonction 5 est la plus élégante conceptuellement. Au lieu de partager un mot de passe de base de données permanent entre dix services, le coffre en génère un à la demande, valable une heure, propre à ce service et à cette session. Un secret volé devient inutilisable presque immédiatement, et le journal permet de savoir exactement quel service a fait quoi.

Pour démarrer sans complexité : les secrets chiffrés de votre outil de CI (secrets GitHub Actions, variables protégées GitLab) constituent déjà une amélioration considérable par rapport à un fichier versionné. N'attendez pas de pouvoir déployer Vault.

4. La révolution des identités éphémères​

C'est l'évolution la plus importante des dernières années sur ce sujet.

La formule qui résume l'idée : « le meilleur secret est celui qui n'existe pas ». Un secret que vous n'avez pas ne peut pas fuiter, ne demande aucune rotation, et ne traînera pas dans un ancien fichier de configuration oublié.

Recommandation concrète en 2026 : si vous configurez aujourd'hui un déploiement depuis GitHub Actions ou GitLab CI vers AWS, Azure ou Google Cloud, utilisez OIDC plutôt que des clés d'accès permanentes. La configuration prend une heure de plus la première fois, et supprime une catégorie entière de risques.

5. Le moindre privilège appliqué​

La méthode qui fonctionne réellement : commencez avec zéro permission, lancez votre application, regardez ce qui échoue, ajoutez exactement la permission manquante, recommencez. C'est fastidieux la première fois, mais c'est la seule approche qui produit un ensemble de droits juste — et elle documente au passage ce que votre application fait vraiment.

6. Le cas particulier des mots de passe utilisateurs​

La règle pratique la plus importante ici : n'implémentez jamais vous-même la gestion des mots de passe. Utilisez le module d'authentification de votre cadriciel, qui applique déjà bcrypt ou Argon2 avec un sel correct. Chaque implémentation maison de hachage de mot de passe est une occasion d'erreur, et l'erreur ne se voit pas avant la fuite.

7. La détection de secrets dans le code​

Le niveau 1 est de très loin le plus efficace, parce qu'il empêche le problème au lieu de le signaler. Une fois le secret dans l'historique, quelle que soit la rapidité de détection, la révocation devient obligatoire. Un crochet local évite entièrement cette situation.

Le niveau 4 est à faire au moins une fois. Analysez l'historique complet de vos dépôts existants — la plupart des équipes qui le font pour la première fois découvrent d'anciens secrets oubliés, encore valides.

Retenir en 30 secondes​

  • Un secret passé par Git est compromis définitivement. La seule réponse correcte est la révocation, pas le nettoyage.
  • Sur un dépôt public, le délai entre publication et exploitation d'une clé se compte souvent en minutes.
  • Jamais de secret dans le code, un fichier versionné, une image de conteneur, le code frontal, les journaux ou la messagerie.
  • Une image de conteneur conserve les secrets dans ses couches, même si une instruction ultérieure les supprime.
  • Un coffre-fort de secrets apporte : chiffrement, accès fin, journal d'audit, rotation, et secrets dynamiques à durée de vie courte.
  • Pour démarrer : les secrets chiffrés de votre outil de CI suffisent. N'attendez pas de déployer Vault.
  • L'approche moderne : supprimer les secrets durables au profit d'identités éphémères via OIDC. « Le meilleur secret est celui qui n'existe pas. »
  • Moindre privilège : partez de zéro droit et ajoutez ce qui manque. Cela ne prévient pas la compromission, cela limite son impact.
  • Mots de passe utilisateurs : bcrypt, scrypt ou Argon2, avec un sel unique. La lenteur est une fonctionnalité.
  • N'implémentez jamais vous-même le hachage de mots de passe — utilisez votre cadriciel.
  • Un crochet local avant validation est la protection la plus efficace contre la fuite de secrets.

Suivant : Conteneurs, cloud et outillage : SAST, DAST, SCA →