Application Gateway ve WAF Rehberi

Abstract illustration depicting complex digital neural networks and data flow.

31 Mar 2026

2024’ün ortasında bir finans müşterisinde acil çağrı: “WAF’ı açtık, ödeme sayfası çalışmıyor, müşteriler şikayet ediyor.” Defender alarm panosunda yüzlerce “SQL Injection blocked” kaydı vardı ama hiçbiri saldırı değildi — kart numarasının formatı OWASP CRS’in bir regex’ine takılıyordu. O gece gerçek bir gerçek anladım: WAF’ı doğrudan Prevention modunda açmak, müşterinizi kapıdan çevirmenin en hızlı yoludur. Application Gateway ve WAF güçlü araçlar ama doğru kullanılmazsa hem yanlış pozitif tsunamisi hem de gizli yapılandırma boşlukları üretir. Bu yazı sahada öğrendiklerimle hem mimariyi hem de operasyonel pratikleri içeriyor.

Application Gateway nedir, ne değildir?

L7 (uygulama katmanı) yük dengeleyici ve reverse proxy. URL path, host header, cookie ve method’a göre yönlendirme yapar. Azure Load Balancer L4 (TCP/UDP) düzeyinde çalışır — ikisi farklı katman, farklı amaç. Tipik karışıklık: “Load Balancer da yük dengeliyor, Application Gateway’e gerek var mı?” Cevap: HTTP/HTTPS katmanında akıllı kararlar (path routing, SSL offload, WAF, URL rewrite) gerekiyorsa evet, gereklidir.

Üçüncü ürünle de karışıyor: Azure Front Door. Front Door global edge servis (Microsoft’un POP’larından), Application Gateway bölgesel. Çoklu region mimaride Front Door global ön kapı, her region’da Application Gateway bölgesel L7 trafiği yönetir. Tek region için sadece Application Gateway yeter.

Mimari bileşenler — sahada en sık atlanan ayarlar

Dedicated subnet

Application Gateway kendi subnet’ine yerleştirilmeli, başka kaynak yok. Önerim /24 (256 IP), küçük ortam /27 minimum. v2 SKU autoscale’de 125 instance’a kadar çıkabiliyor; küçük subnet alırsanız ileride dar gelir, taşımak için yeniden oluşturma şart.

Frontend, listener, routing rule, backend pool

Sırasıyla: public/private IP → port + protokol + hostname (listener) → kural → backend hedefler. Multi-site listener ile tek gateway’de çoklu domain barındırma:

az network application-gateway http-listener create 
  --gateway-name myAppGw --resource-group prod-rg 
  --name listener-shop --frontend-port port443 
  --frontend-ip appGwPublicIP 
  --host-name shop.example.com 
  --ssl-cert shop-cert

Health probe — production’a açmadan ayarla

Default probe sadece / isteği atıyor; backend ana sayfası 200 dönüyorsa healthy sayılıyor. Saha gerçeği: ana sayfa 200 dönerken DB bağlantısı kopuk olabilir. Custom probe ile /health endpoint’i tanımlayın, uygulama backend bağımlılıklarını kontrol edip 200/503 döndürsün:

az network application-gateway probe create 
  --gateway-name myAppGw --resource-group prod-rg 
  --name probe-api 
  --protocol Https --host-name-from-http-settings true 
  --path /health --interval 30 --timeout 20 --threshold 3

WAF — gerçek hayatta uygulama

WAF v2 OWASP CRS 3.2 (3.1, 3.0 da var) ile geliyor. SQL injection, XSS, RFI, LFI, command injection, protocol violation kategorileri. Modlar:

Detection: Sadece logla, engelleme. Yeni kurulumlarda 2-4 hafta bu modda kalır.
Prevention: Tespit edilen saldırı isteğini reddet (403).

Dört adımlı geçiş protokolüm tüm projelerde aynı:

WAF’ı Detection modda devreye al, Diagnostic Settings ile log Analytics workspace’e log gönder.
2-4 hafta gerçek trafikte gözlem. Aşağıdaki KQL ile false positive’leri bul.
Her false positive için exclusion tanımla (header, cookie, body field).
Trafik temizleninceye kadar tekrarla, sonra Prevention’a geç.

WAF log analizi — günlük standardım

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where action_s == "Blocked"
| summarize blockCount = count() by ruleId_s, requestUri_s, clientIp_s
| order by blockCount desc
| take 50

Bu sorgu her sabah çalıştırdığım ilk şey. En sık tetiklenen rule_id’leri görüp, gerçek saldırı mı yoksa false positive mi olduğuna karar veriyoruz. ruleId 942100 (SQL injection) genelde aramalarda “OR” gibi kelimeler geçen e-ticaret sitelerinde tetikleniyor — exclusion gerekir.

Exclusion örneği

az network application-gateway waf-policy managed-rule exclusion add 
  --policy-name myWafPolicy --resource-group prod-rg 
  --match-variable RequestArgNames 
  --selector-match-operator Equals 
  --selector "comment" 
  --rule-set-type OWASP --rule-set-version 3.2 
  --rule-group-name REQUEST-942-APPLICATION-ATTACK-SQLI 
  --rule-id 942100

Yorum alanındaki SQL benzeri içeriği yalnızca o kuraldan muaf tutuyoruz; başka kuralı (XSS gibi) yorum alanında çalıştırmaya devam ediyor. Tüm kategoriyi kapatma yanlışına düşmeyin.

Custom rule — IP, geo, rate limit

Bir müşterimde belirli bir ülkeden bot trafiği patladı. OWASP rule’lar yetmedi, custom rule ile çözdük:

