Microsoft AZ-500: Architecture de sécurité réseau — Guide d'étude

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Security Engineer Associate AZ-500 — 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.

Vue d’ensemble

L’architecture de sécurité réseau d’Azure impose une connectivité selon le principe du moindre privilège, part du principe d’une compromission et met en œuvre une surveillance continue. Elle combine la micro-segmentation au sein des réseaux virtuels, des plans de contrôle à état (stateful) pour le trafic est-ouest et de sortie (egress), des protections en périphérie pour les points de terminaison exposés à Internet, et un accès privé au PaaS. Les conceptions robustes privilégient un accès basé sur l’identité au niveau de la couche applicative tout en maintenant des frontières de réseau solides, un routage explicite et une télémétrie vérifiable.

Contrôles et segmentation du réseau virtuel

Les sous-réseaux constituent la première frontière de segmentation. Placez les charges de travail (workloads) ayant des niveaux de confiance, des cycles de vie et des politiques similaires dans le même sous-réseau ; séparez les niveaux (web, application, données) afin de pouvoir appliquer des politiques et des routes indépendantes. Évitez les sous-réseaux « partagés » plats qui mélangent outils d’administration, serveurs de rebond (jump hosts) et charges de travail métier ; ils compliquent la gestion des politiques et augmentent le rayon d’impact (blast radius).

Les Network Security Groups (NSGs) appliquent un filtrage à état (stateful) de niveau 3-4 par sous-réseau ou par carte réseau (NIC). Les règles de trafic entrant et sortant sont évaluées par priorité (le nombre le plus bas en premier), avec un « DenyAll » (Refuser tout) implicite à la fin. Les NSG sont à état : les réponses aux flux autorisés sont permises automatiquement, vous aurez donc rarement besoin de règles de port éphémère. Sur le plan opérationnel, liez les NSG aux sous-réseaux pour des contrôles généraux, puis affinez sur les cartes réseau critiques. Documentez toujours le propriétaire, l’objectif et la date d’expiration de toute autorisation « temporaire ».

Les Application Security Groups (ASGs) vous permettent de référencer des groupes de VM par leur nom plutôt que par leur adresse IP, de sorte que les règles survivent à la mise à l’échelle et à la rotation des adresses IP. Étiquetez les VM dans des ASG basés sur les rôles (par ex., asg-web, asg-app) et exprimez des politiques telles que « asg-web → asg-app TCP 443 ». Cela réduit la prolifération des règles et la dérive opérationnelle.

Les règles de sécurité effectives résultent de la fusion des NSG appliqués à la fois à une carte réseau et à son sous-réseau. L’autorisation/le refus correspondant le plus spécifique (par priorité) l’emporte. Validez avec les « Règles de sécurité effectives » dans le portail ou via la vérification du flux IP de Network Watcher pour détecter les entrées conflictuelles avant les fenêtres de déploiement.

Les Service tags (par ex., AzureLoadBalancer, Storage, Sql, Internet, VirtualNetwork) sont maintenus par Microsoft et regroupent de grands espaces d’adresses IP dynamiques en cibles de règles stables. Préférez les service tags aux listes d’adresses IP manuelles pour éviter les pannes lors de la rotation des adresses IP des services. Par exemple, restreignez le trafic de sortie (egress) vers Storage et Sql tout en refusant un accès large à Internet.

La micro-segmentation et la Confiance Zéro (Zero Trust) sont mises en œuvre en :

Appliquant des NSG avec un refus par défaut et en n’ouvrant que des chemins explicites et minimaux.
Utilisant des ASG pour encoder l’intention de la charge de travail.
Restreignant le trafic de sortie (egress) avec des service tags ou un filtrage basé sur les FQDN via Azure Firewall.
Appliquant la règle « pas d’IP publique sur les serveurs » et en routant tout le trafic de sortie via un point d’inspection contrôlé.

Exemple : créez une règle NSG autorisant le trafic web vers applicatif via TLS avec des ASG et refusez explicitement tout le reste avec une priorité plus élevée que le refus implicite pour documenter l’intention.

az network nsg rule create \
  --resource-group rg-sec \
  --nsg-name nsg-app \
  --name allow-web-to-app-443 \
  --priority 200 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-asgs asg-web \
  --destination-asgs asg-app \
  --destination-port-ranges 443

Services de sécurité réseau et protection de la périphérie

Azure Firewall est un pare-feu entièrement à état (stateful), à haute disponibilité, avec une politique centralisée. Utilisez-le pour :

Le contrôle du trafic est-ouest et de sortie (egress) lorsque les NSG sont insuffisants (noms de domaine, inspection TLS).
Le DNAT pour une exposition entrante limitée lorsque Application Gateway n’est pas adapté.
La journalisation centralisée et la Threat Intelligence.

