Fastly Next-Gen WAF : tutoriel pour une application progressive et sûre

Publié le

14 juil. 2026

Temps de lecture

12 min de lecture

Fastly Next-Gen WAF peut identifier des signaux dans les requêtes et appliquer des actions par la configuration de politiques et de règles. Il ne remplace pas l'autorisation applicative, la validation des entrées, la protection de l'origine ni la réponse aux incidents. Traitez-le comme un contrôle de sécurité qui nécessite un responsable, un périmètre testé, une télémétrie utile et une application progressive.

Prérequis

Préparez les éléments suivants avant de modifier le comportement du WAF :

• L'accès au compte ou à l'espace de travail Fastly Next-Gen WAF propriétaire du site cible, ainsi que les propriétaires du service et de l'application capables de valider le trafic.
• Un inventaire à jour des domaines, chemins, API, points d'administration, intégrations approuvées, méthodes de déploiement et protections contre le contournement de l'origine.
• Une référence du trafic légitime : parcours utilisateur critiques, clients API, plages IP partenaires lorsque cela est justifié, trafic navigateur et bot, méthodes attendues et codes de réponse normaux.
• Une destination de logs ou une vue des événements WAF avec rétention, contrôle d'accès, horodatages, corrélation des requêtes et un processus d'examen des faux positifs.
• Un opérateur de restauration nommé et une courte procédure pour désactiver ou restreindre la politique ou règle candidate.

Ne collez pas d'identifiants de production, cookies de session, en-têtes d'authentification, données de paiement, données personnelles brutes ni corps de requête client réels dans un simulateur, ticket, webhook ou chat. Utilisez des valeurs synthétiques et masquez les échantillons avant de les partager.

1. Établir le périmètre de la politique avant d'ajuster les détections

Créez ou sélectionnez la politique qui protège le site et le déploiement visés, en suivant la documentation Fastly sur les politiques Next-Gen WAF. Vérifiez la couverture réelle avec une requête contrôlée et les logs ; le seul nom d'une politique ne prouve pas que le nom d'hôte, le chemin de trafic ou l'intégration sont protégés.

Pour chaque politique, consignez :

• Les domaines et environnements qu'elle protège, et si la politique correspond à la production, au staging ou à un canari limité.
• Le déploiement et le chemin de requête, y compris le proxy ou service qui transmet le trafic au WAF.
• Le propriétaire de l'application, le responsable de la sécurité, les profils de trafic attendus et les flux métier protégés.
• Le responsable du changement, la fenêtre de revue, les métriques de succès et l'action de restauration.

Gardez les périmètres de développement, de staging et de production distincts. Une exception de test d'intégration permissive ou un endpoint de test bruyant ne doit pas devenir une exclusion de production non revue. Si une même application doit être traitée différemment par nom d'hôte ou route, définissez et vérifiez explicitement les limites plutôt que de supposer un héritage de politique.

2. Comprendre les signaux et le périmètre des exclusions

Les signaux sont des étiquettes que Fastly utilise pour des propriétés de requêtes associées à des attaques, anomalies, bots, API ou autres comportements. La détection des signaux et la réponse sont des décisions distinctes. Fastly indique que certains signaux système, dont les signaux de correctif virtuel CVE, API et de prise de contrôle de compte, doivent être activés avant de pouvoir être utilisés. Consultez Configurer les signaux système et Utiliser les signaux système.

Commencez par observer un petit ensemble de signaux pertinents pour la menace sur une route étroite. Comparez les signaux aux parcours connus comme fiables et à l'automatisation attendue. Consignez la forme de la requête, le signal, l'action, la réponse et l'effet métier, pas seulement le nombre.

Utilisez une exclusion de signal uniquement pour empêcher qu'un faux positif précis et compris soit étiqueté par un signal précis. Ce n'est pas une liste d'autorisation générale et elle peut réduire la détection future sur chaque requête correspondant à ses conditions. Le guide des règles d'exclusion de signal de Fastly explique que les exclusions empêchent les requêtes correspondantes d'être étiquetées avec le signal système spécifié.

Rendez les exclusions aussi étroites que possible :

• Liez l'exclusion au seul signal qui a produit le faux positif.
• Limitez-la à des attributs stables qui expriment le cas sûr connu, comme un chemin et une méthode étroitement bornés, plutôt qu'à un site entier ou une chaîne user-agent large.
• Définissez un responsable, une raison, une date de création, un lien vers les preuves et une date de revue. Supprimez-la lorsque le comportement applicatif ou la détection est corrigé.
• Testez à nouveau la requête légitime visée et une requête malveillante ou malformée voisine afin que l'exception ne masque pas la classe de menace.

Fastly prend en charge les conditions de règle fondées sur les champs de requête et, pour les exclusions de signal, sur les champs propres au signal. Examinez les champs et opérateurs disponibles dans Définir les conditions de règle avant de fonder une protection sur un en-tête de proxy peu fiable ou un chemin à correspondance lâche.

3. Ajouter des règles de requête pour des décisions spécifiques et explicables

