Comment gérez-vous les secrets de manière sécurisée dans le cloud ?
Réponse courte
Stockez les secrets dans un service géré dédié (Secrets Manager, Parameter Store, Vault), chiffrés avec une clé KMS, et accordez l'accès via des rôles IAM pour que les charges de travail les récupèrent à l'exécution avec des identifiants à courte durée de vie. N'intégrez jamais de secrets dans le code, les images de conteneurs ou des fichiers .env versionnés. Ajoutez une rotation automatique, des politiques de clé restreintes et une journalisation d'audit pour que chaque récupération soit traçable.
La gestion des secrets est l'endroit où les bonnes intentions rencontrent la réalité : les développeurs veulent que l'application « ait simplement » le mot de passe de la base de données, et les chemins faciles — un .env dans le dépôt, une constante dans le code, une variable d'environnement intégrée dans une image — fuient tous. L'entretien attend le modèle sécurisé et le raisonnement.
Le bon modèle
- Un coffre de secrets dédié. Utilisez Secrets Manager, SSM Parameter Store (SecureString) ou HashiCorp Vault. Ils gardent les secrets hors du contrôle de version et vous donnent versionnement, rotation et journaux d'accès.
- Chiffrement via KMS. Le coffre chiffre les secrets avec une clé KMS en utilisant le chiffrement par enveloppe — KMS détient la clé maître et ne l'expose jamais ; une clé de données par secret effectue le gros du chiffrement. Les politiques de clé contrôlent qui peut même déchiffrer.
- Accès via des rôles IAM, pas des clés statiques. La charge de travail assume un rôle et récupère le secret à l'exécution. Combiné à des identifiants de rôle à courte durée de vie, il n'y a aucun secret à longue durée de vie à voler au repos dans l'application.
- Rotation et audit. Activez la rotation automatique pour qu'un identifiant fuité ait une durée de vie utile courte, et journalisez chaque appel
GetSecretValuepour que les récupérations soient attribuables.
Pourquoi les chemins faciles échouent
Un .env versionné vit pour toujours dans l'historique git. Un secret intégré dans une couche d'image Docker reste dans cette couche même si un RUN rm ultérieur supprime le fichier — quiconque récupère l'image peut l'extraire. Les simples variables d'environnement apparaissent dans les vidages mémoire (crash dumps), les processus enfants et la journalisation.
Ce que recherchent les recruteurs
Citer un coffre géré, expliquer le chiffrement par enveloppe KMS et les politiques de clé, insister sur l'accès par rôle IAM plus la rotation, et savoir pourquoi les couches d'image et l'historique git rendent « le supprimer plus tard » inutile.
Questions de suivi probables
- Qu'est-ce que le chiffrement par enveloppe et comment KMS utilise-t-il une clé de données ?
- Comment faites-vous tourner un identifiant de base de données sans interruption de service ?
- Pourquoi un secret dans une couche d'image Docker reste-t-il exposé même après l'avoir supprimé dans une couche ultérieure ?