{
  "name": "BlockHighRiskGeoRate",
  "priority": 100,
  "ruleType": "RateLimitRule",
  "rateLimitDuration": "OneMin",
  "rateLimitThreshold": 100,
  "matchConditions": [{
    "matchVariables": [{ "variableName": "RemoteAddr" }],
    "operator": "GeoMatch",
    "matchValues": ["XX", "YY"]
  }],
  "action": "Block"
}

Belirli ülke + dakikada 100 istek üzeri = blok. Saldırı 10 dakikada söndü, gerçek müşteri etkilenmedi.

SSL/TLS — Key Vault entegrasyonu şart

Sertifikayı doğrudan gateway’e yüklemek artık kabul edilemez bir pratik. Key Vault entegrasyonu ile sertifika yenileme otomatikleşir:

az network application-gateway ssl-cert create 
  --gateway-name myAppGw --resource-group prod-rg 
  --name shop-cert 
  --key-vault-secret-id "https://prod-kv.vault.azure.net/secrets/shop-cert"

Gateway’in user-assigned managed identity’si Key Vault’tan get/list izinleriyle sertifikayı çeker. Sertifika yenilendiğinde Key Vault yeni versiyonu yayınlar, gateway 4 saat içinde otomatik günceller. Bir banka müşterimde 45 sertifikayı bu şekilde yönetiyoruz, manuel takip ekibi yok.

End-to-end SSL

PCI-DSS gereksinimi olan müşterilerde gateway’de SSL terminate edip backend’e plaintext gitmek kabul edilmiyor. End-to-end SSL ile arka tarafta da HTTPS:

Frontend cert: Key Vault’tan public CA imzalı.
Backend cert: self-signed olabilir, ancak gateway’e “trusted root” olarak yüklenir.

Otomatik ölçekleme ve performans

v2 SKU autoscale ile başlangıç 2 instance, max örneğin 20. Spike olduğunda Capacity Unit (CU) artar, fatura ona göre. Min 0 yazma; sıfırdan ayağa kalkma süresi var, kullanıcı bunu görür. Min’i en az 2 tut, zone-redundant deploy et (3 zone’a dağılsın), production SLA %99.95.

Kapasite planlaması için CU başına ~50 RPS varsayımıyla başla, gerçek trafikte Azure Monitor’dan Throughput ve Total Requests metriklerini izle, autoscale eşiklerini gerçek veriye göre ayarla.

İzleme ve sorun giderme — 502 dünyası

Production’da en sık karşılaştığım hata: 502 Bad Gateway. Sebep listesi (sıklık sırasıyla):

Backend health probe başarısız (yanlış path, yanlış port, NSG bloku).
Backend timeout aşıldı — uzun ETL endpoint için requestTimeout arttır (default 30 sn).
Backend SSL cert mismatch (end-to-end SSL’de hostname doğrulama).
NSG inbound 65200-65535 portlarını engelliyor — bu port aralığı Application Gateway management trafiği için ayrılmış, aksini açma.

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS" and Category == "ApplicationGatewayAccessLog"
| where httpStatus_d == 502
| summarize cnt = count() by backendPoolName_s, requestUri_s, serverRouted_s
| order by cnt desc

Gerçek mimari kalıbı — e-ticaret örneği

Bir müşterinin AKS üzerinde çalışan e-ticaret platformu. Tek public IP üzerinden:

shop.example.com → frontend deployment (3 replika)
shop.example.com/api/* → API deployment (5 replika)
shop.example.com/payment/* → ödeme servisi (zone-redundant 6 replika, end-to-end SSL)
admin.example.com → admin paneli (IP allowlist + custom rule)

WAF Prevention modunda, ödeme path’i için ek özel kurallar: rate limit (IP başına dakikada 30 istek), bot manager rule set, geo-restrict (sadece TR + EU). Aylık ortalama 12.000 saldırı isteği bloklanıyor, gerçek kullanıcı etkilenmiyor.

Sıkça Sorulan Sorular

WAF v1 ve v2 arasında geçiş kolay mı?
Hayır. v1’den v2’ye in-place upgrade yok, paralel oluşturup DNS cutover gerekiyor. Yeni projelerde kesinlikle v2 ile başla; v1 yeni feature almıyor ve roadmap’ten düşmek üzere.

Application Gateway mi, NGINX Ingress mi (AKS için)?
İkisi birbirini dışlamıyor. AKS’te Application Gateway Ingress Controller (AGIC) ile gateway’i ingress olarak kullanabiliyorsun. NGINX daha esnek ama operasyonel yükü senin. WAF yerleşik olarak gateway’de, NGINX için ayrı modül kurmak gerekir.

WAF false positive’i hızlıca nasıl çözerim?
Acil prod sorunlarında o kuralı global devre dışı bırakmak yerine, problemli endpoint için per-rule exclusion tanımla. Tüm kategoriyi kapatmak güvenlik açığı yaratır. Sonra logları analiz edip kalıcı çözümü kur.

Sonuç

Application Gateway ve WAF, doğru kurulduğunda hem performans hem güvenlik için temel bir bileşen. Yanlış kurulduğunda hem müşteri kaybedersin hem de yanlış güvenlik hissi yaşarsın. Saha disiplinim: dedicated /24 subnet, custom health probe, Detection → Prevention dört adımlı geçiş, Key Vault SSL entegrasyonu, KQL ile günlük log incelemesi, end-to-end SSL hassas iş yüklerinde. Bu disiplinle bir kurumsal web platformunu hem PCI-DSS uyumlu tuttuk hem de aylık 50.000+ saldırıyı sessizce engelledik.

CloudSpark Azure güvenlik ve uygulama mimarisi danışmanlığı ile Application Gateway ve WAF kurulumunuzu, kural optimizasyonunuzu ve operasyonel SLA’nızı sürdürülebilir hale getiriyoruz.

Etiketler: