4 — Virtual Networking

Couche réseau privée d'Azure → permet aux ressources de communiquer entre elles, avec internet, et avec on-prem.

Virtual Network (VNet)

Réseau privé régional isolé dans Azure → contient des ressources organisées en subnets.

Caractéristiques

• Régional : un VNet existe dans une seule région (mais peering possible cross-region).
• Address space : un ou plusieurs CIDR (RFC1918 : 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). Pas d'overlap avec les VNets peerés.
• Subnets : sous-divisions du address space, chaque subnet peut avoir un NSG / route table / service endpoint propre.
• 5 IP réservées par subnet : .0 (network), .1 (default gateway), .2/.3 (Azure DNS), .255 (broadcast). Donc un /24 = 251 IP utilisables.

Connectivité par défaut

• ✅ Communication entre subnets d'un même VNet (route system par défaut)
• ✅ Accès outbound internet par défaut (IP éphémère MS)
• ❌ Accès inbound : non par défaut (sauf Public IP attachée + NSG ouvert)
• Le VNet peering ajoute automatiquement les routes vers le VNet peer

Subnets réservés (noms exacts)

⚠️ Modifier un VNet/subnet n'est pas possible si des ressources existantes sont impactées (ex: changer le CIDR avec des subnets actifs, redimensionner un subnet plein).

IP Addressing

Private IP

• Attribuée automatiquement aux ressources dans le subnet (DHCP Azure).
• 2 modes : Dynamic (par défaut, peut changer après stop/dealloc) / Static (fixée, recommandée pour DC, FW, DNS internes).
• Pour la plupart des ressources : portée par la NIC. Pour LB / App Gateway : configurée sur la ressource elle-même (frontend IP).

Public IP

• Ressource séparée créée à part puis associée à VM, LB, App GW, VPN GW, NAT GW, Bastion, Firewall…
• 2 modes : Static (recommandé prod) / Dynamic (libre après dissociation).

Pour AZ-104 : retenir Standard SKU = inbound bloqué par défaut (zero-trust). Le SKU de la Public IP doit matcher celui du LB / VPN GW associé.

🚨 Standard SKU Public IP = Static allocation OBLIGATOIRE (pas Dynamic). Dynamic n'existait que sur Basic (retiré sept 2025). Donc tout nouveau Public IP = Standard + Static. Conséquence : pour associer une Public IP à un LB Standard, elle doit forcément être Standard + Static.

Outbound vers internet — 4 options (ordre de priorité Azure)

1. Public IP attachée à la VM (frontend IP)
2. NAT Gateway sur le subnet (recommandé pour multi-VM)
3. Public LB avec règles outbound
4. Default outbound IP Azure (éphémère, 🚨 retiré : après le 31 mars 2026, les nouveaux VNets créés via l'API ont leurs subnets privés par défaut → plus d'outbound implicite, une méthode explicite est obligatoire — MS recommande NAT GW)

💡 SNAT (Source NAT) : quand une VM en IP privée sort vers internet, sa private IP est traduite en Public IP au passage (sinon internet ne sait pas où renvoyer la réponse). Chaque connexion sortante consomme 1 port SNAT (sur ~64k dispos par Public IP). Trop de connexions simultanées → SNAT exhaustion = nouvelles sorties internet échouent.

NAT Gateway : pose 1+ Public IPs en sortie, attaché au subnet. Toutes les VMs du subnet sortent par ces IPs. SNAT scalable : jusqu'à 16 IPs ou Public IP Prefix → ~1M ports total → résout les soucis de SNAT exhaustion du default outbound (limité à ~1024 ports/VM). Pas de connexion inbound (sortie uniquement). 1 seule IP = SPOF possible → préférer plusieurs IPs pour HA.

Network Security Group (NSG)

Firewall stateful L3/L4 → règles allow/deny basées sur source/dest IP + port + protocole.

Composition d'une règle

Règles par défaut (non supprimables, priority 65000+)

Inbound :

• AllowVNetInBound (65000) — trafic interne au VNet et VNets peerés
• AllowAzureLoadBalancerInBound (65001) — health probes
• DenyAllInBound (65500)

Outbound :

• AllowVNetOutBound (65000)
• AllowInternetOutBound (65001)
• DenyAllOutBound (65500)

Association : Subnet vs NIC

• NSG associé à un subnet OU à une NIC (ou les deux en même temps).
• ⚠️ Les deux s'appliquent en série (pas l'un qui prend le dessus) :
  • Inbound : Subnet NSG → puis NIC NSG
  • Outbound : NIC NSG → puis Subnet NSG
