Lorsqu’un agent d’intelligence artificielle utilise l’identifiant d’un utilisateur humain pour accéder à des bases de données, le système n’obtient pas une « identité d’agent » cachée derrière le compte : il voit l’utilisateur lui-même. Telle est la conclusion centrale d’une mesure réalisée par Naseeb Ahmed Mian dans un environnement de production utilisant Azure, Azure CLI et sqlcmd.
Dans la configuration examinée, les compétences de l’agent logiciel se connectaient aux bases de données via la commande sqlcmd, en utilisant l’authentification par Azure CLI. La commande extrait le jeton d’accès mis en cache après la connexion de l’utilisateur, puis le présente à la base de données. Par conséquent, les connexions apparaissaient sous le nom de l’utilisateur, avec le nom de son appareil et l’outil sqlcmd, qu’il ait lui-même écrit la requête ou que l’agent l’ait exécutée.
Le journal d’audit voit l’identifiant, pas l’intention
Le journal de session affichait le nom de connexion de l’utilisateur, le nom du poste de travail et l’interface cliente, mais ne comportait aucun champ permettant de distinguer les actions exécutées par l’agent. Les requêtes humaines et automatisées deviennent ainsi identiques dans le journal, et les contrôles ultérieurs ne peuvent pas appliquer, en fonction de la source d’exécution, une limitation du débit des requêtes, une étape d’approbation ou une politique de conservation différente.
Le problème ne se limite pas aux enquêtes de sécurité. Si une requête exécutée plusieurs mois auparavant est contestée ultérieurement, le journal ne permettra pas d’établir si l’utilisateur l’a écrite ou si un outil automatisé l’a lancée. Il attribue précisément l’action à l’identifiant, mais reste silencieux sur l’intention et l’acteur réel.
Que révèle le jeton d’accès ?
Le jeton remis par Azure CLI contenait la portée user_impersonation, ainsi qu’une revendication indiquant que l’authentification avait inclus un facteur multifacteur. En pratique, chaque action exécutée par l’agent est accompagnée de la preuve que l’utilisateur a passé l’authentification multifacteur, même si celle-ci a eu lieu plusieurs heures auparavant et dans le cadre d’une autre tâche.
En outre, la durée de validité du jeton, de 84 minutes, ne représente pas nécessairement la fin de l’exécution de l’agent. Le CLI renouvelle automatiquement le jeton au moyen d’un jeton d’actualisation ; l’exécution non surveillée peut donc se poursuivre jusqu’à l’expiration du jeton d’actualisation ou à la désactivation du compte utilisateur.
L’appartenance aux groupes élargit le tableau
L’examen des affectations de rôles n’a révélé qu’une seule ligne : le rôle Reader dans un abonnement hors production. Toutefois, le jeton d’accès comprenait 37 groupes, tandis qu’une requête sur l’appartenance directe en affichait 34, avec l’existence de groupes imbriqués. Parmi les groupes concernés par l’accès figuraient notamment des rôles tels que lecteur de bases de données SQL, utilisateur à privilèges élevés, contributeur aux ressources et administrateur de base de données.
Le danger tient au fait que ces appartenances peuvent porter les autorisations effectives au niveau de la couche de données et n’apparaissent pas nécessairement dans les contrôles des rôles de la couche de contrôle. Ainsi, la portée d’accès de l’agent peut sembler limitée lors d’un examen traditionnel, alors que l’appartenance aux groupes lui confère une capacité plus étendue.
Qu’est-ce qui change concrètement ?
Lors du test de la même identité sur deux magasins de production à une heure d’intervalle, deux résultats fortement divergents sont apparus. Dans l’un d’eux, l’identité ne disposait que des autorisations CONNECT et SELECT et ne pouvait pas se connecter à la couche sécurisée. En revanche, un autre point d’analyse de production affichait 430 tables et 107 autorisations, comprenant la lecture, l’écriture, la définition du schéma et l’administration de la base de données.
La comparaison montre que l’étendue des autorisations n’est pas déterminée par l’identité seule ; le chemin d’accès, le moteur et les contrôles associés au point de terminaison sont également des facteurs décisifs. Un point de terminaison peut être en lecture seule selon sa documentation, tandis que ses règles de sécurité ne sont pas nécessairement appliquées lorsque les données sont appelées via un autre moteur.
Lecture éditoriale de certi.news : le problème n’est pas que l’agent soit « dépourvu d’identité », mais que l’identité humaine ait été utilisée comme substitut rapide à une identité automatisée indépendante. Cela s’effondre à trois niveaux : l’attribution, l’étendue des autorisations et la révocation. La mesure a également montré que l’environnement dans lequel l’identifiant disposait de la capacité de supprimer des données d’une base de données sécurisée était le seul où aucun journal d’audit n’était activé. Des questions importantes restent ouvertes concernant la cohérence de l’appartenance aux groupes, la persistance des autorisations temporaires dans les jetons émis et la capacité des organisations à enregistrer l’intention d’exécution, et pas seulement le détenteur de l’identifiant.