Microsoft AZ-700: Sécurité du réseau — Guide d'étude

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Network Engineer AZ-700 — 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.

Contrôle d’accès réseau : conception des NSG et ASG, routage et peering

Les groupes de sécurité réseau (NSG) restent le mécanisme principal et peu coûteux pour filtrer le trafic entrant et sortant des sous-réseaux et des cartes réseau (NIC). Les NSG sont stateful (à état), peuvent référencer des service tags (par ex., Internet, Storage) et prennent en charge les groupes de sécurité d’application (ASG) pour regrouper les cartes réseau des machines virtuelles et faciliter la maintenance des règles pour les grands parcs. Appliquez les NSG au niveau du sous-réseau pour une segmentation large et au niveau de la carte réseau pour les exceptions spécifiques à l’hôte ; n’oubliez pas que les deux sont évalués et que l’ensemble de règles effectif le plus restrictif s’applique. Les pièges courants incluent l’oubli des règles par défaut (règles système d’autorisation/refus à des priorités élevées), un mauvais classement des priorités (les priorités des règles NSG vont de 100 à 4096 ; les valeurs par défaut du système se situent à 65 000 et plus), et le fait de supposer que les NSG fournissent des capacités d’IDS/antivirus — ils n’inspectent pas les charges utiles (payloads). Lors du peering de réseaux virtuels, les NSG régissent toujours le trafic entre les pairs, mais les routes définies par l’utilisateur (UDR) peuvent remplacer les routes système et créer involontairement un trou noir (blackhole) pour le trafic si un tronçon suivant (par exemple, vers un Azure Firewall) n’est pas joignable dans ce contexte. Les compromis de conception pèsent le coût et la simplicité des NSG/ASG par rapport à la visibilité et aux contrôles avancés d’un pare-feu centralisé : les NSG sont peu coûteux et performants pour un filtrage grossier ; utilisez un pare-feu managé pour la journalisation centralisée, le contrôle DNAT/NAT et les politiques de couche applicative.

Contrôles de périmètre et est-ouest : Azure Firewall, DNAT, règles d’application et IDPS

Azure Firewall fournit un périmètre stateful managé capable de gérer les règles DNAT, SNAT et de couche applicative. Architecturez-le dans un sous-réseau dédié AzureFirewallSubnet et utilisez des tables de routage pour diriger le trafic est-ouest hub-spoke à travers le pare-feu pour inspection. Utilisez des collections de règles DNAT pour publier des services internes : spécifiez les plages sources, l’IP de destination, les ports de destination et l’IP:port de destination traduit. Les collections de règles d’application vous permettent d’autoriser par FQDN pour le HTTP/S (par ex., *.microsoft.com), ce qui évite les listes d’autorisation d’IP fragiles. Pour l’inspection approfondie des paquets et l’inspection du trafic chiffré, Azure Firewall Premium ajoute un moteur IDPS et l’inspection TLS, à un coût et une complexité opérationnelle plus élevés pour la gestion des certificats et une latence potentielle. Les NVA tierces restent un choix valide lorsque vous avez besoin de signatures spécialisées ou de caractéristiques de performance spécifiques. Les décisions en matière de mise à l’échelle et de résilience incluent l’utilisation de la mise à l’échelle automatique du pare-feu (v2) ou de déploiements redondants interzones par rapport à des instances fixes : la mise à l’échelle automatique atténue les contraintes de débit mais est plus coûteuse. Surveillez les métriques et les journaux du pare-feu dans Log Analytics pour détecter l’épuisement des ports DNAT/SNAT et ajuster l’ordre des règles et le nombre d’adresses IP publiques si nécessaire.

Azure Firewall Standard : filtrage stateful L3–L7, NAT/DNAT, règles d’application et réseau, service managé avec options de mise à l’échelle automatique et journalisation intégrée.
Azure Firewall Premium : inclut les fonctionnalités Standard plus l’IDPS, l’inspection TLS, la threat intelligence avancée et le filtrage d’URL ; coût plus élevé et nécessite la gestion des certificats/clés pour l’inspection TLS.

Protection de la couche applicative, Private Link et DDoS

Protégez les applications web en périphérie (at the edge) avec des WAF et des services de périphérie distribués. Application Gateway WAF_v2 fournit un WAF régional avec une intégration dans un VNet et est idéal lorsque les backends sont privés (App Service avec ASE ou des VM). Azure Front Door (périphérie) fournit un équilibrage de charge mondial et un WAF en périphérie du CDN, et réduit la latence pour les clients mondiaux ; choisissez Front Door pour le basculement global et Application Gateway pour la protection régionale des backends privés. La protection DDoS (Basic incluse) doit être mise à niveau vers DDoS Protection Standard lorsque des adresses IP publiques hébergent des services importants ; elle profile automatiquement le trafic et atténue les attaques volumétriques pour les ressources dans un réseau virtuel protégé. Pour un accès privé, Private Link/Private Endpoints fournissent une adresse IP privée dans votre VNet pour les services de plateforme, éliminant ainsi l’exposition publique. Les écueils courants incluent l’oubli de désactiver l’accès réseau public sur la ressource PaaS, une mauvaise gestion de l’intégration DNS privée (vous devez posséder et mapper les zones privatelink ou configurer des redirecteurs conditionnels), et s’attendre à ce que les WAF de périphérie atteignent les points de terminaison privés sans un proxy régional ; souvent, un petit proxy inversé renforcé (Application Gateway ou Firewall) dans un sous-réseau de périmètre achemine le trafic de Front Door vers le point de terminaison privé.

