Microsoft AZ-104: Réseaux virtuels Azure — Guide d'étude

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Administrator Associate AZ-104 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Aperçu

Azure Virtual Networking établit la structure de datacenter défini par logiciel (software-defined) pour les charges de travail IaaS et PaaS. Vous concevez un plan d’adressage avec CIDR, découpez des sous-réseaux alignés sur les frontières de confiance, sécurisez les flux est-ouest et nord-sud avec les Network Security Groups (NSG) et Azure Firewall, connectez les environnements en utilisant le VNet peering, VPN Gateway ou ExpressRoute, modelez le trafic avec des routes définies par l’utilisateur, et fournissez une résolution de noms fiable avec Azure DNS. La bonne configuration de ces constructions permet des conceptions en étoile (hub-and-spoke) évolutives, un accès PaaS sécurisé via des Private Endpoints, et un routage prévisible qui satisfait aux exigences de conformité et de performance.

Adressage, segmentation et politique (VNets, Subnets, NSG, ASG, UDR)

Un réseau virtuel définit un ou plusieurs espaces d’adressage RFC1918 qui ne se chevauchent pas en utilisant la notation CIDR (par exemple, 10.0.0.0/16). Vous pouvez ajouter des préfixes d’adresse supplémentaires plus tard s’il n’existe aucun conflit avec les réseaux homologues (peers). Les sous-réseaux segmentent le VNet en blocs routables (par exemple, 10.0.1.0/24 pour le web, 10.0.2.0/24 pour les applications). Réservez un GatewaySubnet dédié pour les passerelles VPN/ExpressRoute ; allouez-le généreusement (au moins /27) pour éviter les futures limites de mise à l’échelle. L’allocation d’IP est dynamique par défaut ; vous pouvez définir des adresses IP privées statiques sur les NIC lorsque c’est nécessaire.

Les routes système par défaut autorisent le trafic intra-VNet et envoient 0.0.0.0/0 vers Internet (sous réserve de la présence d’une adresse IP publique). Les routes définies par l’utilisateur (UDR) remplacent ces valeurs par défaut au niveau du sous-réseau. Créez une table de routage et associez-la à un sous-réseau ; les entrées incluent :

• Saut suivant (Next hop) : Appliance virtuelle (l’IP d’une NVA sur le même VNet), Passerelle de réseau virtuel (pour diriger vers on-prem via VPN/ExpressRoute), Internet (pour forcer la sortie vers Internet), ou Aucun (trou noir/blackhole).
• Tunneling forcé : Envoyez 0.0.0.0/0 vers une passerelle de réseau virtuel pour forcer tout le trafic sortant vers l’environnement on-prem, ou vers une NVA/Azure Firewall pour un contrôle de sortie centralisé. Si vous utilisez BGP avec une passerelle qui annonce une route par défaut, envisagez de désactiver la propagation des routes de la passerelle sur des sous-réseaux spécifiques pour éviter une sélection de chemin non intentionnelle.

Les NSG appliquent une politique avec état (stateful) de niveau L3-L4 sur les NIC ou les sous-réseaux ; les deux portées peuvent être utilisées simultanément et le trafic doit être autorisé par tous les NSG applicables. Les règles sont évaluées par priorité (100–4096 ; les nombres les plus bas en premier) et par direction (entrant/sortant). Les règles par défaut incluent :

• Entrant : AllowVnetInBound (65000), AllowLoadBalancerInBound (65001), DenyAllInBound (65500)
• Sortant : AllowVnetOutBound (65000), AllowInternetOutBound (65001), DenyAllOutBound (65500) Remplacez les règles par défaut avec des règles personnalisées de priorité plus élevée. Utilisez des Service Tags (par exemple, Internet, AzureLoadBalancer, Storage) pour simplifier la maintenance, et des IP Groups pour des listes d’adresses réutilisables.

Les Application Security Groups (ASG) découplent l’adressage IP de la politique. Assignez les NIC à des ASG qui représentent des rôles (par exemple, Web, App, DB) et référencez ces ASG dans les règles de NSG. Cela permet des changements de politique sans toucher aux adresses IP ou aux sous-réseaux et facilite une segmentation cohérente basée sur les rôles au sein d’un VNet.

Options de connectivité : Peering, VPN Gateway et ExpressRoute

Le peering de réseaux virtuels (VNet peering) connecte des réseaux virtuels sur le backbone de Microsoft avec une faible latence et une bande passante élevée. Le peering local se fait au sein d’une même région ; le peering global s’étend sur plusieurs régions. Le peering n’est pas transitif et nécessite des espaces d’adressage qui ne se chevauchent pas. Indicateurs clés :

