Comment créer un groupe de sécurité autorisant uniquement le trafic provenant de CloudFront ?

Pourquoi la question « Comment créer un groupe de sécurité autorisant uniquement le trafic provenant de CloudFront ? » revient sans cesse en AWS, ce qu’elle révèle sur les limites du modèle réseau, et comment y répondre correctement en production.

Comment créer un groupe de sécurité autorisant uniquement le trafic provenant de CloudFront ?  

Pourquoi cette question revient toujours  

Dans l’univers AWS, certaines questions reviennent avec une régularité frappante.
Non pas parce qu’elles sont mal formulées, mais parce qu’elles mettent le doigt sur une tension réelle entre sécurité, réseau et architecture applicative.

À première vue, la question semble simple, presque triviale.
En réalité, elle révèle une excellente intuition d’architecture… et une limite structurelle du modèle réseau AWS.

I. D’où vient cette question ?  

Cette question apparaît presque toujours dans les mêmes scénarios concrets :

• Une application est exposée via :contentReference[oaicite:0]{index=0}
• L’origine est un Application Load Balancer (ALB), une instance EC2, un service ECS, ou parfois une API interne
• On souhaite éviter absolument que cette origine soit accessible directement depuis Internet

Le raisonnement sous-jacent est parfaitement sain :

« Si tout le trafic passe par CloudFront, alors mon backend ne devrait accepter que CloudFront. »

La réponse instinctive est donc logique :

« Je vais restreindre mon groupe de sécurité à CloudFront uniquement. »

C’est précisément à cet instant que le problème apparaît.

II. Le malentendu fondamental : CloudFront n’est pas une IP  

Un :contentReference[oaicite:1]{index=1} fonctionne avec :

• des plages IP (CIDR)
• ou des références à d’autres security groups

Or CloudFront :

• n’a pas d’adresse IP fixe
• utilise des centaines de plages IP
• réparties à l’échelle mondiale
• qui évoluent régulièrement

Il est donc impossible d’exprimer dans un security group :

« Autorise uniquement CloudFront »

Sans :

• ouvrir un nombre massif de CIDR
• maintenir une liste mouvante et fragile
• ou créer une illusion de sécurité

III. Pourquoi ouvrir 0.0.0.0/0 est une fausse solution  

Dans de nombreux projets, on finit par trouver une règle du type :

Inbound: 443 from 0.0.0.0/0

Avec un raisonnement souvent résumé ainsi :

« De toute façon, seuls les clients passent par CloudFront. »

En pratique, cela signifie pourtant :

• accès direct possible à l’ALB
• bypass complet du CDN
• contournement du cache
• exposition directe aux attaques
• appels backend hors CloudFront, et donc coûts inutiles

CloudFront devient optionnel, ce qui annule une grande partie de sa valeur.

IV. Ce que révèle cette question  

Cette question est intéressante parce qu’elle met en évidence plusieurs réalités souvent sous-estimées :

• le filtrage réseau ne suffit pas toujours
• la sécurité ne peut pas être basée uniquement sur l’IP
• il faut parfois changer de couche de contrôle

Autrement dit :

• le vrai problème n’est pas « comment écrire le security group »
• le vrai problème est « comment prouver que la requête vient bien de CloudFront »

Une fois cette reformulation faite, les solutions deviennent claires.

V. Les solutions qui tiennent en production  

1.Validation applicative via un header secret  

(le pattern le plus courant)

CloudFront permet d’ajouter un header personnalisé aux requêtes envoyées à l’origine, par exemple :

X-Origin-Secret: s3cr3t-value

Côté ** Application Load Balancer** ou application :

• toute requête sans ce header est rejetée
• le backend devient inaccessible sans CloudFront

Avantages :

• ✔ simple à mettre en place
• ✔ très efficace
• ✔ compatible avec ALB, ECS, EC2

2. AWS WAF comme « gardien » de l’origine  

Avec AWS WAF :

• attaché à CloudFront à l’ALB
• règles strictes sur headers, méthodes, comportements
• protection contre bots, scans, attaques automatisées et DDoS

Avantages :

• sécurité centralisée
• règles déclaratives et auditées
• observabilité native

C’est souvent la solution privilégiée en contexte entreprise ou compliance.

3. Cas particulier : S3 avec OAI / OAC  

Quand l’origine est un bucket Amazon S3 :

• OAI / OAC permettent un accès exclusivement via CloudFront
• aucune IP à gérer
• aucune règle réseau
• sécurité entièrement gérée par AWS

C’est le gold standard pour les sites statiques.

VI. Pourquoi cette question est un bon signal  

Très honnêtement, cette question est rarement posée par hasard.

Elle indique que la personne :

• raisonne en surface d’attaque
• anticipe les scénarios de bypass
• comprend les impacts sécurité et coûts
• cherche une architecture robuste, pas seulement fonctionnelle

Conclusion  

La question :

« Comment créer un groupe de sécurité autorisant uniquement le trafic provenant de CloudFront ? »

est intéressante parce qu’elle :

• part d’une excellente intuition
• révèle une limite structurelle d’AWS
• oblige à changer de niveau de raisonnement
• mène à de meille

La bonne réponse n’est pas :

« Voilà le bon CIDR »

La bonne réponse est :

« Le contrôle doit se faire ailleurs que dans le security group. »

Et c’est exactement ce qui fait toute la différence entre
une infrastructure qui marche
et une infrastructure qui tient dans le temps.

🔗 Ressources utiles  

• CloudFront_ Sécuriser l’accès à l’origine
• AWS WAF – Concepts et cas d’usage