2 — Routing and Interconnectivity

Contrôle du routage (UDR, BGP, Route Server) et interconnexion des réseaux (VNet Peering) → relier les VNets et atteindre les services PaaS en privé (Service/Private Endpoint) sans passer par internet.

A. User Defined Routes (UDR)

A.1 Routes système par défaut (Azure crée auto)

Ces routes ne sont pas modifiables directement, mais peuvent être overridées par une UDR.

A.2 Route Table (UDR)

• Ressource Azure régionale → contient des routes custom
• Associée au subnet (pas au VNet, pas à la NIC)
• Une route table peut être associée à plusieurs subnets
• Limite : 400 routes par table

A.3 Composition d'une route

⚠️ Pour qu'une NVA route le trafic → activer IP forwarding sur sa NIC (sinon le paquet est droppé).

A.4 Précédence des routes (la plus spécifique gagne, sinon par type)

Azure choisit d'abord par longest prefix match (la route au préfixe le plus spécifique gagne). À préfixe identique, l'ordre par type s'applique :

1. UDR (Custom)        ← à préfixe égal, gagne
2. BGP (ExpressRoute, VPN dynamic)
3. System routes       ← fallback Azure

🚨 Exception (piège) : les routes système pour VirtualNetwork (intra-VNet), VNet peering et Service Endpoints sont des preferred routes qui ne peuvent PAS être overridées par BGP, même si BGP annonce un préfixe plus spécifique. Et aucune UDR ne peut override une route Service Endpoint.

Cas typique : forcer le trafic via un Firewall NVA → UDR 0.0.0.0/0 → 10.0.0.4 (NVA) sur le subnet à filtrer.

A.5 Forced tunneling

Concept : forcer tout le trafic outbound internet d'un VNet à passer par on-prem (via VPN/ER) pour inspection.

Setup :

1. UDR sur le subnet : 0.0.0.0/0 → Next hop: Virtual network gateway
2. La GW relaie via VPN/ER vers le firewall on-prem qui filtre internet
3. Côté on-prem : router le trafic vers l'internet réel après inspection

Use case : compliance (gov, fintech), tout l'outbound doit être loggé/filtré côté on-prem avant d'atteindre internet.

A.6 Service chaining (hub-spoke + NVA)

Pattern où le trafic est routé à travers une séquence de NVAs (firewall, IDS) avant d'atteindre la destination.

Setup type :

1. NVA déployée dans VNet hub (peered aux spokes)
2. UDR sur subnets spokes : next hop = IP NVA dans hub
3. IP forwarding activé sur la NIC de la NVA
4. Peering options : Allow forwarded traffic côté hub (sinon NVA peut pas relayer entre spokes)

Use case : trafic spoke ↔ spoke ou spoke → on-prem doit traverser le firewall central dans le hub.

A.7 Diagnostic UDR

• Network Watcher > Next Hop : indique quel hop est appliqué pour un couple (VM, dest IP)
• Network Watcher > Effective routes (sur la NIC) : montre les routes effectives (system + UDR + BGP + peering)

B. Azure Route Server

Service managé qui permet à des NVAs (firewalls, SD-WAN, custom routers) d'échanger des routes BGP avec Azure SDN automatiquement.

B.1 Pourquoi ?

Sans Route Server, si tu veux qu'une NVA annonce ses routes au VNet :

• Tu dois maintenir des UDR statiques sur chaque subnet
• Quand la NVA apprend une nouvelle route on-prem, tu dois manuellement maj toutes les UDR

Avec Route Server :

• La NVA établit du BGP avec Route Server
• Route Server propage automatiquement ces routes BGP à tous les VNets peerés
• Pas besoin d'UDR manuelles, le routage est dynamique

B.2 Use cases typiques

• NVA SD-WAN (Cisco, Palo Alto, Fortinet…) qui apprend des routes des sites distants via BGP → propagation auto dans Azure
• ExpressRoute + VPN coexistence : assurer que les routes ER et VPN sont annoncées proprement
• Hub-spoke avec NVA centrale qui veut annoncer des routes spécifiques cross-spokes sans UDR

B.3 Caractéristiques

• Déployé dans un subnet dédié RouteServerSubnet (/26 minimum — pas de UDR ni NSG associables dessus)
• BGP only (pas OSPF, pas RIP)
• Limite : 16 BGP peers par Route Server (+ limites : 4000 routes/peer, 50 000 VMs, 500 VNets supportés)
• ASN Route Server : 65515 (fixe, Microsoft réservé)
• Branch-to-branch toggle : permet aux NVAs de s'échanger des routes via Route Server

