Construire une gestion des secrets évolutifs dans des environnements cloud hybrides: leçons de l’adoption d’entreprise

Je n’oublierai jamais la matinée il y a quelques années, lorsqu’un coéquipier a accidentellement poussé une clé AWS à un dépôt public Github. Il a fallu moins de 30 minutes avant que quelqu’un ne signale le problème, et bien que nous ayons tourné rapidement les informations d’identification, c’était notre réveil.

À l’époque, notre organisation s’étendait dans un environnement cloud hybride, avec des charges de travail fonctionnant sur AWS, Azure et l’infrastructure sur site. Les secrets ont été dispersés sur Jenkins, Kubernetes, les pipelines CI / CD et les ordinateurs portables de développement. Aucun outil ou politique unique n’a régné comment les secrets ont été stockés ou accessibles. L’étalement était réel et c’était risqué.

Cet incident nous a poussés à prendre au sérieux la gestion des secrets. Ce qui a suivi a été un voyage de 18 mois pour implémenter la gestion des secrets évolutifs et sécurisés au niveau de l’entreprise. C’est l’histoire de la façon dont nous l’avons fait, de ce que nous avons appris et de ce que je recommanderais à tous ceux qui empruntent un chemin similaire. Nous avons également réalisé que sans un système unifié de gestion des secrets, nous introduisions des lacunes d’audit qui pourraient échouer à la fois les contrôles internes et les revues de conformité réglementaire, ce que nous ne pouvions pas nous permettre dans une industrie fortement réglementée.

Pourquoi les nuages hybrides magnifient le problème des secrets

Dans le monde actuel du cloud-natif, les développeurs révèlent de nouvelles applications, des API et des services avec une vitesse à couper le souffle. Chacun nécessite l’accès à des informations sensibles, telles que les informations d’identification de base de données, les clés API et les jetons, et chaque fournisseur de cloud a sa méthode pour les gérer. AWS a un gestionnaire de secrets. Azure propose un coffre-fort clé. Kubernetes possède son propre mécanisme de «secrets» en grappe, qui est essentiellement des données de configuration codées en base64.

Ce modèle décentralisé a fonctionné jusqu’à ce qu’il ne soit pas le cas. Les secrets ont été dupliqués dans tous les environnements. Les clés ont été codées en dur en scripts. Les journaux d’accès manquaient. Il n’y avait pas de politique unifiée de rotation et aucun système d’alerte en place lorsque quelque chose a été mal utilisé. Pire encore, nous n’avions pas de véritable inventaire de l’endroit où vivaient les secrets ni à quelle fréquence ils ont été mis à jour, ce qui signifiait que la révocation d’un seul diplôme pourrait prendre des heures et impliquer plusieurs équipes.

Selon le rapport de l’étalement des secrets de Gitguardian en 2024, 23 millions de secrets ont été divulgués publiquement en 2023 seulement, et 70% d’entre eux étaient encore valables après avoir été exposés. Cette statistique m’a arrêté froid. Notre posture de sécurité a dû changer.

La première décision a été de consolider les secrets à travers les nuages et les environnements. Nous avions besoin d’un plan de contrôle unifié. Après avoir évalué les outils natifs du cloud, nous avons choisi Hashicorp Vault pour sa flexibilité multi-cloud, son support de moteur politique robuste et son entreprise. Nous avons également piloté Akeyless, une alternative basée sur le SaaS avec une architecture zéro-frust et une intégration plus facile. Les deux ont apporté de fortes capacités, mais nous nous sommes appuyés sur le coffre-fort pour des charges de travail critiques et étroitement réglementées.

Les leçons de l’intégration: identité, Kubernetes et CI / CD

Choisir un outil de gestion des secrets est la partie facile. L’intégrer dans une entreprise est l’endroit où le travail commence.

Nous avons commencé avec l’identité. L’approvisionnement manuel des utilisateurs n’était pas une option. Nous avons intégré un coffre-fort avec notre plate-forme SSO en utilisant les groupes OIDC et mappés pour les politiques de saut en fonction des moindres privilèges. Pour les machines, nous avons utilisé le cloud-natif IAM: AWS Rôles, Azure Managed Identities et Kubernetes Service Comptes. Ces identités sont devenues notre nouvelle couche de confiance.

Pour Kubernetes, nous avons déployé l’injecteur de l’agent de coffre-fort. Il a injecté des secrets dans des pods lors de l’exécution sans les stocker en texte clair ou les coder en dur dans des configurations. Les développeurs n’avaient plus besoin de gérer manuellement les secrets; La plate-forme les a gérées automatiquement.

