06 · Implémenter la sécurité pour les services réseau Azure

Version : 1.2 · Date : 2026-10-21 · Domaine 2 de l'examen : Stockage sécurisé, bases de données et mise en réseau (25 à 30 %)

En une phrase : on chiffre les accès hybrides (VPN, ExpressRoute, Private Access), on inspecte au centre (Azure Firewall, hub Virtual WAN), on filtre au plus près des ressources (NSG, ASG, AVNM security admin rules), on retire l'exposition publique des PaaS (Private Link) et on sait prouver qui bloque quoi (Network Watcher).

Ce que l'examen demande#

Repris mot pour mot du guide d'étude SC-500, version anglaise :

Les compléments de l'ancienne AZ-500 (DDoS Protection, routage, sortie par défaut, network security perimeter) sont regroupés en 11.

1. Les bases à maîtriser avant tout#

1.1 Quel outil pour quel besoin ?#

1.2 Le routage, à comprendre avant la sécurité (complément AZ-500)#

Un filtre ne sert à rien si le trafic ne passe pas par lui (UDR, next hops : acquis AZ-700). Les trois points qui tombent en sécurité :

• une UDR 0.0.0.0/0 → appliance virtuelle (IP privée du pare-feu) est le mécanisme d'inspection hub and spoke classique ;
• les routes de service endpoint l'emportent sur les UDR et BGP pour les préfixes du service : ce trafic ne passe donc pas par le pare-feu (7.6) ;
• la route /32 d'un private endpoint l'emporte sur 0.0.0.0/0 (7.2).

1.3 Les service tags et l'adresse 168.63.129.16#

• Un service tag représente les préfixes IP d'un service Azure (Internet, VirtualNetwork, AzureLoadBalancer, Storage, Sql…), tenus à jour par Microsoft. On l'utilise dans les NSG, Azure Firewall et les règles AVNM au lieu de listes d'IP.
• 168.63.129.16 et 169.254.169.254 sont les IP virtuelles de l'hôte (DHCP, DNS, IMDS, sondes d'intégrité). Elles ne sont pas filtrées par les NSG, sauf règle explicite sur les balises AzurePlatformDNS, AzurePlatformIMDS, AzurePlatformLKM.
• 168.63.129.16 n'est joignable que depuis un VNet Azure : un serveur DNS local ne peut pas l'interroger directement (7.3).

2. Network security groups (NSG) et application security groups (ASG)#

2.1 Une règle de NSG#

• Avec état : si le sortant vers le port 80 est autorisé, la réponse revient sans règle entrante (et inversement).
• Une règle modifiée ou supprimée ne coupe pas les connexions existantes : seule une nouvelle connexion est évaluée.
• Augmented security rules : plusieurs IP, plages et ports dans une même règle ; mais un seul service tag ou un seul ASG par champ.
• En entrée, le NSG voit les adresses après la traduction public IP → IP privée ; en sortie, avant la traduction.

2.2 Les règles par défaut (impossibles à supprimer)#

On ne les supprime pas : on les surcharge par une règle de priorité plus forte (nombre plus petit).

Piège : la balise VirtualNetwork couvre l'espace d'adresses du VNet, les VNet appairés, les plages locales connectées par une passerelle, l'IP virtuelle de l'hôte et les préfixes utilisés dans les UDR. La règle 65000 autorise donc beaucoup plus que « mon VNet ».

2.3 L'ordre d'évaluation : sous-réseau, puis network interface#

Cas particuliers vus à l'examen :

• Aucun NSG ni sur le sous-réseau ni sur la NIC : tout le trafic passe… sauf qu'une public IP Standard est sécurisée par défaut : sans NSG, le trafic Internet entrant est bloqué.
• Le même NSG peut être associé à autant de sous-réseaux et de network interfaces qu'on veut.
• Bonne pratique Microsoft : associer le NSG au sous-réseau ou à la network interface, pas aux deux.
• Des AVNM security admin rules sont évaluées avant les NSG (3.3).

flowchart TD
    A["Paquet entrant vers une VM"] --> B{"Security admin rule AVNM ?"}
    B -- "Deny" --> X["Bloqué"]
    B -- "Always Allow" --> V["Livré à la VM, NSG ignorés"]
    B -- "Allow ou aucune règle" --> C{"NSG du sous-réseau :<br/>première règle qui correspond"}
    C -- "Deny" --> X
    C -- "Allow ou pas de NSG" --> D{"NSG de la network interface :<br/>première règle qui correspond"}
    D -- "Deny" --> X
    D -- "Allow ou pas de NSG" --> V2["Livré à la VM"]

2.4 Les application security groups (ASG)#

Un ASG regroupe des network interfaces par rôle (web, logique, base) ; on écrit ensuite les règles avec ces noms au lieu d'IP. Une VM ajoutée à AsgWeb reçoit immédiatement les bonnes règles.

Lecture des règles du schéma : la 120 Deny * → AsgDb 1433 est indispensable, car la règle par défaut 65000 autoriserait tout le VNet à joindre la base ; la 110 AsgLogic → AsgDb passe avant (100 < 110 < 120).

2.5 Mise en œuvre#

Azure CLI (exemple du tutoriel Microsoft Filtrer le trafic réseau) :

# Groupes de sécurité d'application et NSG
az network asg create --resource-group rg-app --name asg-web
az network nsg create --resource-group rg-app --name nsg-app

