Votre équipe stocke les mots de passe de base de données en variables d'environnement en clair dans une config de déploiement versionnée dans le dépôt. Meilleure approche ?
Réponse courte
Les secrets doivent vivre dans un magasin géré avec contrôle d'accès, audit et rotation, injectés au runtime — jamais versionnés. Utilisez un gestionnaire de secrets (AWS Secrets Manager, HashiCorp Vault) et retirez les valeurs versionnées de l'historique, puis faites-les tourner car elles doivent être considérées comme compromises. Le base64 est de l'encodage, pas une protection — n'importe qui peut le décoder. Un dépôt privé répand quand même le secret à tous ceux qui ont l'accès en clone, plus les systèmes CI et les forks. Le compiler dans le binaire ne fait que cacher un secret toujours trivial à extraire.
Un secret versionné est l'un des incidents les plus courants du monde réel, et cette question vérifie si vous connaissez la différence entre cacher un secret et le protéger. La seule bonne réponse retire entièrement le secret du contrôle de version et le gère correctement.
Pourquoi un gestionnaire de secrets est la réponse
Un gestionnaire de secrets (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) vous offre les trois choses que le contrôle de version ne peut pas : le contrôle d'accès (seul le rôle de la charge de travail peut lire le secret), l'audit (chaque récupération est journalisée) et la rotation (le mot de passe peut être changé automatiquement et à la demande). L'application récupère le secret au runtime — via son rôle IAM ou un sidecar — de sorte que rien de sensible n'est jamais versionné. Crucial : comme le mot de passe était déjà dans le dépôt, vous devez le considérer comme compromis : retirez-le de l'historique et faites-le tourner.
Pourquoi les distracteurs échouent
- L'encoder en base64. Le base64 est de l'encodage, pas du chiffrement. Il est réversible par n'importe qui en une commande. Le secret est tout aussi exposé, désormais avec un faux sentiment de sécurité.
- Le déplacer dans un dépôt privé. Un dépôt privé livre quand même le secret à chaque développeur ayant l'accès en clone, à chaque runner CI/CD, à chaque fork et clone local, et à quiconque obtient plus tard l'accès en lecture. « Privé » n'est pas « secret », et l'identifiant reste à jamais dans l'historique git.
- Le coder en dur dans le binaire. Les chaînes d'un binaire compilé s'extraient trivialement avec
stringsou un désassembleur. Vous avez ajouté de la friction de build sans ajouter de protection, et vous ne pouvez toujours pas le faire tourner sans redéploiement.
Le problème de l'historique
Supprimer le fichier de HEAD ne suffit pas : le secret reste dans l'historique git et dans chaque clone. C'est exactement pourquoi la rotation est obligatoire — supposez qu'il a fuité et invalidez-le.
Ce que recherchent les examinateurs
Nommer un magasin de secrets géré avec injection au runtime, insister sur la rotation parce que le secret est déjà compromis, et souligner que base64 et dépôts privés ne sont pas une protection. Les bons candidats ajoutent un garde-fou de pré-commit / scan de secrets pour que cela ne se reproduise pas.
Questions de suivi probables
- Le secret était dans l'historique git — pourquoi supprimer le fichier de HEAD ne suffit-il pas ?
- Comment l'injection au runtime depuis un gestionnaire de secrets atteint-elle concrètement l'application sans secret versionné ?
- Pourquoi devez-vous faire tourner le mot de passe même après l'avoir retiré du dépôt ?