ZTNA mı VPN mi? Uzak Erişim Mimarisinde Karar Kriterleri

Uzak erişim kararı çoğu kurumda “hangi VPN istemcisini kuralım” sorusuna indirgenir. Asıl soru başkadır: Uzaktaki kullanıcıya ağın tamamını mı açıyorsunuz, yoksa yalnız ihtiyaç duyduğu uygulamaları mı? VPN ile ZTNA (Zero Trust Network Access) arasındaki gerçek fark buradadır. Aşağıda iki modelin farkını, ZTNA’nın sınırlarını ve hibrit yaklaşımın ne zaman mantıklı olduğunu bir karar ağacıyla ele alıyoruz.

VPN ve ZTNA’nın erişim modeli farkı

Uzak erişim VPN’i (SSL VPN veya IPsec), kimliği doğrulanan istemciye kurumsal ağda bir IP adresi verir ve istemciyi ağın bir parçası yapar. Kullanıcının hangi sistemlere ulaşacağını, VPN havuzundan iç ağa yazılmış firewall kuralları belirler. Bu kurallar çoğunlukla kullanıcı grubuna göre değil havuz alt ağına göre yazılır. Sahada en sık gördüğümüz tablo budur: VPN havuzundan sunucu ağına “any” izin. Sonuçta uzak kullanıcıların büyük kısmı ihtiyacından çok daha geniş bir ağı görür; ele geçirilmiş bir VPN hesabı ya da zararlı yazılım bulaşmış bağlı bir dizüstü bu genişlik içinde yatay hareket eder.

ZTNA erişimi uygulama düzeyinde verir. Kullanıcı ve cihaz her bağlantı isteğinde politika motoru tarafından değerlendirilir; izin çıkarsa yalnız o uygulamaya giden bir oturum kurulur. Uygulamalar internete doğrudan açılmaz; genellikle iç ağdaki bir bağlayıcı (connector) dışarıya doğru bağlantı kurar, gelen port açmaya gerek kalmaz. NIST SP 800-207 bu modeli, kaynağa erişim kararının ağ konumuna değil kimlik, cihaz durumu ve bağlama göre oturum bazında verilmesi olarak tanımlar.

Temel fark şudur: VPN’de güven bağlantı anında verilir ve oturum boyunca sürer; ZTNA’da güven her uygulama erişiminde, politika koşullarına göre yeniden değerlendirilir. Biri kapıyı açar. Diğeri odayı.

Ajanlı ve ajansız ZTNA mimarileri

ZTNA ürünleri iki temel erişim biçimi sunar; çoğu kurum ikisini birlikte kullanır:

• Ajanlı (client-initiated): Uç noktaya kurulan istemci, kullanıcıyı ve cihazı tanıtır, cihaz duruş bilgisini (disk şifreleme, EDR durumu, işletim sistemi sürümü, yönetilen cihaz olup olmadığı) politika motoruna iletir ve trafiği yalnız izinli uygulamalar için tünele alır. RDP, SSH, dosya paylaşımı ve web dışı protokoller için gereklidir.
• Ajansız (service-initiated / tarayıcı tabanlı): Kullanıcı bir ters vekil sunucu (reverse proxy) üzerinden web uygulamasına tarayıcıyla erişir. Yönetilmeyen cihazlar, tedarikçiler ve iş ortakları için uygundur; ancak cihaz duruşu sınırlı görülür ve web dışı protokol desteği kısıtlıdır.

Mimari açıdan ikinci ayrım, politika uygulama noktasının nerede durduğudur: üreticinin bulut hizmeti (SSE/SASE platformları) veya kurumun kendi veri merkezindeki bir ağ geçidi. Bulut tabanlı modelde trafik üreticinin altyapısından geçer; veri yerleşimi ve gizlilik değerlendirmesinde bunu ayrıca ele alın.

Karşılaştırma tablosu: güvenlik, performans, işletim

Kriter	Uzak erişim VPN	ZTNA
Erişim kapsamı	Ağ / alt ağ	Uygulama
Güven değerlendirmesi	Bağlantı anında	Her erişimde, sürekli
Cihaz duruş kontrolü	Ürüne bağlı, genellikle bağlantı anında	Politikanın parçası
Dışa açık yüzey	VPN ağ geçidi internete açık	Uygulamalar gizli; bağlayıcı dışarıya bağlanır
Yatay hareket riski	Yüksek, kurallar genişse	Düşük, uygulamayla sınırlı
Protokol desteği	Tüm IP trafiği	Ürüne göre; UDP ve sunucudan istemciye bağlantılar sınırlı olabilir
İlk kurulum yükü	Düşük	Uygulama envanteri ve politika tasarımı gerekir
İşletim yükü	Kural setine bağlı	Uygulama ekleme ve politika bakımı sürekli

