Exposer une application : bordure, CDN, WAF et anti-DDoS

Une application bien exposée reste privée par défaut : seule sa porte d'entrée est publique, et chaque service de bordure qu'on y ajoute répond à un problème précis. Entre Internet et votre serveur, les fournisseurs proposent une pile de services qu'on empile souvent sans savoir lequel protège de quoi. Cette page explique ce que chacun fait réellement, ce que la protection anti-DDoS incluse couvre déjà, et pourquoi un pare-feu applicatif managé bloque vos propres utilisateurs si vous l'activez brutalement. Elle s'adresse à qui doit exposer une application sur Internet sans y laisser ses machines.

Ce que vous allez apprendre

• Situer chaque service de bordure et ce dont il protège, ou pas.
• Comprendre ce que la protection anti-DDoS incluse couvre gratuitement.
• Décrire la méthode qui active un pare-feu applicatif sans bloquer votre propre trafic.
• Poser le principe « private by default » : rien n'est public, sauf la porte d'entrée.
• Placer les couches de bordure dans le bon ordre.

Prérequis

• Savoir ce qu'est un sous-réseau privé et une passerelle NAT (qui traduit les adresses privées pour sortir sur Internet) : voir Tables de routage et gateways.
• Savoir qu'un répartiteur de charge distribue le trafic entre plusieurs serveurs : cette page le cite comme porte d'entrée, et la leçon Load Balancing : répartition de charge L4, L7 et terminaison TLS du même module le détaille.

Que signifie « private by default » ?

« Private by default » veut dire qu'aucune ressource n'est joignable depuis Internet tant qu'on ne l'a pas décidé, et qu'une application exposée n'a qu'un point d'entrée public. Vos machines vivent dans un sous-réseau privé, sans adresse publique par machine ; seul le point d'entrée (un répartiteur de charge, éventuellement précédé d'un CDN) porte une adresse publique. Quand une machine doit joindre Internet ou un service managé, la sortie se fait par une passerelle NAT ou par un lien privé, jamais par une adresse publique posée sur la machine.

Ce principe réduit la surface d'attaque à une porte surveillée au lieu d'autant de portes que de machines. Il détermine aussi l'ordre des sections qui suivent : on commence par les services qui protègent cette porte d'entrée, puis on montre comment les empiler.

Que fait chaque service de bordure ?

Chacun résout un problème précis, et aucun ne remplace un autre. Les empiler tous par précaution coûte cher et complique le diagnostic ; n'en poser aucun laisse le serveur d'origine exposé directement. Le tableau ci-dessous sert de grille de décision.

Service	Ce qu'il fait réellement	Ce qu'il ne fait pas
CDN	sert le contenu depuis un point proche du visiteur, absorbe la charge des fichiers statiques	il ne protège pas d'une requête applicative malveillante
Protection anti-DDoS	absorbe un volume de trafic destiné à saturer la liaison ou la pile réseau	elle ne distingue pas une requête légitime d'une requête abusive au niveau applicatif
Pare-feu applicatif	inspecte le contenu des requêtes HTTP et bloque des motifs connus	il ne corrige pas la faille : c'est un filtre, pas un correctif
Passerelle d'API	authentifie, limite le débit par client, route vers plusieurs services	elle n'accélère rien et ajoute un intermédiaire de plus
Répartiteur de charge	distribue le trafic entre serveurs sains, termine TLS	il ne filtre pas le contenu des requêtes
Lien privé (point de terminaison privé)	fait dialoguer vos ressources avec un service managé sans passer par Internet	il ne concerne pas le trafic entrant de vos visiteurs

Glissez pour voir

Les cinq premiers traitent le trafic qui entre, le dernier traite le trafic qui sort. Cette distinction est la plus utile à retenir : on cherche d'abord à savoir de quel sens de circulation on parle, parce que les réflexes et les coûts n'ont rien à voir.

Que couvre la protection anti-DDoS incluse ?

