AWS Couche de roche: L'IV qui pourrait ouvrir la porte aux attaques enchaînées partout dans votre entreprise

Amazon Bedrock a ouvert une énorme porte aux entreprises pour intégrer des modèles de langage avancés dans leurs processus: il permet aux modèles non seulement de répondre aux questions, mais aussi de consulter des CRM, activer des fonctions sans serveur et récupérer des informations de dépôt d'entreprise. Ce même pont entre l'IV et les systèmes d'affaires est ce qui multiplie le risque, car il transforme l'agent IA en un autre élément de l'infrastructure avec ses propres permissions, portée réseau et vecteurs d'attaque.

Une équipe de recherche en sécurité de XM Cyber a découplé ce problème et validé plusieurs voies d'attaque qui profitent de cette connectivité. Il ne s'agit pas de briser la boîte d'un modèle par la force brute, mais d'abuser des pouvoirs, des configurations et des permissions entourant Bedrock pour atteindre des ressources précieuses en dehors du moteur d'inférence lui-même. Pour ceux qui gèrent ou sécurisent un environnement dans AWS, c'est une leçon claire : protéger les modèles ne suffit pas si le contexte autour d'eux n'est pas assuré. Vous pouvez consulter la page Bedrock sur AWS pour mieux comprendre leurs capacités : https: / / aws.amazon.com / substrat rocheux /, et l'étude complète de XM Cyber avec des diagrammes et des recommandations techniques est disponible à: Construction et développement d'applications d'IA Agéniques sécurisées dans AWS Bedrock.

Un chemin d'attaque qui attire l'attention est celui qui utilise les enregistrements d'invocation du modèle. Bedrock conserve des traces de chaque interaction pour des raisons de vérification; ces fichiers peuvent contenir des invites sensibles ou des résultats PII. Si un acteur malveillant peut lire le seau où ces journaux sont stockés ou les rediriger vers une destination sous leur contrôle, obtient un flux continu d'informations. Dans un autre scénario connexe, toute personne qui a la permission d'enlever des objets dans S3 ou de supprimer des flux de journaux peut supprimer des empreintes falsifiées ou un jailbreak, compliquer les enquêtes médico-légales et maintenir l'accès sous couverture.

L'architecture des bases de connaissances dans Bedrock - le modèle connu sous le nom de Retrieval Augmented Generation (RAG) - est une autre surface critique. Ici, les sources de données originales (S3, SharePoint, Salesforce, Confluence) coexistent avec les index et les magasins qui rendent ce contenu consultable. Si un attaquant obtient des identifiants pour lire la source directement, il peut exfilter des données sans passer par le modèle; s'il vole des secrets que Bedrock utilise pour se connecter aux services SaaS, il peut passer latéralement à des systèmes d'identité comme Active Directory. La différence entre la lecture des données brutes et la manipulation de la connexion est la différence entre l'espionnage et une porte pour les privilèges d'escalade.

En complétant cela, le lieu où les informations déjà traitées sont stockées - bases vectorielles ou entrepôts structurés - a ses propres risques. Les plates-formes vectorielles commerciales ou les services gérés peuvent contenir des clés et des paramètres dans des configurations qui, s'ils sont lus via les API Bedrock (par exemple via des requêtes qui récupèrent des objets de configuration), permettent à l'attaquant de contrôler des entiers ou des données clones. Avec les bases natives de l'AWS comme Aurora ou Redshift, le vol d'identifications peut donner un accès direct aux tableaux et à l'information relationnelle complète.

Les agents de roche sont des éléments autonomes conçus pour orchestrer les tâches. L'accès aux agents de création ou de mise à jour peut changer votre instruction de base et les outils que vous utilisez, provoquant des utilisations indésirables : de la divulgation des instructions internes à l'annexion d'exécuteurs malveillants agissant comme « portes arrière » et apportant des modifications aux bases de données ou aux comptes utilisateurs au nom de flux légitimes. Dans ce type de scénario, l'action malveillante est camouflée dans le comportement attendu de l'agent, ce qui rend la détection difficile.

Il y a aussi un vecteur plus subtil : au lieu de toucher l'agent, l'agresseur compromet l'infrastructure que l'agent invoque. Si un acteur peut mettre à jour le code d'une fonction Lambda ou publier des couches avec des dépendances malveillantes, injecter un comportement nuisible dans les appels que l'agent fait à des outils externes. C'est un moyen efficace de polluer une chaîne d'exécution sans modifier directement l'agent.