Performans konusunda genelleme yapmak yanıltır. Tam tünel VPN’de tüm trafik veri merkezine taşınır; bölünmüş tünel (split tunnel) bu yükü azaltır ama internet çıkışı kontrolsüz kalır. Bulut tabanlı ZTNA’da gecikme, kullanıcıya en yakın üretici erişim noktasının konumuna ve uygulamaya giden yol üzerindeki bağlayıcıya bağlıdır. Pilotta kendi kullanıcılarınızın bulunduğu lokasyonlardan ölçüm yapın. Veri sayfası yetmez.

Kullanıcı deneyimi de bir karar kriteridir. VPN’de kullanıcı bağlanmayı unutur, bağlantı kopar, otel ağı IPsec trafiğini engeller; uzak erişim destek taleplerinin büyük kısmı bunlardan gelir. Ajanlı ZTNA arka planda sürekli çalışır, kullanıcı yalnız uygulamayı açar. Buna karşılık bir erişim reddedildiğinde nedenin (cihaz uyumsuzluğu, eksik grup üyeliği, politika koşulu) kullanıcıya ve yardım masasına anlaşılır biçimde gösterilmesi gerekir. Gösterilmezse sorun giderme VPN’dekinden daha zor hale gelir.

ZTNA’nın sınırlamaları ve uygun olmadığı senaryolar

ZTNA’nın her uzak erişim ihtiyacını karşıladığını varsaymak, geçiş projelerinin en sık yaptığı hatadır. Şu durumlara özellikle bakın:

• Sunucudan istemciye başlatılan bağlantılar: Yardım masası araçlarının uzaktaki bilgisayara bağlanması, SCCM gibi yönetim araçlarının istemciye erişmesi, VoIP ve bazı aktif FTP senaryoları ZTNA ürünlerinde desteklenmeyebilir veya ek yapılandırma ister.
• Bağımlılıkları belirsiz eski uygulamalar: Dinamik port kullanan, IP adresi koda gömülü veya çok sayıda arka uç sistemle konuşan istemci-sunucu uygulamaları uygulama bazlı tanımlamayı zorlaştırır.
• Siteler arası bağlantı: Şubeler ve veri merkezleri arasındaki sürekli bağlantı ZTNA’nın konusu değildir; site-to-site IPsec veya SD-WAN ile çözülür.
• Ağ yöneticisi erişimi: Network ekiplerinin geniş yönetim ağlarına erişimi uygulama bazlı modele kolay sığmaz; bu erişim genellikle PAM veya sıçrama sunucusu (jump host) üzerinden ayrıca yönetilir.
• Bağımlılık ve maliyet: Bulut tabanlı ZTNA, üreticinin hizmet sürekliliğine bağımlılık yaratır; hizmet kesintisinde uzak erişimin nasıl sağlanacağı önceden planlanmalıdır.

Karar ağacı: VPN, ZTNA veya hibrit

Aşağıdaki sorular sırayla cevaplandığında çoğu kurumda mimari netleşir:

1. Uzak kullanıcıların eriştiği uygulamaların envanteri çıkarılabiliyor mu? Hayırsa önce envanter. Envanter olmadan ZTNA politikası yazılamaz. Bu sürede mevcut VPN, aşağıdaki sıkılaştırmalarla korunur.
2. Uygulamaların çoğu web tabanlı veya SaaS mı? Evetse ZTNA (ajansız erişim dahil) güçlü adaydır; yönetilmeyen cihazlar ve tedarikçiler için hızlı kazanım sağlar.
3. Sunucudan istemciye bağlantı, eski istemci-sunucu uygulaması veya geniş yönetim erişimi gereken gruplar var mı? Evetse bu gruplar için VPN (veya PAM) bir süre daha kalır: hibrit model.
4. Cihazlar yönetiliyor mu? Yönetilen cihazlarda ajanlı ZTNA ve duruş kontrolü; yönetilmeyen cihazlarda yalnız ajansız ve dar kapsamlı erişim.
5. Tedarikçi ve üçüncü taraf erişimi var mı? Bu erişim VPN hesabıyla veriliyorsa ZTNA’ya ilk taşınacak grup budur; uygulama bazlı ve süreli erişim riski doğrudan azaltır.

