AWS Machine Learning Blog→ original

AWS a présenté deux patterns de protection WAF pour Amazon Bedrock AgentCore Runtime

AWS a publié un guide avec deux patterns architecturaux pour protéger Amazon Bedrock AgentCore Runtime via AWS WAF. La première option ajoute un proxy Lambda entre l'équilibreur de charge et le VPC Endpoint, pour une transformation souple des requêtes. La seconde cible directement les adresses IP de l'ENI, supprimant un saut supplémentaire. Une politique de ressources avec la condition aws:SourceVpce bloque le contournement direct du WAF. Les deux patterns ont été testés avec l'authentification SigV4 et OAuth via Amazon Cognito JWT.

Traité par IA depuis AWS Machine Learning Blog ; édité par Hamidun News
AWS a présenté deux patterns de protection WAF pour Amazon Bedrock AgentCore Runtime
Source : AWS Machine Learning Blog. Collage: Hamidun News.
◐ Écouter l'article

AWS a publié deux modèles architecturaux pour protéger les agents IA dans Amazon Bedrock via AWS WAF, testés avec l'authentification SigV4 et OAuth via Amazon Cognito JWT.

Pourquoi AgentCore Runtime a besoin de la protection WAF

AgentCore Runtime—un composant d'Amazon Bedrock pour exécuter des agents IA en production—n'a pas de filtrage intégré au niveau des applications web par défaut. Sans architecture supplémentaire, un attaquant peut agresser l'agent avec des injections, des DDoS ou une contrefaçon de demandes en accédant directement au service.

AWS WAF (Pare-feu d'applications web) vous permet de bloquer les vecteurs d'attaque connus, de limiter le débit de demandes et d'appliquer des groupes de règles gérés avant que la demande n'atteigne l'agent. Les deux modèles présentés utilisent un équilibreur de charge d'application (ALB) accessible sur Internet avec AWS WAF attaché et acheminent le trafic via un point de terminaison VPC Interface vers AgentCore Runtime.

Paramètres clés des deux solutions :

  • ALB est exposé à Internet, AWS WAF inspecte chaque demande entrante
  • Le trafic est dirigé via le point de terminaison VPC Interface vers AgentCore Runtime
  • La politique de ressources interdit le contournement direct du WAF
  • L'authentification SigV4 et OAuth (Amazon Cognito JWT) est prise en charge
  • Les deux modèles sont testés dans des scénarios de bout en bout

Modèle 1 par rapport au Modèle 2 : quelle est la différence

Le Modèle 1 place AWS Lambda entre ALB et le point de terminaison VPC dans un rôle de proxy. La fonction reçoit la demande après filtrage WAF, peut la transformer—ajouter des en-têtes, normaliser les chemins, modifier le corps—puis la transmet à AgentCore via le point de terminaison VPC Interface. Cela offre un contrôle maximal du trafic, particulièrement utile si la logique de transformation de requêtes ou la validation supplémentaire avant l'agent est nécessaire. Le coût est une latence supplémentaire et les coûts d'invocation de Lambda.

Le Modèle 2 élimine complètement le saut de Lambda : ALB adresse directement les adresses IP des ENI (Elastic Network Interfaces) sur le point de terminaison VPC Interface. C'est un schéma plus simple avec une latence inférieure et sans frais généraux Lambda. Convient lorsque la transformation de demande n'est pas nécessaire et que la minimisation de la latence tout en maintenant la protection WAF est la priorité.

«

Les deux modèles sont testés de bout en bout avec l'authentification SigV4 et OAuth (Amazon Cognito JWT) », note AWS dans le blog Machine Learning.

Comment fermer la porte dérobée par le biais de la politique de ressources

La partie la plus critique des deux modèles est la configuration correcte de la politique de ressources d'AgentCore Runtime. Sans elle, la protection WAF perd son sens : un attaquant peut découvrir le point de terminaison public d'AgentCore et l'appeler directement, contournant complètement ALB et WAF.

La solution est la condition `aws:SourceVpce` dans la politique de ressources. Elle autorise les appels à AgentCore uniquement via un point de terminaison VPC Interface spécifique, garantissant que tout le trafic passe par ALB et AWS WAF. La porte dérobée directe est fermée au niveau de la politique IAM.

Cette approche met en œuvre la défense en profondeur : WAF est la première ligne de filtration, la politique de ressources est la seconde, empêchant le contournement de la première.

Ce que cela signifie

Les conseils AWS offrent aux développeurs d'agents IA sur Bedrock des modèles prêts et testés au lieu de réinventer eux-mêmes les schémas de protection. Le choix entre eux est simple : si la transformation de requête est nécessaire—Modèle 1 avec Lambda ; si la vitesse et la simplicité sont prioritaires—Modèle 2 avec un routage direct vers ENI.

Questions fréquemment posées

Quelles méthodes d'authentification les deux modèles prennent-ils en charge ?

Les deux modèles sont testés avec AWS SigV4 (signature de demande via les clés d'accès AWS) et OAuth avec les jetons Amazon Cognito JWT. Le choix dépend de l'architecture de votre application.

Pourquoi WAF seul est-il insuffisant sans politique de ressources ?

AWS WAF protège uniquement le trafic passant par ALB. Si vous ne fermez pas l'accès direct au point de terminaison d'AgentCore avec une politique de ressources utilisant la condition `aws:SourceVpce`, un attaquant peut contourner WAF en accédant directement à AgentCore via son adresse publique.

Pourquoi

Amazon Bedrock AgentCore Runtime est-il vulnérable sans WAF ?

AgentCore Runtime n'a pas de filtrage intégré au niveau des applications web par défaut. Sans architecture supplémentaire, un attaquant peut agresser l'agent avec des injections, des DDoS ou une contrefaçon de demandes.

ZK
Hamidun News
Actualités IA sans bruit. Sélection éditoriale quotidienne de plus de 50 sources. Produit de Zhemal Khamidun, Head of AI chez Alpina Digital.

Vous voulez cesser de lire sur l'IA et commencer à l'utiliser?

AI News est un fil d'actualité IA. Hamidun Academy vous apprend à utiliser l'IA dans votre travail.

Qu'en pensez-vous ?
Chargement des commentaires…