ZTNA Nedir? VPN'in Yerini Alan Sıfır Güven Erişimi

ZTNA nedir sorusunun kısa yanıtı: Zero Trust Network Access (Sıfır Güven Ağ Erişimi), kullanıcıyı ağa değil yalnızca yetkili olduğu uygulamaya bağlayan ve her oturumda kimliği, cihazın güvenlik duruşunu ve bağlamı yeniden doğrulayan erişim modelidir. Klasik VPN'in "bir kez doğrula, ağın tamamına al" yaklaşımının yerini alır.

ZTNA Nedir ve Sıfır Güven Ne Anlama Gelir?

ZTNA, "hiçbir kullanıcıya, cihaza ve ağ konumuna örtük güven duyulmaz" ilkesini uzaktan erişime uygulayan teknolojidir. Kullanıcı önce kimliğini doğrular, cihazı güvenlik duruşu kontrolünden geçer, ardından yalnızca politikanın izin verdiği uygulamaya, o oturum için bağlanır. Ağın geri kalanı kullanıcı açısından görünmezdir.

Sıfır güven bir ürün değil, bir mimari yaklaşımdır. Referans tanımı, ABD Ulusal Standartlar ve Teknoloji Enstitüsü'nün (NIST) SP 800-207 Zero Trust Architecture yayınında yapılır. Belgenin temel ilkelerini sadeleştirirsek:

• Tüm veri kaynakları ve bilgi işlem servisleri birer "kaynak" olarak ele alınır; yazıcıdan ERP sunucusuna kadar her şey korunmalıdır.
• Ağ konumundan bağımsız olarak tüm iletişim güvence altına alınır; iç ağdan gelen istek dış ağdan gelen kadar şüphelidir.
• Erişim oturum bazında ve en az yetki ilkesiyle verilir.
• Erişim kararı dinamik politikaya dayanır: kimlik, uygulama, cihaz durumu ve davranışsal sinyaller birlikte değerlendirilir.
• Kurum, sahip olduğu ve kullandığı tüm varlıkların bütünlüğünü ve güvenlik duruşunu izler.
• Kimlik doğrulama ve yetkilendirme erişim öncesinde kesin biçimde uygulanır ve gerektiğinde yenilenir.
• Toplanan ağ, varlık ve trafik verisi güvenlik duruşunu sürekli iyileştirmek için kullanılır.

NIST aynı belgede mantıksal mimariyi üç bileşenle tarif eder: erişim kararını veren Policy Engine, kararı bağlantı emrine çeviren Policy Administrator ve kullanıcı ile kaynak arasındaki yolu açıp kapatan Policy Enforcement Point. ZTNA, bu mimarinin uzaktan ve hibrit çalışan kullanıcılar için uygulanmış hâlidir; VPN'in çözmeye çalıştığı aynı problemi, yani "ofis dışındaki kişiyi iç uygulamaya güvenle bağlama" problemini farklı bir güven modeliyle çözer.

Klasik VPN Neden Artık Yeterli Değil?

Klasik uzak erişim VPN'i, kullanıcıyı bir kez doğruladıktan sonra iç ağın bir üyesi hâline getirir; erişim uygulamaya değil ağ segmentine verilir. Bu örtük güven, ele geçirilen tek bir hesabı yanal hareket için başlangıç noktasına çevirir ve internete açık VPN portalını saldırganlar için kalıcı bir hedef yapar.

VPN, tasarlandığı dönemin varsayımlarını taşır: uygulamalar veri merkezindedir, kullanıcı şirket cihazı kullanır ve ağın içi güvenlidir. Bu varsayımların üçü de bugünün hibrit çalışma düzeninde geçerliliğini kaybetmiştir. Saha projelerimizde en sık gördüğümüz dört zayıflık şunlardır:

• Geniş erişim: Muhasebe uygulamasına ulaşması gereken bir kullanıcı, tünel kurulduğu anda çoğu kurulumda tüm sunucu VLAN'ını da görebilir.
• Tek seferlik doğrulama: Oturum açıldıktan sonra cihaz virüs kapsa da, kullanıcı başka bir ağa geçse de tünel açık kalır.
• Cihaz körlüğü: Klasik VPN, bağlanan cihazın antivirüsü çalışıyor mu, işletim sistemi güncel mi, disk şifreli mi bilmez.
• İnternete açık yüzey: VPN portalı tanım gereği herkese açıktır; portaldaki bir zafiyet, yama yayınlanana kadar tüm kurumu riske sokar.

