4 — Private & Public Access Security (AZ-500)

Sécuriser l'exposition des PaaS Azure : confiner l'accès au réseau privé (Service/Private Endpoints, Private Link, intégration VNet) et durcir les surfaces publiques restantes (TLS, Azure Firewall, App Gateway/Front Door + WAF, DDoS).

A. Service Endpoints — restreindre, sans privatiser

Le Service Endpoint étend l'identité du VNet/subnet vers le backbone Azure : le PaaS voit l'IP privée source et son firewall accepte le subnet via une VNet rule. L'IP reste publique côté résolution DNS (pas de Private DNS). Angle réseau → renvoie « détail → AZ-700 ».

Service Endpoint Policies (SEP) = contrôle anti-exfiltration storage uniquement : filtre l'egress du subnet vers des comptes storage nommés (subscription/RG/account), au lieu d'autoriser toute la région via le service tag NSG. Le trafic système (backups, etc.) n'est jamais bloqué.

🚨 SEP couvre Microsoft.Storage seulement (+ alias /services/Azure/MachineLearning). Pour SQL MI, le trafic non-Storage (BACPAC on-prem, Data Factory, autre cloud) échappe à SEP → compléter avec UDR/NSG/Firewall. 🚨 SEP n'a aucun effet via Private Endpoint (PE et SEP sont indépendants).

📐 Réf : Service endpoint policies pour Azure Storage

B. Private Endpoints — la NIC privée injectée

PE = NIC avec IP privée dans ton subnet, mappée à une instance précise d'un service (subresource : blob, sqlServer, vault…). Connexion inbound unidirectionnelle (le client initie ; le provider ne route jamais vers toi).

3 piliers à sécuriser :

• NSG sur subnet PE : depuis la GA, les NSG s'appliquent au trafic vers le PE (sinon PrivateEndpointNetworkPolicies à activer) → filtre source/port.
• Private DNS privatelink.<service>.<suffixe> : override le CNAME public vers l'IP privée. Lier la zone au VNet. DNS Zone Group = auto-gestion des A-records (création/suppression, multi-région) — sans script.
• Public network access = Disabled sur la ressource : DNS et access-control sont indépendants. Le CNAME privatelink reste résolvable publiquement (pour scénarios hybrides) ; l'accès est refusé au front-door du service si public désactivé.

🚨 Une zone privatelink ne doit héberger qu'un type de service ; mélanger plusieurs PE du même type dans une zone écrase les A-records → résolution cassée. 🚨 DNS Zone Group : max 5 zones, 1 seule zone par nom, 1 seul group par PE. 🚨 Résolution publique réussie ≠ accès : elle confirme seulement l'existence du nom, pas l'attachement d'un PE.

📐 Réf : What is a private endpoint? · Private DNS zone values

C. Private Link Service — exposer SON propre service

Pour offrir ton service à des consommateurs (autres VNets/tenants) sans IP publique : place l'app derrière un Standard Load Balancer, crée un Private Link Service (PLS) référençant la frontend IP du SLB. Les consommateurs créent un PE pointant vers ton alias ou resource URI.

• NAT IP (subnet provider, ≥8 recommandé) : SNAT côté provider → pas de conflit d'IP avec le consommateur, qui n'a pas besoin d'espace non chevauchant. 64k ports/NAT IP/VM ; scale en ajoutant NAT IPs ou VMs.
• Visibility : None (RBAC) | Restrictive (subs approuvées + RBAC) | All. Auto-approval = liste de subs approuvées automatiquement.
• TCP Proxy v2 : récupère l'IP source réelle + LinkID du PE (le NAT masque sinon la source).

🚨 Standard LB obligatoire — Basic LB non supporté. IPv4 + TCP/UDP uniquement. Idle timeout ~5 min (TCP keepalives requis).

📐 Réf : What is Azure Private Link service?

D. App Service / Functions — inbound vs outbound

Deux fonctions orthogonales, souvent confondues :