• Allow virtual network access active la connectivité routée entre les réseaux homologues.
• Allow forwarded traffic autorise le trafic transféré par des NVA (appliances virtuelles réseau) à traverser le peering.
• Use remote gateways permet à un réseau virtuel d’utiliser une passerelle VPN/ER dans un « hub » homologue. Le hub doit avoir l’option Allow gateway transit activée. Un réseau virtuel ne peut utiliser les passerelles distantes que d’un seul homologue. Les réseaux virtuels homologues ne reçoivent pas automatiquement les routes des clients P2S ; les utilisateurs finaux doivent installer des configurations de client VPN mises à jour qui incluent les routes vers les nouveaux spokes.

Azure VPN Gateway fournit des tunnels IPSec/IKE :

• Site à site (S2S) connecte les équipements VPN sur site à Azure ; utilisez un VPN basé sur les routes (IKEv2) pour la plupart des scénarios, en particulier avec BGP et plusieurs tunnels.
• Point à site (P2S) permet à des clients individuels (Windows, macOS, Linux) de se connecter en utilisant OpenVPN, IKEv2 ou SSTP. La configuration du client contient des routes statiques vers les préfixes Azure ; téléchargez-la à nouveau lorsque les espaces d’adressage changent ou que vous ajoutez des spokes joignables derrière un hub.
• VNet à VNet utilise le S2S au sein des régions/tenants Azure, nécessitant des adresses qui ne se chevauchent pas. Utile lorsque le peering n’est pas possible (par exemple, entre différents tenants avec des frontières administratives).
• SKU : Préférez VpnGw1–VpnGw5 (et les variantes AZ pour la redondance de zone). La SKU Basic est héritée et manque de fonctionnalités (pas d’IKEv2/BGP). Le type basé sur les routes (Route-based) prend en charge P2S, BGP et le mode actif-actif. Le type basé sur les stratégies (Policy-based) est limité (S2S uniquement, pas de BGP).
• BGP annonce les préfixes de manière dynamique, prend en charge le transit sur plusieurs tunnels et simplifie le basculement des routes. Les règles NAT du VPN peuvent traduire les préfixes sur site/Azure qui se chevauchent lorsque c’est inévitable.

ExpressRoute fournit une connectivité privée, garantie par un SLA, via le circuit d’un partenaire jusqu’à la périphérie du réseau Microsoft (edge) :

• Un circuit est provisionné par le fournisseur (bande passante, facturation, SKU) et lié à votre abonnement via une clé de service. La redondance est intégrée : chaque circuit expose deux connexions, une primaire et une secondaire ; votre routeur doit établir deux sessions BGP pour la haute disponibilité (HA).
• Types de peering :
  • Le peering privé (Private peering) achemine le trafic privé RFC1918 vers les réseaux virtuels via une passerelle de réseau virtuel ExpressRoute (ErGw1AZ–ErGw3AZ). Il prend en charge BGP, le basculement rapide et, en option, FastPath pour l’accélération du plan de données.
  • Le peering Microsoft (Microsoft peering) expose les services publics de Microsoft (par exemple, Stockage, SQL, Microsoft 365) via des adresses IP publiques avec des filtres de route. Utilisez-le pour les points de terminaison accessibles sur Internet tout en restant en dehors de l’Internet public. Microsoft 365 nécessite une validation supplémentaire.
• Utilisez ExpressRoute Global Reach pour interconnecter des sites sur site via le backbone de Microsoft. Pour le tunneling forcé, annoncez une route par défaut sur le peering privé, ou associez-le à des UDR/Azure Firewall pour une sortie sélective.

Coexistence : Un réseau virtuel peut avoir à la fois des passerelles VPN et ExpressRoute utilisant le même GatewaySubnet ; utilisez le transit de passerelle et les UDR pour contrôler les flux. ExpressRoute est privilégié pour le trafic d’entreprise stable ; le VPN sert de solution de secours ou pour la connectivité des succursales/petits bureaux.

Résolution de noms et accès sécurisé au PaaS (Azure DNS, Endpoints)

Azure DNS héberge des zones publiques afin que vos enregistrements accessibles sur Internet résident sur la plateforme DNS mondiale d’Azure avec une haute disponibilité. Pour la résolution intra-VNet, les zones privées Azure DNS (Azure DNS Private Zones) fournissent un service de noms en split-horizon. Liez des réseaux virtuels à une zone privée pour activer la résolution ; activez éventuellement l’enregistrement automatique pour que les enregistrements A des machines virtuelles s’enregistrent et se mettent à jour automatiquement lors des changements d’IP de la carte réseau. Pour la résolution de noms hybride et le transfert conditionnel entre Azure et les environnements sur site, déployez un Azure DNS Private Resolver avec des points de terminaison entrants/sortants et des ensembles de règles qui transfèrent les domaines sélectionnés (par exemple, corp.contoso.com vers le DNS sur site, ou privatelink.* vers Azure).

