4 — Azure Firewall

Pare-feu managé as a service → filtre le trafic réseau (L3/L4) et applicatif (L7/FQDN) au périmètre du Hub, piloté par des Firewall Policy (DNAT, Network, Application).

A. Vue d'ensemble

Azure Firewall est un service de firewall managé as a service, scalable, hautement disponible, intégré à Azure. Il sert principalement de firewall périmétrique dans un Hub VNet (pattern Hub-and-Spoke) ou intégré à un Secured Virtual Hub (Virtual WAN).

A.1 Capacités principales

L3/L4 : règles IP/port (équivalent NSG mais centralisé et plus puissant)
L7 : filtrage FQDN (HTTP/S), Web Categories, URL Filtering (Premium)
TLS Inspection (Premium uniquement)
IDPS (Intrusion Detection and Prevention System) — Premium uniquement
Threat Intelligence intégrée : bloque les IPs/FQDN connus malicieux
DNS Proxy : Azure Firewall peut être DNS Proxy pour les VMs des spokes
DNAT : Inbound NAT pour publier des services internes
Forced tunneling : redirige le trafic vers on-prem pour inspection

A.2 Caractéristiques techniques

Déployé dans un subnet dédié AzureFirewallSubnet (/26 minimum)
IP publique Standard SKU obligatoire en frontend
Scaling automatique : Azure ajuste les instances selon la charge
Zone-redundant ou zonal (recommandé : zone-redundant en prod)
Support VNet-to-VNet filtering and routing (avec table de routage à configurer)
Firewall Policy : ressource séparée qui contient toutes les règles → attachable à 1 ou N firewalls

B. SKUs

SKU	Throughput	Features
Basic	~250 Mbps	TPE. L3/L4 + L7 FQDN. Threat Intel en mode Alert seulement. ❌ pas d'IDPS, pas de TLS inspection, pas de DNS Proxy / Custom DNS, pas de Web Categories, pas de FQDN dans les Network rules, pas de forced tunneling, pas d'autoscale (2 instances fixes)
Standard	jusqu'à 30 Gbps	Production standard. Rules L3/L4/L7 FQDN + Threat Intel (Alert / Alert+Deny) + DNS Proxy + Web Categories (basées FQDN)
Premium	jusqu'à 100 Gbps	Production sensible (gov, fintech, healthcare) : Standard + TLS inspection + IDPS + URL filtering (chemin complet) + Web Categories basées URL

⚠️ Pièges SKU :

Basic A bien le Threat Intelligence (mais en mode Alert uniquement, pas Alert+Deny).

Web Categories existent en Standard ET Premium : Standard catégorise sur le FQDN, Premium sur l'URL complète (nécessite TLS inspection). Seul l'URL filtering full-path est Premium-only.

💡 Choix SKU :

Compliance / TLS inspection nécessaire / IDPS → Premium

Production "normale" → Standard (suffisant 90% des cas)

Pas de prod, lab / TPE budget réduit → Basic (limité)

C. Composants & déploiement

C.1 Subnet dédié `AzureFirewallSubnet`

Nom exact obligatoire (sensible à la casse)
/26 minimum (64 IPs) — recommandé /26 ou plus large
Pas de NSG, pas de UDR ne s'applique sur ce subnet (Azure gère le routing du firewall lui-même)
Conseil : déployer dans un HUB VNet (pattern Hub-and-Spoke)

C.2 Subnet additionnel pour Forced Tunneling

Pour le forced tunneling (Azure Firewall envoie tout son outbound vers on-prem via VPN/ER) → un 2ème subnet est requis :

Nom : AzureFirewallManagementSubnet
/26 minimum
Sert pour les communications de management Azure du firewall lui-même

C.3 Firewall Policy (ressource séparée)

Pattern moderne : on ne configure plus les règles directement sur le firewall. À la place :

On crée une ressource Firewall Policy indépendante
On y met toutes les règles
On attache la policy au firewall : Firewall > Firewall policy > Change

Avantages :

Une seule policy → attachée à N firewalls (ex : 1 policy parent dans chaque région) → 1 update = propagation auto à tous les firewalls
Versionnable : changer de policy sur un firewall = changement instantané
Inheritance parent/child (voir section E)
Workload-specific : différentes équipes app peuvent avoir leurs policies enfants

