Gestion sécurisée des secrets et variables d’environnement

Les secrets codés en dur — clés API, mots de passe de bases de données, clés privées TLS et jetons OAuth intégrés directement au code source — comptent parmi les vulnérabilités de sécurité les plus courantes et les plus faciles à prévenir. Les secrets présents dans le code source sont exposés dans l’historique du contrôle de version (même après leur suppression), visibles par tous les développeurs disposant d’un accès au dépôt et fréquemment divulgués lorsque des dépôts sont rendus publics par accident. Des outils comme GitGuardian et truffleHog recherchent en continu les secrets divulgués sur des plateformes comme GitHub.

Les variables d’environnement retirent les secrets du code source en les injectant au moment de l’exécution par l’intermédiaire de l’OS hôte ou de l’orchestrateur de conteneurs. L’application lit os.environ['DB_PASSWORD'] au lieu d’utiliser une valeur codée en dur. Cette approche est préférable au codage en dur, mais les variables d’environnement présentent des faiblesses : elles apparaissent dans les listes de processus, sont héritées par les processus enfants, se retrouvent souvent dans les vidages mémoire après incident et les journaux de débogage, et nécessitent une rotation manuelle. Elles conviennent au développement, mais ne suffisent pas à elles seules pour gérer les secrets en production.

Les gestionnaires de secrets sont des systèmes conçus spécifiquement pour stocker, renouveler et auditer l’accès aux secrets. Parmi les principales solutions figurent HashiCorp Vault (open source et entreprise), AWS Secrets Manager, Azure Key Vault et Google Cloud Secret Manager. Les applications s’authentifient auprès du gestionnaire de secrets au moment de l’exécution, récupèrent le secret et l’utilisent : aucun secret n’est jamais stocké sur disque ou dans des variables d’environnement. Tous les accès sont consignés, ce qui permet de vérifier qui a accédé à quel secret et à quel moment.

Un avantage essentiel des gestionnaires de secrets par rapport aux variables d’environnement est la rotation automatique. AWS Secrets Manager peut renouveler automatiquement les mots de passe des bases de données RDS selon une planification (par exemple, tous les 30 jours), sans nécessiter de redéployer l’application. Le gestionnaire de secrets met à jour le mot de passe dans la base de données et le secret stocké simultanément. Les applications qui récupèrent les secrets à chaque connexion reçoivent automatiquement le nouvel identifiant. Cela élimine la pratique courante consistant à utiliser des mots de passe de comptes de service « permanents » qui ne sont jamais renouvelés.

La première ligne de défense contre les Secrets validés dans le dépôt est un fichier .gitignore correctement tenu à jour, qui exclut tous les fichiers susceptibles de contenir des Secrets. Toutefois, .gitignore empêche uniquement les validations futures : les Secrets déjà validés restent présents dans l’historique git. Si des Secrets sont validés par erreur, ils doivent être considérés comme compromis immédiatement : faites tourner le Secret, puis, si nécessaire, utilisez des outils comme git filter-repo pour réécrire l’historique (ce qui est requis pour la conformité, mais insuffisant à lui seul, car le Secret a peut-être déjà été extrait).

Les fichiers d’infrastructure en tant que code (IaC) (Terraform, CloudFormation, manifestes Kubernetes) contiennent fréquemment des Secrets : chaînes de connexion aux bases de données, clés d’API dans les déclarations de variables d’environnement et certificats TLS. Ces fichiers sont souvent validés dans le contrôle de version, ce qui crée un risque d’exposition des Secrets. Les solutions comprennent les Secrets dynamiques de Vault (Vault génère un identifiant à courte durée de vie spécifiquement pour chaque exécution de Terraform), les Secrets Kubernetes (stockés dans etcd, ils doivent être chiffrés au repos) et external-secrets-operator, qui synchronise les Secrets depuis un gestionnaire de Secrets vers Kubernetes au moment de l’exécution.

Chaque Application ou service ne doit accéder qu’aux Secrets dont il a spécifiquement besoin : c’est le principe du moindre privilège appliqué aux Secrets. Une Application web a besoin du password de la base de données, mais pas de la clé privée CA. Une tâche de génération de rapports a besoin d’identifiants de base de données en lecture seule, et non d’un accès en écriture. Les gestionnaires de Secrets appliquent ce principe au moyen de politiques d’accès qui précisent quelles identités (rôles IAM, comptes de service, AppRoles) peuvent lire quels Secrets, tous les accès étant enregistrés à des fins d’audit.

Les Secrets dynamiques sont générés à la demande pour un demandeur précis et expirent automatiquement. Vault peut générer un identifiant temporaire de base de données valide pendant 1 heure et associé au service précis qui l’a demandé. Après son expiration, l’identifiant est automatiquement révoqué par la base de données. Cette approche signifie qu’il n’existe aucun identifiant statique à longue durée de vie susceptible d’être volé : même si un Attacker capture un identifiant dynamique, celui-ci expire rapidement et est associé à l’identité demandeuse dans les journaux d’audit.

Les pipelines CI/CD nécessitent fréquemment des Secrets : identifiants de fournisseurs Cloud pour le déploiement, jetons de registre Docker et clés de signature. Never stockez jamais les Secrets dans les scripts de pipeline ou les fichiers de configuration. Utilisez plutôt le magasin de Secrets intégré à la plate-forme de pipeline (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials Store) ou récupérez les Secrets depuis un coffre central au moment de l’exécution à l’aide d’une identité machine. Marquez les variables de Secret comme masquées dans les journaux afin d’éviter toute exposition accidentelle dans la sortie de Build.

Les gestionnaires de Secrets fournissent des journaux d’audit complets de chaque événement d’accès à un Secret : quelle identité a accédé à quel Secret, depuis quelle IP, à quel moment et si l’accès a réussi ou a été refusé. Ces journaux sont essentiels pour la conformité (SOC 2, PCI-DSS) et la réponse aux incidents. Lorsqu’un identifiant est soupçonné d’être compromis, les journaux d’audit révèlent quels systèmes y ont accédé et quand, ce qui permet d’identifier rapidement les systèmes potentiellement affectés et de prendre des décisions de confinement.

Les hooks de pré-validation sont des scripts qui s’exécutent automatiquement avant la finalisation de chaque validation git, permettant de détecter les Secrets avant leur entrée dans l’historique du contrôle de version. Des outils comme detect-secrets (Yelp), GitLeaks et git-secrets (AWS) s’intègrent comme hooks de pré-validation et analysent les fichiers préparés à la validation à la recherche de motifs correspondant à des clés d’API, des chaînes de connexion, des clés privées et des jetons JWT. Si un Secret est détecté, la validation est refusée et le développeur est invité à supprimer l’identifiant. Le cadre pre-commit facilite l’ajout et le partage de configurations de hooks entre les équipes.

Testez votre compréhension des concepts CompTIA Security+ (SY0-701) présentés dans cette leçon.

Dans cette leçon, vous avez appris que les Secrets codés en dur dans le code source doivent être éliminés et remplacés par des gestionnaires de Secrets comme Vault ou AWS Secrets Manager, que la rotation automatique supprime les identifiants à longue durée de vie dont les Attackers pourraient abuser même après une compromission initiale, et que les Secrets dynamiques et les politiques d’accès fondées sur le moindre privilège limitent la valeur de tout Secret exposé. Nous allons maintenant étudier la sécurité des dependencies et l’analyse de la composition logicielle.