Azure NSG : valider une règle Service Tag avant son déploiement

Une équipe doit autoriser les workloads d’un subnet de production à joindre un service Azure public. La modification proposée semble étroite : remplacer Internet par un Service Tag dans la règle NSG sortante. Pourtant, le tag peut couvrir toutes les régions, inclure des préfixes qui évolueront sans nouveau déploiement et ne désigne pas une instance précise du service. Une règle valide syntaxiquement peut donc être trop large, incomplète ou impossible à expliquer pendant un incident.

Le cas d’usage est un pool de workers qui doit pousser de la télémétrie vers Azure Monitor en HTTPS. Le runbook ne cherche pas seulement à obtenir un Allow. Il doit prouver le besoin, choisir le bon scope, vérifier la décision NSG effective, observer un flux réel, puis décider de promouvoir, corriger ou rollbacker la règle.

Figer le contrat de flux

Commencez par décrire le flux sans utiliser le nom de la règle candidate. Cela évite de transformer la solution supposée en diagnostic.

change:
id: CHG-2847
source: snet-workers-prod
source_resource: vmss-workers-prod
direction: outbound
protocol: tcp
destination_port: 443
business_dependency: telemetry-export
candidate_service_tag: AzureMonitor
candidate_scope: global

current_state:
matching_rule: DenyInternetOutBound
observed_result: denied

required_evidence:
- destination-fqdn-and-resolved-ip
- service-tag-purpose-and-direction
- current-tag-prefix-snapshot
- effective-rule-decision
- application-request-correlation
- rollback-rule-and-owner

Le FQDN appelé, l’IP résolue et le port restent indispensables. Un Service Tag agrège des préfixes IP gérés par Microsoft ; il ne valide ni le nom TLS, ni le tenant, ni la ressource cible. Si le besoin exige une instance précise ou un contrôle par FQDN, une règle NSG fondée uniquement sur le tag ne porte pas toute la politique.

Vérifier le sens réel du Service Tag

Contrôlez la documentation du tag avant la configuration. Certains tags sont recommandés uniquement en entrée ou en sortie, certains supportent un suffixe régional, et certains ont des dépendances vers d’autres tags. Évitez AzureCloud par commodité : il représente les adresses publiques des datacenters Azure et inclut des ressources qui n’appartiennent pas à votre organisation.

Tag candidate: AzureMonitor

Review
Purpose matches the actual dependency
Recommended direction includes outbound
Regional form exists or does not exist
Required dependent tags are identified
Public cloud matches the workload cloud
Tag is supported on an NSG destination

Hard stops
AzureCloud chosen only because the exact dependency is unknown
Inbound-only tag used for an outbound requirement
Service tag treated as a resource or tenant identity
Required protocol or destination port still unknown

Le scope régional n’est pas un réglage cosmétique. Lorsqu’un tag le supporte, une forme comme Storage.FranceCentral réduit le périmètre aux préfixes de la région concernée. Quand il ne le supporte pas, documentez explicitement que la règle reste globale et ajoutez des contrôles applicatifs adaptés.

Capturer les préfixes derrière le tag

Microsoft met à jour automatiquement les préfixes d’un Service Tag. L’exploitation doit donc conserver un snapshot au moment du changement, puis détecter les évolutions au lieu de supposer que le périmètre restera identique.

LOCATION="francecentral"
TAG="AzureMonitor"

az network list-service-tags \
--location "$LOCATION" \
--query "values[?name=='$TAG'].{name:name,changeNumber:properties.changeNumber,prefixes:properties.addressPrefixes}" \
--output json > "service-tag-${TAG}-${LOCATION}.json"

jq -e 'length == 1 and .[0].prefixes != null and (. [0].prefixes | length > 0)' \
"service-tag-${TAG}-${LOCATION}.json"

jq -r '.[0].changeNumber, (.[0].prefixes[] | tostring)' \
"service-tag-${TAG}-${LOCATION}.json"

La localisation de l’appel indique où interroger l’API ; elle ne rend pas automatiquement global un tag régional ni régional un tag global. Conservez le changeNumber, le cloud, la date et les préfixes. Ce snapshot sert à la revue, au diagnostic et au contrôle de dérive.

Lire la règle déployée et les règles effectives

Le template proposé n’est pas l’état effectif. Vérifiez l’association du NSG au subnet, la priorité, une éventuelle règle sur la NIC et les security admin rules d’Azure Virtual Network Manager.

RESOURCE_GROUP="rg-network-prod"
NSG="nsg-workers-prod"
NIC="vmss-workers-prod-instance-nic"

az network nsg rule list \
--resource-group "$RESOURCE_GROUP" \
--nsg-name "$NSG" \
--query "[].{priority:priority,name:name,direction:direction,access:access,destination:destinationAddressPrefix,ports:destinationPortRanges}" \
--output table

az network nic list-effective-nsg \
--resource-group "$RESOURCE_GROUP" \
--name "$NIC" \
--output json > effective-nsg-before.json

