CloudFront avec WAF et Lambda@Edge

AWS WAF (pare-feu d’applications Web) filtre et surveille les requêtes HTTP/HTTPS qui atteignent votre distribution CloudFront. En associant une ACL Web WAF à votre distribution, vous pouvez bloquer les attaques Web courantes, telles que l’injection SQL, les scripts intersites (XSS), les robots malveillants et les attaques du Top 10 OWASP, avant qu’elles n’atteignent votre origine.

WAF fonctionne à la périphérie CloudFront : les requêtes malveillantes sont donc rejetées depuis l’emplacement périphérique le plus proche au lieu d’atteindre votre ALB ou votre serveur d’application. Cela réduit la charge de votre backend et arrête les attaques plus près de leur auteur.

Une ACL Web WAF contient des règles et des groupes de règles ordonnés. Chacun compare les attributs des requêtes et applique une action (Allow, Block, Count ou CAPTCHA). Les règles sont évaluées par ordre de priorité ; l’action de la première règle correspondante est appliquée.

AWS fournit des groupes de règles gérés : il s’agit d’ensembles de règles prédéfinis et gérés par AWS et les vendeurs d’AWS Marketplace. L’ensemble AWS Managed Rules - Core Rule Set couvre le Top 10 OWASP sans aucune configuration. AWS met à jour les groupes de règles gérés lorsque de nouvelles menaces apparaissent, ce qui réduit votre charge opérationnelle.

Les règles fondées sur le débit de WAF comptent les requêtes provenant de chaque adresse IP source sur une période de 5 minutes. Si une adresse IP dépasse le seuil (par exemple, 2 000 requêtes en 5 minutes), WAF bloque les requêtes supplémentaires provenant de cette adresse jusqu’à ce que le débit diminue. Les règles fondées sur le débit protègent contre les attaques par force brute, le bourrage d’identifiants et les attaques simples d’extraction de données par DDoS.

AWS WAF Bot Control est un groupe de règles géré qui classe le trafic en plusieurs catégories : robots vérifiés (Googlebot, Bingbot), extracteurs de données, outils de surveillance et trafic humain. Vous pouvez configurer des actions différentes pour chaque catégorie : autoriser les robots des moteurs de recherche, soumettre les robots inconnus à un défi CAPTCHA et bloquer les extracteurs malveillants.

Les ACL Web WAF ont pour portée CLOUDFRONT (globale, pour une utilisation avec CloudFront) ou REGIONAL (pour une utilisation avec ALB, API Gateway, AppSync ou les groupes d’utilisateurs Cognito dans une Region précise). Les ACL WAF dont la portée est CloudFront doivent être créées dans la Region us-east-1, quel que soit l’endroit d’où provient le trafic, car CloudFront est géré depuis cette Region.

Il s’agit d’un piège d’examen important : si vous créez une ACL Web WAF dans eu-west-1 et tentez de l’associer à CloudFront, l’association échoue. Créez toujours les ACL WAF CloudFront dans us-east-1.

Lambda@Edge vous permet d’exécuter des fonctions Lambda Node.js ou Python dans les emplacements périphériques CloudFront en réponse aux événements CloudFront. Les fonctions s’exécutent quelques millisecondes après la requête de l’utilisateur, sans acheminer le trafic vers une Region centrale pour le traitement.

Les fonctions Lambda@Edge sont déployées dans la Region us-east-1, puis automatiquement répliquées vers tous les emplacements périphériques CloudFront dans le monde. Ainsi, votre code s’exécute aussi près que possible de l’utilisateur, ce qui permet la personnalisation, l’authentification et les tests A/B à la périphérie avec une surcharge de latence minimale.

Les fonctions Lambda@Edge peuvent intercepter les requêtes et les réponses CloudFront à quatre points du cycle de vie :

• Viewer Request : après que CloudFront a reçu la requête du visiteur et avant la vérification du cache ; à utiliser pour l’authentification, les redirections et la manipulation des en-têtes
• Origin Request : après un échec de recherche dans le cache et avant la transmission à l’origine ; à utiliser pour la réécriture d’URL et l’ajout d’en-têtes personnalisés à destination de l’origine
• Origin Response : après réception de la réponse de l’origine et avant sa mise en cache ; à utiliser pour ajouter des en-têtes de sécurité et modifier la réponse
• Viewer Response : avant que CloudFront n’envoie la réponse au visiteur ; à utiliser pour ajouter ou modifier les en-têtes de réponse

AWS propose deux options de calcul en périphérie présentant des compromis différents :