Bu tablo Fortinet'in ürün yönünü de değiştirdi. Fortinet sürüm notlarına göre FortiOS 7.6.3 itibarıyla SSL VPN tünel modu kaldırılmış ve yerini TCP 443 üzerinden de çalışabilen IPsec VPN almıştır; eski yapılandırmalar yükseltmede taşınmaz. Giriş seviyesi bazı modellerde bu kaldırma daha erken sürümlerde başladığından kendi modeliniz için sürüm notlarını doğrulamanız gerekir. Ayrıntılı geçiş adımlarını FortiOS 7.6'da SSL VPN'in kaldırılması ve geçiş planı yazımızda topladık; mevcut kurulumunuzun ayrıntıları için FortiGate VPN yapılandırma rehberimiz hâlâ geçerli bir başlangıç noktasıdır.

ZTNA Nasıl Çalışır?

ZTNA'da erişim kararı ağ konumuna değil üç girdiye dayanır: doğrulanmış kullanıcı kimliği, uç noktanın o anki güvenlik duruşu ve talep edilen uygulama. Karar noktası politikayı üretir; uygulama noktası bağlantıyı yalnızca hedef uygulamaya, yalnızca o oturum için açar ve koşullar değişince kapatır.

Adım adım akış çoğu üreticide benzerdir:

1. İstek: Kullanıcı bir iç uygulamayı açmak ister. Cihazdaki ZTNA ajanı ya da tarayıcı tabanlı erişimde ters proxy isteği yakalar.
2. Kimlik doğrulama: Kullanıcı kurumsal dizin (Active Directory, Entra ID, SAML sağlayıcısı) üzerinden doğrulanır; çok faktörlü doğrulama bu adımın standart parçasıdır.
3. Cihaz duruşu: Ajan, cihazın işletim sistemi sürümü, antivirüs durumu, disk şifreleme, etki alanı üyeliği gibi özelliklerini raporlar; bunlar etiketlere dönüşür.
4. Politika kararı: "Finans grubundaki kullanıcı + güncel ve şirket yönetimindeki cihaz + ERP uygulaması" eşleşmesi varsa erişim onaylanır, yoksa reddedilir.
5. Bağlantı: Trafik uygulama geçidi üzerinden yalnızca hedef uygulamaya taşınır. Uygulama internete doğrudan açılmaz; kullanıcı ağın geri kalanına yönlendirme dahi yapamaz.
6. Sürekli değerlendirme: Cihaz duruşu bozulursa (örneğin antivirüs kapatılırsa) etiket düşer ve oturum politika gereği sonlandırılır.

Bu akışın iki sonucu vardır. Birincisi, uygulamalar "karanlık" hâle gelir: dışarıdan tarandığında ne bir port ne de bir giriş sayfası görünür. İkincisi, güvenlik kontrolleri kullanıcıya değil bağlantıya bağlanır; aynı kullanıcı şirket dizüstüsünden ERP'ye ulaşırken, kişisel tabletinden yalnızca e-posta arayüzünü görebilir. Bu ayrım, klasik VPN'de ancak karmaşık kural setleriyle ve çoğu zaman eksik biçimde kurulabilir.

VPN ile ZTNA Karşılaştırması

VPN ile ZTNA arasındaki temel fark güven modelidir: VPN ağa erişim verir ve bir kez doğrular; ZTNA uygulamaya erişim verir ve sürekli doğrular. Aşağıdaki tablo karar vericilerin en sık sorduğu on kriteri yan yana koyar; her satır projelerimizde gözlemlediğimiz tipik davranışı özetler.

Tablo, ZTNA'nın "daha iyi bir VPN" değil farklı bir güven modeli olduğunu gösterir. Bununla birlikte VPN tamamen ölmüş değildir: şubeler arası IPsec tüneller, UDP tabanlı bazı eski uygulamalar ve VoIP gibi senaryolarda IPsec VPN hâlâ doğru araçtır. Sağlıklı bir tasarımda ikisi bir süre yan yana yaşar; ZTNA kullanıcı erişimini, IPsec ise site-to-site ve istisna trafiğini taşır.

Fortinet ZTNA Mimarisi: FortiClient, EMS ve FortiGate Uygulama Geçidi

Fortinet ZTNA mimarisi üç bileşenden oluşur: uç noktadaki FortiClient ZTNA ajanı, kimlik ve cihaz duruşunu etiketlere çeviren FortiClient EMS ve erişim kararını uygulayan FortiGate ZTNA uygulama geçidi. Yapı FortiOS 7.0 ile tanıtıldı; FortiGate'in mevcut IPS, antivirüs ve web filtreleme profilleri ZTNA trafiğine de uygulanır.

Bileşenlerin görev dağılımı şöyledir:

