IAM, OAuth, IAAG… Le nouveau standard qui pourrait sauver votre infrastructure en 2026
A retenir sur la sécurité des agents d'IA
- Les DSI ne peuvent que constater que les utilisateurs pros donnent accès aux données de l'entreprise à des applications externes.
- Lorsque ces applications externes sont des agents d'IA, les risques de sécurité explosent.
- Okta propose une norme pour donner aux organisations plus de visibilité et de contrôle sur ces autorisations.
D'ici à la fin de 2026, beaucoup d'entre nous auront au moins un agent alimenté par l'IA qui fera quelque chose en coulisses pour notre compte. D'ici cinq ans, il pourrait s'agir de dizaines ou de centaines d'agents. Non seulement ils prendront des décisions sur ce qu'il convient de faire (sur la base de leurs observations autonomes), mais ils se connecteront à de multiples sources de données (ainsi qu'entre eux) afin d'optimiser ces décisions et d'autres résultats.
Cet avenir devrait terrifier la plupart des organisations. Mais comme les employés sont poussés à en faire plus avec l'aide de l'IA, ils chercheront à lancer ces agents et à leur donner accès à toutes les ressources de l'entreprise nécessaires.
Surtout, le justificatif d'identité actuel pour un tel accès d'application à application fourni par l'utilisateur - connu sous le nom de jeton OAuth - peut être terriblement inadapté à la tâche. D'autant qu'un piratage à tout remis en question.
Le rôle des systèmes IAM
Les systèmes de gestion des identités et des accès (IAM), tels que Identity Platform d'Okta et Entra de Microsoft, servent de panneau de contrôle pour gérer quels humains ont accès à quelles ressources de l'entreprise
Cependant, ces mêmes systèmes sont souvent hors circuit lorsqu'il s'agit de savoir comment d'autres applications se sont vu accorder un accès similaire aux ressources pour le compte de ces utilisateurs.
De quoi créer des angles morts IAM et des risques de sécurité évitables. Depuis, Okta travaille avec l'IETF (Internet Engineering Task Force) sur un projet de norme ouverte destiné à combler cette lacune.
Proposer une nouvelle norme
Okta fait référence à la spécification sous le nom de "Cross-App Access" ou XAA. Cependant, la spécification est connue sous un autre nom : Identity Assertion Authorization Grant (IAAG). Par rapport aux technologies propriétaires et, dans certains cas, aux normes de facto, une norme ouverte est une technologie mise à la disposition de l'industrie en toute liberté.
Les entreprises et les développeurs, y compris les concurrents IAM d'Okta tels que Microsoft et Ping Identity, sont libres de construire leurs propres implémentations de la technologie sans avoir à payer de royalties à ses inventeurs.
HTTP - la technologie de base qui permet à n'importe quel navigateur web d'accéder à n'importe quel site web - est une norme ouverte. Les deux principales technologies qui permettent aux passkeys de fonctionner -- le WebAuthn du World Wide Web Consortium et le Client to Authenticator Protocol (CTAP) de la FIDO Alliance -- sont des normes ouvertes.
Google, Amazon, Salesforce, Box et Zoom figurent parmi les premiers utilisateurs de l'IAAG
Si n'importe quelle entreprise peut inventer une technologie et la proposer au monde entier pour qu'elle soit considérée comme une norme ouverte, la véritable mesure pour savoir si cette technologie est réellement une norme ouverte est liée au rythme auquel elle est adoptée par d'autres entreprises. Selon Okta, Google, Amazon, Salesforce, Box et Zoom figurent parmi les premiers utilisateurs de l'IAAG.
Alex Simons, vice-président de Microsoft chargé des innovations en matière d'IA, a déclaré à ZDNET que Microsoft prévoyait de prendre en charge la nouvelle norme IAAG dans Entra (la solution IAM basée sur le cloud de l'entreprise).
Par ailleurs, Aaron Parecki, directeur des normes d'identité chez Okta, et Brian Campbell, ingénieur de Ping Identity, apparaissent comme co-auteur de la dernière version de la norme IAAG.
Les coulisses de la délégation d'accès
Voici ce qui se passe généralement en coulisses. Lorsqu'une application se voit accorder un accès direct à une autre application au nom d'un utilisateur final (un type d'accès connu sous le nom d'"accès délégué"), l'opérateur de la seconde application (le "serveur de ressources") est invité à délivrer un identifiant de connexion spécial que la première application (l'"application cliente") utilise ensuite pour s'authentifier auprès du serveur de ressources, comme si elle prétendait être l'utilisateur final lui-même.
À cette étape d'un flux de travail OAuth classique, le serveur de ressources du compte Google informe l'utilisateur final qu'il a reçu une demande de Slack en tant qu'application cliente souhaitant obtenir des droits d'accès spécifiques (énumérés dans la liste affichée) au compte Google de l'utilisateur. Si l'utilisateur donne son accord en cliquant sur le bouton "Autoriser", Google envoie à Slack un jeton d'accès OAuth spécifique à l'utilisateur final, à son compte Google et aux droits d'accès énumérés. Capture d'écran par David Berlind/ZDNET
Dans un tel scénario, l'utilisateur final, considéré par la norme OAuth comme le "propriétaire de la ressource", délègue tout ou partie de ses droits d'accès au serveur de ressources à l'application cliente. Ce justificatif spécial est connu sous le nom de jeton OAuth. Avant que le serveur de ressources ne délivre un tel jeton à l'application cliente, l'utilisateur final est généralement consulté au moyen d'une boîte de dialogue (voir la capture d'écran ci-dessus) pour obtenir son autorisation de procéder à la délégation.
Si l'utilisateur final donne son accord, le serveur de ressources (généralement un "serveur d'autorisation" spécialisé agissant au nom du serveur de ressources) délivre le jeton OAuth à l'application cliente, qui est alors chargée de le stocker en toute sécurité. Après tout, il s'agit essentiellement de l'équivalent de l'identifiant et du mot de passe de l'utilisateur final.
Similitude avec le comportement humain
Au début de cette année, lorsque plus d'un milliard d'enregistrements de clients ont été exfiltrés de manière criminelle et évitable des instances Salesforce de certaines des marques les plus importantes et les plus connues au monde, les pirates se sont appuyés sur des jetons OAuth volés pour perpétrer leur crime.
Une fois que l'utilisateur final a consenti à l'émission d'un jeton OAuth et que l'application cliente a reçu ce jeton, elle l'utilise comme identifiant de connexion au serveur de ressources, de la même manière que les humains présentent leurs identifiants et leurs mots de passe au moment de la connexion. Chacun de ces jetons OAuth est limité à l'utilisateur (encore une fois, le "propriétaire de la ressource") qui l'a octroyé, aux droits d'accès spécifiques qui ont été délégués au moment de l'octroi (il peut s'agir d'un sous-ensemble des droits généraux de l'utilisateur) et au serveur de ressources qui l'a délivré.
Un jeton OAuth délivré par Google (le serveur de ressources) à Slack (l'application cliente) en mon nom est donc spécifique à Google et associé à mon identité Slack. Slack ne peut pas présenter ce même jeton à une autre application comme Zoom, ni présenter ce jeton à Google au nom d'un autre utilisateur. Si certains jetons sont éternels, d'autres expirent au bout d'un certain temps. Les émetteurs de jetons peuvent également invalider les jetons (ou les révoquer) à leur guise. Cela revient à désactiver un mot de passe ou à changer la serrure de votre porte d'entrée.
A l'origine de OAuth
Bien qu'il existe plusieurs types de jetons pour divers cas d'utilisation, l'idée d'un jeton Open Authorization ou OAuth est née à une époque où, dans le scénario susmentionné, un utilisateur saisissait simplement son identifiant et son mot de passe Google dans Slack.
Et il est difficile de croire que beaucoup d'entre nous, utilisateurs, fournissaient volontiers ces informations d'identification. Du point de vue de la cybersécurité, cette pratique a soulevé des questions difficiles, mais surtout rhétoriques.
À qui donnions-nous vraiment ce nom d'utilisateur et ce mot de passe ? S'agit-il d'une entreprise légitime ou d'une application malveillante habilement déguisée en outil incroyablement utile ? Même si l'application est légitime, comment et où stocke-t-elle en toute sécurité les informations d'identification secrètes que nous venons de partager avec elle ? Et si l'application cliente n'avait besoin que d'un sous-ensemble des droits d'accès globaux de l'utilisateur final ?
Et la question du consentement
Par ailleurs, contrairement à OAuth, il n'y avait pas d'étape explicite au cours de laquelle l'utilisateur donnait son consentement. "Le consentement était implicite dans l'identifiant", explique Parecki. "Ainsi, vous donniez votre mot de passe à une application, l'application transmettait le mot de passe à un service et le présentait comme s'il s'agissait de vous. Il s'agit en quelque sorte d'un consentement implicite, n'est-ce pas ? Parce que le fait qu'elle ait le mot de passe signifie qu'elle a dû l'obtenir légitimement, n'est-ce pas ? Ce qui, nous le savons, n'est pas une bonne chose".
L'arrivée d'OAuth a éliminé la nécessité pour les utilisateurs de partager leurs informations d'identification secrètes afin de permettre un accès inter-applications en leur nom.
Ce système a très bien fonctionné sur l'internet au cours des deux dernières décennies. Mais la question de savoir qui est véritablement le propriétaire de la ressource s'est alors posée. C'est l'utilisateur final qui est considéré comme le propriétaire de la ressource, et c'est donc lui qui finit par consentir à l'émission du jeton OAuth. Mais l'utilisateur final est-il vraiment le propriétaire de la ressource ? Ou est-ce l'organisation ? Et si c'est l'organisation - ce qui est le cas - l'organisation ne devrait-elle pas être partie prenante au flux de travail OAuth ?
Et la question du contrôle
Selon Okta, dans les scénarios de consommation où l'utilisateur final souhaite qu'une application client telle qu'un agent d'intelligence artificielle prenne des mesures sur son compte Gmail personnel, il est tout à fait possible que l'utilisateur final soit le propriétaire de la ressource qui consent à l'émission d'un jeton d'accès OAuth. Mais dans les scénarios organisationnels où les ressources appartiennent réellement à l'organisation et où l'accès à ces ressources est contrôlé par un plan de contrôle central, le consentement ultime devrait plutôt provenir de ce plan de contrôle central - le système IAM.
Pourquoi cela est-il judicieux ? Parce que les utilisateurs finaux sont mauvais pour défendre l'infrastructure d'application d'une organisation. Par exemple, des recherches ont montré que même après avoir reçu une formation en cybersécurité, 98 % des utilisateurs baissent leur garde et succombent à des attaques de phishing. Selon la norme IAAG, l'utilisateur final a toujours le choix d'opter pour une connexion entre une application client comme Slack et une ressource comme l'installation de Zoom par l'organisation. Mais c'est le système IAM de l'organisation qui approuve en dernier ressort cette demande de connexion et l'émission ultérieure du jeton d'accès OAuth nécessaire.
De la même manière que l'accès aux ressources est accordé aux humains, cette forme de consentement est configurée à l'avance par l'administrateur du système, explique M. Parecki. "Pour tous les utilisateurs de l'entreprise, nous aimerions permettre à Slack d'obtenir des jetons d'accès pour les comptes Dropbox de nos utilisateurs", explique Parecki à titre d'exemple. "C'est une politique qui se trouve dans l'IdP [Identity Provider, un acronyme parfois utilisé de manière interchangeable avec IAM]. Désormais, Slack peut obtenir un jeton d'accès parce que la politique est configurée dans le fournisseur d'identité".
Quand les agents d'intelligence artificielle se déchaînent
L'approche a également du sens dans un monde qui est sur le point d'être submergé par des agents d'IA. Dans ce scénario d'agents IA déchaînés, il n'est pas difficile d'imaginer à quelle vitesse le système IAM central pourrait ne plus être en phase avec toutes les permissions accordées, au nom de qui et pour quelles ressources. À grande échelle, un seul agent malveillant pourrait faire beaucoup de dégâts en très peu de temps.
"Même s'il s'agit d'un agent, il s'agit toujours d'un logiciel et il est toujours représenté par son identifiant client", explique M. Parecki. "Supposons que vous souhaitiez qu'un nouvel agent soit capable d'indexer l'ensemble de votre contenu dans 20 applications d'entreprise. L'agent a besoin de plus de données et essaie d'accéder à plus de choses [que dans le scénario d'application client OAuth typique]. Vous ne voulez pas que chaque utilisateur de l'entreprise doive cliquer 20 fois sur une demande de consentement juste pour commencer à utiliser votre nouvel outil d'IA."
La norme proposée implique donc plus qu'un simple ajustement du flux de travail OAuth pour vérifier auprès du propriétaire réel de la ressource (l'organisation) au lieu de l'utilisateur final qui utilise la ressource. La structure du jeton doit également être améliorée. Par exemple, alors qu'un flux de travail OAuth standard implique l'identifiant de l'utilisateur tel qu'il est indiqué par le fournisseur de la ressource, ce flux de travail OAuth amélioré implique l'identifiant de l'utilisateur tel qu'il est indiqué par le système IAM de l'organisation. Un enregistrement du système IAM est également inclus dans le flux de travail amélioré.
Deux exemples d'utilisation de la norme IAAG
Non seulement ces champs de données supplémentaires permettent d'insérer le système IAM de l'organisation au cœur du processus d'octroi d'OAuth, mais ils facilitent également un degré plus élevé de visibilité et de contrôle centraux qui n'étaient pas disponibles auparavant pour les DSI.
Prenons par exemple les scénarios suivants :
Un employé a 25 agents d'IA et décide de quitter l'entreprise
Un employé a 25 agents d'intelligence artificielle qui travaillent en son nom et agissent sur un large éventail de serveurs de ressources de l'organisation.
Lorsqu'il décide de quitter l'entreprise, le service informatique doit déprovisionner ces agents.
Dans le cadre de ce nouveau système OAuth, un responsable informatique peut interroger le système IAM de l'organisation non seulement pour consulter tous les jetons émis pour un utilisateur donné sur l'ensemble des serveurs de ressources, mais aussi pour révoquer plus facilement tout ou partie de ces jetons dans le cadre d'un exercice de déprovisionnement ciblé.
Un agent d'IA divulgue des informations confidentielles au LLM
L'organisation découvre qu'un agent d'intelligence artificielle, dont l'utilisation a été approuvée à l'origine par tous les employés, divulgue des informations confidentielles au LLM sous-jacent.
Pour arrêter l'hémorragie, le RSSI décide que l'ensemble du fournisseur de la solution d'IA agentique doit être immédiatement déprovisionné de l'infrastructure applicative de l'organisation.
Avec une simple requête au système IAM, un responsable informatique devrait être en mesure de découvrir plus facilement les jetons pertinents et de les déprovisionner.
Comme pour beaucoup de nouvelles normes, il faudra peut-être un certain temps avant que tout se mette en place de manière à donner aux responsables informatiques un contrôle centralisé sur la prolifération de l'IA agentique (sans parler des connexions standard d'application à application qui s'établissaient déjà dans le dos des responsables informatiques). Non seulement le projet de norme doit passer par les dernières étapes d'approbation à l'IETF, mais la prise en charge de la nouvelle norme doit apparaître dans les différents serveurs d'autorisation utilisés par tous les fournisseurs SaaS qui prennent en charge les connexions basées sur OAuth à partir d'applications clientes.
Source : Lire l'article original