Azure Network Watcher : valider les Flow Logs avant d'ouvrir une règle NSG

Quand une application Azure ne joint plus une API interne, un compte Storage, une base SQL ou un endpoint partenaire, la demande arrive souvent sous forme simple : “ouvre le NSG”. C’est le moment dangereux. Sans preuve, l’équipe risque d’ajouter une règle large qui masque une route UDR incorrecte, un firewall qui bloque, une résolution DNS inattendue, une dérive de subnet ou un flux qui ne part jamais de la machine.

Le cas d’usage est un service orders-api-prod hébergé sur une VM ou un workload connecté à un subnet applicatif. Depuis un déploiement réseau, il ne rejoint plus payments-api-prod sur 443. L’objectif du runbook est de décider s’il faut corriger une règle NSG, une route, une policy firewall, une source NAT, ou rollbacker le changement réseau avant d’élargir l’accès.

Figer le flux attendu

Commencez par décrire le flux comme un contrat exploitable. Une règle NSG ne se juge pas seulement avec une IP source et un port. Il faut connaître la source réelle, la cible, le protocole, le chemin réseau attendu, le point de contrôle et la preuve qui permettra de fermer l’incident.

flow:
name: orders-to-payments-prod
source:
  workload: orders-api-prod
  subnet: snet-app-prod
  expected_private_ip: 10.42.12.24
destination:
  service: payments-api-prod
  fqdn: payments.internal.contoso.local
  expected_private_ip: 10.44.8.15
  port: 443
  protocol: Tcp

expected_path:
vnet: vnet-prod-spoke-a
route_next_hop: AzureFirewall
inspection: azfw-prod-weu
destination_zone: internal-api

control_points:
- source_nsg
- destination_nsg
- effective_route
- azure_firewall_policy
- dns_answer_from_workload
- target_service_log

decision_needed:
- fix_nsg_rule
- fix_route_or_firewall_policy
- fix_dns_or_target
- rollback_network_change

Ce contrat évite de traiter tous les refus comme un manque de règle NSG. Un flux peut être bloqué par le NSG source, par le NSG destination, par une route qui envoie le trafic ailleurs, par Azure Firewall, ou par un service cible qui refuse la connexion.

Vérifier les règles effectives avant les règles déclarées

La configuration déclarée ne suffit pas. Azure applique les règles par priorité, avec des règles par défaut, des associations de subnet ou de carte réseau et parfois plusieurs NSG dans le chemin. L’état utile est l’état effectif vu par l’interface réseau.

SUBSCRIPTION="00000000-0000-0000-0000-000000000000"
RG="rg-app-prod"
VM="orders-api-prod-01"
NIC="orders-api-prod-01-nic"

az account set --subscription "$SUBSCRIPTION"

az network nic list-effective-nsg --resource-group "$RG" --name "$NIC" --output table

az network watcher test-ip-flow --resource-group "$RG" --vm "$VM" --direction Outbound --protocol TCP --local 10.42.12.24:49152 --remote 10.44.8.15:443 --output json

test-ip-flow donne une première décision : autorisé ou refusé, avec la règle responsable quand elle est identifiable. Si le test autorise mais que l’application échoue, continuez le diagnostic. Le problème est probablement ailleurs dans le chemin ou dans la cible.

Lire les routes effectives

Un flux autorisé par le NSG peut disparaître dans une mauvaise route. Une UDR peut envoyer le trafic vers un firewall, un NVA, Internet, un peering inattendu ou un prochain saut absent. Avant d’ouvrir une règle, prouvez le prochain saut.

RG="rg-app-prod"
NIC="orders-api-prod-01-nic"
DESTINATION="10.44.8.15"

az network nic show-effective-route-table --resource-group "$RG" --name "$NIC" --output table

az network watcher show-next-hop --resource-group "$RG" --vm "orders-api-prod-01" --source-ip 10.42.12.24 --dest-ip "$DESTINATION" --output json

Si le prochain saut observé ne correspond pas au contrat, la bonne correction n’est pas une règle NSG. C’est une correction de route, d’association de table, de peering, ou un rollback de la modification UDR.

Corréler les Flow Logs avec KQL

Les NSG Flow Logs et les logs enrichis par Traffic Analytics sont utiles quand ils répondent à une question précise : le flux part-il, dans quel sens, avec quelle décision, pendant quelle fenêtre, et depuis quelle IP réelle ?