Tous les grands fournisseurs incluent gratuitement une protection contre les attaques volumétriques, et elle suffit dans la grande majorité des cas. Elle agit sur les couches réseau et transport : inondations de paquets, amplification DNS ou NTP, saturation de la bande passante. Vous n'avez rien à activer, et vous ne verrez généralement jamais ces attaques.

Ce qui n'est pas couvert par le niveau inclus, c'est l'attaque applicative : des requêtes HTTP parfaitement formées, en apparence légitimes, mais suffisamment nombreuses pour épuiser votre base de données. Le trafic reste modeste en volume, donc invisible pour une protection volumétrique, et coûteux pour vous.

Niveau	Ce qui est traité	Ce que ça coûte
Inclus chez tous les fournisseurs	attaques volumétriques réseau et transport	rien, activé par défaut
Offre avancée du fournisseur	attaques applicatives, accompagnement pendant l'incident, protection contre la surfacturation	abonnement mensuel à quatre chiffres, souvent avec engagement annuel
Fournisseur spécialisé de bordure	même périmètre, parfois inclus dans des offres d'entrée de gamme	variable, à comparer sérieusement

Glissez pour voir

L'attaque qui vous coûte cher sans rien casser

Le danger sous-estimé n'est pas l'indisponibilité, c'est la facture. Une infrastructure élastique répond correctement à une attaque applicative : elle grossit. Vous restez en ligne, et vous découvrez le coût de cette montée en charge à la fin du mois.

C'est précisément ce que couvre la protection contre la surfacturation incluse dans les offres avancées : le fournisseur rembourse les ressources consommées pendant l'attaque qu'il a lui-même qualifiée. Sans cet engagement, l'élasticité que vous payez pour encaisser vos pics de trafic sert aussi à encaisser ceux d'un attaquant.

Deux garde-fous simples valent mieux que rien : un plafond de montée en charge sur vos groupes d'instances, et une alerte de dépassement de budget telle que décrite dans la page gouvernance et coûts.

Comment activer un pare-feu applicatif sans bloquer ses utilisateurs ?

Un pare-feu applicatif managé activé d'un clic avec ses règles par défaut bloque presque toujours du trafic légitime. Les jeux de règles génériques, dérivés du référentiel OWASP, détectent des motifs d'injection dans les paramètres de requête. Or un formulaire qui accepte du texte libre, un éditeur de contenu ou une recherche produisent naturellement des chaînes que ces règles considèrent comme suspectes.

La méthode qui évite l'incident tient en quatre temps, et le premier est celui qu'on saute :

1. Activez en mode comptage, jamais en blocage. Les règles s'évaluent et journalisent ce qu'elles auraient bloqué, sans rien empêcher. C'est le même principe que pour tout garde-fou neuf : observer avant d'interdire.

2. Laissez tourner une à deux semaines, le temps de couvrir un cycle d'usage complet, week-end et traitements mensuels compris. Un jour d'observation ne montre pas le rapport hebdomadaire qui déclenche la règle.

3. Analysez les correspondances une par une. Chacune est soit une vraie tentative, soit un usage légitime à autoriser explicitement. Une règle qui produit exclusivement des faux positifs se désactive : la garder en la contournant partout revient à ne plus rien lire.

4. Passez en blocage règle par règle, en commençant par celles qui n'ont généré aucun faux positif. Un basculement global le jour de la mise en production est la meilleure façon de perdre la confiance des équipes applicatives.

Un pare-feu applicatif est un filtre, jamais un correctif. Il achète du temps face à une vulnérabilité connue en attendant le déploiement du correctif, et il élimine le bruit de fond des scanners automatiques. Il ne rend pas sûre une application qui ne l'est pas : si vous vous en servez pour repousser indéfiniment une correction, vous avez seulement rendu la faille plus difficile à voir. Pour comprendre ce qu'un tel filtre inspecte concrètement, le guide BunkerWeb montre le même mécanisme en version auto-hébergée.

Le piège de l'adresse IP du client