• Si l'un des deux bloque, le trafic est bloqué → le plus restrictif gagne.
• Stateful : si inbound autorisé, le retour outbound l'est automatiquement (et inversement).

Limites

• Pas d'inspection L7 (pour ça → Azure Firewall ou App Gateway WAF, voir fiche 5).
• Évalué uniquement pour le trafic IP, pas pour les flux east-west déjà autorisés par le système.

Augmented Security Rules (ASR)

Simplifient les règles NSG en évitant les listes d'IP à rallonge.

Service Tags

Étiquettes gérées par Microsoft représentant des plages IP de services Azure (mises à jour auto).

Exemples utiles :

• Internet, VirtualNetwork, AzureLoadBalancer
• Storage, Storage.WestEurope (régionalisable)
• AzureCloud, AzureActiveDirectory, AzureKeyVault, AzureBackup
• Sql, AzureMonitor, EventHub

❌ Pas de Service Tag custom. Tout est géré par MS.

Application Security Groups (ASG)

Groupes logiques de NICs → permettent d'écrire des règles NSG par "rôle" (ex web-asg, db-asg) au lieu d'IPs.

Règles à connaître :

• ASG attaché à des NICs, pas directement à des VMs (mais ça revient au même).
• Toutes les NICs d'un ASG doivent être dans le même VNet.
• Quand un ASG est utilisé en source ET destination dans une règle, les ressources doivent être dans le même VNet.
• Une NIC peut appartenir à plusieurs ASGs.

Combo gagnant : NSG avec règle web-asg → db-asg port 1433 Allow au lieu de gérer des plages IP.

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

Scenario 1 : SaaS B2B early stage — appli 3-tier monorégion

Contexte business : startup SaaS RH (~50 clients), 1 seule région (West Europe), 2 personnes aux ops. Besoin : isoler web/app/DB, n'exposer que le frontend, garder des règles simples. Choix architectural : 1 VNet /16 découpé en 3 subnets (web/app/db), 1 NSG par subnet, et des règles écrites avec des ASG (groupes logiques) plutôt que des IP. Aucune IP publique sur les VMs back/DB. Architecture / pattern :

• VNet 10.10.0.0/16 → subnets 10.10.1.0/24 (web), .2.0/24 (app), .3.0/24 (db).
• NSG-web : Internet → web-asg:443 Allow, le reste de l'inbound bloqué.
• NSG-app : web-asg → app-asg:8080 Allow (que des ASG, aucune IP).
• NSG-db : app-asg → db-asg:1433 Allow, et deny VirtualNetwork sur 1433 sinon toute VM du VNet pourrait taper la DB.
• Sortie web via NAT Gateway avec IP publique fixe (whitelistée chez les partenaires de paiement). Trade-offs assumés :
• Gain : segmentation claire et règles qui survivent au scaling.
• Perte : plus d'objets à gérer (3 NSG, 3 ASG) qu'un simple VNet à plat. Pièges à éviter :
• Écrire les règles NSG par IP plutôt que par ASG → ingérable dès qu'on passe en VMSS.
• Oublier de bloquer VirtualNetwork → db-asg:1433 : une VM ad-hoc dans le subnet web pourrait alors taper la DB.
• Laisser la sortie Internet ouverte sur le subnet db → exfiltration possible. Bloquer l'outbound Internet sur app et db, n'autoriser que des Service Tags précis (AzureKeyVault, Storage.WestEurope).

📐 Réf. CAF — Network segmentation : la micro-segmentation par tier (web/app/db) avec NSG + ASG plutôt que des plages IP est le pattern CAF de segmentation réseau. Lien

Scenario 2 : E-commerce retail — DR cross-region actif/passif

Contexte business : e-commerce français (~2M visites/mois). Région primaire France Central, DR France South. RTO 1h, RPO 15min, 100% cloud. Choix architectural : 2 VNets aux plages d'adresses non chevauchantes, reliés par Global VNet Peering, avec des IP privées fixes pour les DBs (failover DNS plus simple). Architecture / pattern :

