Azure Network Watcher : migrer les NSG Flow Logs sans perdre la preuve réseau

Les NSG Flow Logs Azure ne peuvent plus être créés et leur retrait est annoncé pour le 30 septembre 2027. Attendre la dernière fenêtre transforme une évolution connue en incident d’observabilité : les fichiers historiques restent soumis à la rétention du compte de stockage, mais les ressources de flow logs et Traffic Analytics associés aux NSG ne constituent plus une cible durable.

Le cas d’usage est une plateforme Azure en hub-and-spoke. Plusieurs NSG Flow Logs alimentent un compte de stockage et un workspace Log Analytics. Des requêtes KQL, alertes et runbooks utilisent encore AzureNetworkAnalytics_CL. L’objectif n’est pas seulement d’activer les Virtual Network Flow Logs. Il faut prouver que le nouveau périmètre couvre les flux utiles, adapter les consommateurs au schéma NTANetAnalytics, puis désactiver l’ancien chemin sans trou de visibilité ni double collecte durable.

Figer le contrat d’observabilité avant la migration

Commencez par les décisions que les logs doivent soutenir. Un inventaire de ressources ne dit pas si l’équipe saura encore expliquer un refus réseau, une sortie inattendue ou un flux inter-VNet après la bascule.

scope:
subscriptions: [prod-connectivity, prod-workloads]
regions: [westeurope]
virtual_networks: [vnet-hub-prod, vnet-app-prod]
evidence_to_preserve:
- allowed_and_denied_flows
- source_destination_protocol_port
- nsg_and_rule_when_available
- bytes_packets_and_flow_count
- traffic_analytics_queries
consumers:
- soc-network-workbook
- denied-flow-alert
- incident-network-pack
acceptance:
overlap_hours: 24
max_ingestion_delay_minutes: 70
required_queries_green: 4
rollback:
keep_nsg_flow_logs_enabled_until_acceptance: true
delete_new_flow_log_only_after_evidence_export: true

Le délai accepté doit tenir compte de Traffic Analytics : les blobs sont collectés par intervalles, puis agrégés avant leur arrivée dans Log Analytics. Une absence immédiate dans KQL n’est donc pas une preuve de panne.

Inventorier les flow logs et leurs consommateurs

Listez les ressources existantes, leur cible, leur rétention et l’activation de Traffic Analytics. Relevez aussi les requêtes, workbooks, alertes et exports qui dépendent de l’ancienne table. C’est souvent là que se trouve le vrai risque de migration.

SUBSCRIPTION_ID="00000000-0000-0000-0000-000000000000"
az account set --subscription "$SUBSCRIPTION_ID"

az network watcher flow-log list --location westeurope --query "[].{name:name,enabled:enabled,target:targetResourceId,storage:storageId,analytics:flowAnalyticsConfiguration.networkWatcherFlowAnalyticsConfiguration.enabled,workspace:flowAnalyticsConfiguration.networkWatcherFlowAnalyticsConfiguration.workspaceResourceId,interval:flowAnalyticsConfiguration.networkWatcherFlowAnalyticsConfiguration.trafficAnalyticsInterval}" --output table

Classez ensuite les NSG Flow Logs par VNet, subnet et NIC réellement couverts. Une migration agrégée au niveau VNet simplifie la configuration et évite les doublons, mais elle peut élargir le périmètre par rapport à une collecte limitée à quelques interfaces. Ce changement de couverture doit être assumé, chiffré et documenté avant création.

Utilisez le script de migration fourni par Network Watcher quand les configurations diffèrent ou quand seuls certains subnets et NIC sont journalisés. Azure Policy devient plus pertinente si la cible est homogène et doit s’appliquer à tous les VNets présents et futurs. Dans les deux cas, exécutez d’abord l’analyse et conservez son rapport avec le changement.

Vérifier les prérequis avant la double émission

La nouvelle ressource doit écrire dans un compte de stockage compatible, et Microsoft.Insights doit être enregistré. Vérifiez également les droits de l’identité qui crée le flow log et ceux nécessaires à Traffic Analytics sur le workspace.

az provider show --namespace Microsoft.Insights --query "registrationState" --output tsv

az storage account show --ids "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-observability-prod/providers/Microsoft.Storage/storageAccounts/stflowprod" --query "{name:name,location:primaryLocation,httpsOnly:enableHttpsTrafficOnly,networkDefaultAction:networkRuleSet.defaultAction}" --output yaml

N’ouvrez pas largement le compte de stockage pour faire passer la migration. Si l’écriture échoue, séparez autorisation, réseau du compte et configuration du flow log. Le correctif doit rester ciblé et réversible.

Activer un Virtual Network Flow Log canari

Commencez par un VNet représentatif, avec le même compte de stockage et le même workspace que l’ancien chemin. Gardez le NSG Flow Log actif pendant une fenêtre courte afin de comparer les deux sources.

RG_NETWORK="rg-network-prod"
RG_OBS="rg-observability-prod"
VNET="vnet-app-prod"
FLOW_LOG="fl-vnet-app-prod-weu"
STORAGE_ID="/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/$RG_OBS/providers/Microsoft.Storage/storageAccounts/stflowprod"
WORKSPACE_ID="/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/$RG_OBS/providers/Microsoft.OperationalInsights/workspaces/log-prod"