Les points de terminaison de service (Service Endpoints) étendent l’identité de votre réseau virtuel à certains services Azure (par exemple, Stockage, SQL) sur le backbone de Microsoft, tout en conservant l’adresse IP publique du service. Sur le pare-feu du service PaaS, restreignez l’accès à un réseau virtuel/sous-réseau spécifique. Ils sont faciles à activer par sous-réseau et par service, ne nécessitent aucune modification DNS et fonctionnent bien pour des scénarios simples, uniquement dans Azure. Cependant, la ressource conserve une adresse IP publique et n’est pas adressable en privé depuis un environnement sur site sans passer par le point de terminaison public.

Les points de terminaison privés (Private Endpoints) placent une carte réseau (NIC) avec une adresse IP privée de votre sous-réseau sur la ressource PaaS via Private Link. Le trafic reste sur le réseau privé, permettant un contrôle précis de l’exfiltration des données et un accès depuis les environnements sur site via VPN/ExpressRoute. Une configuration DNS appropriée est essentielle : surchargez le FQDN public de la ressource pour qu’il se résolve en son FQDN privatelink, qui pointe vers votre adresse IP privée. Utilisez des zones DNS privées Azure (par exemple, privatelink.blob.core.windows.net) liées aux réseaux virtuels. Choisissez les Private Endpoints lorsque vous avez besoin d’un adressage véritablement privé, d’un accès inter-sites et de contrôles de sortie stricts.

Azure Firewall et gouvernance centralisée des flux sortants/entrants

Azure Firewall est un pare-feu stateful (à état), natif du cloud, qui s’adapte de manière élastique et fournit une politique centrale pour les architectures en étoile (hub-and-spoke). Déployez-le dans un sous-réseau dédié nommé AzureFirewallSubnet. Pour les scénarios de tunneling forcé, ajoutez un AzureFirewallManagementSubnet afin que le trafic de gestion utilise Internet tandis que le trafic de données suit votre route par défaut.

Les types de collections de règles s’appliquent dans cet ordre et selon la priorité de la collection de règles :

• Les règles DNAT traduisent les adresses IP/ports publics entrants sur le pare-feu en adresses privées (par exemple, mapper l’IP publique du pare-feu sur le port 443 à une VM web). Associez-les à des NSG sur le sous-réseau de destination pour appliquer le principe du moindre privilège.
• Les règles réseau filtrent le trafic de couches L3-L4 (IP source/destination, protocoles, ports). À utiliser pour les protocoles non-HTTP(S) et pour contrôler les flux sortants et intra-spoke.
• Les règles d’application contrôlent le trafic HTTP/S sortant par FQDN ou par étiquettes FQDN (par exemple, WindowsUpdate). La référence (SKU) Premium ajoute l’inspection TLS et l’IDPS pour un filtrage approfondi du trafic HTTP(S). La fonctionnalité Threat Intelligence peut être configurée sur Alerter (Alert) ou Refuser (Deny) pour agir sur les adresses IP/domaines malveillants connus. Combinez Azure Firewall avec des UDR (0.0.0.0/0 vers le pare-feu en tant qu’appliance virtuelle) pour centraliser le trafic sortant ; autorisez le trafic transféré (forwarded traffic) sur le peering pour les spokes. Envoyez les journaux vers Log Analytics pour l’audit et l’analyse, et utilisez les hiérarchies de stratégies/Azure Firewall Manager pour standardiser à grande échelle.

Scénario de problème pratique

Adobe doit moderniser un réseau hybride : un hub sécurisé dans Azure doit fournir une sortie Internet centralisée, une connectivité sur site (on-prem) à haute disponibilité, un accès privé à Storage et SQL, et une résolution de noms prévisible entre Azure et les datacenters. Les développeurs à distance ont également besoin d’un accès P2S à tous les spokes.

1. Concevoir l’espace d’adressage et la segmentation

• Créer un VNet Hub 10.0.0.0/16 avec les sous-réseaux : AzureFirewallSubnet 10.0.0.0/26, GatewaySubnet 10.0.0.64/27, SharedServices 10.0.1.0/24. Créer des VNets spoke pour les applications (Apps) 10.1.0.0/16 et les données (Data) 10.2.0.0/16.
• Justification : Des blocs CIDR qui ne se chevauchent pas permettent le peering et la croissance future ; les sous-réseaux dédiés répondent aux exigences de la plateforme et simplifient la portée des UDR/NSG.