Dès qu'un CDN ou un répartiteur se trouve devant votre application, l'adresse source que voit votre serveur est celle de l'intermédiaire, pas celle du visiteur. L'adresse réelle voyage dans un en-tête HTTP.

Les conséquences se cumulent et passent inaperçues longtemps : vos journaux enregistrent une poignée d'adresses au lieu de vos visiteurs, votre limitation de débit par adresse compte tout le monde comme un seul client, et vos règles de blocage par adresse ne bloquent plus personne.

Le correctif consiste à configurer chaque couche pour lire l'en-tête transmis par la couche précédente, et uniquement quand elle est bien la couche précédente. Faire confiance à cet en-tête sans vérifier qui l'a écrit permet à n'importe qui de se présenter avec l'adresse de son choix, ce qui contourne d'un coup toutes vos règles fondées sur l'adresse source.

Et la passerelle d'API, et le point de terminaison privé ?

Deux services du tableau ont leur propre leçon, parce qu'ils répondent à une décision à part. La question « une passerelle d'API apporte-t-elle quelque chose devant mon application ? » est traitée dans Faut-il une passerelle d'API devant son application cloud ?. Le service qui joint un stockage ou une base managée sans passer par Internet, et qui fait baisser la facture de passerelle NAT, est expliqué dans Point de terminaison privé : joindre un service managé sans Internet.

Dans quel ordre placer ces couches ?

L'ordre n'est pas une question de goût : chaque couche doit voir un trafic déjà nettoyé par la précédente. Placer le pare-feu applicatif derrière le CDN évite de lui faire inspecter, et donc facturer, des requêtes qui n'atteindront jamais votre origine.

visiteur
   │
   ▼
protection volumétrique       incluse, rien à placer, elle est en amont de tout
   │
   ▼
CDN                           sert le statique, absorbe l'essentiel du volume
   │
   ▼
pare-feu applicatif           inspecte ce qui reste, c'est-à-dire le dynamique
   │
   ▼
répartiteur de charge         termine TLS, choisit un serveur sain
   │
   ▼
vos machines                  sous-réseau privé, aucune adresse publique
   │
   ▼
lien privé  ───────────────►  stockage objet, base managée, gestionnaire de secrets

La dernière ligne, celle du lien privé, est celle qu'on oublie de dessiner. Une architecture de bordure soignée à l'entrée mais dont les machines sortent sur Internet par une passerelle NAT pour joindre le stockage du même fournisseur est incohérente : elle protège la porte et laisse la fenêtre ouverte, en payant le transit deux fois.

Une vérification s'impose enfin sur le serveur d'origine : il doit refuser tout trafic qui ne vient pas de la couche précédente. Sans cette règle, un attaquant qui découvre son adresse publique, ce qui est facile avec un historique de certificats, contourne l'intégralité de la pile que vous venez de construire.

À retenir

• Aucun service de bordure ne remplace un autre. Le CDN sert le contenu, la protection anti-DDoS absorbe le volume, le pare-feu applicatif inspecte les requêtes.
• La protection anti-DDoS incluse couvre déjà les attaques volumétriques, et elle suffit dans la grande majorité des cas.
• Ce que le niveau gratuit ne couvre pas, c'est l'attaque applicative, qui ne casse rien et gonfle la facture par élasticité.
• Un pare-feu applicatif s'active en mode comptage, pendant une à deux semaines, puis règle par règle. L'activer d'un coup bloque vos propres utilisateurs.
• Un pare-feu applicatif est un filtre, pas un correctif. Il achète du temps, il ne corrige pas la faille.
• Derrière un intermédiaire, l'adresse source vue par le serveur n'est plus celle du visiteur, ce qui casse silencieusement journaux, limitation de débit et blocages.
• Private by default : aucune adresse publique par machine, une seule porte d'entrée publique.
• Une passerelle d'API et un point de terminaison privé répondent à des décisions à part, traitées dans leurs propres leçons.
• L'origine doit refuser tout ce qui ne vient pas de la couche précédente, sinon toute la pile se contourne par son adresse publique.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →