Azure Virtual Network Manager : diagnostiquer une règle Security Admin avant de modifier les NSG

Une application ne joint plus une API interne sur le port 443. L’équipe applicative trouve un NSG qui autorise le flux, ajoute une seconde règle plus large, puis constate le même timeout. Le paquet n’atteint pourtant jamais l’évaluation du NSG : une règle Security Admin Azure Virtual Network Manager le bloque plus haut dans la chaîne.

Le cas d’usage est un environnement Azure où une équipe centrale applique des garde-fous réseau à plusieurs VNets, tandis que les équipes produit gèrent leurs NSG de subnet ou de NIC. Le but du runbook est d’identifier la règle réellement décisive, de prouver son périmètre, puis de choisir entre correction ciblée, exception gouvernée, maintien du blocage ou rollback du dernier déploiement régional.

Figer le flux exact avant de toucher aux règles

Une panne réseau n’est pas décrite par « le HTTPS ne passe plus ». Il faut un tuple testable : source, destination, protocole, ports, direction, VNet, région et instant UTC. Conservez aussi un flux témoin non affecté. Sans cette comparaison, une règle globale, un NSG local, une route ou le service cible peuvent produire le même symptôme.

Incident: inc-20260902-014
First observed: 2026-09-02T14:18:00Z
Last known success: 2026-09-02T13:55:00Z

Affected flow
Source VM: vm-orders-prod-02
Source IP: 10.42.8.17
Source VNet: vnet-orders-prod-weu
Destination IP: 10.60.4.21
Destination port: 443/TCP
Direction: outbound
Region: westeurope

Control flow
Same source to 10.60.4.22:443 succeeds

Evidence to preserve
effective Security Admin rules
IP Flow Verify result and rule name
VNet flow log tuple
network group membership
active configuration and regional deployment status
NSG effective rules
application test and UTC timestamps

Ne commencez pas par une ouverture 0.0.0.0/0, une baisse de priorité ou une suppression de NSG. Une règle Security Admin Deny peut arrêter l’évaluation avant le NSG ; élargir le NSG ne change alors rien et laisse une dette de sécurité après l’incident.

Lire l’ordre d’évaluation correctement

Azure Virtual Network Manager évalue les règles Security Admin avant les NSG. Leur action détermine la suite :

• Allow transmet le flux à l’évaluation des NSG, qui peuvent encore le refuser ;
• Always Allow autorise le flux sans poursuivre vers les NSG ;
• Deny bloque le flux sans poursuivre vers les NSG.

La priorité la plus basse numériquement est évaluée en premier. Une exception Allow à priorité 10 peut donc passer avant un Deny global à priorité 100, tout en laissant le NSG appliquer la politique locale. Une exception Always Allow est beaucoup plus forte : elle contourne aussi un refus NSG. Elle doit rester rare, explicite et justifiée par un besoin de gouvernance.

Packet
|
v
Security Admin rules, lowest priority number first
Deny         -> blocked, stop
Always Allow -> allowed, stop before NSG
Allow        -> continue
no match     -> continue
|
v
Subnet and NIC NSG rules
Allow or Deny
|
v
Route, destination listener, TLS and application checks

Cette lecture évite l’erreur inverse : attribuer tout refus à Virtual Network Manager. Si IP Flow Verify retourne une règle Security Admin Allow, le NSG reste dans la chaîne. Si le filtrage autorise le tuple, revenez aux routes, au service cible et au protocole applicatif.

Prouver la règle effective sur le VNet

Inspectez ce qui est effectif, pas seulement le fichier IaC attendu. Un VNet peut entrer dans un network group dynamique après un changement de tag ou d’abonnement. Une configuration peut aussi avoir été modifiée sans être redéployée dans la région, ou déployée avec un délai de convergence.

Les commandes suivantes utilisent l’extension virtual-network-manager de l’Azure CLI. Adaptez les noms au périmètre réel et conservez les sorties dans le dossier d’incident.

RG_NET="rg-network-governance"
NETWORK_MANAGER="avnm-platform-prod"
VNET_RG="rg-orders-prod"
VNET="vnet-orders-prod-weu"
REGION="westeurope"

az network manager list-effective-security-admin-rule --resource-group "$VNET_RG" --virtual-network-name "$VNET" --output json

az network manager list-active-security-admin-rule --resource-group "$RG_NET" --network-manager-name "$NETWORK_MANAGER" --regions "$REGION" --output json

az network manager list-deploy-status --resource-group "$RG_NET" --network-manager-name "$NETWORK_MANAGER" --regions "$REGION" --deployment-types SecurityAdmin --output json

Comparez quatre objets : la règle effective sur le VNet, la règle active dans la région, la définition de la configuration et l’intention déclarée dans IaC. Le statut global Deployed confirme le déploiement régional, pas à lui seul le comportement de chaque NIC. Il faut encore tester le tuple réel.

Demander à IP Flow Verify quelle règle décide

Pour une VM, IP Flow Verify évalue les règles de sécurité et d’administration appliquées à son interface. Le résultat donne une décision et la règle responsable. Utilisez l’IP locale réelle de la NIC et l’IP distante du flux en panne.

VM_RG="rg-orders-prod"
VM="vm-orders-prod-02"

az network watcher test-ip-flow --resource-group "$VM_RG" --vm "$VM" --direction Outbound --protocol TCP --local "10.42.8.17:*" --remote "10.60.4.21:443" --output json