2. Établir la connectivité hub-and-spoke

• Effectuer un peering Hub↔Apps et Hub↔Data avec les options « Autoriser l’accès au réseau virtuel » (Allow virtual network access) et « Autoriser le trafic transféré » (Allow forwarded traffic). Sur le hub, activez « Autoriser le transit par la passerelle » (Allow gateway transit) ; sur les spokes, activez « Utiliser les passerelles distantes » (Use remote gateways).
• Justification : Centralise les flux nord-sud via la passerelle/le pare-feu du hub tout en autorisant les flux est-ouest via le hub, évitant ainsi la complexité d’une topologie maillée (mesh).

3. Fournir une connectivité sur site privée et redondante

• Commander un circuit ExpressRoute (Peering privé) auprès d’un fournisseur ; configurer deux sessions BGP. Déployer une passerelle de réseau virtuel ExpressRoute (ErGw2AZ) dans le GatewaySubnet du hub et lier le circuit.
• Justification : Une connectivité privée, couverte par un SLA, avec une redondance intégrée et une passerelle redondante interzone répond aux besoins de haute disponibilité (HA) et de performance de l’entreprise.

4. Centraliser le trafic sortant et protéger les charges de travail

• Déployer Azure Firewall Standard dans AzureFirewallSubnet. Créer une UDR sur chaque sous-réseau spoke : 0.0.0.0/0 avec comme tronçon suivant (next hop) « Appliance virtuelle » (Virtual appliance) → IP privée du pare-feu. Ajouter des NSG aux spokes n’autorisant que les ports requis vers le pare-feu et au sein du VNet.
• Justification : Azure Firewall + UDR appliquent une politique de sortie, une journalisation et une threat intelligence cohérentes ; les NSG fournissent une micro-segmentation au niveau du sous-réseau/de la carte réseau (NIC).

5. Sécuriser les services PaaS avec un véritable accès privé

• Créer des points de terminaison privés (Private Endpoints) pour Storage et SQL dans le spoke Data. Lier les zones Azure Private DNS (privatelink.blob.core.windows.net, privatelink.database.windows.net) au hub et aux spokes. Désactiver l’accès réseau public sur les ressources PaaS.
• Justification : Les Private Endpoints éliminent l’exposition publique et permettent l’accès depuis l’environnement sur site via ExpressRoute ; Azure Private DNS assure une résolution de noms correcte.

6. Mettre en œuvre la résolution de noms hybride et le transfert conditionnel

• Déployer Azure DNS Private Resolver dans le hub avec des points de terminaison entrants et sortants. Créer des règles pour transférer les requêtes pour corp.adobe.com vers le DNS sur site et pour résoudre les zones privatelink au sein d’Azure.
• Justification : Fournit un DNS déterministe de type « split-horizon » entre Azure et l’environnement sur site sans avoir besoin de VM DNS personnalisées.

7. Activer l’accès des développeurs à distance à tous les spokes

• Configurer un VPN P2S sur la passerelle VPN du hub en parallèle d’ExpressRoute (coexistence). Distribuer le profil client VPN. Après avoir ajouté des spokes, téléchargez à nouveau le package client pour que les routes vers 10.1.0.0/16 et 10.2.0.0/16 soient incluses.
• Justification : Un P2S basé sur le hub simplifie les opérations et, avec des routes client mises à jour et le transit par la passerelle de peering, donne aux utilisateurs une accessibilité à tous les spokes.

8. Renforcer la sécurité avec les ASG et les NSG

• Assigner les cartes réseau (NIC) à des ASG (Web, App, DB) et implémenter des règles NSG autorisant Web→App (TCP 443), App→DB (TCP 1433) par ASG, en refusant tout le reste. Conserver les règles par défaut lorsque cela est approprié.
• Justification : Une politique basée sur les rôles s’adapte sans gestion d’adresses IP et applique le principe du moindre privilège.

Cette architecture répond aux exigences d’Adobe avec la redondance ExpressRoute, la gouvernance centralisée par Azure Firewall, l’accès privé aux services PaaS et un DNS cohérent, tout en garantissant que les utilisateurs distants et les systèmes sur site peuvent atteindre en toute sécurité chaque charge de travail via le hub.

← Machines virtuelles Azure et Services de calcul · Tous les domaines · Équilibrage de charge Azure et Gestion du trafic →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →