SD‑WAN’in en büyük vaadi “esneklik”tir: şube trafiği DIA’dan çıkar, kritik işler DC’ye gider, bazı servisler doğrudan cloud’a bağlanır. Ama bu esneklik doğru sınır çizilmezse şu soruyu cevapsız bırakır: Bu trafikte güvenlik nerede başlıyor, nerede bitiyor? İşte SD‑WAN edge’de trust boundary (güven sınırı) bu yüzden kritik bir mimari karardır.
Problem: “çoklu çıkış” aslında çoklu güvenlik varsayımı demektir
Tek bir internet çıkışı varken, güvenlik kontrol katmanı çoğu zaman nettir: proxy, firewall, DLP, SIEM… Çoklu çıkış modelinde ise risk şuradan gelir:
- Trafik bazen merkezi kontrolden “yan geçer”
- DNS ve IP tabanlı kontroller tutarsızlaşır
- Asimetrik routing, incident triage’ı yavaşlatır
1) Trafiği üç sınıfa ayır: her sınıfın çıkışı ve kanıtı farklıdır
Sahada işe yarayan minimal sınıflandırma:
- Kurum içi/özel: DC, private cloud, partner hatları
- İnternet/SaaS: M365, Google Workspace, CRM, CDN
- Yönetim: MDM, EDR, patch, monitoring ajanları
Her sınıf için şu kararları yazılı yap:
- Çıkış noktası (DIA/DC)
- NAT/egress IP beklentisi
- Denetim/log hattı
- İzin/engelle politikası
2) DNS stratejisi: split‑tunnel kararını DNS ile mühürle
SD‑WAN’de “split tunnel” tartışması çoğu zaman routing üzerinden yapılır, ama asıl etkisi DNS’tedir:
- SaaS için bölgesel resolver mı, merkezi resolver mı?
- İç isimler (split-horizon) nasıl çözülecek?
- DNS logları nerede toplanacak?
Benim pratik önerim:
- Kullanıcı/SaaS trafiği için bölgesel resolver + merkezi log (latency düşer, görünürlük korunur)
- İç isimler için mutlaka kontrol edilen yol (sızıntıyı engelle)
3) Trust boundary’yi tek cümleye indir: “Bu çıkışta hangi kontroller var?”
Her egress için kontrol listesini standartlaştır:
- TLS inspection var mı/yok mu?
- Proxy zorunlu mu?
- Zafiyetli kategori/URL kontrolü var mı?
- DLP/AV nerede?
- CASB/SSPM gibi SaaS kontrolleri nerede devreye giriyor?
Bu soruların cevabı “bazı yerlerde var” olursa, incident sırasında ekipler aynı anda farklı gerçekliklerde çalışır.
4) Log hattı: egress değişse bile olay kanıtı değişmemeli
SD‑WAN mimarisinde minimum kanıt seti:
- Flow/NetFlow (site, app, path)
- DNS log (hangi isim çözüldü)
- Web gateway/proxy log (varsa)
- Firewall log (deny/permit)
- SD‑WAN controller event log (policy change, path flap)
Ama en önemli nokta: bir olayda bu logları tek yerde korele edebilmek.
5) Incident senaryoları: iki kısa tatbikat trust boundary’yi olgunlaştırır
Sahada iki tatbikat çok şey öğretir:
Senaryo A — SaaS erişim problemi (latency/timeout)
Kontrol soruları:
- DNS mi bozuk, path mi?
- Trafik DIA’dan mı çıktı, DC’den mi?
- Asimetrik routing var mı?
- Son 1 saatte policy değişmiş mi?
Senaryo B — Veri sızıntısı şüphesi (yükleme)
Kontrol soruları:
- Hangi çıkış kontrol katmanından geçti?
- Proxy/DLP logları var mı?
- Egress IP, tenant/servis eşlemesi doğru mu?
Sonuç
SD‑WAN, ağ mimarisini esnekleştirir; ama trust boundary tasarlanmadıysa güvenliği belirsizleştirir. Benim sahada en stabil sonuç aldığım yaklaşım; trafiği sınıflandırmak, DNS’i stratejik olarak yerleştirmek, her egress için kontrol listesini yazılı hale getirmek ve log hattını tek korelasyon yüzeyine bağlamaktır. Böylece SD‑WAN, “çoklu çıkış karmaşası” değil; ölçülebilir ve yönetilebilir bir operasyon modeline dönüşür.