Akış Fortinet belgelerinde şöyle tanımlanır: FortiGate, Security Fabric bağlayıcısı üzerinden EMS'e bağlanır ve ZTNA etiketlerini otomatik olarak senkronize eder; EMS etiket değişikliklerini kalıcı bir bağlantı üzerinden anında iletir. Güvenlik duruşu etiketleri; antivirüs kurulu mu, işletim sistemi sürümü nedir, cihaz etki alanına giriş yapmış mı, belirli bir süreç çalışıyor mu, kayıt defteri değeri ne, cihazın zafiyet seviyesi ve bilinen bir CVE'nin varlığı gibi kontrollere dayanır. FortiGate bu etiketleri ZTNA kuralında, güvenlik duvarı politikasında ve NAC politikasında kullanabilir. Temel kurulum adımları Fortinet FortiOS yönetici kılavuzunda belgelenmiştir.

Erişim iki biçimde sunulur. HTTPS erişim proxy'si, web uygulamalarını ve HTTPS içine sarılmış RDP, SSH, VNC gibi oturumları tarayıcıdan ya da ajandan sunar. TCP yönlendirme ise web olmayan istemci-sunucu uygulamaları için FortiClient'ın belirli hedef adres ve portlara giden istekleri yakalayıp uygulama geçidine iletmesini sağlar. Böylece ERP istemcisi ya da veritabanı yönetim aracı gibi uygulamalar ağ tüneli olmadan çalışır. Şube trafiği ve internete çıkış denetimi de aynı modele taşınmak isteniyorsa SASE ve FortiSASE yaklaşımını ele aldığımız yazı bu makalenin doğal devamıdır.

VPN'den ZTNA'ya Geçiş Nasıl Planlanır?

VPN'den ZTNA'ya geçiş tek gecelik bir kesme değil; envanter, kimlik, uç nokta ve pilot uygulama adımlarıyla ilerleyen, VPN'in bir süre paralel çalıştığı kademeli bir programdır. Projelerimizde en çok zaman alan iş teknoloji değil, hangi kullanıcının hangi uygulamaya gerçekten ihtiyaç duyduğunun ortaya çıkarılmasıdır.

1. Uygulama ve kullanıcı envanteri: VPN üzerinden erişilen her uygulamayı, protokolünü (HTTPS, RDP, SSH, veritabanı, dosya paylaşımı) ve kullanıcı gruplarını listeleyin. VPN loglarınız bu envanterin en dürüst kaynağıdır.
2. Kimlik altyapısı: Dizin hijyeni, grup yapısı ve çok faktörlü doğrulama ZTNA'nın ön koşuludur. Yetim hesaplar ve herkesin üye olduğu gruplar politikayı anlamsızlaştırır.
3. Uç nokta hazırlığı: FortiClient EMS kurulur, ajan önce mevcut cihazlara dağıtılır, duruş etiketleri "izleme" modunda toplanır. Cihaz duruşu güvenilir bir uç nokta koruma katmanına dayanır; hangi katmanın gerektiğini EDR, XDR ve MDR farkları yazımızda anlattık.
4. Pilot: Bir veya iki web uygulaması ve gönüllü bir kullanıcı grubuyla başlayın. Bu aşama politika mantığını ve kullanıcı deneyimini düşük riskle sınar.
5. Genişletme: TCP yönlendirme kurallarıyla RDP, SSH ve istemci-sunucu uygulamalarını ekleyin; her uygulama için "kim, hangi cihaz duruşuyla" sorusunu ayrı yanıtlayın. Kural setinin sadeliği için FortiGate politika yönetimi ilkeleri burada da geçerlidir.
6. İstisnaların yönetimi: ZTNA'nın kapsayamadığı UDP tabanlı ya da eski uygulamalar için IPsec VPN'i dar bir kapsamla koruyun.
7. VPN portalının kapatılması: Kullanıcı ve uygulama kapsamı tamamlanınca eski portalı devre dışı bırakın ve erişim loglarını merkezi log yönetimine bağlayın.

Bu sıra, FortiOS 7.6 sonrası SSL VPN'den zorunlu olarak ayrılan kurumlar için de geçerlidir; fark yalnızca birinci adımın çoğu zaman bir sürüm yükseltme takvimiyle birlikte gelmesidir.

KOBİ'ler için ZTNA Gerçekçi mi?

ZTNA yalnızca büyük kurumlara özgü değildir. Mevcut bir FortiGate'i olan KOBİ, FortiClient ve EMS ekleyerek aynı cihaz üzerinde ZTNA uygulama geçidini devreye alabilir. Maliyeti belirleyen kalemler uç nokta sayısı, EMS'in bulutta mı yerinde mi çalışacağı ve şube trafiği için FortiSASE'ye ihtiyaç olup olmadığıdır; tutar ancak keşif sonrası teklifle netleşir.