• VNet-Prod 10.20.0.0/16 (France Central) ↔ VNet-DR 10.30.0.0/16 (France South) en Global Peering.
• Plages CIDR distinctes dès le départ (pas 10.0.0.0/16 partout, le classique des PoC qui finit mal).
• NAT Gateway par région avec Public IP Prefix /29 (8 IPs) → whitelist chez le CDN et les passerelles de paiement.
• DBs en IP privée fixe → le failover DNS pointe sur l'IP DR sans dépendre d'une IP dynamique. Trade-offs assumés :
• Gain : bascule DR simple et rapide, conforme au RTO/RPO.
• Perte : 2 régions à maintenir en parallèle (coût + cohérence des données). Pièges à éviter :
• Chevauchement de CIDR = le peering ne se fait jamais. Copier bêtement le VNet prod en DR plante direct.
• Croire que le Global Peering chiffre par défaut → non. Activer Encryption sur le peering si la donnée l'exige (compliance, PII).
• Public IP Basic sur le NAT GW : impossible depuis sept. 2025 → forcément Standard + Static. Migrer les vieilles VMs encore en Basic.

📐 Réf. CAF — Plan for IP addressing : choisir des espaces d'adressage non chevauchants dès le départ (clé du peering et des futures interconnexions) est une recommandation fondamentale du CAF. Lien

Scenario 3 : Studio gaming — backend multi-VMSS avec sortie internet massive

Contexte business : backend de matchmaking mobile, ~30k connexions simultanées en pic. Le backend (VMSS) appelle beaucoup d'APIs externes (Steam, GameCenter, paiement). Choix architectural : on gère la sortie avec un NAT Gateway doté de plusieurs IP (Public IP Prefix), on restreint l'outbound par Service Tags, et on segmente avec des ASG par micro-service. Architecture / pattern :

• VMSS dans le subnet gameserv (/22 ≈ 1000 IPs pour le scale).
• NAT Gateway + Public IP Prefix /28 (16 IPs) → ~1M ports SNAT cumulés → règle le SNAT exhaustion typique du gaming.
• ASG matchmaking/lobby/payment. NSG outbound : payment-asg → Internet:443 Allow, le reste payment-asg → Internet Deny (réduit le périmètre PCI).
• Service Tags pour la sortie vers Azure : AzureKeyVault, Storage.WestEurope, AzureMonitor. Trade-offs assumés :
• Gain : sortie internet massive sans saturer les ports, périmètre PCI restreint.
• Perte : config NAT + whitelist Service Tags plus lourde qu'une sortie ouverte. Pièges à éviter :
• 1 seule IP publique sur le NAT GW → ~64k ports → saturation en 10 min de prod. Prefix /28 indispensable.
• Laisser AllowInternetOutBound par défaut sur le subnet payment → tout le périmètre PCI-DSS doit logger ; mieux vaut whitelister par Service Tag.
• Croire que le NAT GW gère l'inbound : non, sortie uniquement. Pour l'entrant → LB Standard public + NSG explicite.

📐 Réf. WAF — Reliability (networking) & NAT Gateway : utiliser NAT Gateway avec plusieurs IPs (ou un Public IP Prefix) pour un SNAT déterministe et scalable est la méthode d'outbound recommandée (vs default outbound, retiré). Lien

DEMO — chemins portail & pièges

Créer un VNet

1. Virtual networks > Create
2. Onglet IP addresses : définir address space + premier subnet (au moins un avant la création).
3. Modifier après coup : VNet > Address space ou Subnets > Add (impossible si overlap avec ressources actives).

Public IP + NAT Gateway

Public IP > Create
  SKU: Standard, Static, regional ou zonal
NAT Gateway > Create
  Associer la Public IP créée
  Onglet "Subnets" : sélectionner les subnets concernés

Une seule Public IP attachée = pas de SLA. Pour la prod : prefix /28 = 16 IPs ou plusieurs Public IPs.

NSG basique (RDP autorisé)

1. Network security groups > Create
2. Associer au subnet ou à la NIC de la VM (Subnets ou Network interfaces dans le NSG, ou Networking côté ressource)
3. Inbound security rules > Add :
   • Source: Any (ou IP perso pour limiter)
   • Destination: Any
   • Service: RDP (port 3389) — Azure pré-remplit
   • Action: Allow, Priority: 300

Best practice : restreindre source à ton IP, ou utiliser Azure Bastion au lieu d'exposer 3389/22 sur internet.

NSG + ASG

1. Créer l'ASG : Application security groups > Create (régional, sans VNet à la création)
2. VM > Networking > Application security groups > Configure ASGs → ajouter la VM dans l'ASG (ASG se "lock" sur le VNet de la première NIC)
3. Dans le NSG : règle Source: Subnet web > Destination: ASG mgmtservers > 3389 Allow
4. Outbound deny web sauf Azure Backup :
   • Rule 1: Destination: Service Tag AzureBackup > Allow
   • Rule 2: Destination: Service Tag Internet, ports 80,443 > Deny (priority plus haute que rule 1)