Utilisez une règle de requête lorsque vous pouvez énoncer en une phrase la condition, l'action visée, la population affectée et la condition de restauration. Par exemple : « Journaliser les requêtes vers cet endpoint obsolète avec cette méthode impossible pendant que nous confirmons qu'aucun client n'en dépend. » Ne commencez pas par un blocage global fondé uniquement sur un user-agent, un pays ou un en-tête non validé.

Fastly décrit les règles de requête comme des conditions de requête arbitraires associées à des actions WAF. Les actions et leur disponibilité peuvent différer selon les fonctionnalités du compte et le déploiement ; utilisez donc la documentation actuelle Travailler avec les règles de requête et À propos des règles plutôt que de copier une recette de configuration universelle.

Pour chaque règle de requête :

1. Définissez la plus petite combinaison de route, méthode, domaine ou signal qui exprime le risque.
2. Commencez par une action orientée observation là où le produit et la configuration Fastly le permettent. Ne passez pas directement au blocage sur la base de correspondances théoriques.
3. Ajoutez un nom descriptif et un enregistrement du changement contenant le responsable, le ticket, le volume attendu, l'heure de début, l'heure de fin ou de revue et l'action de restauration exacte.
4. Testez les cas positifs, négatifs et limites. Une règle qui détecte correctement une requête fabriquée mais correspond à un client mobile normal n'est pas prête à être appliquée.
5. Examinez les logs de résultat avec le propriétaire de l'application avant d'élargir la condition ou l'action.

Évitez les règles qui reposent sur un en-tête d'identité fourni par le client, sauf si la frontière du proxy de confiance supprime les valeurs client et définit elle-même cet en-tête. Les décisions WAF ne peuvent pas corriger une origine qui accepte toujours du trafic direct et non authentifié.

4. Utiliser le simulateur, puis valider sur du trafic réel progressif

Le simulateur Next-Gen WAF est utile pour vérifier les conditions et actions attendues sans envoyer un échantillon en production. Il peut indiquer si un échantillon serait bloqué ou journalisé, le code de réponse, les signaux ajoutés et les masquages. Fastly documente des limites importantes : le simulateur ne prend pas en charge la limitation de débit avancée, la déception ni la géolocalisation, et les déploiements Edge WAF peuvent différer de l'implémentation reverse-proxy du simulateur. Consultez Tester la logique de règle avec le Simulator.

Construisez une petite matrice de test avec des échantillons nettoyés :

• Une requête normale pour chaque route critique, incluant les en-têtes et méthodes attendus.
• Une requête qui doit correspondre au signal ou à la règle candidate.
• Une correspondance proche qui doit rester autorisée ou journalisée comme prévu.
• La forme d'un flux authentifié représentée par des valeurs de substitution, jamais un vrai token ou cookie.
• Un échantillon de réponse lorsque la condition ou la décision dépend d'informations de réponse.

La simulation est une vérification de logique, pas une preuve de production. Une fois réussie, déployez la politique ou règle candidate dans un environnement limité ou le périmètre de production sûr le plus étroit. Exercez des parcours synthétiques réels et des clients de test approuvés, puis comparez les événements WAF aux résultats applicatifs et d'origine.

5. Rendre la journalisation utile sans collecter de données sensibles

Journalisez suffisamment pour répondre à ce qui s'est passé : horodatage, identité de politique ou règle, action, signal, nom d'hôte, route normalisée, ID de requête, état de réponse, version de déploiement et un identifiant de réseau client revu du point de vue de la confidentialité lorsque nécessaire. Corrélez les événements WAF avec la télémétrie de périphérie, d'origine et d'application à l'aide d'ID de requête ou de trace.

Appliquez une politique de minimisation des données aux logs WAF et aux outils en aval :

• N'exportez pas les en-têtes Authorization, les cookies, secrets, tokens d'accès, corps de formulaire bruts ni valeurs de requête sensibles.
• Évitez les URL complètes lorsque les chaînes de requête peuvent contenir des données personnelles ou d'identifiants ; utilisez une route normalisée ou un masquage approuvé.
• Limitez l'accès, la rétention et la transmission par webhook aux personnes et systèmes ayant un besoin documenté.
• Traitez les échantillons de revue de faux positifs comme des données opérationnelles sensibles. Masquez-les avant les tickets, chats, supports fournisseurs ou rapports d'incident.

La documentation de journalisation Next-Gen WAF de Fastly décrit les options disponibles. Validez les champs, la latence de livraison et le comportement de masquage dans votre compte avant d'écrire une alerte ou un runbook d'investigation autour d'eux.

Réserves concernant les API et webhooks

Automatiser les changements de politique ou la livraison d'événements est utile, mais un token API ou un webhook est une frontière de sécurité de production. Ne supposez pas que chaque capacité de console, type de règle, champ d'événement ou garantie de livraison webhook est disponible via chaque API ou formule de compte.

