7 — Network Connectivity and Security

Concevoir un réseau Azure sécurisé et évolutif → liaison hybride (VPN, ExpressRoute), sécurisation du trafic (Azure Firewall, DDoS), DNS privé/public et topologie (Hub-Spoke vs Virtual WAN).

A. Azure Firewall

A.1 SKUs

A.2 Firewall Policy

Ressource indépendante qui contient toutes les règles → attachable à 1 ou N firewalls. Remplace les classic rules.

3 types de rule collections :

• DNAT : Inbound NAT (internet → backend privé)
• Network : L3/L4 (IP/port, Service Tags)
• Application : L7 FQDN (HTTP/S, TLS inspection en Premium)

🚨 Network évaluée AVANT Application → une App "Allow" n'override pas une Network "Deny".

A.3 Parent / Child policies

Pattern enterprise : SecOps = parent (règles obligatoires globales) → équipes app = child (workload-specific). Parent toujours évalué avant child.

A.4 1 policy → N firewalls

Une policy attachée à N firewalls régionaux. Update 1× = propagation auto. C'est le pattern ALZ multi-région attendu au 305.

B. Diagnostics réseau hybride — Network Watcher

Pour debug réseau Azure (et hybride pour 1 outil seulement).

🎯 "Monitor continu DEPUIS machine on-prem" → Connection Monitor (le seul hybride). 🎯 "VPN qui tombe, debug" → VPN Troubleshoot.

C. DDoS Protection

🚨 DDoS = L3/L4 (volumétrique). L7 (HTTP flood) = WAF rate-limiting (voir fiche 6) → complémentaires. 🎯 Entreprise / plusieurs IPs → Network Protection. Peu d'IPs / budget → IP Protection.

D. Topologie — Hub-Spoke vs Virtual WAN

D.1 Vue comparative

D.2 Virtual WAN — 2 tiers

D.3 Secured Virtual Hub

vWAN Standard + Azure Firewall intégré dans le hub géré MS → sécurité centralisée sans construire un hub Firewall toi-même.

🎯 Au 305 :

• "Peu de régions, control total, NVA tiers (Palo Alto/F5)" → Hub-Spoke custom
• "Multi-régions/branches, SD-WAN, scale global, sécurité centralisée" → vWAN Standard + Secured Hub

E. Hybride — VPN Gateway vs ExpressRoute

E.1 Vue comparative

E.2 VPN Gateway — SKUs

3 types de connexions VPN :

• Site-to-Site (S2S) : site on-prem ↔ Azure (LAN entier)
• Point-to-Site (P2S) : laptop / remote worker ↔ Azure (1 user)
• VNet-to-VNet (V2V) : VNet ↔ VNet cross-region (alternative au peering)

🚨 Remote workers laptops = P2S, jamais S2S (S2S = LAN entier). 🚨 Basic SKU : pas de BGP, pas de zone-redundancy → éviter prod.

E.3 ExpressRoute — SKUs

Circuit SKU (le tier du circuit)

Modèles de connexion

🚨 "Premium" et "Direct" = 2 axes ORTHOGONAUX : SKU Premium = reach global (multi-region cross-geo) + Global Reach + routes BGP. Modèle Direct = connexion physique directe MS edge (10/100 Gbps owned). Combo "Premium Direct" = très haute exigence enterprise (multi-region + 100 Gbps dédié). Distractor exam : "Premium" seul ≠ "Direct" seul → bien lire l'énoncé (global scope vs débit/ownership physique).

Features critiques

E.4 Combos prod design 305

🚨 HA gateway = utiliser zone-redundant SKU (VpnGwXAZ ou ER Gateway zonal).

F. DNS design (light, AZ-305)

F.1 Les 3 types de zones DNS Azure

F.2 DNS Private Resolver — use case AZ-305

• Inbound endpoint : forwarder DNS depuis on-prem → résolution Azure (PE, services)
• Outbound endpoint : forwarder Azure → on-prem (résolution AD on-prem depuis VMs Azure)
• Rulesets : conditional forwarding par domaine

🎯 Question 305 : "Résoudre privatelink.X.azure.com depuis on-prem via ER" → DNS Private Resolver inbound endpoint.

G. Rappels AZ-104 (compact)

🚨 Private Endpoint > Service Endpoint en prod moderne (DNS privé + isolation totale).

H. Decision tree network AZ-305

Connectivity hybride

On-prem → Azure ?
├─ Petit débit, budget mini, internet OK    → VPN Gateway S2S
├─ Gros débit + latence prévisible          → ExpressRoute Standard/Premium
├─ Multi-régions branches SD-WAN            → Virtual WAN + ER
├─ Remote workers laptops                   → P2S VPN
└─ Prod critique HA                         → ER primary + VPN failover (combo)