az network watcher flow-log create --location westeurope --resource-group "$RG_NETWORK" --name "$FLOW_LOG" --vnet "$VNET" --storage-account "$STORAGE_ID" --traffic-analytics true --workspace "$WORKSPACE_ID" --interval 10 --enabled true

Ne généralisez pas encore. Lancez des probes contrôlées : un flux autorisé, un refus NSG attendu, un flux intra-VNet et, si le périmètre le justifie, un flux inter-VNet. Notez les timestamps UTC, IP, ports et résultat attendu.

Valider le nouveau schéma KQL

Traffic Analytics utilise NTANetAnalytics pour les Virtual Network Flow Logs, en remplacement de AzureNetworkAnalytics_CL utilisé par les NSG Flow Logs. Une simple substitution de nom de table ne suffit pas : plusieurs colonnes perdent leur suffixe de type et le modèle de couverture change.

let StartTime = ago(2h);
let CanarySources = dynamic(["10.42.3.17", "10.42.3.18"]);
NTANetAnalytics
| where TimeGenerated > StartTime
| where SubType == "FlowLog"
| where SrcIp in (CanarySources) or DestIp in (CanarySources)
| summarize
  Flows = sum(AllowedInFlows + DeniedInFlows + AllowedOutFlows + DeniedOutFlows),
  Bytes = sum(BytesSrcToDest + BytesDestToSrc),
  FirstSeen = min(FlowIntervalStartTime),
  LastSeen = max(FlowIntervalEndTime)
by SrcIp, DestIp, DestPort, L4Protocol, FlowStatus, AclRule
| order by LastSeen desc

Les noms exacts des champs doivent être confirmés dans votre workspace : l’instrumentation, la version et les projections locales peuvent varier. Utilisez d’abord NTANetAnalytics | getschema, puis adaptez les requêtes. La validation doit répondre à quatre questions : les probes apparaissent-elles, les autorisations et refus sont-ils distinguables, les volumes restent-ils plausibles, et le délai d’ingestion respecte-t-il le contrat ?

Pendant le chevauchement, ne comparez pas les nombres ligne par ligne. Les deux solutions n’ont pas le même périmètre ni la même déduplication. Comparez des flux canaris connus et des tendances agrégées sur une fenêtre stable.

Migrer les consommateurs avant de couper la source

Dupliquez chaque requête critique vers NTANetAnalytics, puis faites pointer un workbook ou une alerte canari vers la nouvelle version. Gardez une matrice de validation explicite.

Consumer                  Old source                 New source          Status
SOC network workbook       AzureNetworkAnalytics_CL    NTANetAnalytics     validated
Denied flow alert          AzureNetworkAnalytics_CL    NTANetAnalytics     shadow
Incident network pack      AzureNetworkAnalytics_CL    NTANetAnalytics     validated
Monthly traffic export     storage NSG path            storage VNet path   pending

Cutover blocked while any critical consumer is pending.

Pour une alerte, exécutez d’abord la nouvelle requête en mode fantôme : même fenêtre, mêmes cas canaris, aucune notification d’astreinte. Comparez faux négatifs, bruit et délai, puis changez la source de l’alerte dans une modification séparée de la désactivation des anciens logs.

Décider la bascule et préparer le rollback

La bascule est autorisée quand les ressources VNet Flow Logs sont saines, que les blobs arrivent, que les requêtes critiques sont validées et que la couverture élargie ne crée pas un coût ou une exposition de données non acceptés. Désactivez alors les NSG Flow Logs sans les supprimer immédiatement.

decision: cutover
evidence:
vnet_flow_log_enabled: true
raw_blobs_present: true
traffic_analytics_delay_minutes: 34
canary_flows_found: 4/4
critical_consumers_validated: 3/3
storage_cost_reviewed: true
change:
disable_nsg_flow_logs: true
delete_nsg_flow_logs: false
validation_after_change:
- rerun four canary flows
- confirm NTANetAnalytics ingestion
- confirm workbook and shadow alert results
rollback_if:
- a canary flow is absent after the accepted delay
- a critical query cannot explain a known denial
- ingestion or storage authorization fails
rollback_action:
- re-enable the previous NSG flow logs
- keep the VNet flow log for diagnosis
- restore consumers to their previous queries

Supprimez les anciennes ressources seulement après une période d’observation et une sauvegarde des preuves de migration. Leur suppression ne supprime pas les données déjà présentes dans le compte de stockage ; leur cycle de vie reste gouverné par la rétention configurée.

Conclusion

Migrer les NSG Flow Logs ne se résume pas à créer une ressource Network Watcher. Le vrai changement porte sur le périmètre de collecte, le schéma Traffic Analytics et tous les outils qui transforment un flux en décision d’exploitation.

La bonne sortie est vérifiable : inventaire complet, canari en double émission, requêtes NTANetAnalytics validées, consommateurs migrés, anciens logs désactivés puis supprimés plus tard. Si une preuve critique manque, réactivez l’ancien chemin et corrigez le nouveau sans ouvrir une règle NSG pour compenser un problème d’observabilité.