Les groupes de collections de règles contiennent des collections de règles (Réseau, Application, NAT) avec des priorités qui définissent l’ordre d’évaluation. Au sein d’un groupe, les collections de priorité inférieure sont évaluées en premier ; les règles sont appariées selon les critères les plus spécifiques. Conservez les règles DNAT dans leur propre groupe avec la priorité d’évaluation la plus élevée pour capturer le trafic entrant de manière déterministe.

Les règles de réseau filtrent par 5-tuple (IP/port/protocole).
Les règles d’application filtrent par FQDN, catégories d’URL (Premium), et peuvent utiliser des étiquettes FQDN.
Les règles NAT traduisent les adresses/ports publics en adresses/ports privés pour les scénarios entrants.

Le filtrage basé sur la Threat Intelligence bloque les adresses IP/domaines malveillants connus. Exécutez-le en mode Alerte pendant l’établissement de la ligne de base initiale, puis en mode Refus (Deny) une fois les faux positifs traités.

Les fonctionnalités Premium ajoutent :

L’inspection TLS avec déchiffrement du trafic sortant et entrant, permettant une visibilité de niveau 7 et l’IDPS.
La détection et la prévention des intrusions (IDPS) avec des signatures et une priorisation des vulnérabilités.
Le filtrage d’URL et les catégories web pour un contrôle granulaire du trafic de sortie.
Des contrôles avancés des certificats et des politiques TLS.

Sur le plan opérationnel, isolez le pare-feu dans un sous-réseau dédié (AzureFirewallSubnet), routez tout le trafic à destination d’Internet vers celui-ci avec des UDR (routes définies par l’utilisateur), et activez les Zones de disponibilité. Utilisez Firewall Policy (et non les règles classiques) pour une administration évolutive, l’héritage et la divergence Dev/Test avec une politique de base partagée.

Le Web Application Firewall (WAF) atténue les attaques de niveau 7 (SQLi, XSS).

Sur Application Gateway, le WAF protège les applications régionales avec un chiffrement TLS de bout en bout et des politiques par site ; il termine la connexion TLS du client et peut éventuellement rechiffrer vers le backend.
Sur Azure Front Door, le WAF protège les applications distribuées mondialement en périphérie avec un CDN intégré, des protections contre les bots et des contrôles géographiques.

Créez des politiques WAF et associez-les à des passerelles, des écouteurs (listeners) ou des routes. Choisissez initialement le mode Détection pour l’ajustement, puis le mode Prévention pour bloquer. Utilisez des ensembles de règles managées (OWASP 3.x) et ajoutez des règles personnalisées pour les limites de débit ou les plages d’adresses IP. Configurez des exclusions (par ex., des champs JSON ou des en-têtes spécifiques) pour réduire les faux positifs sans affaiblir la protection globale.

Attaque par déni de service distribué (DDoS) :

La protection de base est une protection de plateforme toujours active mais n’offre aucune télémétrie par ressource ni aucun ajustement de l’atténuation.
DDoS Protection: Network Protection ajoute un réglage adaptatif par adresse IP publique, une atténuation automatique, des analyses d’attaques, des alertes, un crédit de protection des coûts et un accès à DDoS Rapid Response.

Activez Network Protection sur les réseaux virtuels (VNets) hébergeant des adresses IP publiques (SKU Standard). Utilisez la télémétrie (Métriques, Journaux de diagnostic) pour observer les vecteurs d’attaque, le cycle de vie de l’atténuation et son efficacité. Architecturez les ressources protégées derrière des équilibreurs de charge ou Application Gateway pour absorber la charge volumétrique, et minimisez l’exposition publique directe. Combinez WAF et DDoS pour une défense en couches.

Accès privé, connectivité hybride et routage

Private Link et les points de terminaison privés fournissent un accès par IP privée depuis votre VNet aux services PaaS. Un point de terminaison privé est une carte réseau (NIC) dans votre sous-réseau, mappée à la ressource PaaS ; le trafic reste sur le réseau principal de Microsoft. Étapes opérationnelles :

Désactiver l’accès au réseau public sur la ressource PaaS pour empêcher tout contournement.
Déployer des zones DNS privées (par ex., privatelink.blob.core.windows.net) et les lier aux VNets pour une résolution de noms transparente.
Gérer les approbations de manière centralisée ; envisager une isolation par abonnement/locataire avec un flux de travail d’approbation manuelle.

Les points de terminaison de service étendent l’identité de votre sous-réseau aux ressources PaaS via leurs adresses IP publiques, permettant au pare-feu PaaS de restreindre l’accès à des sous-réseaux spécifiques. Ils ne créent pas d’adresses IP privées, donc le trafic sortant passe par le périmètre public mais reste au sein du réseau Microsoft. Utilisez des stratégies de point de terminaison de service pour n’autoriser que les comptes de stockage approuvés. Pour les charges de travail conteneurisées sur des machines virtuelles IaaS, assurez-vous que Azure CNI est utilisé afin que les adresses IP des pods/conteneurs proviennent du sous-réseau ; sinon, le point de terminaison de service ne reconnaîtra pas la source et l’accès pourra échouer.