🚨 Classic Rules (l'ancien mode où on mettait les règles directement sur le firewall) est legacy. Tous les nouveaux déploiements utilisent Firewall Policy.

D. Types de Rule Collections

Une Firewall Policy contient 3 types de rule collections, évalués dans un ordre strict :

D.1 Ordre d'évaluation

0. Threat Intelligence  (évalué AVANT tout — bloque/alerte sur IP/FQDN malveillants connus)
1. DNAT rules           (inbound NAT)
2. Network rules        (L3/L4 — IP/port)
3. Application rules     (L7 — FQDN, Web Categories)
   + IDPS (Premium) appliqué après le matching des règles

🚨 Network évaluées AVANT Application → une App rule "Allow" n'override PAS une Network rule "Deny". Si Network dit Deny → c'est mort, Application n'est même pas évalué. 🚨 Threat Intelligence est évalué AVANT les règles DNAT (priorité la plus haute) : un flux vers une IP/FQDN malveillant connu est bloqué (mode Alert+Deny) avant même l'évaluation des rule collections.

D.2 DNAT rules

Inbound NAT : publier un service interne en exposant l'IP publique du firewall sur un port donné.

Exemple : exposer un RDP interne sur l'IP publique du firewall :

Champ	Valeur
Source	`Any` (ou ton IP perso)
Destination Address (IP publique du firewall)	`203.0.113.10`
Destination Port	`33890` (port d'écoute public)
Protocol	TCP
Translated Address	`10.1.1.5` (IP privée de la VM interne)
Translated Port	`3389` (port RDP interne)

→ Un attaquant qui tape rdp://203.0.113.10:33890 arrive sur la VM interne 10.1.1.5:3389, en passant par le firewall (qui logue et inspecte).

D.3 Network rules (L3/L4)

Équivalent NSG mais centralisé, scope plus large :

Champ	Valeur
Source type	IP Address / Service Tag / IP Group
Source	`10.0.0.0/8` (ou Service Tag `Internet`, IP Group, etc.)
Protocol	TCP / UDP / ICMP / Any
Destination type	IP Address / Service Tag / IP Group / FQDN (limité aux FQDN DNS-resolvables)
Destination	`203.0.113.10`
Destination port	`443`
Action	Allow / Deny

Service Tags supportés : AzureCloud, Storage.<region>, AzureKeyVault.<region>, etc.

D.4 Application rules (L7 FQDN)

Filtrage HTTP/HTTPS basé sur le FQDN cible (le firewall fait du SNI inspection pour matcher les FQDN HTTPS sans TLS inspection).

Champ	Valeur
Source	`10.0.0.0/8`
Protocol	HTTP / HTTPS / MSSQL (port + protocol)
Target FQDNs	`.microsoft.com`, `windowsupdate.com`, `.visa.com`
Action	Allow / Deny

Avec wildcards : *.windows.com autorise update.windows.com, download.windows.com, etc.

Web Categories (Standard+) : catégories pré-définies par MS pour bloquer par thème :

Adult, Gambling, Social Networking, Malware, News, etc.

URL Filtering (Premium) : matcher des URLs entières (https://exemple.com/admin/*) — nécessite TLS inspection.

E. Parent / Child Policies

E.1 Concept

Pattern enterprise pour séparer la gouvernance centrale de la configuration spécifique par workload/équipe :

Parent policy = règles obligatoires globales définies par SecOps central (security baseline org : "interdit RDP depuis internet partout", "Threat Intel en Deny")
Child policy = règles workload-specific définies par chaque équipe app (ex : ouvrir le port 1433 pour l'app de paie)

Inheritance : la child policy hérite automatiquement de la parent. Mais elle peut ajouter ses propres règles.

E.2 Ordre d'évaluation

L'ordre global par type prime toujours : DNAT → Network → Application (le firewall itère 3 fois sur tous les RCGs, une fois par type). À l'intérieur d'un type, les RCGs de la policy PARENT sont TOUJOURS évalués avant ceux de la child, quelle que soit la priorité de la child. Ensuite seulement on trie par priorité de RCG, puis par priorité du Rule Collection.

⚠️ Le parent a TOUJOURS la précédence sur la child (citation officielle : "If you inherit a Firewall Policy from a parent policy, rule collection groups in the parent policy always take precedence regardless of the priority of a child policy"). Ce n'est PAS "le parent gagne seulement à priorité égale". Un RCG child avec une priorité plus haute (nombre plus petit) qu'un RCG parent passe quand même APRÈS le parent, à l'intérieur du même type.

Pour chaque type (DNAT, puis Network, puis Application) :
  1. tous les RCGs PARENT d'abord (triés entre eux par priorité de RCG)
  2. puis tous les RCGs CHILD (triés entre eux par priorité de RCG)
  → à l'intérieur d'un RCG : tri des Rule Collections par priorité

📊 Exemple officiel : BaseRCG2 (parent, prio 300) contient une Network rule, ChildRCG1 (child, prio 300) aussi. Bien qu'ils aient la même priorité 300, le parent (BaseRCG2) est évalué avant la child. Idem ChildRCG2 (child, prio 650) reste après les RCGs parent même s'il avait été en prio 100.

Conséquence pratique :

Le parent Deny est garanti définitif : structurellement, la child ne peut jamais court-circuiter un RCG parent du même type.
Si parent n'a aucune règle qui match → on passe à child.
Si rien ne match nulle part → Deny par défaut.
⚠️ Le mode Threat Intel et les DNS settings sont aussi hérités : une child doit être au moins aussi stricte que la parent (Threat Intel child ≥ mode parent).

E.3 Exemple concret

Parent policy "SecOps Baseline" (gérée par l'équipe sécurité centrale) :

Network rule "Deny SMB from Internet" : Source=Internet, Port=445, Deny
Network rule "Allow Azure Backup" : Source=*, Dest=Service Tag AzureBackup, Allow
Threat Intel : mode Deny
IDPS : mode Alert+Deny

Child policy "App-Paie" (gérée par l'équipe app paie, hérite du parent) :

Application rule "Allow SAP Web" : Source=10.10.0.0/16, FQDN=*.sap.com, Allow
Network rule "Allow DB" : Source=10.10.0.0/16, Dest=10.20.1.5:1433, Allow

Évaluation d'un trafic "VM paie → sap.com sur 443" (ordre = par type, parent avant child dans chaque type) :

DNAT (parent puis child) : pas de match
Network parent : pas de match → continue
Network child : pas de match → continue
Application parent : pas de match → continue
Application child : MATCH "Allow SAP Web" → ✅ Allowed

Évaluation d'un trafic "VM paie → SMB vers Internet" :

DNAT (parent puis child) : pas de match
Network parent : MATCH "Deny SMB" → 🚫 Bloqué immédiatement (les Network child et les Application ne sont même pas évalués)

E.4 Régions et héritage parent/child

Règle clé : une Firewall Policy peut être attachée à des firewalls dans n'importe quelle région, peu importe la région où la policy elle-même a été créée. La policy est une ressource régionale (elle a une "home region") mais son attachement est cross-region.

Exemple : une policy CorePolicy créée dans NETWORKING-RG (East US) peut être assignée aussi bien à US1-FW (East US) qu'à EU1-FW (West Europe). Une seule policy peut donc piloter des firewalls dans tout le monde Azure, indépendamment de sa région de création.

Pattern Multi-region typique :

Parent Policy "GlobalBaseline" (créée en West Europe, peu importe)
       │
       ├─── Child Policy "AppA-WE" → Firewall en West Europe
       ├─── Child Policy "AppA-NE" → Firewall en North Europe
       └─── Child Policy "AppA-FRC" → Firewall en France Central

Une seule parent policy gère la baseline globale, chaque région a sa child pour les specifics locaux.

⚠️ SKU match obligatoire entre parent et child : si parent = Premium, child = Premium aussi. Pas de mix.

E.5 Le terme "override" dans le contexte parent/child

Piège de vocabulaire : dans les questions Microsoft, "override one rule in a given region" signifie le plus souvent ajouter une règle spécifique au niveau régional, pas littéralement écraser une règle parent.

Concrètement :

Le parent définit les règles globales obligatoires qui s'appliquent à tous les firewalls (Deny SMB, Threat Intel, etc.).
Le child ajoute des règles propres à sa région/workload (ex : ouvrir un port pour une intégration locale, autoriser un FQDN partner régional).
L'ordre d'évaluation est strict : parent toujours évalué AVANT child. Une parent Deny bloque définitivement, le child ne peut pas réautoriser.

Donc "override one rule in the Australia region" signifie en pratique :

❌ Pas : écraser une règle parent depuis le child (impossible).
✅ Mais : ajouter une règle child spécifique à l'Australie pour gérer un cas particulier que le parent ne traite pas.

Approche correcte pour ce besoin :

Créer une parent policy avec les règles globales et l'assigner à tous les firewalls.
Créer une child policy spécifique à l'Australie avec la règle additionnelle, et l'assigner au firewall Australie.

🚨 Une approche du type "modifier la base policy et ajouter un tag region-specific" ne fonctionne pas : Firewall Policy ne supporte pas le filtrage par tag au runtime (valable en NSG, pas en Firewall Policy).

💡 Pour vraiment "override" une règle parent au niveau child, deux options seulement :

Ne pas mettre la règle dans le parent et la laisser au child uniquement → mais ça casse le principe de baseline globale.

Faire la règle parent suffisamment générique pour que le child puisse l'affiner avec une règle plus spécifique — mais cela ne peut pas inverser un Deny parent.

En réalité, un parent Deny est définitif. Le pattern propre est de structurer le parent pour qu'il pose des Allow/Deny génériques et de laisser les Allow spécifiques aux children.

F. Pattern 1 policy → N firewalls (ALZ multi-region)

Use case : 5 régions, 5 firewalls. On veut une cohérence des règles partout.

Setup :

Créer 1 seule policy central-policy dans le RG SecOps
Pour chaque firewall régional : Firewalls > <fw> > Firewall policy > Change firewall policy > central-policy > Save
Update unique sur la policy → propagation auto aux 5 firewalls

Avantages :

Cohérence : impossible d'avoir un firewall qui dérive
Maintenabilité : 1 endroit à updater
Audit : 1 seul artifact à reviewer pour la compliance

G. Azure Firewall Manager

Service de gestion centralisée pour :

Plusieurs Azure Firewalls dans des Hub VNets ou Secured Virtual Hubs (vWAN)
Gestion des Firewall Policies parent/child
Threat intelligence centralisée
Reporting et logging consolidés

Particulièrement utile pour :

Secured Virtual Hub dans Azure Virtual WAN : déployer Azure Firewall directement dans un hub managé MS, sans monter un Hub VNet custom
Multi-region : gérer N firewalls depuis une console unique
Third-party security providers (palo, checkpoint…) intégrables en SaaS

G.1 Secured Virtual Hub

Dans Virtual WAN Standard, on peut intégrer Azure Firewall directement dans un Virtual Hub managé :

Sécurité centralisée au cœur du hub vWAN
Routing automatique du trafic spoke→spoke et spoke→internet via le firewall
Pas besoin de monter un Hub VNet custom + Azure Firewall + peerings + UDR à la main

H. DNS Proxy & DNS Settings sur le firewall

Azure Firewall peut servir de DNS Proxy pour les VMs des VNets connectés :

VMs des spokes pointent vers l'IP privée du firewall comme DNS server (via Custom DNS settings sur le VNet)
Le firewall résout (en utilisant son propre DNS configuré, ou Azure DNS par défaut)
Avantage : on peut utiliser des FQDN dans les Network rules (le firewall connaît la résolution actuelle des FQDN)

💡 Sans DNS Proxy : les Network rules avec FQDN ne fonctionnent pas (Network rules ne font pas de résolution DNS par défaut).

H.1 Custom DNS sur le firewall

Permet au firewall d'utiliser des DNS custom (ex DNS on-prem via Private Resolver) au lieu d'Azure DNS.

Firewall Policy > DNS settings :

DNS servers : Custom → entrer les IPs (DNS on-prem, Private Resolver Inbound IP, etc.)
Enable DNS proxy : ✅ → les VMs spokes peuvent pointer sur le firewall comme DNS

I. Threat Intelligence & IDPS

I.1 Threat Intelligence (Standard+)

Azure Firewall bloque les flux vers/depuis des IPs et FQDN connus malicieux (alimenté par Microsoft Threat Intelligence Feed).

3 modes :

Off : désactivé
Alert : log uniquement, n'empêche pas le trafic
Alert and Deny : log + bloque (recommandé prod)

I.2 IDPS (Premium uniquement)

Intrusion Detection and Prevention System : inspecte le trafic pour détecter et bloquer les attaques connues (exploits, scans, C2, etc.).

Modes :

Off
Alert : log uniquement
Alert and Deny : bloque les patterns d'attaque

Bypass rules (Premium) : exclure certains trafics critiques de l'inspection IDPS (ex : flux backup à très haut débit).

I.3 TLS Inspection (Premium uniquement)

Décrypte le trafic HTTPS pour inspecter le contenu (URL filtering, IDPS).

Prérequis :

Certificat intermédiaire CA dans Azure Key Vault
Identity managée sur le firewall avec accès au KeyVault
Les clients (VMs spokes) doivent trust le certificat racine de la CA (déploiement via GPO ou Intune)

Use cases :

Compliance gov / fintech / healthcare
Bloquer les téléchargements malveillants via URL filtering

J. Bonnes pratiques

Hub VNet dédié au firewall (pattern Hub-and-Spoke). Ne pas mettre le firewall dans un VNet de workload.
AzureFirewallSubnet /26 minimum. Nommé exactement (sensible à la casse).
Firewall Policy (pas Classic rules) pour tous les nouveaux déploiements.
Parent / Child pattern dès qu'il y a plusieurs équipes/régions.
1 policy → N firewalls : centraliser la baseline.
Threat Intelligence en mode Alert+Deny en prod.
IDPS en Premium pour les workloads sensibles.
DNS Proxy activé en cas d'utilisation de FQDN dans les Network rules.
UDR sur les spokes : 0.0.0.0/0 → IP firewall pour forcer le routage via le firewall.
Logging vers Log Analytics : activer Diagnostic settings sur le firewall (logs Application, Network, DNS proxy, Threat Intel, IDPS).
Tagger les règles : ajouter des descriptions claires pour audit.
Reviewer périodique des règles Allow Any → tendance à dériver.

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

Scenario 1 : Banque retail — Parent/Child Policy multi-région

Contexte business : Une banque a son infra Azure sur 3 régions (prod, DR, analytics). Le SecOps central veut imposer une baseline commune (Threat Intel, deny SMB et RDP exposés), pendant que chaque équipe app (e-banking, marché, RH) garde ses propres règles métier. Choix architectural : Une Firewall Policy Premium parent gérée par le SecOps, dont héritent des child policies par équipe. La baseline s'applique partout ; les équipes n'ajoutent que leurs règles spécifiques. Architecture / pattern :

Parent secops-baseline (Premium) : Threat Intelligence et IDPS en Alert and Deny, TLS Inspection ON (cert root corp dans KeyVault), deny SMB (445) depuis Internet, allow/deny par Web Categories (allow business/financial-services/technology, deny gambling/adult/malware).
Child policies (Premium, héritées) : ebanking-policy (vers SQL prod, *.swift.com), analytics-policy (Databricks, Storage).
3 Firewalls Premium (prod + DR), chacun lié à sa child.
DNAT minimal pour un accès admin contrôlé. Logs vers un Log Analytics central (audit). Trade-offs assumés :
Gain : baseline sécurité garantie partout, autonomie des équipes app.
Perte : tout doit rester en Premium ; ordre des règles à maîtriser. Pièges à éviter :
Lier une child Standard à une parent Premium → impossible. Toutes les child d'une parent Premium sont Premium.
Activer TLS Inspection sans pousser le cert root sur les postes (GPO/Intune) → erreurs de certificat partout.
Mettre les règles SecOps dans la child → l'équipe app peut les modifier. Les garder dans la parent.
Oublier que les Network rules passent avant les Application rules : un Network Allow 8.8.8.8:53 ne sera pas filtré ensuite. Penser à l'ordre.

📐 Réf. CAF/WAF — Rule hierarchy (base policy centrale + policies granulaires) : structurer les règles en hiérarchie parent/child permet d'overlay une base policy SecOps centrale tout en laissant chaque région affiner ses propres règles DNAT/Network/Application. Lien

Scenario 2 : Gov / défense — Azure Firewall Premium + TLS + IDPS

Contexte business : Un ministère traite des données sensibles. Toute la sortie internet doit être inspectée en profondeur : déchiffrement TLS, détection d'exploits/C2 (IDPS), accès limité aux seuls sites autorisés, le tout remonté dans Sentinel. Choix architectural : Un Azure Firewall Premium qui déchiffre et inspecte le TLS (IDPS en Alert+Deny, URL filtering en whitelist). En complément, forced tunneling vers le firewall on-prem via ExpressRoute Direct pour une inspection de secours. Architecture / pattern :

Hub : AzureFirewallSubnet /26 + AzureFirewallManagementSubnet /26 (requis pour le forced tunneling).
Firewall Premium : TLS Inspection ON (cert intermédiaire CA gov dans KeyVault, via managed identity), IDPS Alert+Deny (avec bypass pour les flux critiques type backup), URL filtering en whitelist explicite, Web Categories deny par défaut sauf business/government/technology.
Forced tunneling : management subnet → ExpressRoute → firewall on-prem.
Logs → Sentinel. Cert racine poussé via Intune sur tous les postes. Trade-offs assumés :
Gain : inspection complète du trafic chiffré, conformité, double contrôle Azure + on-prem.
Perte : exige le Premium et la gestion des certificats ; setup plus lourd. Pièges à éviter :
TLS Inspection sans cert racine côté clients → toutes les apps cassent (cert non trusté).
Oublier AzureFirewallManagementSubnet avec le forced tunneling → déploiement échoue.
Pas de bypass IDPS pour backup/monitoring → faux positifs et perf dégradée.
Firewall Standard au lieu de Premium → ni TLS inspection ni IDPS → exigences gov non couvertes.

📐 Réf. CAF/WAF — Forced tunneling mode (inspection sortante on-prem) : configurer Azure Firewall en forced tunneling (Management NIC + AzureFirewallManagementSubnet) route tout le trafic internet vers un next hop on-prem pour appliquer les politiques de conformité avant la sortie. Lien

Scenario 3 : Manufacturier industriel — East-West Firewall entre OT et IT

Contexte business : Un industriel doit isoler strictement son réseau OT (automates, MES, SCADA) de son IT corporate (ERP, RH). Un ransomware sur l'ERP ne doit jamais atteindre les automates. Tout le trafic OT ↔ IT doit être inspecté. Choix architectural : Un Azure Firewall Premium dans le hub, entre un spoke OT et un spoke IT séparés. Des UDR forcent tout flux cross-spoke à passer par le firewall, qui est en deny par défaut entre les deux zones. Architecture / pattern :

Hub avec Firewall Premium.
Spoke OT (10.10.0.0/16) : UDR 0.0.0.0/0 et 10.20.0.0/16 → IP firewall.
Spoke IT (10.20.0.0/16) : UDR 10.10.0.0/16 → IP firewall.
Firewall Policy : allow ciblé MES → ERP (10.10.5.0/24 → 10.20.10.5:8443), deny IT → OT (10.20.0.0/16 → 10.10.0.0/16), IDPS Alert+Deny pour repérer les mouvements latéraux.
Peering hub→spoke avec Allow forwarded traffic = ON (sinon le firewall ne peut pas relayer).
AVNM Security Admin rules en couche supplémentaire : deny IT → OT (override les NSG). Trade-offs assumés :
Gain : OT isolé, blast radius limité, double verrou firewall + AVNM.
Perte : routage par UDR à maintenir ; peering à configurer correctement. Pièges à éviter :
Mettre OT et IT dans le même VNet "pour simplifier" → un ransomware ERP atteint les automates.
Pas d'UDR sur les spokes → le trafic shortcut via peering classique et évite le firewall.
Oublier Allow forwarded traffic sur le peering hub→spoke → le firewall relaie mais le packet est dropé à l'arrivée.
Se reposer sur les NSG seuls → un dev peut les supprimer. La couche AVNM Security Admin est obligatoire en défense en profondeur.

📐 Réf. CAF/WAF — Establish network perimeters / segmentation : établir des périmètres réseau (firewall en perimeter entre zones OT et IT) limite le blast radius et bloque les mouvements latéraux selon le principe du moindre privilège. Lien

DEMO — chemins portail

1. DEMO — Azure Firewall + Parent/Child Policy

Scénario : topologie Hub-and-Spoke avec Spoke1 et Spoke2. Spoke1 doit communiquer avec Spoke2 via le firewall. On crée une policy parent globale qui bloque Google et une policy enfant attachée au firewall.

Phase 1 — Créer la Parent Policy (Premium pour la démo)

Home > Firewall Policies > + Create

Basics :
- RG : rg-secops
- Name : parent-policy-global
- Region : West Europe
- Tier : Premium
- Parent policy : (laisser vide — c'est la parent)
DNS :
- Enable DNS Proxy : ✅
TLS inspection : (skip pour cette démo)
Rules :
- + Add a rule collection group → name rcg-baseline, priority 200
- Dans le RCG → + Add a rule collection :
  - Name : rc-app-baseline
  - Type : Application
  - Priority : 1000
  - Action : Deny
  - Rules :
    - Name : deny-google
    - Source type : IP Address
    - Source : * (tout)
    - Protocol : HTTP, HTTPS
    - Destination type : FQDN
    - Destination : *.google.com
    - OU via Web Category : Social Networking, News, ce que tu veux bloquer
Threat intelligence : Mode = Alert and Deny
IDPS (Premium) : Mode = Alert
Review + create

Phase 2 — Créer la Child Policy (héritée du parent)