Comment les secrets comme les clés d'API et les mots de passe de base de données doivent-ils être gérés dans une application ?

Les secrets — clés d'API, mots de passe de bases de données, clés de signature, jetons — sont des cibles de grande valeur, car un seul secret divulgué peut déverrouiller des systèmes entiers. Bien les gérer consiste surtout à les garder hors des endroits où ils ont tendance à fuiter et à limiter les dégâts si l'un d'eux fuite.

La règle cardinale : pas dans le code

Les secrets ne doivent jamais résider dans le code source, les fichiers de configuration committés dans le contrôle de version, les images de conteneurs ou les bundles côté client. L'historique git est éternel : un secret committé une fois est compromis même après suppression, il doit donc être renouvelé, pas seulement retiré. Intégrer des secrets dans un binaire compilé n'aide pas non plus ; ils sont trivialement extractibles.

Centraliser et injecter

Stockez les secrets dans un gestionnaire de secrets ou un coffre-fort spécialisé (HashiCorp Vault, AWS Secrets Manager, magasins adossés à un KMS cloud). L'application les récupère à l'exécution via une identité authentifiée, ou ils sont injectés sous forme de variables d'environnement/fichiers montés par la plateforme. Cela centralise le contrôle, le chiffrement et l'audit.

Limiter le rayon d'impact

• Moindre privilège : chaque service ne peut lire que les secrets spécifiques dont il a besoin.
• Rotation : faites tourner les secrets selon un calendrier et immédiatement en cas de suspicion d'exposition.
• Identifiants dynamiques à courte durée de vie : le meilleur modèle — le coffre-fort génère à la demande un identifiant qui expire en quelques minutes, de sorte qu'un secret divulgué est presque immédiatement inutile et qu'il n'y a rien de persistant à voler.
• Journalisation d'audit : enregistrez chaque accès aux secrets pour détecter les abus.

Le problème d'amorçage

Il y a toujours un « secret zéro » — l'identifiant initial qu'une application utilise pour s'authentifier auprès du coffre-fort. Résolvez-le avec une identité de charge de travail fournie par la plateforme (rôles d'instance, fédération OIDC, mTLS) plutôt qu'avec encore un autre secret statique.

Ce que les recruteurs recherchent

La base est « ne jamais coder en dur, utiliser un coffre-fort ». Le signal de niveau intermédiaire est la rotation, la limitation au moindre privilège, et surtout la préférence pour des identifiants dynamiques à courte durée de vie, plus la conscience du défi d'amorçage du secret zéro.