• CloudFront Functions : exécution en moins d’une milliseconde, JavaScript uniquement, coût extrêmement faible (environ 1/6 du prix), exécution uniquement lors des événements Viewer Request et Viewer Response, durée limite de calcul de 1 ms, aucun accès au VPC ou au réseau
• Lambda@Edge : durée d’exécution pouvant atteindre 30 secondes (Viewer) ou 30 secondes (Origin), Node.js ou Python, quatre points de déclenchement, possibilité d’effectuer des requêtes réseau et accès au corps des requêtes et des réponses

Utilisez CloudFront Functions pour la manipulation simple des en-têtes, la normalisation des URL et le calcul de la clé de cache. Utilisez Lambda@Edge pour une logique complexe nécessitant des appels réseau, des calculs plus longs ou un traitement côté origine.

Modèles courants de Lambda@Edge à l’examen SAA-C03 :

• Validation des JWT à la périphérie : une fonction Viewer Request valide un en-tête d’autorisation ; les requêtes non autorisées renvoient une erreur 401 sans atteindre l’origine
• Tests A/B : Viewer Request affecte les utilisateurs au groupe A ou B (au moyen d’un cookie) et modifie la requête pour récupérer /a/page.html ou /b/page.html
• Réécriture d’URL : Origin Request réécrit les URL lisibles en chemins de fichiers réels dans S3
• Redimensionnement dynamique d’images : Origin Request construit une requête vers une fonction Lambda de traitement d’images ; Origin Response met en cache l’image redimensionnée
• En-têtes de sécurité HTTP : Viewer Response insère les en-têtes CSP, HSTS et X-Frame-Options

Lambda@Edge présente plusieurs restrictions par rapport à Lambda standard :

• Les fonctions doivent se trouver dans la région us-east-1
• Pas de prise en charge de VPC (impossible d’accéder aux ressources d’un VPC)
• Pas de variables d’environnement (intégrez la configuration au code de la fonction ou récupérez-la depuis Parameter Store au démarrage à froid)
• Impossible d’utiliser les couches Lambda
• Délai d’expiration des événements du visualiseur : 5 secondes ; délai d’expiration des événements d’origine : 30 secondes
• Limite de taille du paquet de déploiement : 1 Mo (événements du visualiseur) / 50 Mo (événements d’origine)

Ces limitations rendent Lambda@Edge inadapté aux calculs de longue durée, aux opérations dépendant d’un VPC ou aux fonctions qui nécessitent une configuration dynamique pour chaque déploiement.

WAF et Lambda@Edge jouent des rôles de sécurité différents et se complètent :

• WAF : blocage des attaques basé sur des signatures (injection SQL, XSS, acteurs malveillants connus, limitation du débit) — les règles gérées traitent automatiquement les attaques courantes
• Lambda@Edge : logique de sécurité métier personnalisée (validation des JWT, vérification des sessions, vérification des jetons d’accès) — solution flexible, mais qui demande un effort de développement

Une architecture de défense en profondeur : WAF bloque d’abord les schémas d’attaque connus : Lambda@Edge valide l’authentification au niveau métier : les URL et cookies signés de CloudFront limitent l’accès au contenu : OAC conserve S3 privé. Chaque couche empêche indépendamment une classe différente d’attaques.

Surveillez votre couche de sécurité périphérique à l’aide de ces outils :

• Journaux WAF : activez la journalisation complète des demandes vers S3, CloudWatch Logs ou Kinesis Firehose pour voir quelles règles correspondent et quel trafic est bloqué
• Métriques WAF : BlockedRequests, AllowedRequests, CountedRequests par règle dans CloudWatch
• Journaux Lambda@Edge : des groupes CloudWatch Logs sont créés dans chaque région où la fonction s’exécute ; utilisez CloudWatch Insights pour effectuer des requêtes entre les régions
• Journaux en temps réel de CloudFront : diffusez les journaux d’accès vers Kinesis pour une analyse immédiate (contrairement aux journaux d’accès standard, regroupés toutes les quelques minutes)

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris que AWS WAF bloque les attaques web courantes à la périphérie de CloudFront à l’aide de groupes de règles gérés et personnalisés, que Lambda@Edge exécute du code personnalisé à quatre points de déclenchement de CloudFront dans le monde entier et que CloudFront Functions offre une exécution en moins d’une milliseconde pour une logique simple côté visualiseur. Les ACL WAF pour CloudFront doivent être créées dans us-east-1. Ensuite, nous étudierons les équilibreurs de charge d’application, de réseau et de passerelle.