“Zero Trust” konuşmalarında odak genelde erişim üzerindedir: Kim, hangi cihaza, hangi uygulamaya girebilir? ZTNA projeleri de çoğu zaman bu sorunu çözüp kapanır. Fakat olayların (ve gerçek sızıntıların) büyük kısmı “içeri giriş”ten değil dışarı çıkıştan olur:
- API’lerden toplu veri çekimi
- Yetkili ama “gereğinden fazla” erişimi olan servis hesapları
- İnternete doğrudan egress ile C2/Dropbox/kişisel depolama
- İç ağdan SaaS’a kontrolsüz veri akışı
Bu yazı, ZTNA’nın ikinci yarısını; yani egress kontrolünü operasyonel ve uygulanabilir şekilde tasarlamaya odaklanıyor.
Egress kontrolü ne demek?
Egress kontrolü; kullanıcıların ve servislerin hangi hedeflere, hangi protokollerle, hangi koşullarda çıkabileceğini belirlemek ve bunu ölçülebilir şekilde uygulamaktır.
ZTNA bağlamında egress; sadece “internet çıkışı” değildir. Örnek:
- Üretim VPC → SaaS API
- Uygulama pod’u → harici webhook
- CI runner → paket deposu
- Jump host → yönetim arayüzleri
Bu yüzden egress kontrolünü “tek bir firewall kural seti” gibi değil; kimlik + bağlam + hedef birleşimi olarak düşünün.
Egress’in üç katmanı: Kimlik, hedef, davranış
Ben sahada egress’i üç katmanda ele alıyorum:
- Kimlik (identity): kullanıcı, cihaz, servis hesabı, workload identity
- Hedef (destination): domain/IP/ASN, SaaS, API endpoint, repo, registry
- Davranış (behavior): hız, hacim, saat, coğrafya, anomali, veri sınıfı
Bu üç katmanı birleştirmezseniz, ya çok açık kalırsınız ya da herkesin işini kırarsınız.
Tasarım başlangıcı: Envanter + “normal akış” haritası
İyi egress kontrolü için ilk deliverable bir “kural seti” değil; bir akış haritasıdır.
Başlangıç soruları:
- Hangi servisler internete çıkmak zorunda?
- Hangi servisler yalnızca belirli SaaS/API’lara çıkmalı?
- CI/CD hangi domain/registry’lere erişiyor?
- Üretim ortamında DNS çözümü nasıl (split-horizon var mı)?
Pratikte bu harita için şu kaynakları birleştiririm:
- Proxy/NGFW log’ları (dest domain, byte, user/workload)
- VPC flow logs (IP/port)
- DNS query log (domain)
- Uygulama config / IaC (endpoint listeleri)
Politika modeli: “Servis odaklı allowlist”
ZTNA egress’te en işe yarayan model:
- Default deny (en azından prod için)
- Servis bazında allowlist (domain/IP/port)
- “Break-glass” için süreli istisna
Servis odaklı yaklaşım, organizasyon büyüdükçe sürdürülebilir olur. “Network team her şeye kural yazsın” modeli ölçeklenmez.
Örnek politika cümleleri:
payments-apiyalnızcabank-gateway.example.com:443vekms.<cloud>:443ci-runneryalnızcanpmjs.org,registry.npmjs.org,github.com,objects.githubusercontent.comsupport-jumpyalnızcaidp,pam,monitoring,ticketingsistemlerine
ZTNA ajanı + egress proxy: En pratik kombinasyon
Birçok ZTNA çözümü uygulama erişimini “tünel” üzerinden verir. Egress için ise iki pratik yol var:
- Explicit proxy (PAC/WPAD veya agent ile)
- Transparent egress (L3/L4 enforce eden gateway)
Benim tercih ettiğim yaklaşım:
- Kullanıcılar için explicit proxy: daha iyi domain kontrolü + TLS inspection opsiyonu
- Workload’lar için gateway: eBPF/sidecar yerine merkezi enforce (kümeye göre değişir)
Burada kritik olan “tek ürün” değil; sinyal birleşimidir: ZTNA kimliği + proxy hedefi + gateway akışı.
Data exfiltration senaryoları ve kontrol noktaları
Senaryo 1: Yetkili kullanıcı toplu veri çekiyor
Kontrol:
- API rate-limit (identity bazlı)
- Query audit log + anomali (normal dışı hacim)
- “High risk” saat/konumda step-up auth
Senaryo 2: Servis hesabı yeni bir SaaS’a veri gönderiyor
Kontrol:
- Egress allowlist (yeni domain blok)
- “New destination” alarmı (servis bazlı)
- Change management entegrasyonu (onaylı hedef listesi)
Senaryo 3: Malware C2 iletişimi
Kontrol:
- DNS filtreleme + threat intel
- ASN/geo bazlı bloklama (temel)
- Proxy üzerinde kategorisel blok + reputasyon
Operasyon: İstisna yönetimi yoksa proje ölür
Egress kontrolünde en çok kırılan yer “istisna”dır. İstisna yönetimi için minimum tasarım:
- İstisnanın sahibi (service owner), nedeni ve süresi
- Onay mekanizması (değişiklik yönetimi)
- Otomatik geri alma (TTL bittiğinde kapanmalı)
- Telemetri: “istisna kullanımı” metriği
Kural seti zamanla büyüyecek. Sürdürülebilirlik için hedefiniz:
- Daha az “global kural”, daha çok “servis kuralı”
- Drift’i görünür kılan IaC (policy as code)
- Denetimde “kimin için ne açık” sorusuna tek cevap
Kapanış: ZTNA’yı veri güvenliğine bağlayın
ZTNA “erişim kontrolü” ile başlar ama “veri kontrolü” ile tamamlanır. Egress kontrolünü tasarlamadığınız ZTNA, çoğu kurumda “içeri girişi düzenleyen ama dışarı kaçışı seyreden” bir sistem olur.
Başlarken hedefi küçük tutun:
- Önce prod workload’ların egress envanterini çıkarın
- En kritik 5 servis için allowlist uygulayın
- İstisna yönetimini (TTL + onay) baştan koyun
- “Yeni hedef” ve “anomali hacim” alarmlarını devreye alın