if ( !emtpy($headline_subheadline ) ) : ?>
Les chercheurs préviennent que les agents IA de confiance peuvent agir comme proxy pour des comptes privilégiés lorsque les autorisations des utilisateurs ne sont pas appliquées en aval.
endif; ?>
Selon une étude de Noma Labs, une technique d’attaque par IA récemment identifiée peut permettre à des utilisateurs non authentifiés de déclencher des flux de travail privilégiés et d’accéder aux systèmes de l’entreprise, mettant en évidence une lacune dans la manière dont les contrôles d’identité et d’accès s’appliquent aux agents IA.
Le rapport, rédigé par Sasi Levi, chercheur principal de Noma Labs, décrit le problème comme un « détournement d’identité de flux de travail », où les attaquants contournent les contrôles standard en envoyant des requêtes normales et inoffensives via un point d’entrée non authentifié tel qu’une boîte de réception d’assistance, un problème GitHub, un formulaire Web ou un document partagé.
« Le pipeline d’IA d’entreprise lit les entrées, interprète la demande et exécute l’action exactement comme prévu », écrit Levi dans le rapport. « Le principal échec est que le demandeur n’avait aucune autorité pour faire cette demande. »
L’autorisation est interrompue au niveau de la couche de workflow
Au centre du problème se trouve ce que Levi décrit comme « un défaut de conception des autorisations dans les pipelines d’IA d’entreprise modernes », où l’identité du demandeur et l’identité utilisée pour exécuter les actions divergent.
« L’identité et les autorisations de l’utilisateur qui déclenche un flux de travail sont découplées de l’identité et des autorisations utilisées pour l’exécuter », a-t-il écrit. En pratique, cela signifie que les workflows effectuent des actions « en utilisant des comptes de service à privilèges élevés ou des clés API de développeur » au lieu de faire respecter les droits d’accès de l’utilisateur initiateur.
En conséquence, les flux de travail de l’IA peuvent agir comme « des proxys non authentifiés pour des actions privilégiées et une exfiltration silencieuse des données », ajoute le rapport.
Vibhum Dubey, chercheur en cybersécurité et membre de l’équipe rouge, a déclaré que le problème reflète une classe connue de faiblesse des autorisations.
« Si une entrée non authentifiée peut déclencher un flux de travail fiable et que ce flux de travail exécute des actions en utilisant ses propres privilèges, le flux de travail peut effectivement agir comme un adjoint confus. »
Il a ajouté que dans de nombreux déploiements, « les autorisations du demandeur d’origine ne sont pas nécessairement réévaluées lorsque le flux de travail exécute des actions sensibles en aval ».
Même demande, autorité différente
Le rapport illustre le risque avec un scénario impliquant des demandes identiques de différents acteurs.
« Considérez deux entrées identiques », a écrit Levi, y compris une requête de données financières provenant du courrier électronique d’un cadre supérieur. « L’opération demandée et l’opération demandée sont identiques, mais la décision d’autorisation devrait être complètement différente. »
« Un directeur financier a droit à ces informations ; un expéditeur externe ne l’a pas. »
Parce que l’entrée elle-même est inoffensive, « les détecteurs d’injection rapide standard et les garde-fous d’agents classent ces entrées de la même manière », a-t-il noté. « Le risque de sécurité ne réside pas dans l’invite ; il se situe dans la limite de l’autorisation. »
Le modèle se comporte correctement, mais pas le système.
Contrairement aux attaques par injection rapide, cette technique ne repose pas sur la manipulation du comportement du modèle, selon le rapport.
« L’attaquant n’a pas du tout besoin de manipuler le modèle », a écrit Levi. « Le modèle suit correctement ses instructions et le workflow suit correctement son chemin d’exécution prédéfini. »
L’échec se produit lorsque le workflow exécute l’action résultante « en utilisant l’identité ou les privilèges du créateur du workflow sans vérifier si le demandeur d’origine était autorisé ».
Cette distinction déplace le problème de la sécurité des modèles vers la manière dont l’identité et les autorisations sont appliquées sur les systèmes interconnectés.
L’activité semble légitime
Étant donné que les actions sont exécutées via des flux de travail fiables à l’aide d’informations d’identification valides, l’activité peut ne pas déclencher d’alertes de sécurité conventionnelles.
« Le risque de sécurité ne réside pas dans l’invite », note le rapport, mais dans la manière dont les flux de travail utilisent « des privilèges que l’attaquant ne possède pas ».
Dubey a déclaré que cela crée un défi de détection pour les défenseurs.
« Les événements individuels peuvent sembler tout à fait légitimes. Les signaux utiles proviendraient de la corrélation entre le demandeur d’origine, l’identité utilisée en aval, les ressources consultées, les paramètres fournis et l’action finale. »
Sans cette corrélation, les accès non autorisés peuvent se fondre dans l’automatisation de routine, a ajouté Dubey.
Le risque augmente à mesure que les attaquants adoptent des workflows agents
Le moment choisi pour la découverte ajoute à son importance. À mesure que les entreprises développent l’automatisation basée sur l’IA, les attaquants commencent également à utiliser des flux de travail similaires en plusieurs étapes pour mener à bien leurs opérations.
Dans un récent article de blog, Google Threat Intelligence Group a décrit le passage d’une utilisation abusive basée sur des invites à des attaques plus autonomes, pilotées par des agents, capables de planifier et d’exécuter des tâches dans tous les environnements.
Cette évolution augmente le recours à la même couche d’exécution mise en évidence dans le rapport Noma, à savoir les flux de travail d’IA qui connectent les systèmes et agissent au nom des utilisateurs, amplifiant ainsi l’impact de toute lacune dans la manière dont l’identité et l’autorisation sont appliquées.
Déplacer les contrôles au-delà du modèle
Noma Labs a déclaré que l’atténuation des risques nécessite de déplacer les contrôles de sécurité au-delà de la couche modèle et dans la conception des applications et de l’infrastructure.
« Atténuer ces risques liés aux flux de travail de l’IA nécessite de déplacer les contrôles de sécurité de la couche modèle vers les couches application et infrastructure », a écrit Levi.
Le rapport recommande d’appliquer un accès conscient de l’identité au point où les actions sont exécutées, y compris la « propagation du contexte utilisateur » et les « étapes explicites d’évaluation du contrôle d’accès et de la protection d’exécution » entre les sorties générées par l’IA et les opérations en aval.
Dubey a déclaré qu’une façon de tester le problème consiste à comparer les résultats entre les utilisateurs ayant différents niveaux de privilèges.
« Si un utilisateur peu privilégié peut obtenir le même résultat qu’un administrateur parce que les systèmes en aval ne voient que l’identité du flux de travail, c’est là que je concentrerais l’enquête. »