CI / CD était un plus grand défi. Les secrets ont été intégrés dans les variables GitLab CI, les configurations Jenkins et les fichiers d’état Terraform. Nous avons créé des rôles de voûte pour chaque étape de nos pipelines, déterminés étroitement à l’environnement. Créer des travaux authentifiés pour faire du saut à l’aide d’Approle et de récupérer des secrets à la volée. Nous avons également créé des jetons liés au temps pour les pipelines sensibles, réduisant encore la fenêtre d’exposition. Ces mesures sont devenues essentielles pour se protéger contre les attaques de chaîne d’approvisionnement.

Le résultat? Nous avons éliminé plus de 90% des secrets statiques dans les pipelines. Plus important encore, nous avons établi la confiance dans le flux de travail; Les développeurs n’avaient pas besoin de enfreindre les règles pour expédier rapidement.

En prime, nous avons signé les journaux d’audit de Vault dans notre SIEM. Maintenant, chaque demande secrète est enregistrée, visible et corrélée avec l’identité de l’utilisateur et le comportement du système. Cette visibilité est devenue critique au cours d’un incident des mois plus tard, lorsqu’un compte de service compromis a été détecté pour accéder aux secrets qu’il ne devrait pas avoir.

Shift de culture: du manuel à l’automatisation, de réactif à résilient

La gestion des secrets n’est pas seulement une transformation technique; C’est culturel. Au début, les développeurs ont résisté. Ils ne voulaient pas apprendre de nouveaux outils ou attendre l’accès. Nous les avons donc rencontrés là où ils étaient:

• Intégration automatisée via Terraform
• Portails en libre-service pour les équipes pour gérer leurs espaces de noms
• Les secrets comme variables d’environnement injectées pendant les constructions

Nous avons également adopté la rotation par défaut. Vault nous a permis d’émettre des informations d’identification dynamiques de courte durée pour les bases de données et les fournisseurs de cloud. Certains secrets n’étaient valables que 24 heures. Cela signifiait même si une fuite se produisait, le rayon de souffle était petit.

Ce n’était pas seulement la sécurité; Il s’agissait de la vitesse du développeur. Si des secrets peuvent être créés, tournés et révoqués en quelques minutes sans approbation manuelle, les équipes se déplacent plus rapidement.

Une autre leçon: plan pour l’échec. Vault est un service critique. Si c’est en baisse, les pipelines échouent, les applications se bloquent et l’accès à l’infrastructure s’arrête. Nous l’avons déployé en mode HA, configuré automatiquement AWS KMS et effectué des tests de chargement. Après une trop de pannes causées par des charges de travail «voisines bruyantes», nous avons donné à Vault son cluster dédié. Problème résolu.

Nous avons également développé un livre de jeu de reprise après sinistre. Les sauvegardes ont été cryptées et testées tous les trimestres. Nous avons simulé des événements d’exfiltration secrètes et pratiqué des jetons de révocation en temps réel. Cette discipline a fait une différence lors d’un événement réel lorsqu’un système partenaire a été compromis – nos politiques de rotation et nos workflows de révocation ont déclenché en quelques minutes.

La gestion des secrets est un investissement

Dans un monde de nuage hybride, où les infrastructures s’étendent sur les centres de données et les nuages, les secrets sont omniprésents et les attaquants en sont conscients. Vous ne pouvez pas sécuriser ce que vous ne pouvez pas voir et vous ne pouvez pas évoluer ce que vous ne pouvez pas automatiser.

S’il y a un point à retenir de notre voyage, c’est celui-ci: Secrets Management n’est pas un projet de sécurité, c’est un investissement de plate-forme. Obtenez correctement l’intégration de l’identité. Prioriser l’automatisation. Appliquer le moins de privilèges. Et surtout, facilitez les développeurs de faire la bonne chose.

Nous n’y sommes pas arrivés pendant la nuit. Mais aujourd’hui, nos secrets sont tournés automatiquement, accessibles en toute sécurité, audités en continu et gérés de manière centralisée. Cette tranquillité d’esprit vaut toutes les heures que nous avons passées à y arriver. À mesure que la complexité des architectures natifs du cloud augmente, la gestion des secrets doit passer d’un service de side-car à un pilier fondamental de la sécurité des entreprises.

Cet article est publié dans le cadre du réseau de contributeurs d’experts Foundry.
Vous voulez rejoindre?