Pratikte orta ölçekli kurumların çoğu bir süre hibrit modelde kalır: genel kullanıcılar ve tedarikçiler ZTNA’da, BT yöneticileri ve özel uygulama kullanıcıları sıkılaştırılmış VPN’de. Hibrit dönemde kurumsal siber güvenlik seviyesini korumak için VPN’i MFA, cihaz kontrolü ve kullanıcı grubuna göre kural ayrımıyla güçlendirmeniz gerekir; ayrıntılar kurumsal VPN güvenliği kontrolleri yazısında.

VPN’den ZTNA’ya aşamalı geçiş

1. Görünürlük: VPN loglarından ve firewall oturum kayıtlarından hangi kullanıcı grubunun hangi uygulamalara eriştiği çıkarılır. Bu liste ZTNA uygulama kataloğunun taslağıdır.
2. Kimlik ve cihaz temelinin hazırlanması: Kimlik sağlayıcıda MFA, koşullu erişim politikaları ve cihaz uyumluluk sinyalleri hazır hale getirilir. Microsoft ortamında bu adımın temelini Conditional Access planlaması oluşturur.
3. Pilot: Web tabanlı birkaç uygulama ve sınırlı bir kullanıcı grubuyla başlanır; gecikme, kullanıcı deneyimi ve destek talepleri ölçülür.
4. Uygulama bazlı taşıma: Uygulamalar gruplar halinde ZTNA’ya alınır; her taşımada ilgili VPN kuralı daraltılır. VPN’deki erişim kaldırılmadan geçiş “tamamlandı” sayılmaz. Yalnız yeni bir kapı eklemiş olursunuz.
5. Tedarikçi erişimi: Üçüncü taraf hesapları ZTNA’ya taşınır, VPN hesapları kapatılır.
6. VPN’in daraltılması: Kalan VPN kullanımı istisna olarak belgelenir, MFA ve duruş kontrolüyle sınırlanır ve periyodik olarak gözden geçirilir.

Geçişin olgunluğunu değerlendirmek için CISA Zero Trust Maturity Model kimlik, cihaz, ağ, uygulama ve veri sütunlarıyla kullanışlı bir çerçeve sunar. Mimarinin uzak erişim tarafı VPN ve güvenli uzak erişim, bütüncül model tarafı Zero Trust güvenlik mimarisi kapsamında ele alınabilir. Kurum içindeki kablolu ağda aynı kimlik ve cihaz yaklaşımı için 802.1X ve NAC geçiş planı yazısına bakabilirsiniz.

Sık sorulan sorular

ZTNA, VPN’in tamamen yerini alabilir mi?

Kullanıcıdan uygulamaya erişimde çoğu senaryoda alabilir. Siteler arası bağlantı, sunucudan istemciye başlatılan bağlantılar ve bazı eski uygulamalar için VPN veya başka çözümler bir süre gerekli kalır; bu yüzden çoğu kurum geçiş döneminde hibrit model kullanır.

ZTNA için mutlaka bulut hizmeti mi kullanmak gerekir?

Hayır. Bazı ürünler politika uygulama noktasını kurumun kendi veri merkezinde çalıştırmaya izin verir. Bulut modeli işletimi kolaylaştırır; kendi barındırdığınız model ise trafiğin üretici altyapısından geçmemesini sağlar. Seçimi veri yerleşimi ve işletim kapasitesi belirler.

Cihaz duruş kontrolü neleri kontrol eder?

Ürüne göre değişir; tipik olarak cihazın kurum tarafından yönetilip yönetilmediği, disk şifrelemesi, EDR ajanının çalışıp çalışmadığı, işletim sistemi sürümü ve güvenlik duvarı durumu değerlendirilir. Bu sinyaller erişim kararına doğrudan girer.

Geçişe hangi kullanıcı grubuyla başlamak mantıklıdır?

Genellikle web tabanlı uygulama kullanan bir pilot grup ve tedarikçi erişimleri ilk adaylardır. Tedarikçi erişimini VPN’den uygulama bazlı ve süreli ZTNA erişimine taşımak riski hızlı ve ölçülebilir biçimde azaltır.