# Autoriser HTTP depuis Internet vers les seules VM du groupe asg-web
az network nsg rule create --resource-group rg-app --nsg-name nsg-app --name Allow-HTTP-Web \
  --access Allow --protocol Tcp --direction Inbound --priority 100 \
  --source-address-prefix Internet --source-port-range "*" \
  --destination-asgs asg-web --destination-port-range 80

# Associer le NSG au sous-réseau
az network vnet subnet update --resource-group rg-app --vnet-name vnet-app --name snet-web \
  --network-security-group nsg-app

Bicep (le même NSG, déclaré en code) :

resource asgWeb 'Microsoft.Network/applicationSecurityGroups@2023-11-01' = {
  name: 'asg-web'
  location: location
}

resource nsgApp 'Microsoft.Network/networkSecurityGroups@2023-11-01' = {
  name: 'nsg-app'
  location: location
  properties: {
    securityRules: [
      {
        name: 'Allow-HTTP-Web'
        properties: {
          priority: 100
          direction: 'Inbound'
          access: 'Allow'
          protocol: 'Tcp'
          sourceAddressPrefix: 'Internet'
          sourcePortRange: '*'
          destinationApplicationSecurityGroups: [ { id: asgWeb.id } ]
          destinationPortRange: '80'
        }
      }
    ]
  }
}

2.6 Flow logs#

Après la date de retraite, Azure supprime les ressources de NSG flow logs mais pas les enregistrements déjà stockés dans le storage account. Les NSG flow logs ne couvrent pas le trafic entrant vers un private endpoint.

3. Azure Virtual Network Manager (AVNM)#

3.1 Le principe#

Azure Virtual Network Manager gère les VNet à grande échelle, entre abonnements et locataires, depuis un point central. Le fonctionnement tient en quatre étapes :

