Une API publique s'exécute en tant que tâches Amazon ECS sur AWS Fargate derrière un Application Load Balancer (ALB). Le dimensionnement automatique du service (Service Auto Scaling) dimensionne les tâches en fonction de l'utilisation du CPU. Récemment, une vague d'attaques par injection SQL a provoqué le dimensionnement maximal du service et l'API est devenue inutilisable. L'architecte doit empêcher les attaques par injection SQL d'atteindre le service ECS, autoriser le trafic légitime et maximiser l'efficacité opérationnelle. Quelle solution répond à ces exigences ?

L'option correcte est de créer une nouvelle ACL web AWS WAF, d'ajouter une règle bloquant les requêtes correspondant au groupe de règles de base de données SQL, et de l'attacher à l'ALB. AWS WAF est conçu pour protéger les applications web contre les exploits courants, y compris les injections SQL, en filtrant le trafic malveillant avant qu'il n'atteigne le service ECS. Le groupe de règles géré "SQL database" contient des règles prédéfinies pour détecter et bloquer les tentatives d'injection SQL, ce qui répond directement à l'exigence de bloquer ces attaques et maximise l'efficacité opérationnelle en utilisant une solution gérée. L'option de surveiller les requêtes HTTP et HTTPS est trop générale et ne bloque pas spécifiquement les injections SQL. L'implémentation d'AWS WAF Bot Control est utile pour gérer le trafic des bots, mais ne cible pas directement les attaques d'injection SQL. La création d'une fonction Lambda pour analyser les journaux et bloquer les adresses IP est une approche réactive et moins efficace, car les attaquants peuvent changer d'adresses IP, et elle ne protège pas contre les premières tentatives d'attaque.