Networking
Azure Firewall : qualifier une règle trop large avant de la resserrer en production
Un runbook de production pour resserrer une règle Azure Firewall sans casser un flux utile, avec inventaire, preuves KQL, dépendances, validation contrôlée et rollback.
Une règle Azure Firewall trop large finit souvent par devenir invisible. Elle a été ajoutée pour débloquer un incident, absorber une migration, laisser passer un partenaire ou gagner du temps pendant un déploiement. Quelques semaines plus tard, personne ne sait plus si elle protège encore un flux réel, si elle masque un problème DNS, ou si elle autorise simplement trop de destinations.
Le cas d’usage est un environnement hub-and-spoke où l’egress passe par Azure Firewall. Une règle applicative ou réseau autorise un périmètre trop large : wildcard FQDN, plage IP généreuse, port ouvert pour plusieurs workloads, ou collection prioritaire héritée d’une urgence. L’objectif n’est pas de supprimer la règle au courage. Le runbook sert à décider si elle peut être resserrée, expirée, découpée ou maintenue temporairement avec une preuve exploitable.
Cadrer la règle comme un risque opérationnel
Avant de modifier la policy, décris la règle comme un contrat de production. Une règle Firewall n’est pas seulement une ligne de configuration. Elle encode une hypothèse sur les workloads, les dépendances, les protocoles, les ports, les identités réseau et le niveau de tolérance au blocage.
Règle à qualifier
Policy: azfw-policy-prod
Rule collection group: rcg-egress-prod
Rule collection: app-egress-shared
Rule: allow-partner-or-temporary-wildcard
Type: application ou network
Sources attendues: snet-app-prod, snet-jobs-prod
Destinations attendues: api.partner.example, auth.partner.example
Ports: 443
Origine de la règle: incident, migration, exception sécurité ou déploiement
Date ou ticket d'introduction
Owner métier et owner plateforme
Questions avant resserrement
Quels flux réels utilisent encore la règle ?
Le trafic vient-il des sources prévues ?
Les destinations observées correspondent-elles au besoin documenté ?
Une règle plus prioritaire masque-t-elle le résultat ?
Quel test prouve qu'un resserrement ne casse pas la production ?
Quel rollback remet l'état précédent sans élargir davantage ?Si l’équipe ne peut pas répondre à ces questions, la bonne première action est de collecter des preuves, pas de retirer la règle.
Lire les hits avant de lire les intentions
La documentation de la règle explique pourquoi elle existe. Les logs montrent ce qu’elle fait réellement. Commence par isoler les événements sur la collection, la règle et les sources attendues.
let StartTime = ago(14d);
let RuleName = "allow-partner-or-temporary-wildcard";
AZFWApplicationRule
| where TimeGenerated > StartTime
| where Rule == RuleName
| summarize
hits = count(),
firstSeen = min(TimeGenerated),
lastSeen = max(TimeGenerated),
sources = dcount(SourceIp),
fqdnCount = dcount(Fqdn),
sampleFqdns = make_set(Fqdn, 20)
by Action, RuleCollection, Rule, Protocol, DestinationPort
| order by hits descPour une règle réseau, remplace le FQDN par les IP et ports observés.
let StartTime = ago(14d);
let RuleName = "allow-shared-egress-443";
AZFWNetworkRule
| where TimeGenerated > StartTime
| where Rule == RuleName
| summarize
hits = count(),
firstSeen = min(TimeGenerated),
lastSeen = max(TimeGenerated),
sources = dcount(SourceIp),
destinations = dcount(DestinationIp),
sampleDestinations = make_set(strcat(DestinationIp, ":", tostring(DestinationPort)), 30)
by Action, RuleCollection, Rule, Protocol
| order by hits descUne règle sans hit récent peut être candidate à expiration, mais pas à suppression immédiate si le flux est mensuel, batch ou lié à une procédure de reprise. Le critère utile est la cohérence entre fréquence métier et observation.
Séparer les bons consommateurs du bruit
Une règle trop large sert souvent plusieurs consommateurs sans que cela soit assumé. Il faut donc regrouper les sources observées par subnet, workload ou environnement, puis repérer les usages hors périmètre.
let StartTime = ago(14d);
let RuleName = "allow-partner-or-temporary-wildcard";
AZFWApplicationRule
| where TimeGenerated > StartTime
| where Rule == RuleName
| summarize hits=count(), lastSeen=max(TimeGenerated), fqdns=make_set(Fqdn, 15) by SourceIp, DestinationPort, Action
| order by hits descComplète avec l’inventaire réseau : quel subnet porte chaque IP, quel service l’utilise, et si la source devrait dépendre de cette règle. Une source inattendue ne veut pas forcément dire attaque. Cela peut révéler un runner CI, un batch oublié, un ancien App Service VNet Integration ou une route qui regroupe trop de workloads derrière la même policy.
Vérifier les dépendances applicatives avant de couper
Le resserrement doit partir du flux réel. Pour une règle FQDN, liste les domaines exacts, les alias, les redirections, les CDN, les endpoints d’authentification et les appels secondaires. Pour une règle IP, vérifie si l’IP est stable, si elle représente une appliance, un service privé, un partenaire ou une destination Internet volatile.
Dépendance à valider
Nom fonctionnel: API partenaire facturation
FQDN appelé par le workload: api.partner.example
FQDN secondaires: auth.partner.example, token.partner.example
Ports et protocoles: HTTPS 443
Sources autorisées: snet-app-prod, snet-jobs-prod
Fenêtre d'usage: continu, batch quotidien, batch mensuel ou DR
Sensibilité au blocage: utilisateur, back-office, supervision ou reprise
Bloquer le resserrement si
le test a été fait depuis un poste admin au lieu du runtime
un FQDN secondaire est observé sans owner
la règle est utilisée par un batch peu fréquent non rejoué
le rollback dépend d'une modification manuelle non documentée
une destination IP masque un nom ou un service non identifiéPrivate Endpoint peut apparaître dans l’analyse si la destination résout vers une adresse privée, mais ce n’est pas le prisme principal. Ici, la question est le périmètre réel de la règle Firewall et sa réversibilité.
Préparer un resserrement mesurable
Ne remplace pas une règle large par une règle cible sans fenêtre d’observation. Prépare le diff comme une hypothèse testable : quelles sources restent autorisées, quelles destinations sont retirées, quelle règle temporaire peut recevoir les refus, et quelle métrique déclenche le rollback.
change:
objective: resserrer allow-partner-or-temporary-wildcard
from:
sources: ["10.42.0.0/16"]
destinations: ["*.partner.example"]
ports: [443]
to:
sources: ["10.42.12.0/24", "10.42.18.0/24"]
destinations: ["api.partner.example", "auth.partner.example"]
ports: [443]
validation:
before:
- export policy actuelle
- capturer hits par source et destination sur 14 jours
- rejouer un appel depuis chaque runtime critique
during:
- surveiller deny sur anciennes destinations
- surveiller erreurs applicatives 401, 403, 5xx et timeouts
- garder le ticket de rollback ouvert
success:
- hits attendus sur la nouvelle règle
- aucun deny inattendu depuis les sources critiques
- probe applicative verte
rollback:
- restaurer l'ancienne règle ou collection
- documenter la destination manquante
- rouvrir uniquement le périmètre nécessaireLe plan doit être lisible par l’astreinte. Si la seule personne capable de rollbacker est l’auteur du changement, la règle n’est pas prête à être resserrée.
Utiliser un canari quand le risque est élevé
Quand Azure Firewall Policy est partagée par plusieurs spokes, un changement apparemment local peut toucher des workloads voisins. Si possible, commence par une source canari : un subnet, un workload, une collection dédiée ou une règle plus spécifique placée avant l’ancienne règle.
Canari acceptable
une source critique mais bien instrumentée
une fenêtre de trafic représentative
un owner disponible pour tester
un rollback de policy déjà prêt
des logs Firewall et application corrélables
Canari insuffisant
seul un curl manuel passe
la source testée ne représente pas le batch réel
l'ancienne règle large reste prioritaire et masque la nouvelle
les denies ne sont pas collectés dans Log Analytics
la validation ignore les appels d'authentification ou de callbackLe canari ne sert pas à se rassurer. Il sert à découvrir les dépendances manquantes avant de réduire le périmètre global.
Décider maintenir, resserrer, expirer ou rollbacker
La décision doit être explicite. Une règle large peut être maintenue temporairement si le risque de coupure est plus élevé que le risque d’exposition, mais elle doit alors porter une date, un owner et une preuve.
Resserrer
Les hits réels correspondent à des sources et destinations connues
Les dépendances secondaires sont documentées
Le canari a produit les mêmes hits sur la nouvelle règle
Les denies inattendus restent nuls ou expliqués
Le rollback a été testé ou relu
Expirer
Aucun hit cohérent avec le cycle métier attendu
Le propriétaire confirme que le flux est retiré
Un test de non-régression couvre le workload historique
La suppression est annoncée avec une fenêtre de surveillance
Maintenir temporairement
La règle sert encore un flux utile mais mal documenté
Le risque de coupure dépasse le risque d'exposition immédiat
Un plan de découpage est ouvert avec date et owner
Les logs restent surveillés jusqu'au prochain changement
Rollbacker
Des denies apparaissent sur un flux critique connu
Une destination secondaire manque dans le nouveau périmètre
La nouvelle règle est masquée par une priorité inattendue
Les erreurs applicatives montent après le changement
Le comportement observé ne correspond pas au planÉvite la fausse victoire qui consiste à resserrer la règle tout en ajoutant ailleurs une exception plus large. Le bilan doit comparer le périmètre avant/après, pas seulement le nom de la règle modifiée.
Valider après changement
Après resserrement, relis les logs dans les deux sens : ce qui passe par la nouvelle règle et ce qui est refusé par les anciennes destinations. Ajoute une validation applicative, pas seulement Firewall.
let ChangeTime = datetime(2026-07-15T08:00:00Z);
let NewRule = "allow-partner-api-tight";
let OldRule = "allow-partner-or-temporary-wildcard";
AZFWApplicationRule
| where TimeGenerated > ChangeTime
| where Rule in (NewRule, OldRule) or Action == "Deny"
| summarize hits=count(), sources=dcount(SourceIp), fqdns=make_set(Fqdn, 20) by bin(TimeGenerated, 15m), Action, RuleCollection, Rule
| order by TimeGenerated ascLa validation est terminée quand le flux attendu passe par la règle cible, les refus inattendus sont compris, les métriques applicatives restent stables et le rollback peut être fermé.
Conclusion
Resserrer une règle Azure Firewall n’est pas une opération de nettoyage cosmétique. C’est un changement de production qui peut retirer un chemin réseau utilisé par un workload, un batch, un callback ou une procédure de reprise.
Le bon runbook part des hits réels, identifie les consommateurs, qualifie les dépendances, prépare un resserrement mesurable, teste un canari si nécessaire, puis décide : resserrer, expirer, maintenir temporairement ou rollbacker. Une règle plus stricte n’a de valeur que si elle reste exploitable, validée et réversible.