Entre Internet et votre serveur, les fournisseurs proposent une pile de services de bordure 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à, pourquoi un pare-feu applicatif managé bloque vos propres utilisateurs si vous l'activez brutalement, et pourquoi les liens privés sont le service de cette liste dont l'effet le plus direct est de faire baisser la facture au lieu de l'augmenter.
Ce que vous allez apprendre
Section intitulée « 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éployer un pare-feu applicatif sans bloquer votre propre trafic.
- Décider si une passerelle d'API vous apporte quelque chose.
- Utiliser un point de terminaison privé, qui réduit risque et facture.
Que fait chaque service de bordure ?
Section intitulée « 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é | fait dialoguer vos ressources avec un service managé sans passer par Internet | il ne concerne pas le trafic entrant de vos visiteurs |
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 ?
Section intitulée « 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 |
Comment activer un pare-feu applicatif sans bloquer ses utilisateurs ?
Section intitulée « 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 :
-
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 l'équivalent du mode observation des garde-fous de gouvernance, et pour la même raison.
-
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.
-
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.
-
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.
Faut-il une passerelle d'API ?
Section intitulée « Faut-il une passerelle d'API ? »Une passerelle d'API se justifie quand plusieurs services distincts doivent être exposés derrière une seule adresse, avec une authentification et des quotas par client. Dans ce cas précis, elle évite de réimplémenter la même logique dans chaque service, et c'est un vrai gain.
Elle ne se justifie pas quand vous exposez une seule application web. Un répartiteur de niveau 7 fait déjà le routage et la terminaison TLS ; ajouter une passerelle devant lui rajoute une latence, un point de panne et une ligne de facture pour un service qui ne rend aucun service supplémentaire.
| Votre situation | La bonne réponse |
|---|---|
| Une application web servie à des navigateurs | répartiteur de niveau 7, rien de plus |
| Une API publique avec des clés par client et des quotas | passerelle d'API, c'est son cas d'usage |
| Plusieurs microservices exposés sous un domaine unique | passerelle d'API, ou un routage applicatif si le nombre reste faible |
| Des fonctions serverless appelées en HTTP | passerelle d'API, souvent imposée par le fournisseur |
Attention à la tarification, qui n'a rien à voir avec celle d'un répartiteur. Une passerelle d'API se facture à la requête, un répartiteur à l'heure et au volume traité. Pour un service à fort trafic et petites réponses, l'écart de facture entre les deux se compte en ordres de grandeur, et il joue contre la passerelle.
À quoi sert un point de terminaison privé ?
Section intitulée « À quoi sert un point de terminaison privé ? »Un point de terminaison privé fait dialoguer vos machines avec un service managé sans que le trafic sorte sur Internet. C'est le service de cette page qui améliore simultanément la sécurité, la latence et la facture, ce qui en fait le plus rentable et le moins connu.
Le problème qu'il résout est invisible tant qu'on ne le regarde pas. Une machine placée dans un sous-réseau privé qui écrit dans le stockage objet du même fournisseur passe, par défaut, par la passerelle NAT puis par l'Internet public, avant de revenir chez le fournisseur. Le trafic ne quitte pas vraiment son réseau, mais il est traité, et donc facturé, comme s'il le faisait.
| Sans point de terminaison privé | Avec |
|---|---|
| le trafic traverse la passerelle NAT | il reste dans le réseau du fournisseur |
| chaque gigaoctet est facturé au traitement NAT | ce traitement disparaît de la facture |
| le service managé est joint par son adresse publique | il est joint par une adresse de votre réseau privé |
| l'accès dépend d'une route vers Internet | il fonctionne sans aucune route sortante |
Deux familles coexistent, et elles ne fonctionnent pas du tout de la même façon. La distinction n'est pas un détail de tarification : elle change ce que vous devez configurer, et surtout ce que vous devez vérifier.
| Famille « route » | Famille « interface » | |
|---|---|---|
| Ce qui est créé | une entrée dans la table de routage | une carte réseau dans votre sous-réseau |
| Adresse du service | reste publique, le nom résout comme avant | devient une adresse privée de votre plage |
| Ce qui dévie le trafic | le routage, vers une liste de préfixes du fournisseur | le DNS, qui renvoie l'adresse privée |
| Portée | souvent limitée au stockage objet | l'ensemble des services managés |
| Facturation | fréquemment gratuite | à l'heure et au volume |
| Franchit-il une interconnexion ? | non, il est local au réseau | oui, joignable depuis un réseau appairé ou une liaison privée |
La première est le gain le plus facile à obtenir sur une facture : elle ne coûte rien et supprime le traitement de la passerelle NAT sur le trafic vers le stockage. La seconde reste rentable dès que le volume est significatif, mais elle mérite un calcul, puisqu'elle a son propre coût horaire.
Dans quel ordre placer ces couches ?
Section intitulée « 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 secretsLa dernière ligne 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
Section intitulée « À 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.
- Une passerelle d'API ne se justifie pas devant une simple application web : elle se facture à la requête, contrairement à un répartiteur.
- Un point de terminaison privé peut faire baisser la facture en supprimant le traitement NAT sur le trafic vers les services managés. Vérifiez le sens du calcul chez votre fournisseur : certains points de terminaison sont eux-mêmes facturés à l'heure et au volume, et le gain n'apparaît qu'au-delà d'un certain trafic.
- 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.