• Utilisez des identifiants à privilèges minimaux, gérés séparément, et effectuez leur rotation selon une planification définie. Ne placez jamais de tokens de longue durée dans VCL, du code navigateur, le contrôle de source ou des URL de webhook.
• Rendez les changements pilotés par API idempotents là où l'API le permet, enregistrez les identifiants de politique ou de règle obtenus et conservez une étape de revue humaine pour les nouveaux comportements de blocage.
• Authentifiez les récepteurs de webhook, validez les signatures ou un autre mécanisme d'authenticité documenté lorsqu'il est disponible, imposez TLS et appliquez des protections contre la répétition, le débit et la taille des payloads.
• Concevez les consommateurs de webhook pour les événements dupliqués, retardés, manquants et désordonnés. Une alerte webhook ne doit pas être le seul enregistrement d'une action d'application.
• N'envoyez que les champs d'événement minimisés et approuvés. Un endpoint webhook n'est pas un lieu approprié pour les corps de requête, identifiants ou données de session client.

Confirmez le comportement des endpoints, l'authentification, les quotas, la pagination et le versionnement dans la référence API Next-Gen WAF actuelle de Fastly. Testez les intégrations avec un récepteur hors production avant de les utiliser pour une réponse automatisée.

6. Faire progresser l'application par étapes

Utilisez des critères de promotion explicites plutôt qu'un déploiement déterminé uniquement par le calendrier :

1. Inventorier : vérifiez la couverture des politiques, les routes critiques, les responsables, la télémétrie et la référence connue comme fiable.
2. Détecter : activez ou observez les signaux pertinents sans introduire un nouveau blocage général. Étudiez les correspondances représentatives et les faux positifs.
3. Simuler : testez des échantillons nettoyés positifs, négatifs et limites par rapport aux conditions candidates.
4. Restreindre : appliquez une règle de requête candidate ou une exclusion de signal uniquement à la plus petite route, au plus petit environnement ou à la plus petite population de trafic sûre.
5. Appliquer : bloquez ou challengez seulement après que le taux de correspondance observé, l'impact sur les utilisateurs légitimes, les signaux de support, les erreurs applicatives et la restauration soient acceptables pour les responsables de la sécurité et de l'application.
6. Réviser : supprimez périodiquement les règles et exclusions temporaires, retestez les flux critiques et révisez les contrôles après les changements applicatifs ou les incidents.

À chaque étape, surveillez les résultats de sécurité et de produit : requêtes correspondantes et bloquées, erreurs WAF, erreurs d'origine, succès de connexion et de paiement, achèvement des API, latence, contacts au support et tentatives de contournement. Une baisse du nombre d'attaques peut signifier que la règle fonctionne, que le trafic a changé, que la journalisation a échoué ou que les utilisateurs ont été bloqués avant d'atteindre l'application.

Restauration

En cas d'incident de faux positif suspecté, privilégiez le rétablissement de l'accès légitime tout en préservant les preuves :

1. Arrêtez d'étendre l'application. Consignez les identifiants de politique et de règle, les horodatages, les ID de requête, les signaux observés, l'action, les routes affectées et l'impact client.
2. Désactivez ou restreignez uniquement la règle, l'action ou l'exclusion candidate en suivant le chemin de restauration prédéfini. Ne désactivez pas largement des protections non liées, sauf si l'incident l'exige.
3. Réexécutez des cas de test légitimes et semblables à une attaque contrôlés, puis vérifiez les parcours applicatifs, événements WAF, trafic d'origine et taux d'erreur.
4. Conservez les preuves nettoyées et mettez à jour l'enregistrement du changement. Corrigez la condition, le périmètre ou le comportement applicatif avant un nouveau déploiement progressif.
5. Si des données ont pu être exposées, ou si un identifiant ou un chemin d'origine peut être compromis, utilisez le processus d'incident de sécurité plutôt que de traiter l'événement comme un problème d'ajustement WAF.

Pièges courants

• Traiter une exclusion de signal comme une liste d'autorisation : Elle supprime un signal spécifié pour les correspondances et peut créer un angle mort au-delà du faux positif initial.
• Bloquer avant d'observer le trafic réel : La réussite du simulateur ne prouve pas le comportement des vrais clients, chemins proxy, géolocalisation ou limites de débit.
• Utiliser des correspondances larges d'IP, pays, user-agent ou chemin : Elles sont facilement trop inclusives et peuvent bloquer des clients, partenaires, crawlers ou systèmes internes.
• Faire confiance aux en-têtes de transfert fournis par le client : À moins qu'un proxy de confiance ne les assainisse et ne les définisse, les clients peuvent les falsifier.
• Traiter les logs ou webhooks comme une télémétrie inoffensive : Ils peuvent contenir un contexte de requête sensible et être retardés, dupliqués ou indisponibles.
• Automatiser les blocages sans responsable de restauration : Un changement API rapide nécessite la même revue par les pairs, piste d'audit et voie de récupération qu'un changement de console.
• Supposer que le WAF protège une origine publiquement accessible : Restreignez et authentifiez séparément l'entrée de l'origine.

Références Fastly principales

• Documentation Next-Gen WAF
• Travailler avec les politiques
• Configurer les signaux système
• Travailler avec les règles d'exclusion de signal
• Travailler avec les règles de requête
• Définir les conditions de règle et limites du Simulator
• Journalisation Next-Gen WAF
• Référence API Next-Gen WAF