CloudFront joue deux rôles dans notre infrastructure : accélérer la distribution des assets et des médias uploadés par les membres, et servir de point d'entrée unique devant lequel AWS WAF inspecte tout le trafic entrant. Les deux fonctions sont indissociables dans notre setup.

L'architecture : CloudFront devant l'application

La plateforme tourne sur AWS, en région eu-west-3 (Paris) : l'application PHP est déployée avec AWS Elastic Beanstalk sur des instances EC2, derrière un Application Load Balancer. En production, tout le trafic des utilisateurs passe par la distribution CloudFront, qui joue le rôle de reverse proxy et de CDN devant cette origine. Le certificat ACM et le WAF de la distribution sont déclarés en us-east-1, la région qu'AWS impose pour les ressources associées à CloudFront.

La distribution sépare trois familles de contenus :

  • Fichiers statiques (CSS, JS, fonts) : TTL long. CloudFront les met en cache dans ses edge locations, et l'origine est libérée de ces ressources.
  • Médias des membres : les photos sont stockées dans Amazon S3 et servies par CloudFront grâce à l'Origin Access Control (OAC). Les buckets restent privés, avec l'accès public bloqué : CloudFront est la seule porte d'accès aux fichiers.
  • Pages dynamiques : transmises à l'origine à chaque requête, pour que le PHP s'exécute normalement.

Cette séparation réserve la puissance de calcul de l'application aux pages dynamiques et rapproche les images de chaque utilisateur.

Verrouiller l'origine

Pour que le WAF reste incontournable, les serveurs applicatifs sont fermés à l'accès direct depuis Internet : le trafic entre par la distribution CloudFront, et donc par le WAF.

AWS WAF : les règles managées

Le WAF est attaché à la distribution CloudFront sous forme d'une Web ACL. Les règles sont évaluées dans l'ordre de priorité ; la première règle qui matche détermine l'action (allow, block, count, challenge).

Nous activons des groupes de règles maintenus par AWS, qui couvrent :

  • La réputation des adresses IP : botnets, scrapers connus et sources malveillantes répertoriées par AWS.
  • Les exploits connus : patterns d'exploitation de vulnérabilités publiques.
  • Les injections : SQL, XSS, path traversal, injection de headers.
  • Les attaques propres à notre pile technique.
  • Les attaques par déni de service de couche 7, avec une détection et une atténuation gérées par AWS.

Ces groupes sont mis à jour par AWS en continu. La sélection colle à notre pile réelle, ce qui concentre l'inspection sur les attaques qui la concernent.

Restriction géographique

Une restriction géographique s'applique à l'ensemble de la distribution, à partir d'une liste de pays. Elle aligne l'accès à la plateforme sur les pays où nos clients et leurs membres se trouvent réellement.

Logs WAF et visibilité

Les journaux du WAF sont envoyés dans Amazon CloudWatch Logs, aux côtés des autres journaux de la plateforme. Chaque requête évaluée y figure avec la règle déclenchée et l'action appliquée.

Ces logs permettent de :

  • Détecter des patterns d'attaque ciblant des endpoints spécifiques
  • Identifier les faux positifs et ajuster une règle en connaissance de cause
  • Corréler des pics de trafic avec des règles déclenchées

CloudWatch Logs Insights permet de les interroger en quelques secondes, ce qui rend l'investigation aussi rapide que la détection.

AWS Shield

CloudFront inclut AWS Shield Standard sans coût supplémentaire. Il assure une protection contre les attaques volumétriques DDoS de couche 3 et 4 (flood UDP/TCP, SYN flood). Pour la couche 7 (HTTP flood), c'est le WAF qui prend le relais avec la protection anti-DDoS gérée par AWS.

Shield Advanced reste disponible en option pour un niveau de protection supérieur, avec support DDoS dédié et absorption de coûts en cas d'attaque.

← Back to blog