Contrôles opérationnels : journalisation, politique, surveillance et pièges courants pour les ingénieurs

L’hygiène opérationnelle est souvent ce qui distingue les parcs réseau sécurisés des parcs fragiles. Activez les NSG Flow Logs (v2) et les diagnostics Azure Firewall vers un espace de travail Log Analytics géré de manière centralisée et intégrez-les à Azure Monitor et Sentinel pour l’analyse, la chasse aux menaces et les alertes. Utilisez Traffic Analytics pour la topologie agrégée, les principales sources de trafic et les anomalies de flux ; rappelez-vous que Traffic Analytics nécessite Network Watcher et un espace de travail Log Analytics dans la même région. Pour les liaisons hybrides, Network Performance Monitor (NPM) et Connection Monitor fournissent des mesures périodiques de latence, de gigue et de santé du chemin, ce qui aide à prouver le respect des SLA pour ExpressRoute et SD‑WAN. Appliquez des garde-fous avec Azure Policy : exigez un Azure Firewall dans les hubs, interdisez la création d’adresses IP publiques sur les ressources exclusivement privées, et auditez les plages de priorité des règles NSG ou les règles non étiquetées. Les pièges courants incluent la précédence des routes (une UDR surcharge les routes système), l’épuisement des ports SNAT lorsque de nombreuses connexions sortent via une seule adresse IP publique (à atténuer en ajoutant des adresses IP publiques ou en utilisant la mise à l’échelle automatique du pare-feu), et les exigences de nommage des sous-réseaux (AzureFirewallSubnet doit exister pour le pare-feu). Les décisions concernant la résilience par rapport au coût sont itératives : centralisez l’inspection pour la visibilité, mais localisez-la pour les chemins sensibles à la latence et utilisez la mise à l’échelle automatique/la redondance zonale là où les charges de travail sont critiques.

Problème pratique : Scénario d’utilisation

Scénario : La société Contoso Ltd. exploite un réseau Azure en hub-and-spoke s’étendant sur deux régions, avec un VNet hub central contenant un Azure Firewall zonal et des services partagés. Les sites de succursales se connectent via SD‑WAN BGP aux hubs régionaux. Plusieurs applications web PaaS utilisent des points de terminaison privés dans les VNets spoke.

Défi : Les clients Internet doivent atteindre une porte d’entrée publique pour le routage mondial, mais le trafic backend des applications web doit aboutir sur des points de terminaison privés et tout le trafic sortant (egress) des spokes doit être inspecté et journalisé sans exposer publiquement les ressources PaaS.

Approche recommandée :

Déployez Azure Front Door Standard/Premium comme point d’entrée public mondial et attachez une Application Gateway régionale dans chaque hub en tant qu’origine privée, ou utilisez Front Door Premium avec une configuration d’origine privée sécurisée là où c’est pris en charge.
Placez une Application Gateway v2 dans le sous-réseau du VNet hub (dédié par AGW) et configurez-la pour transférer le trafic vers le App Service Private Endpoint via le peering de VNet ; activez WAF_v2 sur l’Application Gateway et associez une politique WAF gérée.
Routez tout le trafic sortant des spokes via l’Azure Firewall Premium du hub (dans AzureFirewallSubnet) en utilisant des UDR sur les spokes ; activez les règles DNAT pour les traductions entrantes requises et les règles d’application pour le trafic sortant (egress) FQDN ; activez l’IDPS et l’inspection TLS sur le SKU Premium pour la visibilité du trafic chiffré.
Centralisez les journaux dans un espace de travail Log Analytics, activez les NSG Flow Logs et Traffic Analytics, activez DDoS Protection Standard sur les adresses IP publiques du hub, et appliquez l’architecture avec Azure Policy (exiger un pare-feu, interdire l’accès réseau public sur les services PaaS).

Justification : Front Door offre une disponibilité mondiale et une faible latence, Application Gateway avec WAF_v2 sécurise les backends privés, et Azure Firewall Premium fournit une inspection centralisée, le DNAT et l’IDPS pour le trafic sortant (egress) et entrant (ingress). La journalisation centralisée et l’application des politiques garantissent la visibilité et la conformité tout en gardant les points de terminaison PaaS privés.

← Azure DNS et résolution de noms · Tous les domaines · Équilibrage de charge et gestion du trafic →

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