Stratégie de résolution DNS :

Pour Private Link, assurez-vous que votre chemin de résolution DNS résout le FQDN PaaS vers le point de terminaison privé. Utilisez des zones Azure Private DNS, des redirecteurs conditionnels sur le DNS sur site, ou Azure DNS Private Resolver pour la redirection hybride.
Maintenez des mappages split-horizon faisant autorité clairs pour éviter une résolution publique intermittente.

Connectivité hybride :

VPN Gateway : Pour le site à site, utilisez un VPN basé sur les routes avec IKEv2 et des chiffrements forts. Utilisez BGP pour échanger des routes dynamiquement, ce qui simplifie la croissance et le basculement. Appliquez VPN NAT lorsque des espaces d’adressage se chevauchent. Pour le tunneling forcé, annoncez 0.0.0.0/0 depuis l’environnement sur site via BGP ou appliquez des UDR envoyant 0/0 à une appliance virtuelle ; assurez-vous qu’une route d’exception existe pour les plages privées PaaS si nécessaire.
ExpressRoute : Fournit une connectivité privée ; le chiffrement n’est pas inhérent. Utilisez MACsec (pour ExpressRoute Direct) ou exécutez IPsec sur ExpressRoute pour la confidentialité. Utilisez les communautés BGP et les filtres de route pour le peering Microsoft. Supportez le mode actif-actif avec ECMP sur plusieurs circuits pour la résilience. Pour le tunneling forcé, acceptez les routes par défaut depuis l’environnement sur site et assurez-vous qu’aucun UDR en conflit ne crée de trou noir pour les chemins internet.

Itinéraires définis par l’utilisateur (UDR), appliances virtuelles réseau (NVA) et priorité :

La sélection de la route utilise la correspondance du préfixe le plus long, puis la source : UDR > BGP > Système. Des UDR 0/0 mal appliqués peuvent créer un trou noir pour les chemins de retour ; validez avec la fonctionnalité « tronçon suivant » (next-hop) de Network Watcher.
Pour les NVA, activez le transfert IP sur les cartes réseau et placez-les derrière un équilibreur de charge ou un Gateway Load Balancer pour une insertion transparente et évolutive. Préférez Azure Firewall pour les scénarios gérés ; lorsque des fonctionnalités spécifiques à un fournisseur sont requises, concevez une solution en haute disponibilité (HA) avec plusieurs zones de disponibilité et un équilibrage de charge basé sur des sondes d’intégrité.

Administration, surveillance et télémétrie sécurisées

Connectivité administrative sécurisée :

Azure Bastion fournit un accès RDP/SSH sur TLS depuis le portail ou un client natif sans exposer les adresses IP publiques des VM. Utilisez la référence (SKU) Standard pour la mise à l’échelle, les connexions basées sur IP et les liens partageables. Restreignez l’accès à Bastion via le RBAC et l’accès juste-à-temps.
L’accès juste-à-temps aux VM (Defender for Cloud) ferme les ports de gestion dans les NSG et les ouvre sur demande pour une durée limitée, avec approbation et limites d’adresses IP sources. Combinez-le avec Bastion pour une posture sans IP publique et une piste d’audit précise.

Network Watcher fournit une vérification opérationnelle et une analyse forensique :

Les journaux de flux NSG (v2) écrivent dans un stockage et peuvent être envoyés à Traffic Analytics dans Log Analytics pour obtenir des informations sur les principaux communicateurs, les flux autorisés/refusés et la géographie.
La résolution des problèmes de connexion (Connection troubleshoot) teste activement la connectivité de bout en bout et signale où un chemin est bloqué (NSG, UDR, DNS, pare-feu).
La capture de paquets peut être déclenchée à la demande ou par des alertes ; utilisez des tampons circulaires (ring buffers) pour réduire le stockage et ne capturer que les ports pertinents.
La vérification des routes effectives et du flux IP (Effective routes and IP flow verify) cartographie les décisions d’exécution à travers les UDR, BGP et NSG ; automatisez ces vérifications dans les contrôles préalables (preflight) du CI/CD.

Activez rapidement les journaux de flux NSG et les analyses :

az network watcher flow-log configure \
  --resource-group rg-sec \
  --nsg nsg-app \
  --enabled true \
  --traffic-analytics true \
  --storage-account saflowlogs \
  --workspace /subscriptions/<sub>/resourceGroups/rg-la/providers/Microsoft.OperationalInsights/workspaces/la-workspace

