3 — Virtual Network Security (AZ-500)

Sécuriser le plan réseau Azure (segmentation, filtrage, chiffrement en transit, gouvernance centralisée) du point de vue d'un défenseur, pas d'un architecte connectivité.

Note de cadrage — Tu connais déjà NSG/ASG, Azure Firewall, VPN, peering et vWAN côté connectivité (AZ-700). Cette fiche ne ré-explique pas le fonctionnement de l'infra : elle se concentre sur l'angle sécurité AZ-500 — gouvernance centralisée (AVNM), précédence des règles, chiffrement en transit, et durcissement des firewalls de ressources PaaS. Détail infra (SKU, routage BGP, tunnels, scale units) → AZ-700.

A. NSG / ASG — l'angle sécurité

Rappel express (détail → AZ-700) : NSG = ACL stateful inbound/outbound, associable subnet ET/OU NIC. ASG = groupement logique de NIC référençable comme source/destination (micro-segmentation sans gérer des IP).

Ce qui compte pour AZ-500 :

🚨 Pièges

• NSG stateful : autoriser l'inbound suffit, le retour est implicite. Ne pas créer de règle outbound miroir « par sécurité » (bruit).
• NSG sur GatewaySubnet : non supporté / déconseillé (casse le gateway VPN/ER).
• Un NSG appliqué à un seul NIC d'une VM multi-NIC n'affecte que ce NIC.
• ASG : source et destination doivent être dans la même VNet (limite de portée).

📐 Réf. MCSB — NS-1 Establish network segmentation boundaries : segmenter par NSG/subnet est le contrôle de base. Lien

B. Azure Virtual Network Manager (AVNM) — Security Admin Rules

LE sujet AZ-500 nouveau par rapport à AZ-700. AVNM applique des configs (connectivity + security) à des network groups (statiques ou dynamiques via Azure Policy) à l'échelle d'un management group / subscription.

Security admin rules = règles de sécurité globales évaluées AVANT les NSG. Un owner de NSG ne peut pas les override → garde-fous centraux + flexibilité locale.

Sémantique des 3 actions (à connaître par cœur) :

• Allow → évaluée, puis passe la main aux NSG (le NSG peut encore Deny).
• Always Allow → termine l'évaluation, va direct à la ressource, les NSG ne peuvent plus bloquer (force-allow monitoring/updates).
• Deny → stoppe net, aucun NSG ne peut ré-autoriser.

🚨 Pièges

• Modèle de cohérence éventuelle : les admin rules s'appliquent avec un léger délai aux ressources (et aux nouvelles ressources ajoutées au VNet).
• Non-application par défaut sur VNets contenant SQL Managed Instance ou Databricks (network intent policies prioritaires). Contournement : AllowRulesOnly (champ applyOnNetworkIntentPolicyBasedServices) → seules les règles Allow s'appliquent, jamais les Deny.
• Non-application au niveau subnet pour App Gateway, Bastion, Azure Firewall, Route Server, VPN/ER Gateway, vWAN.
• Ne s'appliquent pas aux private endpoints d'un managed VNet, ni aux VNets non gérés par l'instance AVNM.
• Cas d'usage type : bloquer les high-risk ports (RDP 3389 / SSH 22) globalement avec exceptions ciblées par priorité.

📐 Réf. — Security admin rules vs NSG (precedence officielle) : « Security admin rules take precedence over rules that network security groups define ». Lien

C. UDR & forced tunneling — forcer l'inspection

Rappel : UDR = route table custom associée au subnet, override les routes système. Détail routage → AZ-700.