• VNet Integration (tiers Basic→Premium, /28 mini) : injecte un NIC dans un subnet délégué. NSG/UDR sur ce subnet contrôlent l'egress. WEBSITE_VNET_ROUTE_ALL (ou site property, auditable Azure Policy) pour router tout le trafic. Ne donne aucun accès inbound.
• Access Restrictions = firewall L3/L4 inbound sur l'endpoint par défaut (main site + site scm/kudu séparément). Ne s'applique PAS au trafic entrant par un PE (filtré, lui, par NSG du subnet PE).

🚨 KV references / certificats TLS depuis KV privé : la récupération passe par VNet Integration si KV bloque le public — mais config de certs TLS depuis KV privé non supportée. 🚨 Service tag AppService = IP inbound multitenant seulement (ni ASE, ni IP-based TLS, ni outbound) → inutilisable pour restreindre l'accès entre apps.

📐 Réf : VNet integration · Access restrictions

E. App Service Environment v3 — isolation native

ASE v3 déploie App Service directement dans ton subnet (Isolated v2). En variante ILB : endpoint applicatif interne au VNet (pas d'Internet), suffixe *.appserviceenvironment.net ou domaine custom.

• Subnet dédié ; VNet Integration implicite (toutes les apps dans le subnet, tout l'outbound route par le VNet par défaut).
• NSG contrôle inbound et outbound, y compris ports non-HTTP (impossible en multitenant). PE et IP restrictions explicitement activables.
• App Service Managed Certificate non supporté en ASE → BYOC ou KV (cert <20 ko, PFX, SNI).

🚨 Custom domain suffix : cert dans Key Vault via managed identity ; scm joignable seulement en basic auth si SAN *.scm.

📐 Réf : Certificates and the App Service Environment · ASE vs multitenant

F. Azure SQL Managed Instance — réseau

SQL MI vit toujours dans un VNet (subnet dédié délégué). Durcissement :

• Subnet dédié + délégation Microsoft.Sql/managedInstances (rien d'autre dans le subnet ; pas de gateway subnet).
• NSG obligatoire sur le subnet : filtre le data endpoint VNet-local (port 1433). Règles management auto-provisionnées (service-aided).
• Route table obligatoire : entrées système gérées ; UDR possible pour router via firewall.
• Public endpoint OFF par défaut (séparation des tâches : SQL admin l'active, network admin ouvre le NSG). Si ON : port 3342 (...public.<zone>.database.windows.net,3342), NSG allow > priorité de deny_all_inbound.

🚨 Public endpoint activé sans route 0.0.0.0/0 → Internet : routage asymétrique. Garder le retour par Internet. 🚨 Empêcher l'activation du public endpoint org-wide → Azure Policy (deny).

📐 Réf : Secure your SQL Managed Instance · Configure public endpoint

G. TLS — App Service & API Management

App Service :

• Certs : App Service Managed (gratuit, auto-renew, non exportable, pas de wildcard/ASE) | App Service Certificate (GoDaddy, dans KV) | BYOC (PFX) | import KV (PKCS12, sync auto 24 h).
• Binding : SNI SSL (défaut, multi-certs/IP) vs IP-based SSL (IP dédiée, tier Standard+, clients legacy sans SNI).
• Min TLS version configurable par app (TLS 1.2 défaut).
• mTLS : client certs validés contre CA chain ; cert exposé au code via header.

API Management : certs custom domain, min TLS/ciphers configurables, certs KV-managed (rotation), mTLS vers backends et côté gateway.

🚨 Même cert sur SNI et IP-based du même site → mauvais cert servi (cache client legacy). 🚨 IP-based SSL : 1 IP = 1 cert ; réutiliser le même cert en IP-based cross-app → Cannot set certificate for existing VIP.

📐 Réf : TLS/SSL in App Service · Configure SSL bindings

H. Azure Firewall + Firewall Manager + Firewall Policy

Pare-feu L3-L7 stateful managé. Firewall Policy (recommandé) découple la config du firewall ; Firewall Manager orchestre à l'échelle.

• Types de règles (ordre : DNAT → Network → Application) : DNAT (inbound, IP publique → privée), Network (L3/L4 IP/port), Application (FQDN/URL, L7).
• Policy hiérarchique parent/child : le child hérite des rule collections du parent (parent prioritaire, traité avant). NAT non hérité (spécifique au firewall). Parent et child même région (mais associable à un firewall de toute région).
• Threat Intel hérité : le child ne peut que durcir (Alert→Alert+Deny), jamais désactiver.
• Premium : IDPS signature-based (>67 000 règles, Alert / Alert+Deny), TLS inspection (CA dans Key Vault, déchiffre/inspecte/re-chiffre outbound + east-west), PCI DSS.

🚨 IDPS « Alert seul » = ne bloque pas ; pour Zero Trust → Alert and deny. URL filtering/web categories complètes nécessitent TLS inspection activée. 🚨 Azure Policy : Enable TLS inspection, Enable IDPS, Threat Intelligence, DNS Proxy pour enforcer la conformité.

📐 Réf : Firewall features by SKU · Firewall Manager policy overview

I. Application Gateway (WAF_v2) & Front Door + CDN

ADC régional L7 (App Gateway WAF_v2) vs CDN/edge global (Front Door Premium) :

• App Gateway : subnet dédié (/24 recommandé), backend pool, WAF policy attachable.

• Front Door : terminaison TLS edge, Private Link to origin (Premium) → l'origine (App Service, storage, LB interne) reste privée, FD s'y connecte via PE managé. WAF custom rules + bot manager.

• Azure CDN classique (caching edge, rules engine, geo-filtering) : Front Door Standard/Premium est le successeur stratégique — il intègre les capacités CDN + WAF + edge dans un seul service. Azure CDN Standard from Microsoft (classic) retire le 30 sept. 2027 (Front Door classic le 31 mars 2027) ; Microsoft pousse Front Door Std/Premium pour tout nouveau déploiement.

🚨 FD inspecte seulement les 128 premiers Ko du body → un payload malveillant au-delà passe. App Gateway WAF_v2 (CRS 3.2+) : inspection/enforcement configurables séparément (request_body_inspect_limit_in_kb). 🚨 FD et AGW = rulesets distincts (IDs 949xxx vs 9xxxxx) → maintenir les exclusions des deux séparément si failover Traffic Manager.

📐 Réf : WAF request/upload size limits · Front Door high-availability (comparatif WAF) · Front Door vs Azure CDN comparison

J. WAF — DRS, custom rules, modes

• DRS/CRS managé : règles OWASP + Microsoft Threat Intelligence Collection (remplace certaines règles OWASP pour réduire faux positifs). DRS 2.1 = Front Door Premium only.
• Anomaly scoring (CRS/DRS 2.1+) : chaque règle a une sévérité → score (Critical 5, Error 4, Warning 3, Notice 2). Score ≥5 = bloqué (Prevention) ou loggé (Detection). 1 Critical suffit.
• Paranoia Level : PL1 (défaut, peu de faux positifs), PL2 désactivé par défaut (activer + Log → tuner). PL3/PL4 non supportés Azure.
• Custom rules : évaluées avant le managed set, par priorité ; match → action appliquée, évaluation stoppée. Actions : Allow (skip tout), Block, Log. En Detection mode, l'action custom est toujours loggée quelle que soit la valeur.
• Detection → Prevention : déployer en Detection, analyser logs, tuner exclusions, puis basculer Prevention.

🚨 Changer la version de ruleset réinitialise les customisations de règles (état/action/exclusions) aux défauts → ré-appliquer manuellement. Custom rules / global exclusions / policy settings préservés. 🚨 Exclusions = pour les tokens (ex. AD) provoquant des faux positifs.

📐 Réf : DRS rule groups (App Gateway) · DRS Front Door

K. DDoS Protection — Network vs IP

Infrastructure protection (gratuite, toutes IP publiques Azure) protège la plateforme, pas tes ressources : pas de tuning adaptatif, pas de diagnostics, pas de réponse. Pour une charge exposée → plan dédié.

Règle de décision : < 15 IP publiques → IP Protection (per-IP plus économique) ; ≥ 15 IP, ou besoin DRR/cost protection/WAF discount → Network Protection (1 plan partagé multi-souscriptions du tenant).

🚨 Si Network Protection activé sur le VNet, App Gateway WAF facturé au tarif non-WAF (discount auto). 🚨 Front Door inclut son propre DDoS intégré → derrière FD, un plan est optionnel. Resource privée only = pas d'endpoint à attaquer. 🚨 Non supporté : PaaS multitenant, APIM hors VNet integration, IP publique sur NAT Gateway.

📐 Réf : DDoS tier comparison · DDoS pricing guide

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

Scénario 1 : Santé — PaaS data 100 % privé, anti-exfiltration

Contexte business : un hôpital (HDS/HIPAA) veut que Storage, SQL DB et Key Vault soient invisibles depuis Internet, et qu'un employé interne ne puisse pas copier des données vers un compte storage externe.

Choix architectural : Private Endpoints sur tous les PaaS + DNS privée centralisée (hub) + Service Endpoint Policies pour limiter vers quels comptes storage le compute peut écrire.

Architecture / pattern :

• Private Endpoint pour Storage, SQL DB, Key Vault ; accès public Disabled.
• Zones DNS privatelink.* dans le hub, partagées aux spokes (liaison auto).
• Service Endpoint Policy : le compute ne peut joindre que les comptes storage autorisés.
• NSG sur les subnets des private endpoints (filtrage source).

Trade-offs assumés :

• Gain : aucune surface publique ; exfiltration storage bloquée même par un compte légitime ; conforme.
• Perte : DNS plus complexe (résolution hybride, forwarders) ; coût des PE ; beaucoup de zones à gérer.

Pièges à éviter :

• Mélanger plusieurs services dans une même zone privatelink → enregistrements DNS écrasés.
• Croire que Disabled casse la résolution DNS publique du nom (elle reste, c'est normal).
• La Service Endpoint Policy ne bloque que l'exfiltration vers Storage, pas le reste (compléter avec Firewall/UDR).

📐 Réf. CAF/WAF — Network security (segmentation & private connectivity) : confiner les PaaS via Private Link et bloquer les chemins d'egress réduit la surface d'attaque et l'exfiltration. DP-2 Monitor/prevent data exfiltration (MCSB)

Scénario 2 : E-commerce — exposition web durcie multi-couches

Contexte business : un site marchand mondial subit des attaques applicatives (injection, bots) et volumétriques (DDoS), avec une conformité PCI DSS pour le paiement.

Choix architectural : Front Door Premium en façade (WAF + DDoS) relié en Private Link à une origine App Service privée ; le segment paiement isolé derrière Azure Firewall Premium (inspection TLS, IDPS).

Architecture / pattern :

• Front Door Premium : WAF (règles managées + bots) et Private Link vers l'origine → App Service en accès public Disabled.
• App Service : intégration VNet (vers SQL MI privé) + Access Restrictions n'acceptant que Front Door.
• Segment carte bancaire : Azure Firewall Premium (IDPS Alert+Deny, inspection TLS avec CA en Key Vault).
• DDoS : Front Door protège l'edge ; le VNet backend sous DDoS Network Protection.

Trade-offs assumés :

• Gain : défense en profondeur de l'edge jusqu'à l'origine, origine jamais exposée, conforme PCI.
• Perte : Front Door n'inspecte que 128 Ko du corps des requêtes ; coût élevé (Premium partout) ; double jeu de règles si on ajoute un App Gateway de secours.

Pièges à éviter :

• Laisser le WAF en mode Detection en prod (passer en Prevention après réglage).
• L'inspection TLS est obligatoire pour filtrer/IDPS sur HTTPS.
• Origine joignable hors Private Link → la restreindre via Access Restrictions + service tag.

📐 Réf. WAF — Security (defense in depth, edge protection) : empiler WAF, DDoS et inspection L7 chiffrée protège la disponibilité et l'intégrité de l'application exposée. Zero Trust recommendations for Azure Firewall

Scénario 3 : SaaS B2B — exposer son service privément aux clients

Contexte business : un éditeur SaaS multi-tenant ; ses clients refusent toute exposition Internet et veulent consommer le service depuis leur propre VNet, sans VPN ni conflit d'adresses IP.

Choix architectural : Private Link Service derrière un Standard Load Balancer ; chaque client crée un Private Endpoint vers l'alias fourni. Visibilité restreinte et approbation contrôlée.

Architecture / pattern :

• Service du fournisseur derrière un Standard LB (backend pool par carte réseau).
• Private Link Service : ≥8 IP de NAT (pour monter en charge), visibilité Restrictive, auto-approbation des souscriptions clientes connues.
• TCP Proxy v2 si le service a besoin de l'IP source réelle + du LinkID (identifier le tenant).
• Côté client : Private Endpoint + zone DNS privée.

Trade-offs assumés :

• Gain : aucune IP publique, pas de conflit d'adresses (NAT côté fournisseur), connexion validée par workflow, multi-tenant.
• Perte : Standard LB obligatoire (pas Basic), IPv4/TCP-UDP uniquement, déconnexion après 5 min d'inactivité (keepalives), approbations à gérer.

Pièges à éviter :

• Backend pool configuré par IP : non supporté par PLS (utiliser par carte réseau).
• TCP Proxy v2 sur un seul PLS partageant le même LB → casse les health probes des autres.
• Visibilité All expose l'alias trop largement (préférer Restrictive/None).

📐 Réf. CAF/WAF — Network security (private service exposure) : Private Link Service supprime l'exposition publique côté fournisseur tout en garantissant l'isolation inter-tenants. What is Azure Private Link service?

DEMO — chemins portail

1. Private Endpoint + Private DNS sur un Storage (portail)

Storage account → Networking → onglet Private endpoint connections → + Private endpoint → Basics (région = celle du VNet) → Resource : type Microsoft.Storage/storageAccounts, Target sub-resource blob → Virtual Network : VNet + subnet → DNS : Integrate with private DNS zone = Yes (privatelink.blob.core.windows.net) → Review + create. Puis Networking → Public network access = Disabled.

2. Service Endpoint Policy anti-exfiltration storage (portail)

Créer Service Endpoint Policy → Policy definitions → + Add a resource : Service Microsoft.Storage, Scope Single account, sélectionner le compte autorisé → Add → Create. Sur le subnet compute : Subnets → activer service endpoint Microsoft.Storage → appliquer la policy au subnet.

3. SQL Managed Instance — désactiver le public endpoint (CLI)

az sql mi update --subscription <sub-id> --resource-group <rg> --name <mi-name> --public-data-endpoint-enabled false

Puis fermer la règle NSG inbound port 3342 sur le subnet de la MI. (Empêcher la réactivation org-wide via Azure Policy deny.)

4. Azure Firewall Premium — activer IDPS en mode deny (portail)

Firewall Policy (Premium) → IDPS → Mode = Alert and deny → (optionnel) configurer Private IP ranges pour la direction du trafic → Save. Pour HTTPS : TLS inspection → fournir le CA intermédiaire depuis Key Vault.

5. WAF App Gateway — passer de Detection à Prevention (portail)

WAF Policy → Policy settings : Mode Detection d'abord → analyser logs (faux positifs) → Managed rules : ajuster ruleset/exclusions → Custom rules si bypass nécessaire → repasser Policy settings → Mode Prevention. Vérifier Max request body size (jusqu'à 2000 Ko) et Inspect request body.