Scénario de problème pratique

Starbucks modernise une plateforme de gestion des commandes sur Azure. Les objectifs de sécurité sont : aucune IP publique sur les niveaux applicatifs et de données, une sortie (egress) stricte, une protection web globale et une visibilité opérationnelle.

Créez trois sous-réseaux par région : web, app, data, chacun avec son propre NSG et des ASG alignés sur les rôles.

Justification : La micro-segmentation basée sur les sous-réseaux avec des ASG encode les flux du moindre privilège (web→app 443, app→data 1433) et réduit le rayon d’impact (blast radius). Des NSG distincts par niveau évitent le couplage accidentel de politiques.

Déployez Azure Front Door Standard/Premium avec une politique WAF en mode Prévention utilisant OWASP 3.x et des règles personnalisées pour la limitation de débit et les restrictions géographiques.

Justification : La protection globale en périphérie (edge) absorbe le trafic volumétrique, bloque les attaques L7 courantes avant qu’elles n’atteignent la région et réduit la latence via anycast. Les politiques WAF en périphérie assurent une application cohérente entre les régions.

Placez Application Gateway avec WAF v2 dans chaque région devant le niveau web ; terminez la connexion TLS au niveau d’App Gateway et rechiffrez vers le backend.

Justification : Le routage L7 régional et le WAF complètent Front Door, permettant le mTLS par application vers les backends, l’affinité basée sur les cookies et les déploiements bleu/vert tout en maintenant la capacité d’inspection.

Activez la protection DDoS : Network Protection sur les VNet contenant les adresses IP publiques d’Application Gateway.

Justification : L’atténuation adaptative par IP, la télémétrie et la protection des coûts réduisent les risques liés aux attaques volumétriques ciblant les points d’entrée régionaux. Le périmètre au niveau du VNet garantit que toutes les adresses IP publiques actuelles et futures sont protégées sans configuration par ressource.

Déployez Azure Firewall Premium dans un hub sécurisé ; routez tout le trafic sortant (egress) des sous-réseaux app et data vers celui-ci avec des UDR. Activez l’inspection TLS et l’IDPS pour le trafic sortant, et configurez des règles d’application pour n’autoriser que les FQDN requis.

Justification : Le contrôle centralisé de la sortie avec déchiffrement et détection basée sur les signatures empêche le command-and-control et l’exfiltration de données. Les règles d’application réduisent la maintenance par rapport aux règles basées sur IP et s’alignent sur une sortie Zero Trust.

Utilisez Private Link pour Azure SQL et Storage ; désactivez l’accès au réseau public et configurez des zones DNS privées liées à tous les VNet. Pour les charges de travail conteneurisées, utilisez Azure CNI.

Justification : Les points de terminaison privés (Private endpoints) maintiennent les chemins de données sur le réseau principal (backbone) et éliminent l’exposition publique. Le DNS privé assure une résolution de noms transparente. Azure CNI garantit que les IP des pods proviennent du sous-réseau afin que Private Link et les points de terminaison de service fonctionnent correctement.

Établissez ExpressRoute avec des circuits doubles en mode actif-actif et annoncez les routes sur site avec BGP ; activez IPsec sur ER pour le trafic sensible. N’annoncez pas 0/0 initialement ; pilotez d’abord le tunneling forcé dans un sous-réseau de pré-production (staging).

Justification : ER fournit une connectivité privée et prévisible ; le chiffrement en couches protège les flux de haute sensibilité. Le déploiement contrôlé du tunneling forcé empêche le blackholing accidentel d’Internet et valide les routes d’exception.

Fournissez un accès administratif via Azure Bastion et imposez l’accès juste-à-temps sur toutes les VM ; supprimez toutes les adresses IP publiques des serveurs.

Justification : Élimine les surfaces de gestion exposées tout en préservant un accès auditable et limité dans le temps, aligné sur le principe du moindre privilège.

Activez les journaux de flux NSG et Traffic Analytics, configurez les diagnostics du pare-feu et du WAF vers Log Analytics, et définissez des alertes pour les atténuations DDoS et les pics de blocage WAF.

Justification : La télémétrie unifiée permet une détection proactive, une planification de la capacité et une réponse rapide aux incidents. L’alerte sur les schémas d’anomalies détecte précocement les attaques et les erreurs de configuration.

Implémentez Azure Policy pour refuser les adresses IP publiques sur les cartes réseau (NIC), exiger des NSG sur tous les sous-réseaux et auditer les VNet sans protection DDoS activée ; intégrez les vérifications de politique dans le CI/CD.

Justification : Empêche la dérive de configuration, applique des garde-fous à l’échelle et rend les paramètres de sécurité par défaut reproductibles pour les futures charges de travail.

← Gestion des identités et des accès · Tous les domaines · Sécurité du calcul →

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