Cloud
Azure WAF : passer une policy de Detection à Prevention sans casser le trafic
Un runbook de production pour qualifier une policy Azure WAF avant passage en Prevention avec preuves KQL, périmètre de changement, validation applicative, fenêtre de rollback et décision exploitable.
Passer une policy Azure WAF de Detection à Prevention paraît parfois être une simple bascule de sécurité. En production, c’est un changement applicatif. Les requêtes qui étaient seulement journalisées peuvent être bloquées, des intégrations partenaires peuvent disparaître derrière des 403, et les équipes support découvrent trop tard qu’elles ne savent pas distinguer un vrai blocage d’un faux positif.
Le cas d’usage est une application publiée derrière Application Gateway WAF. La policy fonctionne en Detection depuis plusieurs jours ou plusieurs semaines. L’équipe veut activer Prevention sans affaiblir les règles managées, sans ouvrir d’exclusion large et sans transformer la première heure en incident. Le but du runbook est de décider si la bascule est prête, comment la surveiller, quoi rollbacker et quelle preuve conserver.
Traiter la bascule comme un changement de production
Une policy en Detection n’est pas inactive. Elle produit une simulation opérationnelle des blocages futurs. La question n’est donc pas seulement “combien de règles matchent ?”. La question utile est : quelles requêtes légitimes seraient bloquées si la policy appliquait réellement ses décisions ?
Perimetre du changement
Application Gateway et policy WAF concernes
Hostnames publies
Chemins critiques: login, paiement, import, webhook, API partenaire, callback
Environnements impactes
Version de ruleset managé et custom rules actives
Preuves attendues
Top des blocages simulés en Detection
RuleId et message associés
URI, methode, hostname, client IP et user agent
Volume par tranche de temps
Echantillons de requetes legitimes et illegitimes
Decision par cas: accepter, corriger l'application, exclusion ciblee, custom rule, rollback
Conditions de bascule
Faux positifs critiques traites
Monitoring prêt
Support informe des symptomes attendus
Rollback documente et testeCette fiche évite une erreur fréquente : activer Prevention parce que le nombre global de matches semble faible, alors qu’un seul chemin métier critique concentre les requêtes qui seront bloquées.
Lire les logs Detection comme une prévision
La première requête doit isoler ce que Prevention aurait bloqué. Selon l’ingestion, les tables et champs peuvent varier entre AzureDiagnostics et les tables dédiées Application Gateway. Le principe reste le même : période, hostname, URI, action, ruleId, message et nombre de clients distincts.
let Window = 7d;
AzureDiagnostics
| where TimeGenerated > ago(Window)
| where Category == "ApplicationGatewayFirewallLog"
| extend hostname = tostring(host_s)
| extend uri = tostring(requestUri_s)
| extend method = tostring(requestMethod_s)
| extend action = tostring(action_s)
| extend ruleId = tostring(ruleId_s)
| extend message = tostring(message_s)
| extend clientIp = tostring(clientIp_s)
| where action in ("Matched", "Detected", "Blocked")
| summarize hits=count(),
clients=dcount(clientIp),
firstSeen=min(TimeGenerated),
lastSeen=max(TimeGenerated),
sampleMessages=make_set(message, 3)
by hostname, uri, method, ruleId, action
| order by hits descUn hit WAF n’est pas automatiquement un faux positif. Une vague de requêtes suspectes sur /wp-admin peut être saine à bloquer. Une règle SQLi sur un endpoint d’import interne peut au contraire indiquer un payload légitime mal encodé ou une API qui accepte trop librement des champs à risque. Il faut qualifier par usage, pas par volume seulement.
Construire une matrice de décision par chemin
Avant la bascule, chaque chemin critique doit avoir une décision. La décision peut être de ne rien faire, de corriger l’application, d’ajouter une exclusion ciblée, de renforcer une custom rule, ou de repousser Prevention si la preuve est insuffisante.
Chemin: /login
Signal WAF: brute force, automation, headers atypiques
Impact metier: authentification utilisateur
Decision: Prevention possible si erreurs applicatives et support restent normaux
Validation: taux 403 attendu sur sources suspectes, pas sur cohortes legitimes
Rollback: repasser la policy en Detection si utilisateurs legitimes bloques
Chemin: /api/import
Signal WAF: ruleId sur contenu JSON ou multipart
Impact metier: integration partenaire ou batch critique
Decision: rejouer des payloads representatifs avant Prevention
Validation: correlation WAF + logs applicatifs + reponse partenaire
Rollback: Detection ou exclusion ciblee avec expiration
Chemin: /webhook/provider
Signal WAF: user agent ou signature inhabituelle
Impact metier: evenements entrants asynchrones
Decision: verifier les IP source, signatures et retries fournisseur
Validation: pas de backlog, pas de perte d'evenements
Rollback: Detection si backlog ou retries montent apres basculeCette matrice rend la discussion plus courte pendant le créneau de changement. L’équipe ne débat pas abstraitement de la sévérité WAF. Elle décide chemin par chemin avec un signal et un retour arrière.
Préparer les sondes et la corrélation
Le jour de la bascule, il faut des probes applicatives et des requêtes KQL prêtes. Une sonde qui vérifie seulement la page d’accueil ne suffit pas si les risques se trouvent sur login, import, webhook ou API partenaire.
Avant bascule
Rejouer les parcours critiques depuis un reseau proche des utilisateurs
Verifier les payloads representatifs pour les endpoints sensibles
Ajouter un correlation ID quand l'application le permet
Confirmer que les logs Application Gateway, WAF et applicatifs arrivent
Pendant bascule
Surveiller 403, 502, latence et erreurs applicatives
Comparer les chemins touches aux chemins prevus
Lire les ruleId WAF avant d'ajouter une exception
Garder un canal support ouvert pour les premiers retours
Apres bascule
Capturer avant/apres sur la meme fenetre horaire
Identifier les faux positifs restants
Supprimer les exceptions temporaires inutiles
Documenter la decision finaleLa corrélation est plus importante que le nombre brut de 403. Une augmentation de 403 sur des sources automatisées peut être le résultat attendu. Une poignée de 403 sur un client interne critique peut justifier un rollback immédiat.
Surveiller Prevention sans attendre les tickets
Après activation, la requête de surveillance doit séparer les blocages attendus des blocages nouveaux. Elle doit aussi montrer si un hostname ou un chemin concentre soudain le risque.
let ChangeTime = datetime(2026-06-20T08:00:00Z);
let Window = 2h;
AzureDiagnostics
| where TimeGenerated between (ChangeTime .. ChangeTime + Window)
| where Category == "ApplicationGatewayFirewallLog"
| extend hostname = tostring(host_s)
| extend uri = tostring(requestUri_s)
| extend method = tostring(requestMethod_s)
| extend action = tostring(action_s)
| extend ruleId = tostring(ruleId_s)
| extend clientIp = tostring(clientIp_s)
| where action has_any ("Blocked", "Prevention")
| summarize blocked=count(),
clients=dcount(clientIp),
firstSeen=min(TimeGenerated),
lastSeen=max(TimeGenerated),
sampleClients=make_set(clientIp, 5)
by hostname, uri, method, ruleId
| order by blocked descIl faut lire cette requête avec les logs applicatifs. Si le WAF bloque une requête, l’application peut ne jamais la voir. L’absence de log applicatif n’est donc pas une preuve que tout va bien. À l’inverse, une hausse d’erreurs applicatives sans blocage WAF indique probablement un autre problème de déploiement.
Encadrer les exceptions au lieu d’ouvrir large
Si un faux positif apparaît après bascule, la réponse la plus rapide n’est pas toujours la bonne. Repasser en Detection peut être préférable à une exclusion large qui restera en place. Une exclusion doit viser un ruleId, un champ, un chemin et une durée.
Avant exception
RuleId identifie
Chemin et hostname limites
Champ matche compris: cookie, header, arg, body, multipart
Exemple de requete legitime conserve
Risque de contournement relu
Expiration ou revue planifiee
Preferer rollback Detection quand
Le faux positif touche un chemin critique large
Le champ matche n'est pas compris
Plusieurs ruleId differents apparaissent d'un coup
L'equipe ne peut pas prouver le trafic legitime
L'exception necessaire serait trop globale
Preferer exclusion ciblee quand
Le payload legitime est stable
Le ruleId est unique ou tres limite
Le chemin est restreint
Le test avant/apres est reproductible
La revue securite accepte le compromisLa discipline est simple : si l’équipe ne sait pas expliquer précisément ce qui est exclu, il vaut mieux rollbacker le mode que garder une exception opaque.
Décider rollout, maintien ou rollback
Le changement doit se terminer par une décision explicite. Le pire état est une policy en Prevention avec des exceptions temporaires, des tickets support ouverts et aucune revue prévue.
Decision: rollout confirme
Les probes critiques passent
Les blocages correspondent aux chemins et sources attendus
Aucun client legitime critique n'est bloque
Les faux positifs restants ont une correction ou une exclusion ciblee
Les logs permettent de reconstruire la decision
Decision: maintien sous surveillance
Prevention reste active mais une revue est planifiee
Les blocages sont acceptables mais pas encore stabilises
Les exceptions temporaires ont une date de retrait
Le support connait les symptomes a escalader
Decision: rollback Detection
Chemin critique bloque sans correction ciblee
Backlog, erreurs metier ou appels partenaires en echec
RuleId ou champ matche non compris
Necessite d'une exclusion trop large
Perte de visibilite ou logs insuffisantsLe rollback doit être propre : repasser la policy en Detection, conserver les logs de la fenêtre, annoter les chemins affectés, puis ajouter les payloads ou scénarios manquants à la matrice avant une nouvelle tentative.
Conclusion
Activer Azure WAF en Prevention n’est pas une case à cocher. C’est un changement de production qui doit partir des logs Detection, passer par une matrice de chemins critiques, s’appuyer sur des probes réalistes et garder un rollback immédiat.
La bonne décision n’est pas toujours d’activer coûte que coûte. Elle peut être de confirmer Prevention, de maintenir sous surveillance avec exceptions ciblées, ou de revenir en Detection quand la preuve manque. Ce qui compte, c’est que le trafic bloqué soit explicable, que le trafic légitime reste vérifié et que chaque exception ait une raison, un périmètre et une sortie.