Sécuriser la prochaine vague d’identités de charge de travail dans le cloud

Ce fut un moment de réalisation pour notre équipe de droit de taille moyenne. Alors que nous construisions un nouveau pipeline d’analyse du cloud-natif qui a duré notre centre de données privé et nos nuages ​​publics, nous nous sommes retrouvés à distribuer des clés API et des rôles d’identité et d’accès à l’accès (IAM) avec Abandon. Initialement, cela semblait être une approche rapide et efficace – nous faisions rapidement des progrès. Nous ne savions pas que cette approche entraînerait des problèmes de sécurité imprévus.

Cependant, il est rapidement devenu un problème urgent. Chaque nouveau microservice ou fonction a sa propre identité. Nous leur avons nommé des choses comme «SVC-Backend-prod» ou «travailleur de données», avec des différences mineures pour le développement ou le test. Nous avions des scripts qui tournaient nos secrets de base chaque semaine, mais rien pour ces nouveaux comptes. Un jour, notre surveillance a éclairé un avertissement: un ancien jeton de compte de service a été utilisé dans deux nuages ​​différents. Mon cœur coulait. Il s’est avéré qu’un développeur avait copié une clé expirée depuis longtemps dans un script oublié.

Nous nous sommes précipités pour inventaire toutes les identités de la machine que nous avions. Cela ressemblait à des dizaines de comptes d’ombre se cachant dans chaque nuage et cluster. Pas étonnant que les erreurs de configuration et les privilèges excessifs s’étaient glissés. Notre processus de développement agile avait préparé par inadvertance la voie à une violation.

Selon un rapport, de nombreuses entreprises ignorent le nombre d’identifices machine qu’ils possèdent – l’étude a révélé «45 fois plus d’identités de la machine que celles humaines», dont la plupart sont non tracés, comme indiqué dans une analyse VentureBeat. Dans notre cas, j’estime que nous avions des centaines de ces identités, bien plus que nous ne l’avons réalisé.

Étalement de l’identité des nuages ​​dans l’ère multi-cloud

Ceci est le nouveau champ de bataille dans la sécurité du cloud. Bien que nous entendions souvent des menaces comme le phishing ou le ransomware, un risque plus insidieux est en augmentation – les identités de la machine. Dans un environnement multi-cloud, le nombre d’identification pour chaque microservice, machine virtuelle (VM) ou fonction sans serveur peut rapidement devenir incontrôlable. Nous nous sommes retrouvés à gérer une demi-douzaine de systèmes IAM sans une vision unifiée d’eux. Des rôles comme «ETL-Service» dans un nuage remplissaient la même fonction que «ETL-travailleur» dans un autre, et nous avons du mal à garder une trace des doublons.

C’était facile de faire des erreurs. Dans notre précipitation à livrer, nous avons donné à de nombreux comptes de services de larges droits administratifs, prévoyant de les affiner plus tard. Les statistiques sont claires: dans son rapport de menaces supérieures en 2024, la Cloud Security Alliance a classé IAM comme la préoccupation numéro un. Cela inclut les comptes humains et machines. Dans la pratique, une identité de machine volée ou mal utilisée permet à un attaquant de se déplacer latéralement – après tout, les charges de travail sont censées se faire confiance.

Notre quasi-Miss a prouvé le danger. Dans un incident, un travail de données de fond a utilisé accidentellement une clé administrative pour accéder aux bases de données de production. Nous ne l’avons attrapé que parce que notre journalisation centrale l’a signalé. Imaginez un attaquant découvrir la même clé dans un référentiel public ou l’intercepter sur le réseau. Les dégâts auraient pu être bien pires.

La cause profonde était apparente: les modèles de sécurité traditionnels se décomposaient. La Cloud Security Alliance note que les fonctions sans serveur, les conteneurs éphémères et les microservices rendent les politiques statiques inefficaces. Nous avons vu cela de première main. Un conteneur peut commencer par un jeton et être parti une heure plus tard, ne laissant presque aucune empreinte à moins que vous n’auditez en permanence. Nous savions que nous devions traiter chaque charge de travail comme non fiable et la vérifier constamment.

Cela signifiait étendre zéro confiance à chaque machine. Nous avons passé à des TL mutuels et à des jetons de courte durée pour les appels de service à service. Par exemple, nos conteneurs dans Kubernetes utilisent désormais des jetons OIDC de notre fournisseur d’identité au lieu de clés intégrées. Ces jetons expirent après quelques minutes. Cette approche s’aligne sur des cadres modernes comme Spiffe, qui met l’accent sur les identités de courte durée pour réduire la probabilité de violation par un compromis sur les informations d’identification, comme recommandé par le cadre Spiffe.

En bref, il n’y a plus de clés perpétuelles assises dans des cas. Nous avons également appliqué rigoureusement le moins de privilèges. Un audit d’autorisations a révélé que de nombreux rôles avaient trop d’autorité. Nous avons supprimé des droits qui n’étaient pas strictement nécessaires. Si un chargeur de données n’avait besoin que d’un accès en lecture, c’est tout ce qu’il conserve. Nous avons automatisé cela via la stratégie en tant que code: toute nouvelle identité de service est créée avec un minimum de portée par défaut. Au fil du temps, nous avons vu des plaintes concernant la chute de l’accès croisé de cloud. Lorsque des privilèges plus élevés étaient nécessaires, le service devait les demander au moment de l’exécution (accès juste à temps) plutôt que de les tenir en permanence.

Pour la visibilité, nous avons centralisé les événements d’identité à travers les nuages ​​dans notre SIEM. Nous alerter maintenant des anomalies telles qu’un conteneur dans un environnement de développement accédant soudainement à une API critique. L’analytique axée sur l’IA aide à faire en sorte que les menaces réelles parmi tous les bruit. Les tendances de l’industrie reflètent ceci: les solutions Cloud XDR évoluent pour donner une visibilité unifiée sur les charges de travail multi-cloud.

