Huit vecteurs d'attaque dans AWS Bedrock à surveiller de près
Analyse technique
Vue d'ensemble des composants exposés
AWS Bedrock agit comme une plaque tournante entre des modèles de base (FMs) accessibles par API, des adaptateurs vers des systèmes (Salesforce, SharePoint, S3, bases de données), des capacités d'exécution (par exemple invocation de Lambda) et des pipelines de journalisation (CloudWatch, S3) qui peuvent contenir des informations sensibles. La plateforme repose sur des contrôles d'accès variés - IAM, rôles, VPC endpoints - mais une mauvaise configuration ou des permissions excessives transforme rapidement ces composants en points d'entrée exploitables. Pour cadrer : Bedrock orchestre des accès à des données et à des actions sur votre environnement cloud, et toute faiblesse devient une porte ouverte pour un attaquant¹ ².
Huit vecteurs d'attaque prioritaires
Les vecteurs listés ci-dessous ont été observés ou décrits dans des analyses publiques et correspondent à des scénarios réalistes d'exploitation d'intégrations Bedrock¹.
- Injection de prompt et exfiltration via connecteurs
- Risque : un prompt malveillant peut amener le modèle à formuler ou transférer des données sensibles via un connecteur configuré.
- Action prioritaire : auditer immédiatement les rôles IAM liés à Bedrock pour détecter des permissions excessives et mettre en place une filtration des prompts en amont.
- Abus de rôles IAM délégués
- Risque : des politiques autorisant "sts:AssumeRole" sans contraintes permettent la pivotation entre comptes.
- Action prioritaire : restreindre les politiques d'assume role par conditions (source ARN, MFA, tags, dates d'expiration).
- Server-Side Request Forgery (SSRF)
- Risque : un adaptateur mal protégé peut être amené à requêter des endpoints internes (métadonnées, services internes) et exposer des credentials.
- Action prioritaire : mettre en place des whitelists d'URL pour les adaptateurs et isoler les accès via VPC endpoints.
- Exécution non contrôlée de fonctions
- Risque : autoriser des invocations Lambda larges permet d'exécuter du code manipulant des données sensibles et de lancer des exfiltrations.
- Action prioritaire : limiter les fonctions invoquables, contrôler les payloads et vérifier les journaux d'exécution.
- Fuites de logs et données persistées
- Risque : CloudWatch et S3 peuvent contenir des prompts complets ou des réponses incluant des secrets.
- Action prioritaire : appliquer du masquage/redaction avant journalisation et chiffrer les buckets avec KMS.
- Poisoning de données
- Risque : pipelines de fine-tuning ou mémoires contextuelles alimentés par des sources non vérifiées peuvent corrompre le comportement du modèle.
- Action prioritaire : valider et tracer les sources de données utilisées pour l'apprentissage ou le context window.
- Compromission de connecteurs tiers
- Risque : un token OAuth compromis sur une application tierce donne un pont direct vers vos données via le connecteur.
- Action prioritaire : révoquer les accès non utilisés, appliquer des scopes minimaux et surveiller l'usage des tokens.
- Exposition cross-account
- Risque : politiques ressources avec "Principal": "*" exposent des artefacts à des comptes externes.
- Action prioritaire : revoir toutes les resource policies et éliminer les wildcards sur "Principal" et "Resource".
Chaînage d'attaques - scénario type
Un attaquant soumet une prompt injectée à un agent. Le modèle appelle un connecteur Salesforce qui dispose de permissions excessives; les données renvoyées sont transmises à une Lambda mal configurée; la Lambda relaie les informations vers un domaine externe contrôlé par l'attaquant; enfin, les logs CloudWatch conservent une trace utile pour l'attaquant et pour la revente des données. Chaque maillon de cette chaîne doit être traité comme un point de défaillance critique et corrigé sans délai¹.
Impacts business
Risques financiers et réputation
La perte ou l'exfiltration de données via ces vecteurs a des conséquences financières lourdes. Le coût moyen d'une fuite de données atteint 4,45 millions USD selon les derniers rapports disponibles⁴. Sur le plan réglementaire, des violations impliquant des données personnelles peuvent déclencher des amendes significatives, et les enquêtes publiques détériorent rapidement la confiance des clients et des partenaires¹.
Conséquences opérationnelles
- Ralentissements ou interruptions de services si des instances doivent être isolées.
- Vol ou fuite de propriété intellectuelle affectant compétitivité et roadmap produit.
- Mouvements latéraux vers d'autres services, multipliant la surface compromise.
Quantification d'un scénario réaliste
Pour une exfiltration simulée de 100 000 enregistrements clients, les coûts directs (forensic, notifications, assistance) peuvent facilement dépasser 1M EUR : enquête forensique estimée à 150k-300k EUR, notifications et conformité 50k-200k EUR, plus impacts indirects et perte de confiance. Ces chiffres confirment que l'inaction a un coût immédiat et quantifiable⁴.
Recommandations opérationnelles (ordre de priorité)
Gouvernance et politique d'accès
- Appliquer le principe du moindre privilège sur tous les rôles Bedrock et bannir les wildcards sur "Resource" et "Action".
- Imposer des conditions IAM basées sur tags, origines d'appel et dates d'expiration pour les rôles assumables.
- Mettre en place des revues de permission hebdomadaires pour les comptes à privilèges élevés.
Isolation réseau et validation des adaptateurs
- Exiger des VPC endpoints pour tout trafic vers des connecteurs internes et isoler les adaptateurs sur des subnets privés.
- Valider strictement toutes les URLs sortantes des adaptateurs grâce à des whitelists applicatives et limiter l'usage de résolveurs DNS publics.
Contrôles de données et masquage
- Filtrer et masquer les PII avant toute journalisation; appliquer la redaction côté agent si possible.
- Chiffrer les données sensibles en repos et en transit avec KMS, et restreindre l'usage des clés via des policies.
Surveillance et détection
- Structurer le logging des invocations Bedrock pour conserver le contexte minimal utile à l'enquête sans stocker les prompts complets.
- Configurer alertes sur comportements anormaux : volume inhabituel d'appels sortants, patterns d'InvokeFunction atypiques, usage d'AssumeRole entre comptes.
Validation des tiers et supply chain
- Révoquer les accès OAuth non utilisés et exiger des scopes limités pour chaque intégration.
- Intégrer des tests de sécurité (pentests) ciblés sur les flux Bedrock et exécuter des jeux de rôle d'incident réguliers.
Formation et contractualisation
- Imposer clauses de sécurité et niveaux de support dans les contrats fournisseurs.
- Former les équipes produit et sécurité aux risques d'injection de prompts et aux procédures d'escalade.
La combinaison d'un durcissement IAM, d'une isolation réseau stricte et d'une surveillance active réduit fortement la fenêtre d'opportunité pour un attaquant. Chaque jour d'inaction augmente le risque d'exposition et le coût final pour l'entreprise. Agir maintenant - revue immédiate des politiques IAM, rotations de tokens et mise en place de scénarios de tests d'injection - n'est pas une option, c'est une urgence opérationnelle¹ ² ³ ⁴.
