Eskişehir’deki bir sigorta şirketinde 2025 son çeyreğinde Azure Firewall mimarisini Standard’dan Premium’a taşıdık. Sebep: KVKK + ISO 27001 dış denetçi “outbound HTTPS trafiğinizde malware C2 kontrolü yok, TLS inspection olmadan ne taradığınızı bilmiyorsunuz” dedi. Geçiş 6 hafta sürdü, beklenmedik üç sorunla karşılaştık ve aylık fatura ~~1.400 USD’den 4.200 USD’ye çıktı. Bu yazı o projeden notlar; Azure Firewall’u “tıkla aç” yerine ciddiye alıp planlayanlar için.
Azure Firewall’un Üç SKU’su: Doğru Karar Matrisi
Microsoft üç SKU sunuyor ve aralarındaki fark fiyat etiketinden çok daha derin:
| Özellik | Basic | Standard | Premium |
|---|---|---|---|
| L3-L7 filtreleme | Var | Var | Var |
| FQDN kuralları | Sınırlı | Var | Var |
| Threat intelligence (alert/deny) | Alert only | Alert + Deny | Alert + Deny |
| TLS inspection | Yok | Yok | Var |
| IDPS (Snort kurallar) | Yok | Yok | Var |
| URL filtreleme + Web kategorileri | Yok | Yok | Var |
| Throughput (max) | 250 Mbps | 30 Gbps | 100 Gbps |
| Tipik aylık (West EU, küçük) | ~300 USD | ~1.000 USD | ~3.000 USD |
Sahada karar kuralım: KVKK/ISO/PCI uyum gereksinimi varsa Premium. SMB veya dev/test ortamı, sadece outbound kontrol gerekiyorsa Standard. Basic’i sadece tek VNet, düşük trafik, lab ortamı için. Sigorta şirketinde Standard çalışıyordu ama denetimde “TLS inspection ve IDPS olmadan exfiltration tespit edemiyorsun” denildi, Premium’a geçtik.
SKU Değişimi: In-Place Upgrade Yok, Yeniden Deploy Var
Sürpriz: Azure Firewall’un SKU’sunu in-place değiştiremezsin. Premium’a geçmek için yeni Premium firewall deploy edip route table’ları geçirmek gerekiyor. Bizim yaklaşım:
- Aynı hub VNet’e ikinci bir AzureFirewallSubnet veya AzureFirewallManagementSubnet eklemek mümkün değil. Geçici çözüm: yeni hub VNet’i geçici olarak kur, peering’leri çoğalt.
- Veya: bakım penceresinde mevcut Standard firewall’ı sil, aynı subnet ve public IP’leri kullanarak Premium deploy et.
Sigorta şirketinde 2. yöntemi seçtik (cumartesi gece 02:00-06:00 bakım penceresi). 12 dakika kesintisiz outbound trafik. Spoke VNet’lerden internet çıkışı kesildi, ama VPN üzerindeki on-prem trafik etkilenmedi (Express Route ayrı path kullanıyordu). Pazartesi sabahı kullanıcılar bir şey fark etmedi.
Firewall Policy: Classic Rules Bırak, Policy’ye Geç
Azure Firewall’un iki kural modeli var: classic rules (firewall’a doğrudan yazılan) ve Firewall Policy (ayrı kaynak, hierarchy destekli). Yeni proje için sadece Firewall Policy. Sebebi: parent-child hierarchy ile global kuralları üstte tut, region-specific kuralları altta override et. Multi-region setup’larda hayat kurtarıyor.
az network firewall policy create
--name fwpol-prod-global
--resource-group rg-network-prod
--sku Premium
--location turkeywest
--enable-dns-proxy true
--intrusion-detection-mode Alert
--threat-intel-mode Deny
# Region-specific child policy
az network firewall policy create
--name fwpol-prod-trwest
--resource-group rg-network-prod
--base-policy fwpol-prod-global
--sku PremiumGlobal policy’de tüm region’lara ortak olan kurallar (örn: M365 traffic allow, malware C2 deny). Region policy’de o bölgeye özel exception’lar.
TLS Inspection: CA Hierarchy Olmadan Çalışmaz
Premium’un en pazarlanan özelliği TLS inspection. Pratikte uygulamak için şu zinciri kurmak gerek:
- Şirket içinde bir Subordinate CA (Microsoft AD CS veya başka). Bu CA’nın sertifikası tüm client makinelerde “Trusted Root” olarak yüklü olmalı.
- Subordinate CA’yı Azure Key Vault’a yükle (private key dahil, PFX olarak).
- Firewall’a Managed Identity ver, Key Vault Secrets User rolü ata.
- Firewall Policy’de TLS inspection ayarına Key Vault sertifikasını bağla.
İşin zor kısmı şu: TLS inspection açıldığında firewall, TLS bağlantısını arada karar (man-in-the-middle yapısı), kendi sertifikasını sunar. Eğer client’ta o CA trusted değilse “certificate error” ile uygulama düşer. Sigorta şirketinde:
- Domain-joined Windows makineler: GPO ile CA otomatik dağıtıldı, sorun yok.
- BYOD MacBook’lar: MDM (Intune) ile CA push edildi.
- Java uygulamaları: Java’nın kendi keystore’una manuel ekledik (cacerts dosyasına).
- Python pip:
REQUESTS_CA_BUNDLEenvironment variable ile CA bundle’ı ekledik. - Docker container’lar: image build aşamasında CA cert kopyalandı.
Bu adımlar planlanmamışsa TLS inspection açma günü chaos olur. Pilot grupla başla (50 makine), onları izle, tüm uygulamalar yeşilse genişlet.
TLS Inspection Bypass Listesi: Bankalar, Ödeme, Sertifika Pinning
Bazı uygulamalar TLS inspection’ı kaldırmaz çünkü certificate pinning yapıyor. Bunlar için bypass kuralı şart:
- Bankacılık siteleri (akbank.com, isbank.com.tr, vb)
- Ödeme processor’leri (stripe.com, iyzico.com)
- Microsoft 365 endpoint’leri (Microsoft kendi resmen TLS inspection’ı destekleme listesini yayınlıyor)
- Apple servisleri (push.apple.com, gateway.icloud.com)
- Bazı SAP siteleri (S/4HANA Cloud)
Microsoft’un “Office 365 / Microsoft 365 IP & URL list” referansı doğrudan Firewall Policy’ye Service Tag olarak eklenebiliyor. Diğerleri için manuel FQDN bypass yazıyoruz.
IDPS (Intrusion Detection / Prevention)
Premium ile gelen IDPS, Snort kurallarına dayalı imza tabanlı tespit yapıyor. İki mod var:
- Alert: Şüpheli trafik tespit edilir, log atılır, ama trafik geçer.
- Deny: Şüpheli trafik bloklanır.
Sahada sıralama: önce Alert mod, en az 30 gün gözlem, false positive’leri whitelist’e al, sonra Deny moda geç. Direkt Deny ile başlarsan iş yapan bir uygulamayı yanlışlıkla bloklayıp incident yaratırsın.
Sigorta şirketinde Alert moddan Deny moda geçişte 14 false positive whitelist’e aldık. Tipik örnekler: bir eski Java uygulamasının HTTP Basic Auth deseni, bir backup tool’unun anormal user agent string’i, bir CRM entegrasyonunun Apache Synapse versiyonu.
DNS Proxy: Açmazsan FQDN Kuralları İşlemez
Critical detay: Azure Firewall FQDN kurallarını DNS resolution sonucu IP üzerinden uygular. Eğer client farklı DNS server kullanıyorsa firewall’un cache’iyle uyumsuz IP’ler döner ve kural patlar. Çözüm: DNS Proxy özelliğini aç, spoke VNet’lerin DNS server’ını firewall private IP’ye yönlendir.
az network firewall policy update
--name fwpol-prod-global
--resource-group rg-network-prod
--enable-dns-proxy true
--dns-servers 168.63.129.16Spoke VNet’lerin DNS ayarını firewall private IP’ye çevir, VM’lerin DNS resolution’ı firewall üzerinden geçsin.
Sahada Düşülen Üç Tuzak
- NSG vs Firewall karışıklığı: Azure Firewall L3-L7 yapsa da NSG yerine geçmez. NSG hâlâ subnet/NIC seviyesinde mikrosegment için lazım. Birlikte kullan.
- Forced tunneling kapalı bırakılması: Default’ta firewall’ın kendi outbound trafiği UDR ile yönlendirilmez. Internet’e direkt çıkar. Eğer ExpressRoute üzerinden on-prem firewall’a göndermek istiyorsan forced tunneling açıp ManagementSubnet kur.
- Cost monitoring eksikliği: Premium pahalı. Outbound data transfer ücreti ayrı (1 GB outbound ~~0.087 USD). Bandwidth heavy iş yükünde fatura sürpriz olur. Cost analysis’te “Service: Azure Firewall” filter’ı ile aylık takip yapılması şart.
Aylık 4.200 USD Faturası Nereden Geliyor
Sigorta şirketinin Premium fatura kırılımı:
| Kalem | Aylık (USD) |
|---|---|
| Azure Firewall Premium (1 instance, deployment unit) | 2.450 |
| Data processed (~~10 TB outbound) | 1.150 |
| 2 Public IP | 10 |
| Log Analytics ingestion (~~150 GB) | 520 |
| Key Vault (TLS inspection sertifikası) | 10 |
| Toplam | ~4.140 |
Standard’dan ~~3.000 USD daha pahalı. Karşılığı: TLS inspection ile şirket dışına giden tüm HTTPS trafiğinin içeriğine bakabiliyoruz, IDPS ile bilinen tehditleri otomatik blokluyoruz, KVKK denetiminde “DLP kontrolüm var” diyebiliyoruz. ROI sayısal değil, risk azaltma değeri.
Alternatifler: Ne Zaman 3rd Party NVA Tercih Edilmeli
Azure Firewall Microsoft-native, kolay yönetim. Ama bazı senaryolarda 3rd party Network Virtual Appliance (Palo Alto, Fortinet, Check Point) tercih edilir:
- Şirketin zaten on-prem’de Palo Alto var, aynı politika dilini bulutta da istiyor.
- SD-WAN ile entegrasyon gerekiyor.
- SASE platformuna (Cato, Zscaler) entegre security stack ihtiyacı var.
Sigorta şirketinde değerlendirdik, on-prem Palo Alto vardı ama “yönetimi sadeleştirelim” dedik, Azure Firewall’la kaldık. Sonuç memnun edici.
Sonuç: Premium Doğru Sebeple Alınırsa Karşılığı Var
Azure Firewall’u “Microsoft yönetiyor, kolay” diye seçmek tek başına yeterli karar değil. SKU seçimi compliance gereksinimine bağlı. TLS inspection açmak teknik proje. IDPS Alert→Deny geçişi disiplin gerektiriyor. Doğru kurulduğunda denetim raporlarında “kanıtlanabilir kontrolüm var” diyebiliyorsun, ekibin de incident response’a daha hızlı tepki veriyor. Yanlış kurulduğunda 4.000 USD’lik bir kara kutu olarak aylık ödüyorsun ama değer üretmiyor.
CloudSpark olarak Azure Landing Zone projelerinde Hub-Spoke + Azure Firewall mimari kurulum hizmeti veriyoruz. CloudSpark Cloud (VHI) tarafında benzer rolü Octavia LB + güvenlik grupları + outbound NAT gateway üstleniyor; on-prem’den private link ile Azure Firewall’a tünel kurma deneyimimiz de var.