Étendre zéro confiance aux charges de travail

Appliquer une confiance zéro au-delà des mots de passe est crucial. Du côté humain, le MFA et l’accès conditionnel sont standard. Pour les charges de travail, nous avons implémenté une approche similaire en utilisant des jetons, des certificats et des contrôles continus. Lorsqu’un service en appelle un autre, il présente un jeton ou un certificat cryptographique, et le service cible le vérifie à chaque fois qu’il est appelé. En effet, chaque microservice a besoin d’un «coup de badge» actuel pour accéder aux ressources.

Une réussite était notre cluster de traitement par lots. Il s’appuyait auparavant sur un compte de service avec une clé API statique. Nous l’avons retravaillé afin que chaque nœud commence par un certificat client de courte durée délivré par notre infrastructure de clé publique interne (PKI). Les serveurs n’acceptent que ces certificats de courte durée. Étant donné que les certificats sont renouvelés quotidiennement, tout certificat volé devient rapidement inutile. De plus, nous enregistrons toutes les demandes et approbations de certificat via notre pipeline sécurisé, nous savons donc toujours quelles identités sont actives.

Nous avons également adopté les privilèges «juste à temps». Les scripts de maintenance et les travaux d’administration demandent désormais des rôles élevés via notre flux de travail basé sur CIEM au lieu d’exécuter avec défaut avec défaut avec défaut. Une identité obtient un jeton limité dans le temps en cas de besoin. Une fois le poste terminé, nous révoquons les droits élevés. Ce changement a considérablement réduit la fenêtre de risque pour nos comptes les plus critiques.

Le gain a été intense. Nous sommes passés de la lutte contre les incendies frénétiques au contrôle proactif. Les développeurs considèrent désormais s’ils ont besoin d’une nouvelle identité – parfois, un seul compte bien adapté sert plusieurs services. Et nous dormons mieux en sachant que même si un jeton est divulgué, il n’est pas valable pendant un court laps de temps.

Une feuille de route pour sécuriser les identités de charge de travail

Sur la base de notre voyage, voici les étapes pratiques que nous avons prises:

• Prenez l’inventaire et classez. Découvrez chaque identité non humaine. Nous avons écrit des scripts pour extraire des listes de tous les comptes de services, clés, certificats et rôles de chaque cloud et cluster. Ensuite, nous les avons tagués par équipe et but. Vous ne pouvez pas sécuriser ce que vous ne pouvez pas voir.
• Appliquer le principe du moindre privilège. Audit les autorisations de chaque identité et supprimez tout excès de autorisation. Nous avons utilisé des outils automatisés pour comparer les privilèges aux besoins. Toute divergence déclenche une alerte. Cela garantit qu’aucune charge de travail n’a plus de droits que nécessaire.
• Utilisez des jetons de courte durée. Remplacez les secrets statiques par des informations d’identification éphémères. Par exemple, les pods de Kubernetes s’authentifient désormais aux services cloud à l’aide de jetons OIDC / JWT de courte durée ou de certificats X.509 plutôt que de clés à longue durée de vie, comme recommandé par le cadre Spiffe. Cela signifie que les informations d’identification expirent automatiquement. Nous avons également automatisé la rotation régulière de tous les secrets restants.
• Accès juste à temps. Intégrez un CIEM ou un coffre-fort pour l’élévation du privilège limité dans le temps. Les ingénieurs demandent les droits nécessaires par le biais d’un flux d’approbation et un jeton éphémère est émis. Cela réduit le nombre de jetons privilégiés debout à travers les nuages.
• Surveillance continue. Activité d’identité de la machine à alimenter dans un XDR / SIEM conscient du cloud. Nous surveillons des anomalies, telles que des charges de travail inconnues qui sont appelées API sensibles. En utilisant l’IA / ML pour hiérarchiser les alertes, nous pouvons rapidement identifier et aborder toute utilisation abusive des identités.
• Gouvernance axée sur les politiques. Codifier les politiques d’identité dans le code. Chaque fois qu’une charge de travail est retirée, son identité est automatiquement révoquée. Nous exigeons que toutes les identités aient un propriétaire et une date d’expiration. De nouvelles identités sont créées par le biais de demandes de traction, qui subissent l’examen et l’approbation des pairs.

La mise en œuvre de ces efforts, mais elle a construit une résilience durable. Nous avons passé des correctifs réactifs à une posture robuste. Les équipes de développement innovent toujours rapidement mais dans les garde-corps. La sécurisation des identités de la machine est désormais aussi intégrée que la sécurisation des utilisateurs humains.

La sécurisation de la prochaine vague d’identités cloud est une tâche continue. À mesure que nous nous étendons à davantage de fournisseurs de cloud et d’appareils Edge, nos politiques doivent s’adapter. Nous avons commencé à explorer des preuves d’identité décentralisées (comme les DID) pour les appareils IoT et l’informatique confidentielle pour les charges de travail sensibles. Cependant, le principe central reste: vérifier chaque identité et minimiser son rayon de souffle.

Aujourd’hui, je suis confiant dans notre prochaine vague de déploiements cloud. En traitant des charges de travail avec la même rigueur zéro-frust, la première rigueur que nous appliquons à nos utilisateurs, nous avons construit une base pour une croissance sécurisée. En fin de compte, une machine sans identité validée n’est qu’un point d’entrée vulnérable; Cependant, celui avec les contrôles appropriés devient une partie de confiance du système – exactement comme il devrait être dans un nuage moderne.

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