Les flux qui définissent les étapes et les conditions pour accomplir les tâches peuvent également être manipulés. En modifiant un flux, vous pouvez insérer un noeud qui envoie des données sensibles à un stockage externe, modifier les conditions qui agissent comme contrôles d'affaires pour permettre des requêtes non autorisées, ou même remplacer la clé de chiffrement utilisée pour les états et les instantanés par un contrôle par l'attaquant. Ainsi, la logique opérationnelle continue de fonctionner apparemment bien alors que la confidentialité ou l'intégrité de l'information est compromise.

Les « gardes » de Bedrock sont la première ligne de défense pour empêcher le modèle de générer des contenus dangereux, d'accepter des injections rapides ou d'exposer des données personnelles. Si quelqu'un peut abaisser les seuils, supprimer les règles ou supprimer ces filtres, une grande partie du contrôle que les organisations pensent avoir disparu. Le traitement des gardes transforme les vulnérabilités logiques en lacunes opérationnelles car il réduit la résilience aux entrées malveillantes qui étaient précédemment bloquées.

Enfin, la gestion centralisée des modèles rapides offre un vecteur d'impact à grande échelle. Modifier un tempéré partagé (ou sa version active) peut être inséré des instructions qui changent le comportement du modèle dans toutes les applications qui le consomment, sans avoir besoin d'un retrait. Ce type de changement « chaud » permet l'exfiltration de masse ou la génération coordonnée de contenu nocif et est difficile à détecter avec la surveillance traditionnelle des applications.

Que devraient faire les équipes de sécurité? La bonne nouvelle est que les défenses sont toujours appliquées avec discipline : gouvernance des identités et accès aussi strict que possible (principe de moindre privilège), contrôle et surveillance de la connexion avec une intégrité garantie, gestion sécurisée des secrets et des clés, segmentation du réseau et limitation de la portée des agents et des fonctions. Il est essentiel de tenir un inventaire des charges d'IA et de cartographier les ressources auxquelles ils ont accès, car, comme le montre l'analyse, un seul permis excessif peut suffire à déclencher une attaque en chaîne. AWS propose des guides de bonnes pratiques pour IAM qui sont un bon point de départ: https: / / docs.aws.amazon.com / IAM / latest / UserGuide / best-practices.html.

L'observabilité est également essentielle : pour s'assurer que les systèmes CloudTrail et d'enregistrement ne peuvent pas être facilement redirigés ou supprimés, et pour encoder des journaux sensibles avec des clés dont l'accès est restreint et vérifié. Les guides de gestion des clés CloudTrail et AWS aident à concevoir ces protections : Trail Nucléaire et AWS KMS. Pour le risque spécifique de RAG et les bases vectorielles, il convient d'examiner les contrôles entourant les pipelines d'ingestion, la rotation des références et les restrictions de réseau qui limitent la possibilité d'extraire des indices complets de l'extérieur du VPC ou de l'environnement administré.

Au niveau de la gouvernance de l'IV, il est utile d'examiner les cadres et les cadres de gestion du risque qui aident à hiérarchiser les contrôles techniques et organisationnels. Le NIST a publié des lignes directrices sur la gestion des risques pour l'IV qui peuvent servir de référence pour les politiques et les processus : NISTE AU FGR. Mettre en oeuvre des examens des changements pour les gardiens, les modèles et les flux rapides et soumettre les modifications aux processus d'approbation avec traçabilité réduit la possibilité de manipulation non détectée.

Bref, Bedrock et des plateformes similaires nous obligent à penser à la sécurité de l'IV en termes généraux : protéger les modèles, oui, mais surtout protéger les comptes, les itinéraires d'intégration et les éléments d'infrastructure qui permettent à un agent de toucher le reste de l'organisation. Si vous voulez passer à des tests conceptuels, des diagrammes et des recommandations opérationnelles, le rapport complet de XM Cyber contient ce matériel technique et a été fourni par des chercheurs d'équipe, dont Eli Shparaga: Construction et développement d'applications d'IA Agéniques sécurisées dans AWS Bedrock.