Les identités non humaines sont devenues la plus grande surface d'attaque non gérée de la sécurité cloud

Dans un environnement cloud d'entreprise typique aujourd'hui, les identités machine — comptes de service, clés API, jetons OAuth, identifiants CI/CD et identités de workload — dépassent les comptes utilisateurs humains dans des proportions couramment citées entre 45:1 et 90:1. Les équipes sécurité ont passé deux décennies à construire la gestion des identités et des accès autour des personnes : intégration, départ, authentification multi-facteurs, revue périodique des accès. Presque aucune de cette infrastructure n'a été conçue pour les machines, et cela se voit. Les identités non humaines (NHI) sont discrètement devenues la plus grande surface d'attaque non gérée de la sécurité cloud, et la plupart des organisations ne peuvent pas répondre à une question basique : combien d'identifiants machine existent dans leur environnement, qui ou quoi en est propriétaire, et quand ont-ils été utilisés pour la dernière fois.

Pourquoi l'IAM traditionnel ne couvre pas les machines

La gouvernance des identités humaines repose sur des hypothèses qui ne tiennent pas pour les machines. Une personne a un manager qui peut attester du besoin continu. Une personne passe un entretien de départ et une checklist d'intégration quand elle quitte l'entreprise. La demande d'accès d'une personne passe par un cycle de revue. Les comptes de service, en revanche, sont fréquemment créés ad hoc par un développeur qui provisionne un nouveau microservice, se voient accorder des permissions larges pour éviter de déboguer des erreurs de permission plus tard, puis ne sont plus jamais revus. L'identifiant survit au projet, au développeur qui l'a créé, et souvent à la raison même de son existence. Multipliez ce schéma sur chaque pipeline CI/CD, chaque intégration SaaS tierce, chaque service interne qui appelle un autre service interne, et le problème d'inventaire devient énorme.

Comment les identifiants machine sont réellement compromis

Les schémas de violation sont remarquablement cohérents dans les rapports d'incidents. Des clés API à longue durée de vie sont commitées dans des dépôts GitHub publics par des développeurs qui oublient de les ajouter à un fichier .gitignore — les scanners automatisés les trouvent et les exploitent en quelques minutes après l'exposition. Des comptes de service sur-privilégiés, dotés d'un accès niveau admin parce que c'était plus rapide que de définir correctement les permissions, transforment un seul identifiant compromis en accès complet à l'environnement. Des jetons OAuth obsolètes d'une intégration SaaS décommissionnée il y a dix-huit mois restent valides parce que personne ne les a révoqués. Et dans les environnements cloud-natifs, les identités de workload qui devraient être éphémères et limitées à un seul pod ou une seule fonction sont au contraire intégrées dans les images de conteneurs comme des secrets statiques à longue durée de vie.

Aucune de ces techniques n'est exotique. Ce sont des échecs d'hygiène de base à grande échelle, et les attaquants le savent. Les attaques basées sur les identifiants ciblant les identités machine sont devenues l'un des vecteurs d'accès initial les plus fiables, précisément parce que les outils défensifs qui détecteraient une connexion humaine suspecte — géographie anormale, heure d'accès inhabituelle, empreinte d'appareil — ne s'appliquent souvent pas proprement à un script qui appelle une API depuis un centre de données à 3 heures du matin, ce qui est un comportement machine parfaitement normal.

Ce qui change réellement

Une nouvelle catégorie d'outils de sécurité a émergé spécifiquement pour combler cette lacune, avec des fournisseurs comme Astrix Security, Entro, Oasis Security et Token Security qui construisent des produits capables de découvrir, inventorier et surveiller les NHI dans les environnements cloud et SaaS d'une manière que les outils IAM généralistes n'ont jamais été conçus pour faire. Ces plateformes commencent généralement par construire un inventaire complet — ce que la plupart des organisations n'ont jamais eu — puis ajoutent une notation de risque basée sur le niveau de privilège, l'âge de l'identifiant et les schémas d'utilisation, et enfin automatisent la remédiation comme la rotation des identifiants ou le cadrage des accès.

Les fournisseurs cloud ont également bougé sur ce sujet. AWS, Google Cloud et Azure proposent désormais tous la fédération d'identités de workload, qui permet à un service de s'authentifier en utilisant des jetons éphémères, automatiquement rotatés et liés à son identité d'exécution réelle plutôt qu'à une clé statique à longue durée de vie. Cela élimine toute une catégorie de risque — l'identifiant statique divulgué — par conception, mais l'adoption nécessite de ré-architecturer les intégrations existantes, ce qui explique pourquoi la migration est lente malgré des outils disponibles depuis plusieurs années.

Ce que les équipes sécurité devraient réellement faire

Commencez par la découverte, pas la remédiation. Vous ne pouvez pas sécuriser ce que vous ne voyez pas, et la plupart des organisations sous-estiment leur nombre de NHI d'un ordre de grandeur jusqu'à ce qu'elles lancent un scan approprié sur les comptes cloud, les consoles d'administration SaaS, les systèmes CI/CD et les dépôts de code source. Une fois l'inventaire établi, priorisez par rayon d'explosion : un identifiant avec un accès cloud niveau admin importe plus qu'une clé API en lecture seule pour un outil interne à faible sensibilité, quel que soit celui qui est plus ancien ou plus visible.

Passez à des identifiants éphémères partout où la plateforme le supporte — fédération d'identités de workload pour l'authentification cloud-à-cloud, jetons OIDC pour les pipelines CI/CD au lieu de secrets statiques stockés dans la configuration du pipeline. Pour les identifiants qui doivent rester à longue durée de vie, imposez une rotation selon un calendrier fixe plutôt que de compter sur quelqu'un qui s'en souvienne manuellement, et définissez des dates d'expiration par défaut plutôt que par exception. Enfin, assignez une propriété. Chaque identifiant machine doit être rattaché à un humain ou une équipe responsable, de la même manière que chaque compte humain est rattaché à un employé. Un identifiant sans propriétaire est un identifiant que personne ne remarquera devenir obsolète, qui ne sera pas signalé pour usage suspect, et que personne ne pensera à révoquer quand le système qu'il sert sera décommissionné — c'est exactement la lacune que les attaquants exploitent actuellement à grande échelle.