Les agents personnels open source accèdent déjà aux réseaux d'entreprise; contrôle d'identité

Moins d'un an après l'apparition des premiers agents personnels de source ouverte, le débat est passé de «si» à «comment» pour contrôler leur présence au sein des réseaux d'entreprises. Les faits confirmés sur le terrain : ces agents - tant ceux qui fonctionnent dans le cloud du fournisseur que ceux qui fonctionnent sur l'ordinateur de l'utilisateur - accèdent déjà aux systèmes d'entreprise par les mêmes canaux que les autres applications : Consentement OAuth, identifiants enregistrés dans les navigateurs, les clés API et les jetons personnels, ou accès direct à partir d'un terminal avec un logiciel local. Ce qui change, c'est l'entité qui agit au nom de l'employé : ce n'est pas seulement un dispositif ou une application, mais un agent autonome qui peut orchestrer des actions étendues en utilisant l'identité de l'employé.

Techniquement, il y a quatre principaux vecteurs par lesquels un agent personnel peut entrer dans un environnement d'entreprise, et chacun nécessite des contrôles différents. Tout d'abord, le flux OAuth: l'agent demande les permissions de Google Workspace, Microsoft 365, Slack ou d'autres, et l'utilisateur accorde l'accès en un seul clic; du point de vue du service, il ressemble à la même session d'employés. Deuxièmement, l'automatisation du navigateur et les gestionnaires de mots de passe intégrés permettent à un agent de « signer » dans un service comme s'il s'agissait de l'humain. Troisièmement, les intégrations non officielles peuvent fonctionner avecClés APIou des jetons à long terme que l'utilisateur crée et maintient; ces références survivent même si l'utilisateur change de rôle. Quatrièmement, les agents locaux installés dans l'ordinateur portable ou les serveurs personnels de l'employé lisent les fichiers, les courriels et les calendriers directement si permis.

Résultat direct: un agent personnel hérite des permissions de l'utilisateur, et demande souvent beaucoup moins d'accès qu'il n'a vraiment besoin de fonctionner. Le risque est double : exposition accidentelle de données sensibles et persistance de l'accès après la fin de la relation de travail. En outre, l'architecture du fournisseur peut compliquer la tâche : certains fournisseurs dirigent l'agent dans un VM propre qui maintient des jetons et met en œuvre des politiques d'utilisateur, pas celles de l'entreprise, qui transfère des sessions et des références à d'autres infrastructures.

Qui cela affecte - t - il? À l'ensemble de la chaîne: les employés qui utilisent des agents pour améliorer la productivité (des développeurs aux vendeurs), les équipements informatiques et de sécurité qui doivent protéger les identités et les données, et souvent des tiers (clients ou fournisseurs) si les informations de l'entreprise sont partagées sans publicité. Pour les organisations réglementées, le risque de non-conformité augmente lorsque les concessions ou les jetons OAuth échappent au contrôle de l'entreprise.

Ce qui est sûr d'être confirmé et ce qui ne l'est pas : il est confirmé que les agents utilisent les mécanismes d'authentification habituels et qu'il existe des exemples d'agents s'intégrant aux services ministériels. On constate également que de nombreux fournisseurs travaillent dans les contrôles de déploiement gérés. C'est une estimation - pas une certitude absolue - que la plupart des entreprises ont déjà des agents personnels connectés sans supervision. L'incertitude est l'étendue exacte de l'accès non supervisé dans chaque organisation et l'évolution des capacités d'allocation et de hors-bord à court terme.

D'un point de vue pratique, identifier l'identité comme un plan de contrôle est la stratégie la plus efficace. Au lieu d'essayer de bloquer toutes les variantes - un jeu de Whac--A-Mole que vous allez toujours perdre - il est approprié de supposer que des agents vont apparaître et concevoir des contrôles sur le périmètre qui comptent vraiment : identités, jetons et sessions. Cela comprend la détection fiable, l'attribution, la limitation des privilèges et les processus de révocation.

Mesures spécifiques et réalisables qu'un agent de sécurité devrait immédiatement mettre en œuvre: d'abord, inventer l'accès de tiers et OAuth concessions dans leurs locataires (Google et Microsoft offrent des contrôles administratifs pour lister les applications avec accès aux données; voir Google Workspace documentation et Azure AD guide de consentement). Deuxièmement, imposer que seules les demandes approuvées exigent des permis au moyen de politiques de consentement centralisées ou de blocage du consentement des utilisateurs. Troisièmement, supprimer ou faire pivoter les jetons à long terme et migrer vers les flux d'authentification en utilisant des jetons de courte durée et une autorisation déléguée avec une portée minimale. Quatrièmement, étendre les politiques de hors-bord pour inclure la révocation automatisée des concessions OAuth, la clôture des sessions actives et la suppression des clés associées à l'employé. Cinquièmement, implémentez la détection dans les terminaux et les réseaux : les solutions EDR / SIEM et CASB ou DLP devraient alerter sur les modèles d'agents typiques (démarrage à partir des gammes IP du fournisseur, création soudaine de clés API, utilisation inhabituelle des comptes de service).

Deux mesures techniques à impact élevé qui nécessitent peu de nouvelles infrastructures : permettre le consentement administratif des applications (pour interdire aux utilisateurs de délivrer des permis uniquement) et mettre en œuvre des politiques d'accès conditionnel fondées sur les risques pour toute authentification comportant des permis étendus. Les deux réduisent les attaques pour abus de jetons et atténueront le problème des séances qui agissent en tant qu'employés non supervisés.

Tout n'est pas résolu aujourd'hui : les défis ouverts demeurent de nature à distinguer avec une grande certitude si une authentification vient de l'humain ou de son agent quand les deux partagent des lettres de créances, et comment faire en sorte que la « connaissance » qu'un agent accumule soit supprimée pendant le hors-bord. Il n'existe pas non plus de normes d'interopérabilité exhaustives pour qu'un administrateur puisse voir « cet agent appartient à cette personne » sans pour autant porter atteinte à la vie privée du fournisseur ou de l'utilisateur. À mesure que ces capacités mûrissent, la combinaison de gouvernance d'identité, de détection spécialisée et de processus d'exploitation robustes est la meilleure défense.

Ressources pratiques et de référence à lire et à appliquer : le Google Workspace Apps Control Guide (https: / / support.google.com / a / reply / 7281227) et la documentation de Microsoft sur le consentement et les permissions dans Azure AD (https: / / learn.microsoft.com / en-us / azure / Activ-directory / manage-apps / consent). Pour les principes techniques sur l'OAuth et les meilleures pratiques de sécurité, la collection OWASP est utile comme liste de contrôle opérationnelle (https: / / tricheseries.owasp.org / trichesheets / OAuth2 _ Cheat _ Sheet.html).

Bref, bloquer les agents personnels en principe est une option politiquement tentante mais peu pratique. La stratégie la plus réaliste et la plus efficace est de traiter l'agent comme une entité externe et de contrôler sa portée par l'identité: inventaire et attribution, principe de privilège mineur, annulation automatique en hors-bord et détection proactive en jetons et en sessions. Ceux qui mettent en œuvre ces mesures n'élimineront pas complètement le risque, mais diminueront considérablement la probabilité et l'impact des fuites et des abus causés par des agents qui agissent avec l'identité des employés.