1. Étendue du gestionnaire : une liste d'abonnements ou des management groups.
2. Network groups : des conteneurs de VNet, à static membership (choix manuel) ou dynamique (conditions évaluées par Azure Policy, par exemple un tag ; il faut alors des droits de lecture et d'écriture sur la stratégie).
3. Configurations appliquées aux groupes : connectivity (maillage ou hub and spoke), security admin, routing (UDR gérées à grande échelle).
4. Déploiement par région : une configuration n'a aucun effet tant qu'elle n'est pas déployée dans la région des VNet cibles.

3.2 Les network groups#

Un VNet peut appartenir à plusieurs groupes et à plusieurs instances AVNM ; les appartenances sont visibles dans Azure Resource Graph.

3.3 Security admin rules#

Points d'examen :

• Une seule security admin configuration par région ; pour en avoir « plusieurs », on crée plusieurs rule collections dans la même configuration (plusieurs connectivity configurations sont possibles).
• Déploiement en cohérence éventuelle : les règles arrivent après un court délai, y compris sur les nouvelles VM.
• Cas d'usage phare : bloquer les ports à haut risque depuis Internet (20, 21, 22, 23, 69, 111, 119, 135, 161, 162, 445, 512, 514, 593, 873, 2049, 3389, 5800, 5900, 11211), avec des exceptions par « Always Allow » ou par priorité.
• Les balises AzurePlatformDNS, AzurePlatformIMDS, AzurePlatformLKM ne sont pas prises en charge dans les security admin rules.
• Non appliquées : aux sous-réseaux de VPN gateway et ExpressRoute, Azure Firewall, Bastion, Route Server, Virtual WAN, Application Gateway sans isolation réseau ; par défaut aux VNet qui contiennent SQL Managed Instance ou Azure Databricks (option AllowRulesOnly pour n'y appliquer que les règles Allow) ; ni aux private endpoints d'un VNet géré.

AVNM ne remplace pas les UDR pour faire passer le trafic entre spokes par le pare-feu du hub : il faut une routing configuration (ou des UDR) qui pointe vers le pare-feu. La routing configuration peut importer l'IP privée d'Azure Firewall comme next hop.

4. Sécuriser Azure Virtual WAN#

4.1 Virtual hub et secured virtual hub#

• Un virtual hub Virtual WAN est un VNet géré par Microsoft qui porte les passerelles (VPN S2S, P2S, ExpressRoute) et relie succursales et VNet.
• Un secured virtual hub est un hub auquel Azure Firewall Manager associe des stratégies de sécurité et de routage. On y déploie Azure Firewall, un fournisseur SECaaS tiers, ou une NVA de pare-feu de nouvelle génération.
• Il filtre le trafic V2V (VNet à VNet), B2V / V2B (succursale et VNet), B2B (succursale à succursale) et la sortie Internet (B2I, V2I), sans UDR à écrire.
• Limite : jusqu'à 80 public IPs par Azure Firewall de secured hub (250 avec BYOIP, en préversion).

4.2 Le routing intent#

Le routing intent est la manière déclarative d'envoyer le trafic vers la solution de sécurité du hub. Chaque hub a au plus une Internet traffic routing policy et au plus une Private traffic routing policy, chacune avec un seul next hop.

À connaître pour l'examen :

• Le routing intent est obligatoire pour sécuriser le trafic entre hubs et entre succursales, même dans un seul hub, et elle doit être activée sur tous les hubs pour un routage symétrique.
• La route par défaut ne se propage pas d'un hub à l'autre : chaque hub sort par sa propre solution de sécurité.
• Prérequis : aucune route table personnalisée (seules defaultRouteTable et noneRouteTable), pas de route statique vers une connexion de VNet ; sinon l'option est grisée.
• Seules certaines NVA sont éligibles comme next hop (pare-feu de nouvelle génération ou rôle double NGFW + SD-WAN) ; la liste est dans la documentation ; au plus une solution SaaS par hub.
• ExpressRoute chiffré (VPN S2S par-dessus ExpressRoute) avec routing intent : autoriser dans le pare-feu le trafic entre les IP privées des tunnels.
• Avant d'activer : sauvegarder passerelles, connexions et route tables (rien n'est restauré automatiquement).

4.3 Azure Firewall Manager#

Firewall Manager centralise les firewall policies (et leur hiérarchie) pour deux architectures : secured virtual hubs (Virtual WAN) et VNet de hub classiques. Il sert aussi à convertir un hub existant en secured hub.

5. Sécuriser les connexions VPN et ExpressRoute#

5.1 La VPN gateway#

5.2 Custom IPsec/IKE policy#

Par défaut, la passerelle propose un ensemble d'algorithmes ; pour un besoin de conformité, on fixe une custom IPsec/IKE policy sur la connexion :

• disponible sur VpnGw15 et VpnGw1AZ5AZ (et les anciens Standard et HighPerformance) ;
• une seule combinaison par connexion ;
• il faut tout spécifier, IKE (Main Mode) et IPsec (Quick Mode) : pas de stratégie partielle ;
• vérifier que le périphérique local la supporte, sinon le tunnel ne monte pas.

Les meilleures performances sont obtenues avec GCMAES256 pour le chiffrement et l'intégrité IPsec.

5.3 Point-to-Site VPN (P2S)#

• Plusieurs types d'authentification peuvent coexister ; le client doit en supporter au moins un avec le bon tunnel.
• Entra ID : préférer le Microsoft-registered app (audience c632b3df-fb67-4d84-bdcf-b95ad541b5c8), sans inscription manuelle ni consentement de Cloud Application Administrator ; les clients manually registered sont retirés le 31 mars 2028 (cloud public). Le Azure VPN Client pour Linux (préversion) est retiré depuis le 31 août 2026.
• On peut restreindre l'accès P2S par utilisateurs et groupes Entra.

flowchart TD
    A["Besoin P2S"] --> B{"MFA et Conditional Access<br/>Entra exigés ?"}
    B -- Oui --> C["Authentification Microsoft Entra ID<br/>tunnel OpenVPN + Azure VPN Client"]
    B -- Non --> D{"Annuaire AD existant<br/>et serveur RADIUS ?"}
    D -- Oui --> E["RADIUS, passerelle en relais"]
    D -- Non --> F["Certificat : racine chargée<br/>sur la passerelle, certificat client"]

5.4 ExpressRoute : privé ne veut pas dire chiffré#

• Par défaut, le trafic ExpressRoute n'est pas chiffré.
• MACsec (couche 2) : uniquement sur ExpressRoute Direct (pas sur un circuit fourni par un opérateur) ; désactivé par défaut ; vous apportez la clé, stockée dans Key Vault (ne pas mettre ce Key Vault derrière un private endpoint : le plan de gestion ExpressRoute doit lire le secret ; ExpressRoute est un trusted service du Key Vault firewall) ; une erreur de clé coupe la connexion, sans repli en clair.
• IPsec (couche 3, de bout en bout) : tunnel VPN S2S par-dessus le private peering ExpressRoute (ou VPN over ExpressRoute dans Virtual WAN). MACsec et IPsec peuvent être activés ensemble.
• Authentification MD5 des sessions BGP possible ; chaque peering est une paire de sessions BGP redondantes.

6. Microsoft Entra Private Access#

6.1 Le principe : ZTNA plutôt que VPN#

Private Access fait partie de Global Secure Access (le Security Service Edge de Microsoft, avec Internet Access). L'utilisateur installe le Global Secure Access client ; son trafic vers les FQDN et IP déclarés privés passe par le service Microsoft, qui applique le Conditional Access, puis le relaie via un private network connector installé dans le réseau de l'entreprise.

6.2 Licences et rôles#

• Entra ID P1 ou P2 (prérequis) + licence Microsoft Entra Private Access (seule) ou Microsoft Entra Suite (aussi incluse dans Microsoft 365 E7).
• Rôles : Global Secure Access Administrator (et Application Administrator pour le Quick Access et les groupes de connecteurs) ; Conditional Access Administrator pour les stratégies ; un Global Administrator pour enregistrer le premier connecteur du locataire.

6.3 Marche à suivre#

1. Activer Global Secure Access dans le locataire.
2. Installer au moins deux connecteurs dans un connector group, vérifier qu'ils sont Actifs.
3. Configurer le Quick Access (ou des per-app access applications : FQDN ou IP + port).
4. Affecter utilisateurs et groupes à l'Enterprise application.
5. Créer les Conditional Access policies qui ciblent ces applications (MFA, appareil conforme, risque…).
6. Activer le Private Access traffic forwarding profile et l'affecter.
7. Déployer le Global Secure Access client (appareils Entra joints ou joints hybrides pour Windows).
8. Évoluer : utiliser la application discovery pour découper le Quick Access en per-app access applications.

7. Private endpoints pour les PaaS#

7.1 Ce qu'est un private endpoint#

Un private endpoint est une network interface en lecture seule, créée automatiquement dans votre sous-réseau, avec une IP privée fixe pour toute sa durée de vie, reliée par Private Link à une ressource précise (et une sub-resource).

Piège majeur : créer un private endpoint ne coupe pas l'accès public de la ressource. Il faut aussi désactiver le public network access (ou restreindre le pare-feu du service).

7.2 Network policies sur le sous-réseau du private endpoint#

Par défaut, les network policies sont désactivées pour les private endpoints d'un sous-réseau : les NSG et les UDR ne s'appliquent pas à eux. On les active par sous-réseau (privateEndpointNetworkPolicies : Disabled, NetworkSecurityGroupEnabled, RouteTableEnabled, Enabled ; la CLI n'accepte que vrai ou faux).

• Pour forcer le passage par un pare-feu, l'UDR doit avoir un préfixe égal ou plus spécifique que l'espace d'adresses du VNet : une route 0.0.0.0/0 ne l'emporte pas sur la route /32 du private endpoint (plus long préfixe).
• Le SNAT est recommandé sur la NVA pour garantir le retour du trafic.
• Le filtrage par port source est ignoré ; refuser le sortant depuis un private endpoint n'a pas de sens.
• Les règles effectives et routes effectives ne s'affichent pas pour sa network interface dans le portail.

7.3 Le DNS, le point qui fait échouer la plupart des déploiements#

Le client continue d'utiliser le nom public (mystorage.blob.core.windows.net). Azure publie un CNAME vers mystorage.privatelink.blob.core.windows.net ; si le client interroge une private DNS zone privatelink.blob.core.windows.net liée à son VNet, il obtient l'IP privée ; sinon il obtient le public IP.

sequenceDiagram
    participant C as Client local
    participant L as DNS local
    participant R as DNS Private Resolver (entrant)
    participant Z as Zone privée privatelink.blob
    C->>L: mystorage.blob.core.windows.net ?
    L->>R: conditional forwarder blob.core.windows.net
    R->>Z: via Azure DNS (VNet lié à la zone)
    Z-->>R: CNAME privatelink, puis A 10.1.2.5
    R-->>L: 10.1.2.5
    L-->>C: 10.1.2.5, trafic par VPN ou ExpressRoute

• Le conditional forwarder vise la zone publique (blob.core.windows.net, database.windows.net), pas privatelink.*.
• Le DNS Private Resolver : inbound endpoint (cible des redirecteurs locaux) et outbound endpoint (vers le DNS local, avec des DNS forwarding rulesets jusqu'à 1 000 règles) ; chacun dans son propre sous-réseau délégué à Microsoft.Network/dnsResolvers.
• Avec un seul DNS partagé, un seul private endpoint par ressource, pour éviter les conflits d'enregistrements.

7.4 Mise en œuvre#

# Private endpoint vers la sous-ressource blob d'un storage account
az network private-endpoint create --resource-group rg-app --name pe-st-blob \
  --vnet-name vnet-spoke --subnet snet-pe \
  --private-connection-resource-id <id-du-compte-de-stockage> \
  --group-id blob --connection-name cnx-st-blob

# Zone DNS privée, lien vers le VNet, groupe de zones pour l'enregistrement A automatique
az network private-dns zone create --resource-group rg-dns --name privatelink.blob.core.windows.net
az network private-dns link vnet create --resource-group rg-dns --zone-name privatelink.blob.core.windows.net \
  --name lien-vnet-spoke --virtual-network <id-du-vnet> --registration-enabled false
az network private-endpoint dns-zone-group create --resource-group rg-app --endpoint-name pe-st-blob \
  --name default --private-dns-zone <id-de-la-zone> --zone-name blob

# Couper ensuite l'accès public du compte
az storage account update --resource-group rg-app --name <compte> --public-network-access Disabled

7.5 Resource Management Private Link (pour aller plus loin)#

Le tableau des ressources Private Link contient aussi les Resource Management Private Links (Microsoft.Authorization/resourceManagementPrivateLinks), pour accéder au plan de gestion Azure Resource Manager en privé.

7.6 Service endpoint ou private endpoint ?#

Détails du service endpoint :

• son activation ferme les connexions TCP ouvertes du sous-réseau vers le service (passage public IP → IP privée) ; les règles de pare-feu du service qui autorisaient le public IP cessent de fonctionner ;
• pour Azure SQL, il ne couvre que la même région ; Microsoft.Storage.Global couvre le stockage de toutes les régions ;
• il faut l'autorisation Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action pour ajouter un sous-réseau à une ressource ;
• ses routes l'emportent sur les UDR et BGP pour les préfixes du service (le trafic ne passe donc pas par le forced tunneling).

Service endpoint policy (Stockage) : sur un sous-réseau qui a déjà le service endpoint, on liste les comptes autorisés (par abonnement, resource group ou compte) ; tous les autres comptes sont refusés. C'est une stratégie d'autorisation : penser aux dépendances. Pas pour le trafic local, pas pour les comptes classiques, pas pour les services managés (sauf SQL Managed Instance).

8. Private Link service#

Le Private Link service permet à un fournisseur (vous, un éditeur) de rendre son application, placée derrière un Load Balancer Standard, joignable par des private endpoints dans les VNet de ses clients (autres abonnements, autres locataires).

Le consommateur se connecte avec l'alias en approbation manuelle (approuvée automatiquement si son abonnement est dans la liste du fournisseur).

9. Azure Firewall#

9.1 Les trois SKU#

Les firewall policies suivent les SKU : Firewall Policy Basic (pour Basic), Standard (Standard ou Premium), Premium (Premium : TLS, IDPS, URL filtering).

9.2 Déploiement#

• Sous-réseau AzureFirewallSubnet, /26 minimum, rien d'autre dedans.
• Forced tunneling : carte de gestion dans AzureFirewallManagementSubnet ; le trafic de gestion reste séparé, et le pare-feu peut alors fonctionner sans public IP sur le chemin des données (la sortie Internet est renvoyée vers un pare-feu local ou une NVA, ou bloquée).
• Le pare-feu doit garder un accès Internet direct : si AzureFirewallSubnet apprend une route par défaut en BGP, la surcharger par une UDR 0.0.0.0/0 → Internet (hors forced tunneling).
• Les spokes envoient leur trafic au pare-feu par une UDR 0.0.0.0/0 (et les préfixes des autres spokes) avec comme next hop l'IP privée du pare-feu (ou par le routing intent dans Virtual WAN).
• SNAT : pas de SNAT vers les plages privées RFC 1918 et RFC 6598 ; le trafic des application rules est toujours SNATé (pour garder l'IP source dans les journaux, utiliser une network rule avec FQDN).
• Le pare-feu complète les en-têtes X-Forwarded-For en HTTP et en HTTPS inspecté.

9.3 Règles et ordre de traitement#

Ordre de traitement complet :

1. Threat intelligence (s'il est activé) : avant tout le reste.
2. Les règles DNAT, puis réseau, puis application, quel que soit le groupe ou la priorité.
3. Dans chaque type : la parent policy d'abord, puis les rule collection groups par priorité (100 à 65 000), puis les collections par priorité ; la première correspondance arrête tout.
4. Sans correspondance : la infrastructure rule collection (FQDN de la plateforme), puis le refus par défaut.

flowchart LR
    A["Paquet"] --> TI{"Threat<br/>intelligence"}
    TI -- "IP ou domaine malveillant,<br/>mode Alert and deny" --> X["Refusé"]
    TI -- "sinon" --> N["DNAT"] --> R{"Network rule<br/>qui correspond ?"}
    R -- "Oui" --> F["Action de la règle"]
    R -- "Non" --> P{"Application rule<br/>qui correspond ?"}
    P -- "Oui" --> F
    P -- "Non" --> I{"Infrastructure<br/>rule collection ?"}
    I -- "Oui" --> F
    I -- "Non" --> X

Piège classique : une network rule Allow TCP 80, 443 vers * rend inutile une application rule Deny google.com : le paquet correspond à la network rule, le traitement s'arrête, google.com passe.

Autres comportements :

• Avec état : le trafic de retour d'une connexion autorisée passe même si une règle refuse le sens inverse ; une règle autorisant A → B n'autorise pas les connexions initiées par B.
• Modifier une règle pour refuser un trafic coupe les sessions existantes concernées (contrairement au NSG).
• Firewall Policy hiérarchique : une child policy hérite des collections de la parent policy, toujours prioritaires ; parent et enfant dans la même région, mais une stratégie peut être associée à des pare-feu de toute région. Les collections NAT ne sont pas héritées (elles sont propres à chaque pare-feu) : le DNAT se définit dans la child policy de chaque pare-feu.

9.4 Threat intelligence, IDPS et TLS inspection#

9.5 DNS proxy et FQDN#

• Le DNS proxy est requis pour utiliser des FQDN dans les network rules ; on configure ensuite l'IP privée du pare-feu comme serveur DNS des VNet, pour que clients et pare-feu résolvent pareil.
• Cache positif jusqu'à 1 heure, négatif jusqu'à 30 minutes ; les IP résolues sont mises à jour toutes les 15 secondes, les anciennes expirent après 15 minutes.
• Toujours préférer les application rules pour HTTP, HTTPS et MSSQL (elles distinguent deux FQDN sur la même IP grâce au SNI) ; les FQDN tags (Windows Update, Azure Backup…) simplifient la sortie des services Microsoft.

9.6 Mise en œuvre#

# Stratégie Premium, renseignement sur les menaces en mode refus
az network firewall policy create --resource-group rg-hub --name fwp-hub --sku Premium --threat-intel-mode Deny

# Groupe de collections, puis collection d'application : sortie HTTPS vers *.microsoft.com depuis le spoke
az network firewall policy rule-collection-group create --resource-group rg-hub --policy-name fwp-hub \
  --name rcg-sortie --priority 300
az network firewall policy rule-collection-group collection add-filter-collection --resource-group rg-hub \
  --policy-name fwp-hub --rule-collection-group-name rcg-sortie --name autoriser-microsoft \
  --collection-priority 100 --action Allow --rule-type ApplicationRule --rule-name microsoft \
  --source-addresses 10.1.0.0/16 --protocols Https=443 --target-fqdns "*.microsoft.com"

10. Network Watcher, diagnostiquer et prouver#

Network Watcher est activé automatiquement dans la région à la création ou à la mise à jour d'un VNet (une instance par région et par abonnement). Il est fait pour l'IaaS, pas pour superviser du PaaS.

En complément, le Virtual Network Verifier d'AVNM analyse l'accessibilité entre ressources en tenant compte des règles et stratégies.

# Quelle règle autorise ou refuse RDP vers la VM ?
az network watcher test-ip-flow --direction Inbound --protocol TCP \
  --local 10.0.0.4:3389 --remote 10.0.1.4:* --vm <id-de-la-vm> --nic <nom-de-la-carte>

# Règles effectives d'une carte réseau
az network nic list-effective-nsg --resource-group rg-app --name nic-vm01 --output table

# Tronçon suivant vers une destination
az network watcher show-next-hop --resource-group rg-app --vm vm01 --nic nic-vm01 \
  --source-ip 10.0.0.4 --dest-ip 13.107.21.200 --output table

11. Compléments AZ-500 et culture réseau#

11.1 Azure DDoS Protection#

• En dessous d'environ 15 public IPs, IP Protection coûte moins cher ; au-delà, Network Protection.
• Avec un plan Network Protection, une Application Gateway avec WAF dans le VNet protégé est facturée au tarif sans WAF.
• Connecteur de données et classeur Microsoft Sentinel disponibles (chapitre 11) ; intégration à Firewall Manager.
• Réduire la surface : moins de public IPs (Private Link), NSG derrière les IP protégées.

11.2 Fin du default outbound access#

Une VM sans méthode de sortie explicite recevait une public IP implicite. Depuis le 30 septembre 2025, les nouvelles VM ne doivent plus compter dessus, et pour les versions d'API postérieures au 31 mars 2026, les sous-réseaux des nouveaux VNet sont privés par défaut (defaultOutboundAccess = false, déjà le défaut du portail). Les VNet existants ne changent pas. Méthodes explicites : NAT Gateway sur le sous-réseau, public IP sur la NIC, outbound rules d'un Standard Load Balancer, ou UDR vers un pare-feu. Azure Advisor signale les NICs concernées.

11.3 Network Security Perimeter#

Disponible en général dans les régions publiques. Il crée une frontière logique autour de PaaS hors VNet (Stockage, SQL Database, Key Vault, Event Hubs, Cosmos DB…) : les membres communiquent entre eux, l'accès public est refusé par défaut sauf access rules entrantes (IP, abonnements) et sortantes (FQDN).

Le trafic des private endpoints n'est pas soumis aux règles du périmètre. Démarrer en mode Transition, analyser les journaux, puis passer en mode Enforced.

11.4 Renvois#

• Azure Bastion (RDP/SSH sans public IP), JIT : chapitre 08.
• WAF sur Application Gateway et Front Door, App Service, APIM : chapitre 09.
• Storage firewall, accès public des comptes : chapitre 04 ; SQL firewall : chapitre 05 ; Key Vault firewall : chapitre 02.

12. Labs conseillés#

À faire dans un abonnement de test (Azure Firewall et la VPN gateway coûtent cher : les supprimer le jour même).

Lab 1 · NSG, ASG et Network Watcher

1. Un VNet, un sous-réseau, deux VM (vm-web dans asg-web, vm-db dans asg-db), un NSG au sous-réseau avec Internet → asg-web 80 autorisé et * → asg-db 1433 refusé.
2. IP flow verify depuis vm-web vers vm-db:1433 : la règle qui refuse est nommée.
3. Effective security rules de la NIC de vm-db : les règles du NSG et les règles par défaut, combinées.
4. Ajouter un second NSG sur la NIC de vm-web sans règle : le port 80 depuis Internet est refusé (les deux NSG doivent autoriser).

Lab 2 · AVNM security admin rule

1. Créer un Virtual Network Manager sur l'abonnement de test, un network group dynamique (tag env = test).
2. Security admin configuration : Deny 3389 et 22 depuis Internet ; la déployer dans la région.
3. Ajouter un NSG qui autorise 3389 : la connexion RDP reste bloquée. Retirer le déploiement : elle passe.

Lab 3 · Private endpoint et DNS

1. Storage account + private endpoint blob sans lier la zone DNS au VNet : nslookup depuis une VM renvoie l'IP publique.
2. Lier privatelink.blob.core.windows.net au VNet et créer le DNS zone group : l'IP privée apparaît.
3. Désactiver l'accès public du compte et vérifier depuis votre poste (refus) et depuis la VM (succès).

Lab 4 · Azure Firewall et ordre des règles

1. Hub avec AzureFirewallSubnet /26, Azure Firewall Standard, Firewall Policy ; spoke appairé avec une UDR 0.0.0.0/0 → IP privée du pare-feu.
2. Application rule Allow *.microsoft.com : curl https://learn.microsoft.com passe, curl https://example.com est refusé (journal AZFWApplicationRule).
3. Ajouter une network rule Allow TCP 443 vers * : example.com passe désormais (les network rules passent avant).
4. Next hop depuis la VM du spoke : VirtualAppliance vers l'IP du pare-feu.

Lab 5 · VPN P2S avec Microsoft Entra ID

1. VPN Gateway VpnGw1AZ route-based, address pool, tunnel OpenVPN, authentification Microsoft Entra ID (Microsoft-registered app).
2. Télécharger le profil, l'importer dans le Azure VPN Client et se connecter : invite Entra avec MFA.
3. Créer une Conditional Access policy ciblant le Microsoft-registered VPN app (ID c632b3df-fb67-4d84-bdcf-b95ad541b5c8) qui exige un appareil conforme : vérifier le refus depuis un poste non conforme.

13. Les pièges d'examen#

14. Scénarios d'entraînement#

1. Contoso a un NSG sur snet-web qui autorise TCP 443 depuis Internet, et un NSG sur la NIC de vm-web1 avec seulement les règles par défaut. Le site n'est pas joignable. Pourquoi ?

En entrée, le NSG du sous-réseau puis celui de la NIC s'appliquent : la NIC refuse avec DenyAllInbound. Il faut autoriser 443 sur la NIC aussi, ou mieux, retirer le NSG de la NIC (un NSG au sous-réseau ou à la NIC).

2. L'équipe sécurité veut qu'aucun VNet de production, présent ou futur, n'expose SSH et RDP à Internet, même si une équipe ajoute une règle NSG. Solution ?

AVNM : network group dynamique (Azure Policy, tag env = prd), security admin configuration avec des règles Deny 22 et 3389 depuis Internet, déployée dans les régions concernées. Les security admin rules passent avant les NSG et un refus les court-circuite.

3. Trois couches applicatives (web, logique, base) dans le même VNet. Comment écrire des règles qui survivent à l'ajout de VM ?

Des ASG (AsgWeb, AsgLogic, AsgDb), des règles par ASG : Internet → AsgWeb 80, AsgLogic → AsgDb 1433 autorisé, puis * → AsgDb 1433 refusé (sinon AllowVNetInBound laisse tout le VNet joindre la base).

4. Fabrikam a quatre hubs Virtual WAN et veut que le trafic entre succursales et entre hubs soit inspecté par Azure Firewall.

Secured hubs (Firewall Manager) et routing intent avec une Private traffic routing policy (et Internet si besoin) sur chaque hub ; vérifier l'absence de route tables personnalisées avant de l'activer.

5. Les commerciaux se connectent en VPN P2S avec un certificat. La DSI veut la MFA et bloquer les appareils non conformes.

Passer la passerelle en authentification Microsoft Entra ID (tunnel OpenVPN, Azure VPN Client, application inscrite par Microsoft) et créer une stratégie de Conditional Access exigeant MFA et appareil conforme.

6. Un datacenter relié par ExpressRoute Direct doit chiffrer le lien vers Microsoft, et une filiale reliée par un circuit d'opérateur aussi.

MACsec sur les ports ExpressRoute Direct (clé dans Key Vault, fenêtre de maintenance) ; pour la filiale, MACsec est impossible : tunnel VPN S2S IPsec par-dessus le private peering.

7. Une entreprise veut supprimer son VPN : les utilisateurs doivent atteindre un partage SMB et un serveur RDP internes, avec MFA, sans ouvrir de port entrant.

Microsoft Entra Private Access : deux private network connectors (sortant 80/443), Quick Access puis per-app access applications (IP + 445, IP + 3389), affectations, Conditional Access MFA, Private Access profile activé, Global Secure Access client. Licence P1 + Private Access (ou Entra Suite).

8. Après la création d'un private endpoint pour un storage account, les VM du spoke résolvent toujours l'IP publique, et le compte reste accessible depuis Internet.

Deux erreurs : la zone privatelink.blob.core.windows.net n'est pas liée au VNet du spoke (ou le DNS zone group manque), et le public network access n'a pas été désactivé.

9. Les serveurs locaux doivent joindre une base Azure SQL par son private endpoint.

DNS Private Resolver avec inbound endpoint dans le hub, zone privatelink.database.windows.net liée au VNet du hub, conditional forwarder local sur database.windows.net vers l'IP du point entrant ; trafic par VPN ou ExpressRoute.

10. Un éditeur SaaS veut que ses clients consomment son API depuis leurs propres VNet, sans Internet ni peering, malgré des plages IP qui se chevauchent.

Private Link service derrière un Standard Load Balancer, NAT IP dans un sous-réseau, visibilité limitée aux abonnements clients, auto-approval pour les clients connus ; proxy protocol v2 si l'API doit connaître l'IP source réelle.

11. Azure Firewall a une network rule Allow TCP 80, 443 vers * et une application rule Deny *.jeux.com. Les jeux restent accessibles. Corriger.

Les network rules sont traitées avant les application rules : retirer la network rule large et autoriser le web par des application rules (FQDN, web categories), ou ajouter un refus dans une network rule plus prioritaire.

12. On doit inspecter le HTTPS sortant pour y appliquer l'IDPS et filtrer des URL complètes.

Azure Firewall Premium avec Firewall Policy Premium : TLS inspection (intermediate CA exportable dans Key Vault, managed identity affectée par l'utilisateur avec Secret Get et List, root CA distribuée aux clients), IDPS en Alert and deny après une phase en Alerte, URL filtering.

13. Un administrateur dit « le NSG bloque RDP » ; un autre dit que c'est la route. Comment trancher vite ?

IP flow verify (donne la règle qui autorise ou refuse), Effective security rules de la NIC, Next hop pour le routage.

15. Pour aller plus loin (au-delà de l'examen)#

• Architecture de référence hub and spoke : Azure Firewall au hub, UDR gérées par la routing configuration AVNM, Bastion au hub, private endpoints et zones DNS centralisées.
• Private DNS zones à grande échelle : une seule zone par service, liée à tous les VNet, créée automatiquement par Azure Policy (DeployIfNotExists) au moment où un private endpoint est créé (voir chapitre 03).
• Standard service endpoint (préversion) : identifiants réseau et intégration au network security perimeter.
• Proxy explicite d'Azure Firewall (préversion) et fichier PAC, pour une sortie HTTP/S sans UDR.
• Microsoft Entra Internet Access : filtrage web côté SSE, restrictions de locataire universelles, réseau conforme dans l'accès conditionnel.
• Azure Policy pour le réseau : interdire les public IPs sur les NICs, imposer les NSG, exiger le threat intelligence sur les firewall policies (définition Azure Firewall Policy should enable Threat Intelligence).

16. Fiche à retenir#

• NSG : priorités 100-4096, première correspondance, avec état, règles par défaut 65000-65500 non supprimables.
• Entrée : sous-réseau puis carte ; sortie : carte puis sous-réseau ; un NSG au sous-réseau ou à la NIC.
• VirtualNetwork inclut les VNet appairés et le site local ; public IP Standard = sécurisée par défaut.
• ASG : par network interface, plusieurs ASG par carte, même VNet ; un seul ASG ou une seule balise par champ.
• NSG flow logs retirés le 30/09/2027 : virtual network flow logs.
• AVNM : network groups static ou dynamic (Azure Policy) ; security admin rules avant les NSG ; Always Allow et Deny court-circuitent les NSG ; priorité 1-4096 ; déployer par région ; une security admin configuration par région.
• Virtual WAN : secured hub = Firewall Manager ; routing intent = une Private traffic routing policy + une Internet traffic routing policy par hub, obligatoire pour l'inter-hub.
• VPN Gateway : GatewaySubnet /27+, route-based, SKU AZ ; custom IPsec/IKE policy complète, une par connexion.
• P2S : Entra ID = OpenVPN + Azure VPN Client (MFA, Conditional Access) ; SSTP = Windows ; Basic : pas d'IKEv2 ni RADIUS.
• ExpressRoute non chiffré : MACsec (Direct, clé dans Key Vault) ou IPsec par-dessus.
• Private Access : client GSA, Quick Access puis par application, Conditional Access, connecteurs sortants 80/443 ×2, licence P1 + Private Access ou Entra Suite.
• Private endpoint : network interface en lecture seule, une sub-resource, approbation auto ou manuelle, ne coupe pas l'accès public.
• DNS : zone privatelink.* liée au VNet + DNS zone group ; local → DNS Private Resolver, redirecteur sur la zone publique.
• Network policies du subnet de private endpoints désactivées par défaut ; 0.0.0.0/0 ne bat pas la route /32.
• Service endpoint : public IP, pas pour le local, gratuit ; service endpoint policy contre l'exfiltration.
• Private Link service : Standard Load Balancer, NAT IP (8 max), alias, visibilité, approbation auto, proxy protocol v2.
• Azure Firewall : AzureFirewallSubnet /26 ; Basic / Standard / Premium (TLS, IDPS, URL) ; menaces → DNAT → réseau → application → infra → refus.
• Threat intelligence : Off, Alerte (défaut), Alert and deny ; Basic = Alert only.
• FQDN en network rule = DNS proxy ; pas de application rules en entrant (WAF).
• Network Watcher : flux IP (quelle règle), règles effectives (toutes les règles), next hop (routage).
• DDoS : IP Protection (par IP) ou Network Protection (100 IP, DRR, cost protection, WAF discount).

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Guide d'étude de l'examen SC-500
• Vue d'ensemble des network security groups Azure
• Façon dont les network security groups filtrent le trafic
• Application security groups
• Filtrer le trafic réseau avec un NSG (tutoriel)
• Routage du trafic de réseau virtuel
• Qu'est-ce qu'Azure Virtual Network Manager ?
• Groupes de réseaux dans Azure Virtual Network Manager
• Règles d'administration de sécurité dans Azure Virtual Network Manager
• Gestion des UDR avec Azure Virtual Network Manager
• Qu'est-ce qu'un secured virtual hub ?
• Routing intent et routing policies du hub Virtual WAN
• À propos du Point-to-Site VPN
• Paramètres de configuration de la VPN gateway
• Références SKU de VPN gateway
• Stratégies IPsec/IKE personnalisées
• Chiffrement pour Azure ExpressRoute
• Découvrir le Microsoft Entra Private Access
• Profils de transfert du trafic Global Secure Access
• Configurer le Quick Access
• Private network connectors Microsoft Entra
• Qu'est-ce que Global Secure Access ? (licences)
• Qu'est-ce qu'un private endpoint ?
• Configuration DNS des private endpoints
• Scénarios d'intégration DNS des private endpoints
• Gérer les network policies pour les private endpoints
• Qu'est-ce que le Azure DNS Private Resolver ?
• Service endpoints de réseau virtuel
• Service endpoint policies pour le Stockage
• Qu'est-ce que le service Azure Private Link ?
• Choisir la référence SKU d'Azure Firewall
• Fonctionnalités d'Azure Firewall par SKU
• Configurer des règles de Azure Firewall (traitement)
• Vue d'ensemble des stratégies Azure Firewall Manager
• Threat intelligence d'Azure Firewall
• Certificats du Azure Firewall Premium
• Paramètres DNS d'Azure Firewall
• Filtrage FQDN dans les network rules
• FAQ d'Azure Firewall (SNAT, forced tunneling)
• Sécuriser votre déploiement d'Azure Firewall
• Présentation d'Azure Network Watcher
• Virtual network flow logs
• Comparaison des niveaux Azure DDoS Protection
• FAQ Azure DDoS Protection
• Accès sortant par défaut dans Azure
• Qu'est-ce qu'un network security perimeter ?