Topologie

Combien de régions / VNets ?
├─ 1-3 régions, control total NVA           → Hub-Spoke custom
├─ N régions/branches, scale, sécurité auto → Virtual WAN Standard + Secured Hub

Sécurité périmètre

Type d'attaque protégée ?
├─ DDoS volumétrique L3/L4                  → DDoS Network Protection
├─ OWASP L7 (régional ou global)            → WAF (voir fiche 6 - App Gateway WAF v2 ou Front Door WAF Premium)
├─ Egress filtering FQDN/IP/TLS inspection  → Azure Firewall Premium
└─ Defense-in-depth bancaire                → FD WAF + AGW WAF + Azure Firewall

I. Scénarios 305 → solution

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

Scénario 1 : Banque de détail — Hub-Spoke multi-région avec inspection centralisée

Contexte business : Banque sur 3 régions Azure (FR Central + EU North en DR). La réglementation exige que tout trafic (spoke↔spoke, spoke↔internet, hybride) passe par un firewall stateful avec IDPS. 1 équipe plateforme centrale + 12 équipes app autonomes. Choix architectural : Hub-Spoke fait main (contrôle total) + Azure Firewall Premium dans chaque hub. Pour garder des règles cohérentes : 1 Firewall Policy parent (SecOps) dont héritent des child policies par équipe. Une UDR force tout le trafic spoke (0.0.0.0/0) vers le firewall. Architecture / pattern :

• 1 hub + 1 Azure Firewall Premium par région ; peering hub↔spoke non-transitif
• Parent policy (Threat Intel Deny, IDPS, règles obligatoires) toujours évaluée avant la child policy de l'équipe
• DNS Private Resolver + Private DNS zones dans le hub pour privatelink.* ; DDoS Network Protection sur les VNets Trade-offs assumés :
• Gain : contrôle total du routage, isolation par équipe, règles obligatoires propagées en 1 seul update
• Perte : tout l'exploitation du hub (firewall, UDR, peering) repose sur l'équipe plateforme ; pas de transit any-to-any automatique Pièges à éviter :
• IDPS Alert and Deny + inspection TLS divisent le débit Premium par ~10 (→ ~10 Gbps) : dimensionner en conséquence
• Croire qu'une App rule "Allow" annule une Network rule "Deny" : les Network rules passent avant
• Nouveaux VNets en subnets privés par défaut (API post-31/03/2026) : prévoir l'egress explicite via firewall (UDR) 📐 Réf. CAF — Network topology and connectivity (design area) : la topologie hub-spoke avec hub géré par l'équipe plateforme dans la subscription Connectivity (Firewall, DNS privé, gateways) est le pattern ALZ de référence pour le routage IP traditionnel/hybride. Lien

Scénario 2 : Distribution / retail — Virtual WAN global avec Secured Hub

Contexte business : Enseigne avec 400 magasins (branches SD-WAN), 6 régions Azure, télétravailleurs nomades. Besoin : transit any-to-any branche↔branche↔VNet, sans construire ni gérer de hubs soi-même. Choix architectural : Virtual WAN Standard (hub managé par Microsoft) avec Secured Virtual Hub (Azure Firewall intégré). Choisi car Microsoft opère le routage inter-hub à notre place. Connectivité mixte ExpressRoute + S2S VPN (branches) + P2S VPN (nomades). Architecture / pattern :

• Hubs vWAN multi-région, maillage any-to-any automatique sur le backbone Microsoft
• Routing intent pousse 0.0.0.0/0 vers le firewall du hub (accès direct ou forced tunnel vers l'egress on-prem)
• Private Endpoints accessibles via le hub Trade-offs assumés :
• Gain : zéro gestion des peerings/routage, scale-out par scale unit, branch-to-branch et sécurité centralisée fournis
• Perte : moins flexible qu'un NVA tiers custom ; en Secured Hub, l'IP publique du firewall ne peut pas venir d'un prefix ni recevoir de DDoS Protection Pièges à éviter :
• Prendre vWAN Basic : c'est S2S VPN seulement (pas d'ExpressRoute, ni P2S, ni Secured Hub) → il faut Standard
• Global Reach entre régions géopolitiques exige des circuits ExpressRoute Premium (pas Standard)
• La bascule Basic → Standard est irréversible 📐 Réf. CAF — Virtual WAN network topology in an Azure landing zone : vWAN est le modèle ALZ recommandé pour la connectivité globale, transitive et dynamique multi-région à fort nombre de branches. Lien

Scénario 3 : Santé / assurance — Zero-Trust accès PaaS via Private Endpoint

