Quand les machines héritent d'autorisations dangereuses
Il est 3 heures du matin et un agent d'IA négocie entre votre instance Salesforce, votre infrastructure AWS et vos flux de travail ServiceNow. L'agent fonctionne sans relâche, prenant des milliers de décisions par minute.
Mais voici ce qui devrait vous terrifier : cet agent d'IA n'utilise pas ses propres identifiants. Il emprunte l'identité d'une application, et cette identité pourrait avoir des autorisations susceptibles de compromettre l'ensemble de votre organisation.
Bienvenue dans le monde des identités d'applications de charge de travail, où la promesse d'opérations commerciales autonomes se heurte à une réalité de sécurité à laquelle la plupart des organisations ne sont pas préparées.
Le nouveau paysage de l'identité
Comme nous l'avons exploré dans notre récent blog sur la convergence des identités humaines et non humaines (NHI), les organisations ont commencé à s'attaquer aux comptes de service et aux clés d'API traditionnels. Les identités de charge de travail représentent la prochaine évolution de ce défi.
Contrairement aux comptes de service traditionnels qui reposent sur des utilisateurs humains avec des mots de passe statiques, les identités d'applications de charge de travail utilisent une authentification moderne basée sur des jetons (généralement OAuth ou des certificats) avec des autorisations affinées qui ne sont pas liées au cycle de vie d'un utilisateur humain et sont spécialement conçues pour l'automatisation. En théorie, cela les rend parfaites pour notre avenir alimenté par l'IA. En pratique ? Elles sont devenues la surface d'attaque la plus négligée de votre environnement.
Les entreprises modernes fonctionnent avec des identités de charge de travail, ces mécanismes d'authentification essentiels qui permettent aux applications de se connecter en toute sécurité. Les exemples incluent :
- Entra ID service principals et applications enregistrées
- Applications Salesforce connectées et externes
- Applications personnalisées Google et comptes de service GCP
- Rôles AWS IAM
- Okta Integration Network apps et intégrations d'applications personnalisées
- Applications GitHub OAuth
- Intégrations Snowflake OAuth
Le problème de l'héritage de l'agent d'IA
Lorsque les agents d’IA et les serveurs MCP interagissent avec vos applications, ils héritent des autorisations d’identité de charge de travail de cette application. L’identité de l’application dicte la portée maximale de ce qu’un agent d’IA peut faire de manière autonome.
Cela crée des risques sans précédent :
1. Identités hautement privilégiées : l'accès au niveau administrateur accordé lors des moments « il suffit de le faire fonctionner » devient une porte dérobée permanente pour les attaquants, avec une visibilité bien moindre que les violations humaines.
2. Privilèges inutilisés : cette application OAuth d’un POC vieux de six mois ? Toujours active, elle dispose toujours d’un accès privilégié à la production, toujours une porte qu’un système compromis pourrait franchir.
3. Combinaisons de privilèges toxiques et séparation des tâches :
Des autorisations individuellement raisonnables deviennent des combinaisons dangereuses lorsqu'elles sont héritées par des systèmes autonomes fonctionnant à la vitesse de la machine. Scénarios réels qui empêchent les équipes de sécurité de dormir :
- Une application GitHub avec un accès en lecture aux référentiels privés ET un accès en écriture à la production. Une seule identité détient le pouvoir de voler la propriété intellectuelle précieuse et d’attaquer et de compromettre directement le produit en direct destiné aux clients
- Un rôle AWS avec des privilèges d'écriture/suppression sur le développement ET la production. Une compromission dans l'environnement de développement moins sécurisé peut alors avoir un impact direct sur l'environnement de production critique.
- Une application connectée Salesforce accédant aux données client ET modifiant les paramètres de sécurité. Un attaquant qui compromet cette seule identité obtient les clés du royaume : il peut voler des données et dissimuler ses traces en désactivant les journaux d'audit ou d'autres fonctionnalités de sécurité.
4. Secrets non renouvelés : sans renouvellement automatisé, les identifiants deviennent permanents. Un agent d’IA pourrait effectuer des milliers d’appels d’API avec des jetons qui auraient dû expirer il y a des mois.
5. Contrôles réseau manquants : les identités de charge de travail manquent de restrictions IP, exposant vos systèmes à un accès depuis n'importe où, ce qui facilite la tâche des acteurs malveillants, et vous ne le sauriez jamais.
6. Confiance mal configurée : des relations de confiance trop larges créent des chemins d'attaque que les machines peuvent exploiter plus rapidement que les humains ne peuvent les détecter.
L'avantage d'Okta Identity Security Posture Management
Okta ISPM fournit la base pour sécuriser l'ensemble du périmètre d'identité, y compris les identités humaines, non humaines et agentiques à mesure qu'elles deviennent plus répandues dans votre pile technologique. Qu'il s'agisse d'un compte de service d'administrateur Salesforce avec un mot de passe, d'une application GitHub OAuth, d'un utilisateur AWS IAM avec une clé API ou d'un administrateur Okta avec un jeton, Identity Security Posture Management vous offre la visibilité et le contrôle nécessaires pour gérer ces autorisations puissantes avant qu'elles ne soient exploitées.
Couvrez vos applications les plus critiques, y compris les IdP, SaaS et l'infrastructure Cloud : contrairement aux outils axés sur l'infrastructure ou les applications individuelles, Okta Identity Security Posture Management offre une découverte et une gestion complètes de votre paysage d'identité.
Couvrir les types NHI les plus critiques : Okta Identity Security Posture Management prend en charge un large éventail de NHI, des comptes de service hérités, en passant par les clés d’API et les jetons, aux applications OAuth modernes et aux agents Salesforce AI.
Travaillez à l'échelle : Okta Identity Security Posture Management découvre et classe automatiquement les NHI dans votre environnement.
La voie à suivre : prêt pour l'avenir pour les agents d'IA et les NHI
Chaque identité de charge de travail est une superpuissance potentielle (ou une vulnérabilité) pour les agents d’IA et les systèmes automatisés. La question n’est pas de savoir si vous avez besoin d’une stratégie de sécurité des identités complète. Il s’agit de savoir si vous la mettrez en œuvre avant votre premier incident lié à un agent d’IA.
Dans un monde où les agents d'IA prennent des décisions autonomes grâce à des identités héritées, la sécurité des identités n'est pas seulement une question de protection, il s'agit de permettre l'avenir de votre entreprise basé sur l'IA. Okta Identity Security Posture Management vous offre la visibilité et le contrôle nécessaires pour adopter les agents d'IA en toute confiance, en commençant par la découverte et la gestion complètes des identités dans l'ensemble de votre environnement.
Parce que les organisations qui résoudront la crise de l'identité de la charge de travail ne se contenteront pas de survivre à la révolution de l'IA, elles la définiront.
Prêt à sécuriser vos identités de charge de travail ? Découvrez comment Okta Identity Security Posture Management aide les principales organisations à protéger leur avenir autonome.