C. VNet Peering

Connecte 2 VNets en privé via le backbone Azure → low latency, haute bande passante, pas de gateway requise.

C.1 Caractéristiques

• ✅ Cross region / subscription / tenant
• ❌ Pas d'overlap d'IP autorisé entre les 2 VNets
• ❌ Pas de transitivité : A↔B et B↔C n'implique pas A↔C
• 🔒 Chiffrement : quand le trafic traverse entre datacenters (hors périmètre physique MS), le hardware réseau applique MACsec (data-link layer) — applicable au trafic de peering. Pour un chiffrement host-level garanti VM↔VM (intra-VNet et cross-peering), activer Azure Virtual Network encryption (voir §C.6)
• Bilatéral : configurer A→B et B→A (sinon state = "Disconnected" / "Initiated")
• 📊 Limite : 500 peerings max par VNet → au-delà, passer sur Azure Virtual WAN (transitivité native)

💡 Peering en état Disconnected = l'un des 2 liens (A→B ou B→A) a été supprimé. Solution : delete le peer restant + recréer les 2 (pas de "reconnect" in-place).

💡 LocalNotInSync : si tu modifies l'address space d'un VNet déjà peered. Solution : Peering > Sync (pas besoin de delete + recreate).

C.2 Options de peering (à connaître pour AZ-700)

C.3 Le couple Gateway Transit ↔ Use Remote Gateways

Les 2 options vont toujours ensemble en miroir :