Une règle Allow ne garantit rien si un deny de priorité supérieure s’applique. À l’inverse, un test réussi peut provenir d’une règle plus large déjà présente. La preuve attendue est le nom de la règle qui décide réellement le flux, pas la seule présence de la règle candidate.

Simuler le flux avant de l’observer

Pour une VM ou une NIC prise en charge, IP Flow Verify permet de tester le tuple direction, protocole, IP locale, IP distante et ports, puis retourne la règle qui autorise ou refuse. Testez au moins une IP actuellement résolue et un témoin qui doit rester refusé.

VM_ID="/subscriptions/<subscription>/resourceGroups/rg-app-prod/providers/Microsoft.Compute/virtualMachineScaleSets/vmss-workers-prod/virtualMachines/3"
LOCAL_IP="10.42.8.17"
REMOTE_IP="<resolved-azure-monitor-ip>"

az network watcher test-ip-flow \
--vm "$VM_ID" \
--direction Outbound \
--protocol TCP \
--local "${LOCAL_IP}:52000" \
--remote "${REMOTE_IP}:443" \
--output json

# Negative control: this destination must remain denied.
az network watcher test-ip-flow \
--vm "$VM_ID" \
--direction Outbound \
--protocol TCP \
--local "${LOCAL_IP}:52001" \
--remote "203.0.113.10:443" \
--output json

Adaptez la cible aux types de ressources supportés par l’outil. La simulation qualifie la politique NSG, pas la résolution DNS, le routage, un firewall intermédiaire, TLS ou la disponibilité du service. Un Allow est une condition nécessaire, pas un test de bout en bout.

Déployer en canari et observer le vrai trafic

Appliquez d’abord la règle à un subnet ou un groupe de workers borné. Gardez le deny existant, insérez l’allow avec une priorité documentée et observez pendant une fenêtre qui couvre le comportement normal du workload.

Canary scope
One worker group or dedicated subnet
TCP 443 only
Candidate Service Tag only
No parallel firewall or route change

Positive gates
Application export succeeds with correlation ID
Effective NSG result names the intended allow rule
Destination IP belongs to the captured tag snapshot
VNet flow logs show the expected tuple and decision
Error and retry rates return to the accepted baseline

Negative gates
Control destination remains denied
No unexpected ports become reachable
No broader rule masks the candidate
No unexplained destination prefix appears

Utilisez les Virtual Network flow logs pour une nouvelle collecte. La création de nouveaux NSG flow logs n’est plus disponible et ce mécanisme est en retrait. Les logs prouvent le tuple réseau observé ; corrélez-les avec la requête applicative, car un flux TCP autorisé ne prouve pas que la télémétrie a été acceptée par le bon service.

Automatiser la dérive utile

Le Service Tag évolue hors de votre pipeline IaC. Une automatisation raisonnable capture périodiquement le tag, compare son changeNumber et son ensemble de préfixes, puis ouvre une revue quand le périmètre change.

On service tag change
Store old and new changeNumber
Produce added and removed CIDR sets
Identify every NSG and UDR using the tag
Re-run positive and negative flow tests
Verify application probes and VNet flow logs
Require review when scope or dependencies change

Do not
Expand custom IP allowlists automatically
Treat a prefix addition as proof of compromise
Remove a prefix before dependent traffic has drained
Skip validation because Microsoft manages the tag

Le bon signal n’est pas « le tag a changé », mais « le changement modifie le périmètre d’une règle qui protège tel flux ». Reliez donc l’inventaire réseau au propriétaire applicatif et au test de validation.

Décider promotion, correction ou rollback

Terminez le changement avec une décision explicite.

promote:
when:
- purpose-and-direction-match
- effective-rule-is-the-intended-rule
- positive-and-negative-tests-pass
- application-and-flow-evidence-correlate

correct:
when:
- a-regional-tag-can-reduce-scope
- a-required-dependent-tag-is-missing
- another-rule-masks-the-candidate
action: revise-and-repeat-canary

rollback:
when:
- unexpected-destination-becomes-reachable
- application-failure-rate-increases
- effective-decision-cannot-be-explained
action:
- remove-candidate-rule
- restore-previous-priorities
- verify-control-deny
- reconcile-in-flight-exports

Rollbackez la règle, pas l’ensemble de la politique réseau. Conservez le snapshot du tag et les résultats avant/après afin de distinguer un problème de scope, de priorité, de route ou d’application.

Conclusion

Un Service Tag simplifie la maintenance des préfixes Azure, mais il ne remplace ni un contrat de flux ni une identité de destination. Une règle NSG exploitable doit relier besoin applicatif, direction, port, scope régional éventuel, préfixes au moment du changement et règle effective.

La bonne décision arrive après un test positif, un test de refus, un canari et une preuve applicative corrélée aux logs réseau. Si le périmètre ne peut pas être expliqué ou si une autre règle décide le flux, corrigez avant de promouvoir. Si le canari élargit l’accès ou dégrade le service, retirez la seule règle candidate et revenez à l’état capturé.