Sesiunea 3
Azure Firewall
Zero-to-hero — de la concepte la deploy și operare în producție
Ghid complet zero-to-hero pentru ingineri de rețea și arhitecți Azure. Versiune 2026, construit pentru predare practică în Azure Portal.
Ce vei învăța astăzi
Fundamente
De ce există Azure Firewall, comparație cu NSG, App Gateway, Load Balancer și concepte de rețea esențiale.
SKU-uri și Arhitecturi
Basic vs Standard vs Premium, modele Hub-and-Spoke, Secured Virtual Hub și Forced Tunneling.
Deploy & Configurare
Laborator zero-to-hero în Azure Portal: VNet, subnets, Firewall Policy, reguli, UDR și DNS.
Operare & Troubleshooting
Monitorizare, metrici, logging, cele mai frecvente probleme și bune practici de inginerie.
Capitol 1
De ce există Azure Firewall și de ce contează
În orice infrastructură există un moment în care nu mai este suficient să spui că ai o rețea, câteva VM-uri și niște NSG-uri. Ai nevoie de un punct central prin care poți controla, jurnaliza și securiza traficul. Exact aici intră Azure Firewall.
Analogia cu campusul de birouri
NSG
Agentul de pază de la ușa fiecărei clădiri. Controlează accesul local, la nivel de NIC sau subnet.
Application Gateway
Recepția web pentru vizitatorii HTTP și HTTPS. Se ocupă de routing, WAF și TLS termination.
Load Balancer
Dirijorul care împarte mașinile spre mai multe intrări. Distribuie trafic L4 eficient.
Azure Firewall
Postul central de control care vede fluxurile importante, aplică reguli unificate și ține jurnalul tuturor deciziilor.
Azure Firewall nu înlocuiește toate celelalte servicii de rețea. El completează NSG, Application Gateway, Load Balancer și gateway-urile de VPN/ExpressRoute.
Ce oferă Azure Firewall concret
Control centralizat est-vest și nord-sud
Controlează traficul dintr-un singur punct, indiferent dacă fluxul este între subnets, între VNet-uri sau spre internet.
Reguli L3-L7
Aplică reguli de rețea (IP, port, protocol), reguli de aplicație (FQDN, URL categories) și reguli NAT (SNAT, DNAT).
Jurnalizare și observabilitate nativă
Integrare nativă cu Azure Monitor, Log Analytics și Workbooks pentru vizibilitate completă.
Serviciu PaaS, scalare automată
Nu administrezi appliance-uri, patch-uri sau HA manual. Azure Firewall se scalează automat după cerere.
Comparație: Azure Firewall vs alte servicii Azure
| Serviciu | Nivel | Scop principal | Când îl folosești | Ce nu face |
|---|---|---|---|---|
| Azure Firewall | L3-L7 | Control centralizat, NAT, filtrare, logging | Politică unificată pentru trafic inbound, outbound și inter-VNet | Nu este reverse proxy web dedicat |
| NSG | L3-L4 | Allow/deny pe NIC sau subnet | Micro-segmentare locală, reguli simple IP/port | Nu oferă policy centrală, NAT, TLS inspection |
| Application Gateway | L7 | Load balancing și protecție web HTTP/HTTPS | Path-based routing, WAF, TLS termination | Nu gestionează generic tot traficul TCP/UDP |
| Load Balancer | L4 | Distribuție de trafic TCP/UDP | Load balancing simplu și performant | Nu face filtrare aplicativă sau analiză avansată |
| VPN/ExpressRoute Gateway | L3 | Conectivitate între Azure și on-prem | Transport privat/hibrid | Nu este firewall și nu înlocuiește regulile de securitate |
O arhitectură matură le combină: NSG pentru segmentare locală, Azure Firewall pentru control centralizat, Application Gateway pentru web, iar Gateway-urile pentru conectivitate hibridă.
Capitol 2
Concepte de rețea esențiale
Concepte fundamentale
Allow și Deny
Azure Firewall pornește cu deny implicit. Permiți explicit fluxurile dorite; tot restul este blocat.
Stateful Firewall
Dacă permiți o conexiune inițiată dintr-o parte, răspunsurile asociate sunt permise fără reguli separate.
Layer 3 / Layer 4 / Layer 7
L3 = IP sursă/destinație. L4 = porturi și protocoale (TCP 443, UDP 53). L7 = FQDN, URL category, TLS inspection, IDPS.
DNS Proxy
Foarte important pentru filtrarea corectă pe FQDN în network rules. Fără DNS Proxy, regulile FQDN pot fi inconsistente.
Concepte de rutare și NAT
SNAT
Firewall-ul schimbă IP-ul sursă la ieșire pentru a reprezenta resursa outbound.
DNAT
Firewall-ul publică un serviciu intern pe baza unei adrese IP publice și port.
UDR (User Defined Route)
Route table cu next hop definit astfel încât traficul să treacă obligatoriu prin firewall.
DNS Proxy
Foarte important pentru filtrarea corectă pe FQDN în network rules.
Dacă NSG-ul este semaforul local dintr-o intersecție, Azure Firewall este centrul de control al traficului din tot orașul.
Capitol 3
SKU-uri: Basic vs Standard vs Premium
| Capabilitate | Basic | Standard | Premium | Observații practice |
|---|---|---|---|---|
| Scalare | Până la 250 Mbps | Până la 30 Gbps | Până la 100 Gbps | Alege după cerințe de throughput și complexitate |
| Threat Intelligence | Nu | Da | Da | Util pentru deny/alert către IP-uri și domenii malițioase |
| DNS Proxy și Custom DNS | Nu | Da | Da | Important pentru filtrare robustă pe FQDN |
| Web Categories | Nu | Da | Da | Util pentru control outbound web în enterprise |
| TLS Inspection și IDPS | Nu | Nu | Da | Necesare pentru medii sensibile și inspecție avansată |
| Cost | Mai mic | Mediu | Mai mare | Standard = punct de pornire corect pentru enterprise |
Pentru majoritatea mediilor enterprise, Standard este punctul de pornire corect. Premium este justificat când ai nevoie de TLS inspection, IDPS și control mai profund.
Capitol 4
Modele arhitecturale
Single VNet simplu
Bun pentru laboratoare sau medii mici. Firewall-ul stă în același VNet cu workload-urile. Simplu de configurat și de înțeles.
Hub-and-Spoke
Modelul enterprise clasic. Firewall-ul stă în hub și protejează mai multe spoke-uri. Route tables direcționează tot traficul prin hub.
Secured Virtual Hub / Virtual WAN
Variantă managed când vrei integrare strânsă cu topologii mari și conectivitate globală.
Forced Tunneling
Folosit când vrei ca traficul de ieșire să meargă spre alt dispozitiv sau on-premises. Necesită Management NIC.
Arhitectura Hub-and-Spoke: Hub VNet conține AzureFirewallSubnet /26, Application Gateway, GatewaySubnet VPN/ER și Azure Firewall. Route tables cu regula 0.0.0.0/0 → Firewall forțează tot traficul din spoke-uri prin hub.
Ce trebuie să știe un network engineer înainte de deployment
Subnet dedicat obligatoriu
Azure Firewall se deployează într-un subnet denumit exact AzureFirewallSubnet. Nu pune alte resurse în acest subnet.
Dimensionare minimă /26
AzureFirewallSubnet trebuie dimensionat la minimum /26. Serviciul are nevoie de spațiu pentru scalare.
Management Subnet opțional
AzureFirewallManagementSubnet este necesar pentru forced tunneling. De asemenea minimum /26.
Planifică rutarea de la început
Definește clar ce subnets și ce spoke-uri vor trimite traficul prin firewall.
Design DNS înainte de reguli FQDN
Custom DNS și DNS Proxy trebuie tratate explicit înainte de a scrie reguli bazate pe FQDN.
Definește inbound, outbound și east-west
Claritatea direcțiilor de trafic este esențială pentru un set de reguli curat și ușor de auditat.
Laborator
Deploy Zero-to-Hero în Azure Portal
Urmărim pașii în ordine logică: Resource Group → VNet și Subnets → Firewall Policy → Azure Firewall → DNS și Threat Intelligence → Route Table (UDR).
Setul minim de resurse recomandat
Resource Group
rg-lab-firewall-001 — Region: West Europe
VNet
vnet-hub-lab-001 — Address Space: 10.20.0.0/16
Subnets
AzureFirewallSubnet: 10.20.0.0/26, AzureFirewallManagementSubnet: 10.20.0.64/26, VM test: 10.20.1.0/24
Firewall & Policy
azfw-lab-001 cu fwpol-lab-001 (SKU Standard)
Un /16 pentru VNet oferă spațiu să adaugi ulterior spoke-uri, subnets pentru AKS, Application Gateway, Bastion sau alte workload-uri fără să refaci planul IP.
Pașii 1-3: Resource Group, VNet și Firewall Policy
8.1 Resource Group
Portal → Resource groups → Create. Introdu rg-lab-firewall-001, alege subscription-ul și region-ul.
8.2 VNet și Subnets
Virtual networks → Create. Name = vnet-hub-lab-001, address space = 10.20.0.0/16. Adaugă cele 3 subnets: AzureFirewallSubnet /26, AzureFirewallManagementSubnet /26 și snet-workload /24.
8.3 Firewall Policy
Firewall Policy → Create. Name = fwpol-lab-001. Alege SKU Standard pentru echilibrul corect între funcții și cost.
Pasul 4: Creează Azure Firewall
Setări de bază
Firewalls → Create. Name = azfw-lab-001. Region = aceeași cu VNet-ul. Virtual network = vnet-hub-lab-001.
Firewall Policy
Selectează fwpol-lab-001. Firewall Policy este modelul recomandat pentru management centralizat.
Public IP
Creează un Public IP nou pentru firewall. Necesar pentru servicii inbound și management.
Pașii 5-6: DNS, Threat Intelligence și UDR
DNS și Threat Intelligence
În Firewall Policy → DNS Settings: activează DNS Proxy. În Threat Intelligence, setează Alert pentru laboratoare, Alert and Deny pentru producție.
Route Table (UDR)
Route tables → Create. Name = rt-workload-to-fw. Adaugă rută 0.0.0.0/0 cu Next hop = IP-ul privat al Azure Firewall. Asociază la subnetul snet-workload.
Fără UDR, workload-urile ar ieși direct la internet prin ruta implicită Azure. UDR-ul forțează traficul prin Azure Firewall.
Capitol 5
Reguli și Ordinea de Procesare
Ordinea logică de evaluare: DNAT → Network Rules → Application Rules. Regula este terminating: la primul match, procesarea se oprește imediat.
Tipuri de reguli
Network Rules (L3/L4)
Trafic bazat pe IP, port și protocol. Exemple: DNS UDP/TCP 53, outbound HTTPS TCP 443, SSH/RDP din subnets administrative.
Application Rules (L7)
Control la nivel de FQDN și categorii web. Exemple: *.microsoft.com, registry-uri pentru AKS/containere, blocarea categoriilor web.
DNAT Rules
Publică un serviciu intern spre exterior pe baza IP-ului și portului. Folosește DNAT doar când chiar ai nevoie de expunere inbound.
Prioritatea și ordinea regulilor
Deny implicit
Azure Firewall pornește cu deny implicit. Dacă nu permiți explicit, traficul este blocat.
Reguli terminating
La primul match, procesarea se oprește. Evaluare: DNAT → Network → Application.
Priorități numerice
Rule collection groups și rule collections au priorități numerice. Numărul mai mic = prioritate mai mare.
Politici ierarhice
Politica părinte are prioritate față de politica copil. Util pentru guvernanță centralizată.
DNS, FQDN, Service Tags și IP Groups
DNS Proxy și Custom DNS
DNS Proxy este critic pentru filtrare FQDN în network rules. Custom DNS trebuie ales dacă organizația folosește rezoluție internă sau split-horizon DNS.
Service Tags și IP Groups
Service Tags simplifică regulile pentru servicii Azure (AzureMonitor, Storage, Sql). IP Groups fac regulile mai curate și reutilizabile.
Pattern bun enterprise: IP Groups pentru surse interne + Application rules pentru destinații web + DNS Proxy pentru consistență.
Capitol 6
Threat Intelligence, TLS Inspection și IDPS
Aici apare diferența mare dintre Standard și Premium. Aceste funcții sunt relevante pentru organizații cu cerințe de securitate avansate.
Threat Intelligence Filtering
Compară traficul cu feed-ul Microsoft de IP-uri și domenii cunoscute malițioase. Disponibil în Standard și Premium. Alert sau Alert and Deny.
TLS Inspection (Premium)
Decriptarea controlată a traficului TLS pentru inspecție mai profundă. Necesită certificate gestionate corect și politică de privacy.
IDPS (Premium)
Inspectează fluxuri pentru semnături și comportamente suspecte. Alert sau Alert and Deny. Vizibilitate profundă asupra amenințărilor.
Standard poate fi suficient pentru filtrare de bază și control egress. Premium apare când ai de apărat date sensibile sau vrei vizibilitate asupra traficului criptat.
Capitol 7
Monitorizare, Metrici și Logging
Un firewall fără observabilitate este doar pe jumătate operat. Ai nevoie de diagnostic settings, metrici, logs și alerte configurate din ziua zero.
Cum configurezi observabilitatea
Log Analytics Workspace
Trimite jurnalele în LAW pentru interogări avansate cu KQL. Activează Diagnostic Settings pe firewall și policy.
Metrici cheie
Urmărește: Throughput, Data processed, Rule hit count și Latency.
Alerte operaționale
Construiește alerte pentru ThreatIntel, firewall health, deployment failures și anomalii de trafic.
Corelarea jurnalelor
Corelează jurnalele firewall cu NSG flow logs, VM logs, App Gateway logs și activitate de schimbare.
Întrebări utile în operare zilnică
Surge de trafic neobișnuit?
Verifică metrici de throughput și corelează cu schimbările recente de configurație.
Reguli cu hit count zero?
Regulile neutilizate adaugă complexitate fără valoare. Un firewall matur este și un firewall curat.
Throughput crescut brusc?
Poate indica o rută greșită sau un serviciu neașteptat expus.
Latență anormală?
Verifică dacă există asimetrie de rutare sau reguli care procesează volume mari.
Flux operațional: exemplu practic
Analiză configurații
Revizuiește RuleCollectionGroups și Route Tables.
Inspectare loguri
Caută deny pe FQDN, IP sau port.
Verificare conectivitate
Outbound 443 și DNS rezolvă corect.
Raportare probleme
Utilizatorii semnalează update-uri eșuate.
Capitol 8
Cum se combină Azure Firewall cu alte servicii
Azure Firewall + NSG
Combinația normală și recomandată. Firewall-ul oferă control central L7; NSG oferă micro-segmentare locală. Se completează, nu se exclud.
Azure Firewall + Application Gateway
Foarte des întâlnit pentru aplicații web. App Gateway se ocupă de web și WAF; Azure Firewall de control central și egress.
Azure Firewall + Load Balancer
Load Balancer distribuie traficul L4 eficient; firewall-ul îl inspectează și jurnalizează.
Azure Firewall + VPN/ExpressRoute Gateway
Design-ul clasic pentru hub-and-spoke și conectivitate hibridă. Gateway-ul aduce traficul on-prem; firewall-ul îl inspectează.
Nu încerca să convertești aceste servicii într-un singur produs. Fiecare are rolul lui. Designul matur le combină după stratul de rețea și după responsabilitate.
Capitol 9
Troubleshooting: cele mai frecvente probleme
| Simptom | Cauza probabilă | Ce verifici |
|---|---|---|
| Traficul outbound ocolește firewall-ul | UDR lipsă sau neasociat la subnet | Route table pe subnet, next hop IP firewall, effective routes |
| DNS nu merge din workload | DNS proxy / custom DNS greșit sau blocat | Setările DNS din policy și regulile UDP/TCP 53 |
| Aplicația publică nu răspunde | DNAT sau NSG sau routing greșit | NAT rules, public IP, rule hit counts, NSG, backend reachability |
| Asymmetry / trafic instabil | Route return path greșite (hub-and-spoke) | UDR pe subnetul aplicației și traseul de întoarcere |
| FQDN rule nu funcționează | DNS Proxy dezactivat sau rezoluție inconsistentă | DNS settings, logs, cache și tipul corect de regulă |
Capitol 10
Bune practici de inginerie
Un deployment sănătos de Azure Firewall nu înseamnă doar că funcționează — înseamnă că este ușor de operat, de auditat și de extins în timp.
16 bune practici esențiale (selecție)
Deploy prin Firewall Policy
Folosește Firewall Policy pentru consistență și guvernanță. Permite reutilizare și management centralizat.
Deny by default, documentează fiecare allow
Pornește cu deny implicit și adaugă reguli de allow explicit, documentate. Fiecare regulă trebuie să aibă un motiv business clar.
IP Groups și Application Rules
IP Groups pentru surse interne, Application rules pentru destinații web. Fac regulile mai curate și mai ușor de auditat.
Evită DNAT când există alternative
Nu publica servicii prin DNAT dacă există alternative mai potrivite: App Gateway sau Private Access patterns.
Observabilitate din ziua zero
Planifică metrici, logs, alerte și workbook-uri înainte de prima regulă.
DNS coerent și testare incrementală
Păstrează DNS-ul coerent. Testează schimbările incremental cu plan de rollback. Revizuiește periodic regulile.
Studiu de caz
Studiu de caz real
O companie cu aplicații interne și ieșire controlată la internet are mai multe spoke-uri și workload-uri sensibile. Nevoia: control centralizat al tuturor ieșirilor, protecție web și conectivitate hibridă.
Deciziile cheie de implementare
Control total al ieșirilor
UDR pe toate spoke-urile cu next hop = Azure Firewall. Se impune controlul tuturor ieșirilor prin firewall.
Application Rules pentru update-uri
Application rules pentru update-uri și endpoint-uri aprobate. Lista albă explicită, nu allow-all.
DNAT minim
DNAT doar pentru servicii absolut necesare. Restul traficului inbound merge prin App Gateway.
Integrare cu Azure Monitor
Firewall-ul este integrat cu Azure Monitor și cu alertele operaționale din prima zi de producție.
Verifică-ți cunoștințele
1 Ce problemă rezolvă Azure Firewall și cum diferă de NSG?
Azure Firewall oferă control centralizat L3-L7 cu policy unificată, NAT, filtrare FQDN și logging. NSG oferă micro-segmentare locală L3-L4 pe NIC sau subnet.
2 Care este dimensiunea minimă a AzureFirewallSubnet?
/26 — serviciul are nevoie de spațiu pentru scalare și operațiuni interne.
3 Care este ordinea de procesare a regulilor în Azure Firewall?
DNAT → Network Rules → Application Rules. La primul match, procesarea se oprește (terminating).
4 Când alegi Standard vs Premium?
Standard este punctul de pornire corect pentru enterprise. Premium când ai nevoie de TLS inspection, IDPS și control profund al traficului criptat.
5 De ce este important DNS Proxy?
Fără DNS Proxy activat, regulile bazate pe FQDN pot fi inconsistente deoarece rezoluția DNS nu trece prin firewall.
6 Ce faci dacă traficul outbound ocolește firewall-ul?
Verifici dacă UDR-ul este asociat la subnet cu next hop = IP-ul privat al Azure Firewall și ruta 0.0.0.0/0.
Resurse și Pași Următori
Ai parcurs ghidul complet zero-to-hero pentru Azure Firewall — de la concepte fundamentale, prin deploy practic în Azure Portal, până la operare, troubleshooting și bune practici de inginerie.