Angle sécurité : la route 0.0.0.0/0 → next hop Virtual Appliance (IP privée de l'Azure Firewall / NVA) force tout le trafic sortant à transiter par l'inspection. C'est le pattern de base d'un hub-spoke sécurisé self-managed.

🚨 Pièges

• Next hop type VirtualAppliance exige IP Forwarding activé sur le NIC du NVA (sinon le NVA droppe). IP Forwarding doit rester désactivé sur les VM ordinaires (MCSB NS-3).
• En secured virtual hub (vWAN), on n'écrit pas d'UDR : le routing intent les génère automatiquement (voir §E).
• Une UDR mal pensée vers le firewall peut créer du routage asymétrique (retour qui ne repasse pas par le FW) → drops. Symétrie obligatoire.

📐 Réf. MCSB — NS-3 Deploy firewall at the edge : l'inspection centralisée s'appuie sur le forçage de route. Lien

D. VPN / Peering / VNet encryption — chiffrement en transit

VNet encryption : chiffre le trafic VM↔VM sur le backbone Azure (option, dépend du HW). C'est le complément quand IPsec/MACsec ne s'appliquent pas (flux intra-Azure).

🚨 Pièges

• Peering ≠ chiffrement automatique : le trafic peered traverse le backbone Microsoft (privé) mais non chiffré sauf si VNet encryption est activée.
• ExpressRoute private peering non chiffré par défaut — erreur classique de croire que « privé » = « chiffré ».

📐 Réf. CAF — Define network encryption requirements (flows A/B/C, où appliquer IPsec/MACsec/VNet encryption). Lien

E. Virtual WAN + Secured Virtual Hub — sécurité managée

Rappel : secured virtual hub = hub vWAN + Azure Firewall (ou NVA / SaaS SECaaS) intégré, piloté par Azure Firewall Manager. Routage auto, pas d'UDR à écrire.

Routing intent = le levier sécurité. Deux policies max par hub :

• Internet Traffic policy → tout l'egress Internet des spokes/branches passe par le FW (advertise 0.0.0.0/0).
• Private Traffic policy → tout le trafic branch↔VNet, VNet↔VNet, inter-hub, branch↔branch passe par le FW.

🚨 Pièges

• Routing intent obligatoire pour inspecter le trafic inter-hub / branch-to-branch, même avec un seul hub. Sans lui, ces flux ne sont pas inspectés.
• Inspection inter-hub symétrique → routing intent doit être activé sur tous les hubs.
• Forced tunnel (egress vers on-prem) disponible uniquement avec routing intent + private policy. Migration direct↔forced : retirer 0.0.0.0/0 des additional prefixes avant d'activer l'internet policy (ordre imposé).
• Bypass Azure Firewall pour le private traffic = trafic privé non inspecté (choix explicite, à justifier).

📐 Réf. WAF — Hub-spoke vWAN, improved security : « all traffic flows are inspected by a firewall » via secured hubs centralisés. Lien

F. Sécuriser P2S/S2S + Encryption over ExpressRoute

P2S (point-to-site) — authentification :

• Microsoft Entra ID auth : supportée uniquement avec tunnel OpenVPN (SSL) + Azure VPN Client. Débloque Conditional Access + MFA sur le VPN → c'est l'option à recommander en sécurité.
• Autres : certificat (IKEv2/SSTP/OpenVPN), RADIUS. Basic SKU ne supporte pas OpenVPN.
• App registration : nouvel App ID Microsoft-registered évite le consentement manuel (plus sûr, pas de rôle Cloud App Admin requis). Les clients manually registered retirent (Public Cloud le 31 mars 2028).

Encryption over ExpressRoute (ER non chiffré par défaut) :

MACsec et IPsec indépendants et combinables (MACsec = lien physique, IPsec = bout-en-bout).

🚨 Pièges

• MACsec impossible sur circuit ER via provider — réservé à ER Direct (la clé doit appartenir à une seule entité).
• MACsec : tout le trafic du lien est chiffré (BGP + data), pas de fallback non-chiffré en cas de mismatch de clé → perte de connectivité (prévoir fenêtre de maintenance, changer un lien à la fois). XPN ciphers recommandés ≥40 Gbps.
• Entra P2S sans OpenVPN = impossible (piège récurrent : croire que ça marche en IKEv2).

📐 Réf. — About encryption for ExpressRoute (MACsec L2 vs IPsec L3, indépendants). Lien

G. Firewalls de ressources Azure (PaaS) — « Selected networks »

Durcir les resource firewalls des services PaaS (Storage, Key Vault, SQL…) : passer de Enabled from all networks à Enabled from selected networks (ou Disabled + private endpoint).

Storage — 4 types de règles réseau :

1. Virtual network rules (subnet via service endpoint), 2. IP network rules (plages publiques), 3. Resource instance rules (instance Azure précise), 4. Trusted service exceptions.

🚨 Pièges

• Trusted Microsoft services bypass : exception qui prime sur les règles réseau (ex. ExpressRoute = trusted service peut bypasser le firewall Key Vault stockant les clés MACsec). À cocher en connaissance de cause.
• Private endpoint : son trafic n'est jamais soumis aux règles de firewall réseau ni au network security perimeter → connexion toujours réussie. Pour vraie isolation : PE + Public network access = Disabled.
• Subtilité defaultAction : mettre Public access = Disabled via template ne change pas forcément defaultAction de Allow → Defender/Advisor alertent encore. Portail/CLI mettent Deny automatiquement.
• Network Security Perimeter (NSP, évolution récente) : en mode enforced, le profil du périmètre override le firewall propre de la ressource → top-level gatekeeper.

📐 Réf. MCSB — NS-2 Secure cloud native services with network controls (restreindre l'accès réseau aux services PaaS). Lien

H. Network Watcher — monitoring sécurité

🚨 Pièges

• NSG flow logs retirés le 30 sept. 2027 ; plus de création depuis le 30 juin 2025. Migrer vers VNet flow logs (à connaître pour l'exam — dates et remplacement).
• Activer NSG flow logs et VNet flow logs sur le même workload → double comptage + surcoût. Désactiver les NSG flow logs d'abord.
• Storage account recevant les flow logs ne doit pas avoir de règles réseau bloquant les services Microsoft.

📐 Réf. — VNet flow logs vs NSG flow logs (retrait + support AVNM/encryption). Lien

🏢 Scénarios d'entreprise (CAF/WAF)

Scénario 1 : Banque — gouvernance réseau multi-souscriptions non-contournable

Contexte business : une banque a ~80 souscriptions, chaque équipe gère ses propres NSG. La sécurité centrale veut garantir que RDP/SSH depuis Internet reste bloqué partout, sans qu'une équipe puisse le rouvrir.

Choix architectural : Azure Virtual Network Manager (AVNM) impose des règles Deny prioritaires sur tous les VNets prod ; les NSG restent aux équipes pour le réglage fin.

Architecture / pattern :

• AVNM au niveau racine ; les nouveaux VNets prod rejoignent le groupe automatiquement (via Azure Policy).
• Règles Deny sur les ports à risque (3389, 22…) depuis Internet, prioritaires sur les NSG.
• Exceptions ciblées via règle Allow prioritaire pour les VNets de gestion légitimes.
• Flow logs + Traffic Analytics pour prouver à l'audit que c'est bien appliqué.

Trade-offs assumés :

• Gain : interdiction impossible à contourner, conformité démontrable, nouveaux VNets couverts automatiquement, les équipes gardent leurs NSG.
• Perte : léger délai de propagation ; ne s'applique pas nativement aux VNets SQL MI/Databricks (mode AllowRulesOnly) ; une couche de gouvernance de plus à gérer.

Pièges à éviter :

• Un Deny ne protège pas un VNet contenant SQL MI, sauf en AllowRulesOnly (et alors aucun Deny possible).
• Les private endpoints d'un VNet managé échappent aux admin rules.

📐 Réf. CAF — Azure Virtual Network Manager in Azure landing zones : admin rules pour deny/allow centralisés « regardless of the rules in the NSGs ». Lien

Scénario 2 : Industrie — hub-spoke multi-régions avec inspection forcée de tout le trafic

Contexte business : un industriel multi-sites, sur plusieurs régions Azure, exige qu'aucun flux (sortie Internet, entre spokes, entre hubs, entre sites) n'échappe au pare-feu, avec un minimum de config réseau manuelle.

Choix architectural : Virtual WAN avec secured hubs (Azure Firewall intégré) et routing intent activé sur tous les hubs.

Architecture / pattern :

• Un secured hub par région, policy centrale via Azure Firewall Manager.
• Routing intent Internet + Private → le pare-feu inspecte tout le trafic.
• Forced tunnel si la sortie doit passer par on-prem.
• Aucune route manuelle (UDR) : elles sont générées par le hub.

Trade-offs assumés :

• Gain : inspection complète (y compris entre hubs et entre sites), routage géré par Microsoft, moins d'erreurs, scaling multi-régions natif.
• Perte : coût (Azure Firewall + routing units), moins de contrôle fin qu'un hub fait main, limites du modèle vWAN (80 IP publiques/FW standard).

Pièges à éviter :

• Activer routing intent sur un seul hub ne suffit pas : il faut tous les hubs (symétrie).
• Bypass Azure Firewall sur le trafic privé crée un trou d'inspection silencieux.

📐 Réf. WAF — Hub-spoke vWAN : secured hubs centralisés, « all traffic flows are inspected by a firewall ». Lien

Scénario 3 : Santé — chiffrement bout-en-bout vers Azure + PaaS verrouillé

Contexte business : un hôpital (données patients, HDS/HIPAA) relié à Azure par ExpressRoute Direct exige un chiffrement obligatoire en transit sur le lien, et que Storage/Key Vault ne soient jamais accessibles depuis Internet.

Choix architectural : double chiffrement du lien — MACsec (niveau 2) + IPsec (niveau 3) — et PaaS fermés via Selected networks + private endpoints.

Architecture / pattern :

• ER Direct : MACsec activé, clés stockées en Key Vault, chiffrement XPN (lien ≥40 Gbps), rotation planifiée.
• IPsec par-dessus ER pour le chiffrement bout-en-bout on-prem ↔ VNet.
• Storage/Key Vault : accès public Disabled + private endpoints ; bypass autorisé pour les services de confiance (lecture des clés MACsec).
• Flow logs avec statut de chiffrement pour l'audit.

Trade-offs assumés :

• Gain : défense en profondeur (L2+L3), secrets jamais exposés publiquement, conformité démontrable.
• Perte : MACsec impose ER Direct (coût/engagement) ; risque de coupure lors d'une rotation de clé ; gestion des clés complexe.

Pièges à éviter :

• Croire que le private peering ER est « déjà chiffré » → faux, il faut l'ajouter explicitement.
• Une clé MACsec qui ne correspond pas = coupure totale (aucun fallback) → changer un lien à la fois.
• Un private endpoint ignore le firewall de la ressource : pour une vraie isolation, désactiver aussi l'accès public.

📐 Réf. CAF — Define network encryption requirements (MACsec flow B sur ER Direct, IPsec flow C). Lien

DEMO — chemins portail

1. Créer une Security Admin Rule (AVNM) qui Deny RDP partout

Network Manager → Configurations → Security admin configurations → + Create → créer une Rule collection ciblant un network group → + Add rule : Action Deny, Direction Inbound, Source Service Tag = Internet, Destination port 3389, Priority basse → Save → Deploy sur les régions cibles. (Always Allow pour force-allow monitoring.)

2. Activer un Secured Virtual Hub + Routing Intent

Firewall Manager → Virtual hubs → sélectionner le hub → Security configuration → Internet traffic = Azure Firewall, Private traffic = Send via Azure Firewall, Inter-hub = Enabled → (forced tunnel : ajouter 0.0.0.0/0 aux additional prefixes) → Save. Répéter sur chaque hub.

3. Configurer P2S avec Microsoft Entra ID + OpenVPN

Virtual network gateway (ou User VPN config en vWAN) → Point-to-site configuration → Tunnel type = OpenVPN (SSL), Authentication type = Microsoft Entra ID → renseigner Tenant (https://login.microsoftonline.com/{TenantID}), Audience (App ID Microsoft-registered), Issuer → Save → Download VPN client (Azure VPN Client). MFA/Conditional Access via Entra.

4. Activer MACsec sur ER Direct (clé en Key Vault)

ExpressRoute Direct → Ports → sélectionner le port → MACsec → référencer la user-assigned identity ayant accès GET sur le Key Vault, renseigner CKN/CAK secrets + Cipher (GcmAesXpn256 ≥40 Gbps) → activer port par port. Configurer la même clé côté edge on-prem.

5. Verrouiller un Storage Account + activer VNet flow logs

Storage account → Networking → Enabled from selected networks → ajouter VNet rules / IP rules / Resource instances → cocher/décocher Allow trusted Microsoft services selon besoin (ou Disabled + Private Endpoint). Puis Network Watcher → Flow logs → + Create → cible Virtual network, Storage destination + Enable Traffic Analytics (Log Analytics workspace). Désactiver d'abord d'éventuels NSG flow logs sur le même workload.