Saha deneyimimizde ZTNA'nın küçük ve orta ölçekte anlamlı olduğu üç durum öne çıkar. Birincisi, dışarıdan çalışan yükleniciler ve muhasebe, hukuk gibi dış danışmanlar: bu kişilere VPN vermek tüm ağı açmak demektir; ZTNA ile yalnızca ilgili uygulama görünür. İkincisi, kişisel verilerin erişim denetimi: en az yetki ve ayrıntılı erişim kaydı, KVKK Kurulu'nun Kişisel Veri Güvenliği Rehberi'nde anlatılan erişim yetki matrisi ve log tutma yaklaşımıyla örtüşür; güncel mevzuatı ve resmî rehberi doğrulamanız koşuluyla ZTNA bu tedbirlerin teknik karşılığını sağlar. Üçüncüsü, fidye yazılımı riski: saldırganın VPN hesabıyla ağa girip yedek sunucusuna ulaşması ZTNA'da tasarım gereği engellenir.

Sora Yazılım olarak yaklaşımımız bağımsız çözüm ortağı rolünden gelir: mevcut FortiGate'inizi, kullanıcı profilinizi ve uygulama envanterinizi keşif görüşmesinde çıkarır, ZTNA ile IPsec'in sınırlarını birlikte çizer, kurulumu yapar ve isterseniz politika bakımını yönetilen hizmet olarak sürdürürüz.

Sık Sorulan Sorular

ZTNA VPN'in yerini tamamen alır mı?

Kullanıcıların uygulamalara uzaktan erişimi için evet; ZTNA bu senaryoda daha dar yetki ve daha iyi görünürlük sağlar. Şubeler arası site-to-site bağlantılar, UDP tabanlı eski uygulamalar ve bazı VoIP senaryoları için IPsec VPN geçerliliğini korur. İkisi çoğu kurumda bir süre birlikte çalışır.

ZTNA için mutlaka ajan yazılımı gerekir mi?

Hayır. Web uygulamaları için tarayıcı üzerinden çalışan ajansız erişim mümkündür; ancak cihaz duruşu kontrolü ve web olmayan uygulamalar için ajan gerekir. Fortinet mimarisinde bu ajan FortiClient'tır ve duruş bilgisi FortiClient EMS üzerinden etiketlere dönüşür.

FortiGate üzerinde ZTNA için ek lisans gerekir mi?

FortiGate'teki ZTNA uygulama geçidi FortiOS'un yerleşik bir özelliğidir. Uç noktada FortiClient ve merkezde FortiClient EMS lisansı gerekir. Lisans kapsamı sürüme ve pakete göre değiştiğinden güncel Fortinet belgeleriyle doğrulanmalı, tam kapsam teklif aşamasında netleştirilmelidir.

ZTNA ile SASE arasındaki fark nedir?

ZTNA, kullanıcının iç uygulamalara güvenli erişimini düzenleyen tek bir işlevdir. SASE ise ZTNA'yı güvenli web ağ geçidi, CASB, hizmet olarak güvenlik duvarı ve SD-WAN ile birleştirip buluttan sunan daha geniş bir çerçevedir. FortiSASE, ZTNA'yı bu bütünün içinde sunar.

ZTNA KVKK uyumuna nasıl katkı sağlar?

ZTNA, kişisel veri içeren uygulamalara erişimi kimlik, cihaz ve uygulama bazında sınırlar ve her erişimi kaydeder. Bu, KVKK Kurulu'nun Kişisel Veri Güvenliği Rehberi'ndeki erişim yetki matrisi ve log tutma tedbirleriyle uyumludur; ancak uyum bir bütündür, güncel mevzuatı ve resmî rehberi doğrulayın.

Geçiş sırasında kullanıcılar kesinti yaşar mı?

Doğru planlandığında hayır. Pilot aşamasında VPN açık kalır, kullanıcılar uygulama bazında ZTNA'ya taşınır ve sorun çıkarsa aynı gün VPN'e dönülebilir. Kesinti riski en çok kimlik altyapısı hazırlanmadan ajanın toplu dağıtıldığı projelerde görülür.

Sonuç

ZTNA, uzaktan erişimin güven modelini değiştirir: ağ yerine uygulama, tek seferlik doğrulama yerine sürekli değerlendirme, görünür portal yerine dışarıdan görünmeyen kaynaklar. NIST SP 800-207'nin çizdiği çerçeve, Fortinet tarafında FortiClient, EMS ve FortiGate uygulama geçidi üçlüsüyle somutlaşır; FortiOS 7.6.3 ile SSL VPN tünel modunun kaldırılması bu geçişi birçok kurum için takvime bağlamıştır. Doğru sıra envanter, kimlik, uç nokta, pilot ve kademeli genişlemedir.

Mevcut VPN yapınızı ZTNA'ya nasıl taşıyacağınızı birlikte değerlendirmek için ücretsiz keşif görüşmesi talep edebilirsiniz; ihtiyacınıza uygun FortiClient, EMS ve FortiSASE kapsamı için teklif hazırlarız.