Contexte business : Assureur santé dont les données (SQL, Storage, Key Vault) ne doivent pas être exposées sur internet. Accès requis depuis les VNets Azure ET depuis le datacenter on-prem (ExpressRoute), sans aucune route internet vers le PaaS. Choix architectural : Private Endpoint sur chaque service PaaS (IP privée dans le VNet) + Private DNS zones (privatelink.*) + DNS Private Resolver pour la résolution depuis on-prem. Accès public coupé sur les ressources cibles. Architecture / pattern :

• 1 Private Endpoint par instance PaaS (limite l'exfiltration) ; NSG/ASG sur le subnet des PE
• Private DNS zones liées à tous les VNets ; le resolver inbound endpoint est la cible des forwarders on-prem
• Option : UDR sur le subnet PE pour inspecter le trafic via Azure Firewall (flux symétrique via SNAT) Trade-offs assumés :
• Gain : plus d'exposition internet, trafic sur le backbone Microsoft, accès cross-region et hybride
• Perte : coût et complexité DNS (une mauvaise config = fuite vers l'IP publique) ; 1 PE facturé par instance Pièges à éviter :
• DNS mal configuré : sans la bonne Private DNS zone liée au bon VNet, la résolution retombe sur l'IP publique → trafic hors private endpoint
• Confondre Private Endpoint (IP privée, recommandé) et Service Endpoint (backbone mais IP publique du service)
• Oublier d'activer le support NSG sur le subnet PE (désactivé par défaut) 📐 Réf. — Secure your Azure Private Link deployment : recommandations Zero-Trust pour Private Endpoint (mapping instance-level, NSG/ASG, Private DNS Resolver hybride, désactivation de l'accès public). Lien

DEMO

Demo Portail — Azure Firewall Policy parent/child

Parent policy SecOps (Premium) :

1. Firewall Policies > + Create
2. Basics : RG rg-secops, Name parent-policy, Tier Premium
3. DNS : Enable DNS Proxy ON
4. Threat Intel : mode Deny
5. IDPS : mode Alert (puis Alert+Deny après tuning)
6. Rules → + Add a rule collection group :
   • Name rcg-base, Priority 200
   • Dans le RCG → + Add a rule collection :
     • Name rc-network, Type Network, Priority 200, Action Allow
     • Rule allow-proxy : Source 10.0.0.0/8, Protocol TCP, Dest 203.0.113.10:8080
7. Review + Create

Child policy équipe app (héritage parent) :

1. Firewall Policies > + Create
2. Basics : RG rg-app, Name child-app-policy, Tier Premium (SKU match parent)
3. Cocher Inherits from a parent policy → sélectionner parent-policy
4. Rules : ajouter ses RCGs workload-specific
5. Review + Create

Attacher child policy au firewall :

1. Firewalls > myfirewall > Firewall policy > Change firewall policy
2. Sélectionner child-app-policy → Save

Parent rules s'exécutent avant child, toujours. Ordre global : Threat Intel → IDPS → DNAT → Network → Application.

Demo Portail — 1 policy → N firewalls (ALZ multi-region)

1. Créer 1 seule policy central-policy (SecOps RG)
2. Pour chaque firewall régional : Firewalls > <fw> > Firewall policy > Change firewall policy > central-policy > Save
3. Update unique sur la policy = propagation auto aux N firewalls

Demo Portail — Connection Monitor (hybride)

1. Network Watcher > Connection Monitor > + Create
2. Basics : Name cm-hybrid-test, Region (toute région supportée)
3. Test groups :
   • + Add test group : Name onprem-to-sql
   • Sources : VM on-prem (agent installé) ou Arc-enabled
   • Destinations : mysrv.database.windows.net (Azure SQL)
   • Test configuration : TCP/443, frequency 30s
4. Review + Create
5. Monitor → graphes latence + perte + hop-by-hop

Demo Portail — ExpressRoute (vue)

Le setup ER nécessite coordination avec un Provider — au 305 c'est awareness, pas mise en place.

1. ExpressRoute circuits > + Create
2. Basics : RG, Name er-paris
3. Configuration :
   • Port type : Provider (Equinix, Orange…) ou Direct (10/100 Gbps direct MS)
   • Provider : (selon Provider choisi)
   • Peering location : ex Paris
   • Bandwidth : 1 Gbps (ou autre)
   • SKU : Local / Standard / Premium
   • Billing model : Metered ou Unlimited
4. Review + create → MS provisionne le circuit côté backbone, tu finalises avec ton Provider qui livre le lien physique
5. Activer Global Reach si besoin de connecter 2 sites on-prem via backbone MS