Rejouez le même test vers la destination témoin. Si le flux affecté retourne un Deny Security Admin et le témoin un Allow, vous disposez d’une différence exploitable. Si les deux sont autorisés, le filtre n’est pas la cause : contrôlez l’effective route, l’écoute sur 443, le TLS et les logs du service.

IP Flow Verify ne remplace pas un test applicatif. Il prouve une décision de filtrage pour le tuple fourni, pas qu’un serveur répond, qu’un certificat est valide ou qu’une API accepte l’identité du client.

Confirmer avec les VNet flow logs

Les VNet flow logs apportent la preuve temporelle. Pour une décision Azure Virtual Network Manager, le champ aclID identifie la ressource d’évaluation, flowGroups[].rule porte le nom de la règle, et le tuple indique direction et état. Un état D sous le nom d’une règle Security Admin matérialise le refus.

{
"aclID": "/subscriptions/<sub>/resourceGroups/rg-network-governance/providers/Microsoft.Network/networkManagers/avnm-platform-prod",
"flowGroups": [
  {
    "rule": "Deny-Prod-To-Shared-Except-Approved",
    "flowTuples": [
      "1788358740000,10.42.8.17,10.60.4.21,52344,443,6,O,D,NX,0,0,0,0"
    ]
  }
]
}

Les flow logs doivent être activés sur chaque VNet à observer. S’ils n’existaient pas avant l’incident, ne présentez pas leur absence comme une preuve d’autorisation. Conservez alors IP Flow Verify, les règles effectives, le statut de déploiement et les logs de la destination, puis ajoutez la couverture manquante comme action de fiabilisation.

Retrouver pourquoi le VNet est dans le périmètre

Une règle correcte peut s’appliquer au mauvais VNet. Vérifiez la portée du Network Manager, le network group ciblé et son type de membership. Pour une appartenance dynamique, relevez les tags, le groupe de ressources, l’abonnement et le résultat de conformité ayant inclus le VNet.

Posez ensuite trois questions :

• la source ou la destination correspond-elle aux préfixes attendus ?
• le VNet devait-il appartenir à ce network group à cet instant ?
• l’exception prévue est-elle une règle de priorité supérieure ou seulement un NSG local incapable de battre le Deny global ?

Les règles Security Admin ne s’appliquent pas à tous les cas de manière identique. Certains subnets de services managés sont exemptés, et les Private Endpoints ne sont pas couverts par ces règles. Cette limite doit affiner le diagnostic, pas pousser à utiliser Private Endpoint comme explication universelle.

Choisir une correction bornée

La correction dépend de la preuve :

Rule is correct and flow must stay blocked
Keep Deny
Fix caller, target or architecture
Remove temporary NSG openings created during diagnosis

VNet entered the wrong network group
Correct membership condition or tag
Validate the resulting member set before regional deployment

Legitimate narrow exception is missing
Add higher-priority Allow for exact source, destination and port
Keep downstream NSG evaluation
Avoid Always Allow unless bypassing NSG is explicitly required

Last deployment introduced an overbroad rule
Restore the previous tested configuration as regional goal state
Commit only the affected regions
Verify convergence and effective rules

Filtering is not the cause
Stop changing Security Admin rules and NSGs
Continue with routing, listener, TLS, identity and application evidence

Préférez Allow à Always Allow quand l’équipe applicative doit conserver un filtrage NSG plus précis. Une exception doit avoir un propriétaire, une justification, une date de revue et un test négatif prouvant qu’un flux voisin reste refusé.

Déployer par canari et préparer le rollback

Une configuration Security Admin est déployée par région et suit un modèle de convergence éventuelle. Ne concluez pas au premier paquet autorisé. Commencez par un network group canari ou une région à faible risque, vérifiez le statut, les règles effectives et plusieurs tuples, puis élargissez.

Le rollback n’est pas la suppression improvisée d’une règle. Il consiste à rétablir une configuration connue, à la redéployer comme état cible dans les régions concernées, puis à prouver que l’ancienne décision est revenue. Comme une seule configuration Security Admin par Network Manager peut être déployée dans une région, omettre une configuration lors du commit peut la retirer de l’état cible : relisez toujours la liste complète avant validation.

Before deployment
Diff configuration, collections, priorities and network groups
Export current active rules and regional goal state
Record positive and negative test tuples
Confirm rollback configuration and authorized operator

Canary validation
Deployment status is Deployed
Expected rule is effective on canary VNet
Required flow passes IP Flow Verify and application test
Neighboring unauthorized flow remains denied
VNet flow log names the expected deciding rule

Rollback trigger
broader source or destination becomes reachable
Always Allow bypasses an intended NSG control
unexpected VNets enter the targeted group
deployment state differs across regions
effective rules cannot be reconciled with declared intent

Conclusion

Quand une règle Security Admin intervient, modifier le NSG est souvent une action sans effet et parfois une future faille. Le diagnostic doit partir du tuple, lire l’ordre Security Admin puis NSG, interroger les règles effectives, confirmer avec IP Flow Verify et les VNet flow logs, puis expliquer le membership du VNet.

La décision finale doit rester exploitable : maintenir un blocage justifié, créer une exception Allow étroite, corriger le network group, ou redéployer la dernière configuration connue. La panne est close lorsque le flux attendu fonctionne, le flux négatif reste bloqué et le rollback est encore prouvable.