• Hub (qui a la VPN/ER GW) → Allow gateway transit ON = "je prête ma GW"
• Spoke (qui veut l'utiliser) → Use remote gateways ON = "j'emprunte celle du Hub"

Les 2 doivent être ON pour que ça fonctionne.

Exemple — un hub (VNet1) connecté à on-prem, deux spokes (VNet2, VNet3) peerés au hub : pour que les spokes atteignent l'on-prem via la GW du hub, configurer le couple gateway transit / use remote gateways sur chaque paire :

• VNet1 (Hub) : contient la VPN GW vers on-prem
• VNet1 → VNet2 peering : Allow gateway transit = ON ; VNet2 → VNet1 peering : Use remote gateways = ON
• VNet1 → VNet3 peering : Allow gateway transit = ON ; VNet3 → VNet1 peering : Use remote gateways = ON

VNet2 et VNet3 atteignent alors l'on-prem via la GW de VNet1.

⚠️ Gateway transit incompatible avec le VPN Gateway Basic SKU (Standard min). Spoke ne peut consommer qu'1 remote gateway à la fois (un spoke ne peut pas avoir 2 hubs avec gateway transit).

C.4 Allow forwarded traffic — quand l'activer ?

Règle : Allow forwarded traffic autorise le trafic relayé par une NVA (ou Azure Firewall) à entrer dans le VNet, pas juste le trafic émis directement par les VMs du peer.

Cas où il FAUT activer :

• Hub-Spoke avec NVA dans le hub qui route entre spokes :
  • Spoke1 → NVA dans Hub → Spoke2
  • Sur le peering Hub → Spoke2 : Allow forwarded traffic = ON (sinon le trafic relayé est dropé en arrivant à Spoke2)
• Forced tunneling via on-prem : trafic spoke → NVA hub → VPN GW → on-prem → ça remonte un retour. Côté retour, il faut Allow forwarded traffic sur les bons peerings.

Cas où on peut laisser OFF :

• Peering simple A ↔ B sans NVA au milieu → pas besoin
• Communication directe VM-à-VM via le peering classique

💡 Désactiver Allow VNet access = aucun trafic VM↔VM, dans aucun sens (pas de "single direction"). Cas légitime rare : peering uniquement pour gateway transit (Spoke utilise VPN du Hub sans pouvoir taper sur les VMs du Hub). Pour du blocage à sens unique → utiliser des NSG, pas le peering.

C.5 Config typique Hub-and-Spoke complet

→ Symétrie miroir entre chaque paire Hub↔Spoke.

C.6 Azure Virtual Network encryption

Chiffrement host-level du trafic VM↔VM : Azure crée un tunnel DTLS entre les VMs. Couvre le trafic intra-VNet, mais aussi cross-peering régional ET global (private IP → private IP).

Prérequis :

• SKU de VM supportées : séries Dv4/Ev4/Lsv3/Fv6 et plus récentes (D/E/M/L/F-series v4+). Trafic vers une VM non supportée → reste en clair.
• Accelerated Networking activé sur la NIC.
• Stop/start des VMs existantes après activation.

2 enforcement modes (champ enforcement) :

🚨 À ne PAS confondre avec MACsec : MACsec = chiffrement infra-level (data-link layer), appliqué automatiquement par le hardware réseau MS entre datacenters (côté ExpressRoute, déjà couvert). VNet encryption = host-level (DTLS), opt-in, scope VM↔VM.

⚠️ Incompatibilités : ne PAS activer dans un VNet contenant une ExpressRoute Gateway (casse la connexion on-prem), un Private Link Service, ou avec DNS Private Resolver / App Gateway / Azure Firewall dans le VNet.

D. Service Endpoints

Permet à un subnet d'accéder à un service PaaS public (Storage, SQL, KeyVault…) via le backbone MS au lieu d'internet, sans IP publique côté ressource.

D.1 Caractéristiques

• Configuré au niveau du subnet : Subnet > Service endpoints > Microsoft.Storage
• Active pour tous les comptes du même type dans la sub (Storage, Sql, KeyVault…) → granularité limitée
• Du côté du service : ajouter le subnet dans Networking > Selected networks > Virtual networks
• ❌ Ne fonctionne pas pour on-prem (le subnet doit être dans Azure)
• Gratuit
• Pas d'IP privée côté ressource (le PaaS garde son endpoint public, juste le routage est optimisé)

D.2 Service Endpoint Policy (SEP) AZ-700 specific

Concept : une Service Endpoint Policy restreint quel(s) compte(s) PaaS un subnet peut atteindre via Service Endpoint.

Sans SEP : si tu actives Microsoft.Storage Service Endpoint sur ton subnet → tes VMs peuvent atteindre n'importe quel Storage Account de la planète via le backbone.

Avec SEP : tu restreins à un Storage Account précis, à un RG entier, ou à une subscription entière.

Cas d'usage :

• Prévention d'exfiltration de données : tes VMs ne peuvent pas pousser de la donnée vers un Storage externe (perso ou attaquant)
• Compliance : seuls les Storage Accounts du tenant sont accessibles

Limites :

• Principalement Storage Account (Microsoft.Storage) — c'est le cas à connaître pour l'exam. MS a étendu le support : Azure SQL Managed Instance sait aussi filtrer son trafic Storage via SEP. Les autres managés (KeyVault, SQL DB, App Service…) ne supportent pas les endpoint policies.
• Le SEP est attaché au subnet après la Service Endpoint (subnet doit déjà avoir le Service Endpoint Microsoft.Storage activé)

⚠️ Service Endpoint Policy ≠ Private Endpoint. SEP filtre quoi un subnet peut atteindre via Service Endpoint. Private Endpoint crée une IP privée dans le subnet vers la ressource.

E. Private Link & Private Endpoint

E.1 Vocabulaire (très important pour AZ-700)

• Private Link = la technologie qui permet d'exposer un service Azure (ou tiers) avec une IP privée dans ton VNet.
• Private Endpoint = la NIC concrète déployée dans ton subnet, qui porte l'IP privée vers la ressource.
• Private Link Service = côté producer : ce que tu déploies pour exposer ton service à des clients tiers (Azure ou autre tenant).

E.2 Comparaison Service Endpoint vs Private Endpoint

E.3 Private Endpoint — fonctionnement

1. Tu choisis une ressource PaaS (Storage, SQL, KeyVault, App Service…)
2. Tu crées un Private Endpoint dans ton subnet
3. Azure provisionne :
   • Une NIC dans ton subnet avec une IP privée issue du address space du subnet
   • Une connection privée vers la ressource cible
4. Tu intègres avec une Private DNS Zone (privatelink.blob.core.windows.net, privatelink.database.windows.net…) pour que le FQDN public résolve vers l'IP privée

Schéma de flux :

VM (10.0.1.5) ──> nslookup mystorage.blob.core.windows.net
                       ↓
                Private DNS Zone (liée au VNet)
                       ↓
                Retourne 10.0.2.10 (IP du Private Endpoint)
                       ↓
VM ──> 10.0.2.10 (PE NIC) ──> Storage Account (backbone privé)

Planning du subnet hôte des Private Endpoints :

• Chaque PE consomme 1 IP privée du subnet (par sous-ressource ciblée). Prévoir l'adressage en conséquence.
• Aucune délégation de subnet requise (contrairement à d'autres services injectés).
• PrivateEndpointNetworkPolicies est Disabled par défaut → NSG et UDR sur le subnet du PE sont ignorés. À activer (NSG seuls, UDR seuls, ou les deux) pour appliquer NSG/UDR aux PE — utile pour forcer le trafic PE via un firewall (UDR /32 ou préfixe ≤ taille du VNet, le 0.0.0.0/0 ne suffit pas à override la route /32 du PE).

E.4 Approbation de connexion Private Endpoint

Cas n°1 — Même tenant, mêmes permissions sur les 2 ressources :

• L'approbation est automatique (auto-approve) lors de la création du Private Endpoint

Cas n°2 — Cross-tenant ou permissions séparées (cas "partenaire") :

• Le propriétaire du service cible (ex: Storage Account, SQL DB) doit approuver manuellement la demande de Private Endpoint
• Chemin côté propriétaire de la ressource : <Resource> > Networking > Private endpoint connections > <connexion en pending> > Approve / Reject

3 états possibles :

E.5 Private Link Service (PLS) — exposer ton service

C'est l'inverse d'un Private Endpoint classique : ici, c'est toi qui exposes un service interne à des clients tiers (autres Azure tenants).

Setup côté producer (toi) :

1. Tu as un service interne derrière un Standard Load Balancer (frontend privé)
2. Tu crées un Private Link Service rattaché au LB
3. Azure te donne un alias : myservice.<guid>.<region>.azure.privatelinkservice
4. Tu partages cet alias à tes clients

Setup côté consumer (le partenaire) :

1. Le partenaire crée un Private Endpoint dans son propre VNet, ciblant ton alias PLS
2. Demande envoyée → en Pending sur ton PLS
3. Toi (producer), tu valides : Private Link Center > Private link services > <pls> > Private endpoint connections > Approve
4. La connexion est établie, le partenaire utilise une IP privée dans son propre VNet pour atteindre ton service

Avantages :

• Pas d'overlap d'IP entre clients : chacun a sa propre IP dans son VNet, c'est NAT transparente
• Trafic 100% sur backbone Azure, jamais sur internet
• Modèle d'approbation : tu décides qui peut consommer (manuel ou par subscription whitelist)

Use case typique :

• SaaS B2B qui sert des grands comptes : tes clients consomment ton service via Private Endpoint depuis leur VNet → leur trafic ne traverse jamais internet.

🔑 TCP Proxy Protocol v2 activable sur le PLS → permet de récupérer la vraie source IP du client (sinon tu vois la NAT IP du PE et plus l'identité du tenant).

Consommer un PLS / Private Endpoint depuis on-prem (objectif "integrate PLS with on-premises clients") :

Un client on-prem atteint un PE/PLS injecté dans un VNet Azure via VPN S2S ou ExpressRoute (le PE n'est PAS routable depuis internet, mais l'est via la liaison hybride). Le blocage habituel est la résolution DNS : on-prem ne connaît pas la Private DNS Zone Azure.

• Setup DNS : déployer un DNS Private Resolver (inbound endpoint) dans le VNet lié à la Private DNS Zone (privatelink.*).
• Sur le serveur DNS on-prem : ajouter un conditional forwarder pour le FQDN public du service (ex database.windows.net, pas privatelink.database.windows.net) → pointant vers l'IP de l'inbound endpoint du Resolver.
• Résolution : on-prem → forwarder → inbound endpoint → Private DNS Zone (liée au VNet) → renvoie l'IP privée du PE → le client on-prem atteint le PE via VPN/ER.

💡 Détail complet du pattern DNS hybride (Resolver inbound/outbound + rulesets) → fiche 3 §E.

F. Azure Virtual Network Manager (AVNM) AZ-700 specific

Service centralisé qui gère tous les VNets across subscriptions depuis un seul point, au lieu de configurer chaque VNet individuellement : bloquer les ports non sécurisés, forcer le routage via NVA, gérer les plages IP, appliquer une baseline de sécurité globale.

F.1 Pourquoi AVNM ?

Avant AVNM, dans une grande entreprise :

• Plusieurs subscriptions Azure, des dizaines voire centaines de VNets
• Configuration manuelle sur chaque VNet : peering, NSG, UDR, IP range
• Difficile de standardiser des règles de sécurité globales
• Pas de vision centralisée

AVNM est le service centralisé pour gérer tous les VNets across subscriptions avec :

• Connectivity à l'échelle (hub-spoke, mesh, hub-spoke with direct)
• Security baseline qui override les NSG locaux
• UDR centralisées
• IP address management
• Tout piloté par Azure Policy sous le capot

F.2 Features principales

F.3 Hiérarchie d'implémentation

1. Network Manager Instance

   • Associé à une subscription ou management group
   • Définit le scope : seuls les VNets dans ce scope sont gérables

2. Network Groups

   • Grouper des VNets : ex prod-vnets, dev-vnets
   • Statique : tu listes les VNets manuellement
   • Dynamique : via Azure Policy qui détecte par tag, location, RG, etc.
     • Ex : tag = env:prod → ajouté automatiquement dans le groupe prod-vnets

3. Configurations à push at scale

   • Connectivity config (hub-spoke, mesh)
   • Security admin config (règles override NSG)
   • Routing config (UDR centralisées)
   • IPAM

4. Deployments

   • Config appliquée PAR REGION (à refaire pour chaque région concernée)
   • Process : Deploy > Choose configs > Choose target regions > Deploy

F.4 Security Admin Rules — override NSG

Différence clé avec les NSG :

Flux d'évaluation :

Trafic entrant → AVNM Security Admin Rules → NSG (subnet) → NSG (NIC) → VM

3 actions possibles pour une Security Admin Rule :

• Deny → bloqué, peu importe ce que disent les NSG locaux ✅
• Allow → continue dans les NSG locaux (qui peuvent encore bloquer)
• Always Allow → autorisé et court-circuite l'évaluation NSG (les NSG locaux ne peuvent plus bloquer ce flux) — utile pour garantir un flux critique (monitoring, AD, etc.)

⚠️ Une seule Security Admin Configuration déployable par région (mais elle peut contenir plusieurs rule collections).

💡 Intent policies dans Deployment options : permet de cocher des templates "Allow always" pour des services Azure essentiels (Backup, KeyVault, etc.) sans avoir à écrire manuellement les rules.

F.5 Connectivity Configurations

3 topologies supportées :

→ AVNM crée automatiquement les peerings correspondant à la topologie choisie.

G. Récap : quand utiliser quoi ?

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

Scenario 1 : Grand groupe multi-sub — migration manuelle vers AVNM

Contexte business : Un groupe industriel a 12 BU avec des souscriptions Azure indépendantes (héritage de rachats). 80 VNets éparpillés, peerings manuels, NSG incohérents, zéro vue centrale. Le CISO veut une baseline sécurité opposable en audit ISO 27001. Choix architectural : Piloter tout depuis Azure Virtual Network Manager (AVNM) au niveau Management Group. Les VNets sont rangés en groupes par tag, et des règles de sécurité orga s'imposent à tous les NSG. Architecture / pattern :

• Instance AVNM avec scope = Root MG (~80 VNets).
• Network Groups dynamiques (Azure Policy) : ng-prod (tag env=prod), ng-dev, ng-shared-services (tag tier=shared) → ajout auto.
• Security Admin rules (prioritaires sur les NSG) : deny RDP (3389) et SMB (445) depuis Internet, allow depuis AzureBastion.
• Connectivity : hub-and-spoke, avec connexion directe entre spokes prod (sans passer par le hub).
• Déploiements à refaire par région (EU West, EU North, France Central). Trade-offs assumés :
• Gain : baseline sécurité centralisée et opposable, peerings standardisés.
• Perte : prérequis MG commun ; chaque config se déploie région par région. Pièges à éviter :
• Vouloir AVNM sans Management Group commun → il ne voit pas les subs. Mettre en place le MG d'abord.
• Oublier qu'un déploiement AVNM est par région → à répéter pour chaque région.
• Mettre des règles Allow au lieu de Deny → les Allow ne forcent rien, ils pré-autorisent. Le vrai levier, ce sont les Deny.
• Garder les peerings manuels en parallèle de la Connectivity Config → conflits de routage, double peering.

📐 Réf. CAF/WAF — Network topology and connectivity (define topology) : le hub-spoke géré centralement est la topologie recommandée par le CAF pour standardiser routage et sécurité across subscriptions, alignée avec les Azure landing zones. Lien

Scenario 2 : SaaS B2B — exposer Private Link Service à 100 clients banques

Contexte business : Un éditeur SaaS vend à 100+ banques/assurances. Contrat : le trafic client ↔ SaaS ne doit jamais passer par internet, audit annuel, 1 client = 1 tenant. Choix architectural : Côté éditeur, exposer le service via Private Link Service (PLS) posé sur un Load Balancer interne. Chaque client se connecte avec un Private Endpoint dans son propre VNet → liaison 100% privée, validée à la main par tenant. Architecture / pattern :

• Côté SaaS : LB Standard privé → backend VMSS → PLS rattaché au LB. Alias partagé myservice.<guid>.<region>.azure.privatelinkservice.
• TCP Proxy Protocol v2 activé → on garde la vraie IP source du client (audit per-tenant).
• Côté client : il crée un Private Endpoint → reçoit une IP privée dans son adressage, et ajoute un record DNS vers cette IP.
• Approbation manuelle des nouveaux tenants (contrat + sub ID whitelisté). Trade-offs assumés :
• Gain : trafic jamais sur internet, identification fine par client.
• Perte : approbation manuelle ; limites PLS à surveiller à grande échelle. Pièges à éviter :
• Croire qu'un Private Endpoint suffit côté éditeur → non : PLS côté producer + PE côté consumer (sens inverse).
• Oublier TCP Proxy v2 → tous les tenants arrivent avec la même IP (la NAT) → pas d'audit ni de rate-limiting par client.
• NAT subnet trop petit → il faut au moins 8 IPs libres, sinon la création échoue.
• Limites PLS : 8 frontends max par LB Standard, 1000 connexions PE max. Au-delà, multiplexer plusieurs LB/PLS ou passer à DNS + mTLS.

📐 Réf. CAF/WAF — WAF Security (limiter l'accès réseau public) : minimiser l'exposition publique en utilisant Private Link / Private Endpoints pour l'intégration réseau privée des services PaaS est la recommandation WAF pour réduire la surface d'attaque. Lien

Scenario 3 : Gov / défense — forced tunneling et inspection on-prem

Contexte business : Une agence publique gère un workload classifié. Aucune sortie directe vers internet : tout doit transiter par le firewall on-prem pour inspection et journalisation. Liaison Azure ↔ on-prem en ExpressRoute Direct. Choix architectural : Hub-Spoke avec forced tunneling : une route par défaut (UDR 0.0.0.0/0) renvoie tout le trafic vers le firewall on-prem via ExpressRoute. Une règle AVNM bloque en plus toute sortie internet directe (défense en profondeur). Architecture / pattern :

• Hub : ExpressRoute Gateway (GatewaySubnet /27), Azure Bastion /26.
• Spokes : peerés au hub avec Use remote gateways = ON et Allow forwarded traffic = ON.
• UDR sur chaque spoke : 0.0.0.0/0 → Virtual network gateway (ExpressRoute) → tout l'outbound part vers le firewall on-prem, qui filtre/log puis relaie.
• AVNM Security Admin rules : deny sortie Internet depuis tous les spokes (filet de sécurité si l'UDR est supprimée).
• Aucune IP publique sur les VMs (sortie par UDR, entrée par Bastion). Trade-offs assumés :
• Gain : contrôle total de l'egress, inspection souveraine, double verrou UDR + AVNM.
• Perte : routage plus complexe ; risque d'asymétrie si BGP mal propagé. Pièges à éviter :
• UDR à la main sur 50 spokes → ingérable. Utiliser l'AVNM Routing Configuration pour pousser l'UDR sur le network group spokes.
• Forced tunneling sans bonne propagation BGP côté on-prem → le retour ne sait pas où aller → routage asymétrique.
• ExpressRoute Standard au lieu de Direct → la souveraineté gov exige un lien physique direct, sans partenaire tiers.
• Bastion en Basic : pas de session recording → non-conforme à l'audit gov. Prendre le Standard.

📐 Réf. CAF/WAF — Traditional Azure networking topology (forced tunneling / contrôle egress) : la topologie hub-spoke traditionnelle (routage et sécurité gérés par le client) est le pattern CAF quand on a besoin de contrôle total et granulaire du routage, condition d'un forced tunneling souverain. Lien

DEMO — chemins portail

1. DEMO — Configure User Defined Routes

Home > Route tables > + Create

1. Basics : RG, Region, Name rt-spoke-to-nva
2. Review + create
3. Aller dans la Route table créée → Routes > + Add :
   • Route name : default-to-firewall
   • Destination type : IP Addresses
   • Destination IP addresses/CIDR ranges : 0.0.0.0/0
   • Next hop type : Virtual appliance
   • Next hop address : 10.0.0.4 (IP privée de la NVA / Azure Firewall)
4. Subnets > Associate : VNet, choisir le subnet à forcer

Activer IP forwarding sur la NVA (si NVA custom, pas pour Azure Firewall) :

• Virtual machines > <nva> > Networking > <nic> > IP configurations > Enable IP forwarding > ON

Tester : depuis une VM du subnet associé, tracert 8.8.8.8 doit passer par la NVA.

2. DEMO — Configure VNet Peering

Home > Virtual networks > <VNet-A> > Peerings > + Add

Azure crée les 2 sens d'un coup si tu as les droits sur les 2 VNets.

Section 1 — This virtual network (côté A→B) :

• Peering link name : vnetA-to-vnetB
• Traffic to remote virtual network : Allow
• Traffic forwarded from remote virtual network : Allow (si NVA cross-spoke)
• Virtual network gateway or Route Server : None / Use this virtual network's gateway (si A est le hub) / Use the remote virtual network's gateway (si A est le spoke)

Section 2 — Remote virtual network (côté B→A) :

• Peering link name : vnetB-to-vnetA
• Virtual network deployment model : Resource Manager
• Subscription + Virtual network : sélectionner VNet-B
• Mêmes options en miroir

Vérification :

• Status doit être Connected des 2 côtés
• Si Initiated ou Disconnected → un côté manque

3. DEMO — Service Endpoints

Étape 1 — Activer Service Endpoint sur le subnet :

Home > Virtual networks > <vnet> > Subnets > <subnet> > Service endpoints

• Service : sélectionner Microsoft.Storage (ou Microsoft.Sql, Microsoft.KeyVault, etc.)
• Save

Étape 2 — Côté Storage Account :

Home > Storage accounts > <storage> > Networking > Firewalls and virtual networks

• Public network access : Enabled from selected virtual networks and IP addresses
• Virtual networks → + Add existing virtual network : sélectionner le VNet + subnet
• Save

Le subnet doit avoir le Service Endpoint activé (sinon Azure rejette l'add).

💡 Une fois le Service Endpoint activé sur le subnet, la VM atteint le Storage sur son endpoint public en passant par le backbone MS : trafic via backbone, pas internet, mais toujours sur l'IP publique du Storage (pas d'IP privée injectée comme avec un Private Endpoint).

4. DEMO — Configure Service Endpoint Policies

Use case : un subnet avec Service Endpoint Microsoft.Storage peut atteindre tous les Storage Accounts. On veut le restreindre à un seul.

Étape 1 — Créer la Service Endpoint Policy :

Home > Service endpoint policies > + Create

1. Basics : RG, Region, Name sep-storage-allowed
2. Policy definitions → + Add a definition :
   • Service : Microsoft.Storage
   • Resource : choisir le scope :
     • Single account : 1 Storage Account précis
     • All accounts in subscription : tous les Storage de la sub
     • All accounts in resource group : tous les Storage du RG
   • Sélectionner la ressource
3. Review + create

Étape 2 — Associer au subnet :

Service endpoint policy > Associated subnets > + Edit subnet association

• Sélectionner VNet + subnet → Save

Résultat : depuis les VMs du subnet, seuls les Storage du scope définis sont accessibles via le Service Endpoint. Les autres Storage retournent un 403 Forbidden ou un drop selon le cas.

⚠️ SEP : seul Microsoft.Storage est filtrable au niveau ressource (par compte/RG/sub). Azure SQL Managed Instance est le seul autre service managé supporté pour la cohabitation. Les autres (KeyVault, SQL DB, etc.) ne supportent pas les endpoint policies. À noter : appliquer une SEP fait passer le scope du Service Endpoint Storage de régional à global, et la SEP est une allow-policy (tout ce qui n'est pas listé est refusé).

5. DEMO — Configure a Private Endpoint for Azure Files

Étape 1 — Créer le Private Endpoint :

Home > Storage accounts > <storage> > Networking > Private endpoint connections > + Private endpoint

1. Basics : RG, Name pe-storage-file, Region
2. Resource :
   • Connection method : Connect to an Azure resource in my directory
   • Resource type : Microsoft.Storage/storageAccounts
   • Resource : <storage>
   • Target sub-resource : file (ou blob, queue, table, dfs…)
3. Virtual Network :
   • VNet + subnet (subnet doit avoir suffisamment d'IPs libres)
   • Dynamically allocate IP ou Static
   • Application security group (optionnel)
4. DNS :
   • Integrate with private DNS zone : ✅ (recommandé, sinon résolution KO)
   • Zone créée auto si pas existante : privatelink.file.core.windows.net
5. Review + create

Étape 2 — Tester depuis une VM du VNet :

• nslookup <storage>.file.core.windows.net → doit retourner l'IP privée du PE (ex 10.0.2.10), pas l'IP publique
• Mount du share Azure Files → fonctionne via l'IP privée

6. DEMO — Private Link Service

Setup côté producer (toi qui exposes un service).

Prérequis : un Standard Load Balancer avec frontend privé et un pool backend (VMs / VMSS).

Étape 1 — Créer le Private Link Service :

Home > Private link services > + Create

1. Basics : RG, Name pls-myservice, Region
2. Outbound settings :
   • Load balancer : sélectionner ton Standard LB
   • Load balancer frontend IP : sélectionner la frontend privée
   • Source NAT subnet : choisir un subnet pour le NAT outbound (au moins 8 IPs disponibles recommandé)
   • Enable TCP Proxy V2 : ✅ (recommandé pour récupérer la vraie source IP du client)
3. Access security :
   • Visibility : Anyone with your alias (public alias) OU restreint à des subscriptions
   • Auto-approval : (optionnel) liste de subscriptions auto-approuvées
4. Tags > Review + create

Étape 2 — Récupérer l'alias :

Sur le PLS créé → onglet Overview → noter l'Alias : myservice.<guid>.<region>.azure.privatelinkservice

→ Tu le partages à tes clients (consumer).

Étape 3 (côté consumer / partenaire) — Créer le Private Endpoint :

Home > Private endpoints > + Create

1. Connection method : Connect to an Azure resource by resource ID or alias
2. Resource ID or alias : coller l'alias fourni par le producer
3. VNet + subnet (dans le VNet du consumer)
4. Create → demande envoyée en Pending

Étape 4 (retour côté producer) — Approuver la connexion :

Private link services > pls-myservice > Private endpoint connections > <connexion pending> > Approve

→ Le partenaire peut maintenant consommer ton service via une IP privée dans son VNet.

7. DEMO — Configure AVNM Groups & Networking

Prérequis : avoir plusieurs VNets dans une (ou plusieurs) sub.

Étape 1 — Créer la Network Manager Instance :

Home > Azure Virtual Network Manager > + Create

1. Basics : Name avnm-corp, Region, Description
2. Scope :
   • Scope type : Subscription ou Management group
   • Sélectionner la/les subscription(s) ou MG concernées
3. Features to enable : cocher
   • ✅ Connectivity
   • ✅ Security admin
   • ✅ User-defined routing
   • ✅ IP address management (selon besoin)
4. Review + create

Étape 2 — Créer des Network Groups :

Dans l'AVNM → Network groups > + Create

1. Name : ng-hub
2. Description, créer

Répéter pour ng-spokes-prod, ng-spokes-dev, etc.

Étape 3 — Ajouter des membres (dynamique avec Azure Policy) :

Sur le Network Group → Group members > Create Azure Policy

1. Policy name : policy-tag-prod-to-ng-spokes-prod
2. Conditions :
   • tags['env'] equals 'prod'
3. Create → tous les VNets avec tag env=prod sont auto-ajoutés au groupe

💡 Ajout statique aussi possible : Add manually > sélectionner les VNets

Étape 4 — Créer une Connectivity Configuration :

Dans AVNM → Configurations > Connectivity > + Create

1. Name : connect-hub-spoke
2. Topology : Hub and spoke
3. Hub : sélectionner un VNet hub (pas un network group)
4. Spoke network groups : sélectionner ng-spokes-prod
5. Spoke connectivity : ✅ Direct connectivity (si spokes doivent se parler entre eux sans passer par le hub)
6. Use hub gateway : ✅ (si le hub a une VPN/ER GW à partager)
7. Save

Étape 5 — Deployer la config :

Deployments > + Deploy

1. Configurations : sélectionner connect-hub-spoke
2. Target regions : choisir les régions concernées (à refaire pour chaque région !)
3. Next > Deploy

→ AVNM crée automatiquement les peerings hub-spoke selon la topologie.

8. DEMO — Configure AVNM Network Security

Suite de la demo précédente. Va créer une Security Admin Config qui override les NSG des spokes.

Étape 1 — Créer la Security Admin Configuration :

AVNM → Configurations > Security admin > + Create

1. Name : sec-deny-internet-inbound
2. Description

Étape 2 — Ajouter une Rule Collection :

Dans la config → + Add rule collection

1. Name : rc-deny-internet
2. Target network groups : ng-spokes-prod
3. + Add rule :
   • Name : deny-all-internet-inbound
   • Priority : 100
   • Action : Deny
   • Direction : Inbound
   • Source type : Service Tag
   • Source : Internet
   • Destination type : Any
   • Protocol : Any
4. Save

💡 Intent policies dans Deployment options : tu peux choisir des actions pré-définies comme "AllowRulesOnly" qui empêchent les NSG locaux de bloquer ce qu'AVNM autorise.

Étape 3 — Déployer :

Deployments > + Deploy > Security admin configurations

• Sélectionner sec-deny-internet-inbound
• Target regions
• Deploy

Test : même si une VM spoke a un NSG Allow Internet inbound → l'AVNM Admin Rule override et bloque.

Voir les rules effectives :

• Virtual machine > <vm> > Networking > <nic> > Effective security rules → tu vois NSG + Admin rules
• OU : <nic> > Admin security rules (lien direct vers les rules AVNM appliquées)