let StartTime = datetime(2026-07-29T08:00:00Z);
let EndTime = datetime(2026-07-29T10:00:00Z);
let SourceIp = "10.42.12.24";
let DestinationIp = "10.44.8.15";
AzureNetworkAnalytics_CL
| where TimeGenerated between (StartTime .. EndTime)
| where SrcIP_s == SourceIp or DestIP_s == SourceIp
| where SrcIP_s == DestinationIp or DestIP_s == DestinationIp or DestPort_d == 443
| project TimeGenerated,
        FlowDirection_s,
        SrcIP_s,
        SrcPort_d,
        DestIP_s,
        DestPort_d,
        L4Protocol_s,
        FlowStatus_s,
        NSGRule_s,
        NSGList_s,
        Subnet_s,
        VM_s
| order by TimeGenerated desc

Adaptez la table au mode de collecte réellement activé. La preuve importante reste la même : une décision D côté NSG n’a pas la même cause qu’une absence totale de flux ou qu’un flux autorisé puis refusé par le firewall.

Séparer absence de preuve et preuve de blocage

Un piège fréquent consiste à ouvrir une règle parce qu’aucun log ne montre le flux. L’absence de log peut venir d’une télémétrie désactivée, d’une fenêtre de collecte trop courte, d’un diagnostic setting manquant, d’une résolution DNS vers une autre IP, ou d’une application qui n’émet plus l’appel.

Flow Log montre Deny sur la règle attendue
Corriger la règle la plus précise possible
Valider avec test-ip-flow et un appel applicatif

Flow Log montre Allow mais l'appel échoue
Examiner Azure Firewall, proxy, TLS, cible et logs applicatifs
Ne pas ouvrir davantage le NSG

Aucun flux observé
Vérifier Diagnostic Settings, fenêtre de collecte, DNS depuis le workload
Prouver que l'application émet réellement le trafic

Source IP inattendue
Vérifier NAT, load balancer, subnet, révision ou hôte actif
Corriger l'inventaire avant toute règle

Destination IP inattendue
Vérifier DNS, Private Resolver, zone privée ou configuration applicative
Corriger la résolution avant d'ouvrir le réseau

Cette séparation protège la production. Une règle ouverte sur la mauvaise IP ne corrige rien et crée une exception durable.

Construire une correction bornée

Si le blocage NSG est confirmé, la correction doit être minimale, nommée, testable et réversible. Évitez les règles VirtualNetwork vers Any ou les ports trop larges quand le flux attendu est connu.

RG_NET="rg-network-prod"
NSG="nsg-snet-app-prod"
RULE="allow-orders-to-payments-443"

az network nsg rule create --resource-group "$RG_NET" --nsg-name "$NSG" --name "$RULE" --priority 320 --direction Outbound --access Allow --protocol Tcp --source-address-prefixes 10.42.12.24 --source-port-ranges "*" --destination-address-prefixes 10.44.8.15 --destination-port-ranges 443 --description "Temporary validated flow orders-api-prod to payments-api-prod, evidence INC-20260729-014"

La règle doit porter une référence de preuve et un propriétaire. Si la cible est un service managé dont l’IP peut changer, utilisez le mécanisme adapté au service plutôt qu’une IP privée figée sans gouvernance.

Valider et préparer le rollback

La fermeture d’incident ne se limite pas à “la connexion remarche”. Il faut prouver que la règle exacte est utilisée, que le flux applicatif est sain, que le chemin reste conforme, et que le retour arrière est prêt.

Validation finale
test-ip-flow retourne Allow pour le flux exact
Les Flow Logs montrent la règle attendue et pas une règle plus large
Le prochain saut reste celui du contrat
Le firewall ou la cible montre un succès corrélé
L'application valide le scénario métier
L'IaC ou la PR réseau reflète la correction

Rollback
Supprimer la règle temporaire ou revenir au commit réseau précédent
Vérifier que le blocage attendu réapparaît si la règle était temporaire
Restaurer l'association UDR précédente si la route était la cause
Conserver les preuves dans le ticket d'incident

Si la correction a été appliquée manuellement, elle reste provisoire tant qu’elle n’est pas reprise dans l’IaC ou retirée après stabilisation.

Conclusion

Avant d’ouvrir une règle NSG, la bonne séquence consiste à figer le flux attendu, lire les règles effectives, prouver le prochain saut, corréler les Flow Logs, distinguer absence de preuve et preuve de blocage, puis appliquer une correction bornée.

La décision finale doit être explicite : ouvrir une règle ciblée quand le NSG bloque réellement, corriger route, DNS ou firewall quand la preuve pointe ailleurs, ou rollbacker la modification réseau si le chemin attendu n’est plus respecté. C’est ce qui transforme une demande d’ouverture urgente en changement exploitable et réversible.