Kurumsal VPN'den ZTNA'ya Geçiş: Uygulama Bazlı Erişim Nasıl Tasarlanır

Uzak erişim yıllarca kurumsal ağa açılan şifreli bir tünel üzerinden sağlandı. Bu model, kullanıcının önce ağa girmesini ve ardından ağ içindeki kaynaklara ulaşmasını temel alır. Bulut hizmetlerinin, dışarıdan çalışan ekiplerin ve farklı yönetim seviyelerine sahip cihazların artmasıyla bu geniş ağ erişimi daha zor yönetilir hâle geldi. Bir hesabın ya da cihazın ele geçirilmesi durumunda saldırganın ağ içinde keşif yapabileceği alan büyüyebilir.

Sıfır güven ağ erişimi olarak adlandırılan ZTNA yaklaşımı, kullanıcıya geniş bir ağ bölümüne erişim vermek yerine yalnızca yetkili olduğu uygulama veya kaynağa erişim sağlamayı amaçlar. Karar; kimlik, cihaz durumu, istenen kaynak, oturum riski ve erişim koşulları birlikte değerlendirilerek verilir. Geçişin amacı yalnızca uzaktan erişim aracını değiştirmek değildir. Erişim politikasını ağ konumundan uygulama ve kimlik bağlamına taşımaktır.

VPN ile ZTNA arasındaki temel fark

Sanal özel ağ bağlantısı, kullanıcının cihazıyla kurumsal ağ arasında şifreli bir kanal kurar. Yetkilendirme ağ geçidinde yapılır; bağlantı açıldıktan sonra erişimin kapsamı çoğu zaman yönlendirme, ağ bölümleri ve güvenlik duvarı kurallarıyla sınırlandırılır. Bu yapı doğru tasarlandığında güvenli olabilir, ancak kullanıcı ile uygulama arasındaki yetki ilişkisini görünür kılmak zorlaşabilir.

ZTNA uygulamaları, mimariye göre geçit, bağlayıcı veya aracı katman üzerinden belirli kurumsal kaynaklara erişim sağlar; uygulamanın genel ağdan gizlenmesi yaygın, ancak evrensel olmayan bir dağıtım modelidir. Kimlik doğrulama ve yetkilendirme, kurumsal kaynağa yönelik oturum kurulmadan önce yapılır; politika gerektirdiğinde oturum sırasında yeniden değerlendirilebilir. Kullanıcı, uygulamanın bulunduğu ağın tamamına yönlendirilmez. NIST SP 800-207 bu yaklaşımda ağ konumu ya da cihaz sahipliğinin tek başına güven nedeni sayılmaması gerektiğini belirtir.

Bu fark, VPN'in hemen kaldırılması gerektiği anlamına gelmez. Ağ yönetimi, belirli eski protokoller ve uygulama yerine tüm alt ağa erişim gerektiren sınırlı işler bir süre daha VPN kullanabilir. Geçiş planı, uygulama bazlı erişime uygun iş yüklerini ayırmalı ve kalan ağ erişimini daraltmalıdır.

Kaynak envanteri ve erişim haritası

ZTNA projesi bir ürün kurulumuyla değil, kaynak envanteriyle başlar. İnternet üzerinden erişilen uygulamalar, veri merkezindeki web uygulamaları, uzak masaüstü hizmetleri, yönetim arayüzleri ve özel protokol kullanan eski sistemler ayrı ayrı listelenmelidir. Her kaynak için hizmet sahibi, veri sınıfı, kimlik yöntemi, bağımlılıklar, kullanıcı grupları ve beklenen erişim yolu kaydedilmelidir.

Mevcut VPN günlükleri gerçek kullanım hakkında önemli kanıt sağlar. Hangi grupların hangi hedeflere, hangi saatlerde ve ne sıklıkla bağlandığı incelenebilir. Yalnızca ağ akışına bakmak yeterli değildir; tek oturum içinde açılan yardımcı hizmetler, alan adı çözümleme, sertifika denetimi ve kimlik sağlayıcısı bağlantıları da haritalanmalıdır. Aksi hâlde pilot sırasında ana uygulama açılırken kritik bir yan bağımlılık çalışmayabilir.

Envanter tamamlandığında uygulamalar geçiş kolaylığına ve riskine göre sınıflandırılır. Standart web protokolleri kullanan, merkezi kimlik doğrulamasına bağlı ve sahibi belli uygulamalar ilk pilot için uygundur. Ağ taraması yapan yönetim araçları, çok sayıda dinamik port kullanan sistemler veya kimlik bütünleştirmesi bulunmayan eski uygulamalar daha ayrıntılı tasarım gerektirir.

Kimlik cihaz ve bağlam sinyalleri

Uygulama bazlı erişimin güvenilirliği, kimlik ve cihaz bilgisinin doğruluğuna bağlıdır. Kişiye özel hesap, güçlü çok faktörlü kimlik doğrulama ve zamanında kapatılan erişim hakları temel gereksinimlerdir. Ortak hesaplar, kalıcı yönetici yetkileri ve uzun ömürlü oturumlar erişim kararını zayıflatır. Hassas işlemlerde yeniden kimlik doğrulama ya da daha güçlü bir doğrulama adımı istenebilir.

Cihaz durumu tek bir uyum etiketine indirgenmemelidir. Desteklenen işletim sistemi, güvenlik güncellemeleri, disk şifreleme, ekran kilidi, uç nokta koruması ve cihazın yönetim kaydı ayrı sinyaller olarak değerlendirilmelidir. Kişisel cihazdan erişime izin verilecekse uygulama verisinin yerel diske indirilmesi, kopyalanması ya da yazdırılması gibi işlemler için ayrı kurallar gerekebilir.

Bağlam sinyalleri yardımcıdır, ancak tek başına kesin hüküm olmamalıdır. Olağan dışı ülke, anonimleştirme ağı, kısa sürede uzak konumlardan gelen istekler veya beklenmeyen saatlerdeki erişim risk puanını yükseltebilir. Yanlış pozitifler iş akışını kesebileceği için yüksek riskte tamamen engelleme, ek doğrulama, salt okunur erişim veya kısa oturum gibi seçenekler önceden tanımlanmalıdır.

Politika karar ve uygulama katmanı

ZTNA mimarisinde politika karar noktası, erişim isteğine ilişkin sinyalleri toplar ve izin sonucunu üretir. Politika uygulama noktası ise bağlantıyı açar, sınırlar veya reddeder. Bu iki rol mantıksal olarak ayrıldığında erişim kuralları merkezi biçimde yönetilebilir; farklı uygulama geçitleri aynı politika yaklaşımını uygulayabilir.

Politikalar doğrudan kişi listeleriyle büyütülmemelidir. Rol, görev, kaynak hassasiyeti, cihaz seviyesi ve erişim amacı gibi nitelikler kullanılmalıdır. Örneğin standart bir uygulama için yönetilen cihaz ve güçlü doğrulama yeterliyken, yönetim arayüzü yalnızca ayrıcalıklı rol, kontrollü cihaz ve onaylı çalışma süresiyle açılabilir. Her kuralın sahibi, gerekçesi, gözden geçirme tarihi ve başarısız olduğunda uygulanacak davranış belirlenmelidir.

Uygulama bağlayıcısı ya da erişim geçidi, korunan kaynağa içeriden dışarı doğru bağlantı kuracak şekilde yerleştirilebilir. Böylece uygulamanın doğrudan internete açılması gerekmez. Yine de geçitlerin kendisi yüksek erişilebilirlik, güncelleme, sertifika yönetimi ve günlükleme açısından kritik altyapı kabul edilmelidir.

Geçiş sırası ve birlikte çalışma dönemi

İlk pilot, işi temsil eden küçük bir kullanıcı grubuyla ve etkisi sınırlı iki ya da üç uygulamayla yapılmalıdır. Başarı yalnızca bağlantının kurulması değildir. Oturum açma süresi, uygulama yanıtı, başarısız erişim nedeni, destek ihtiyacı ve kesinti anındaki geri dönüş yolu ölçülmelidir. Pilot sırasında yeni erişim yolu ile mevcut VPN paralel tutulabilir, ancak kullanıcıların sürekli eski yola dönmesini önlemek için kullanım koşulları açık olmalıdır.

Sonraki dalgalarda uygulamalar iş birimi, protokol ve risk düzeyine göre gruplanabilir. Her dalgadan önce bağımlılık doğrulaması yapılır, erişim grupları temizlenir ve pilot sonuçlarına göre politika ayarlanır. VPN kapsamı aynı hızla küçültülmezse iki ayrı erişim katmanı kalıcı hâle gelir. ZTNA'ya taşınan bir uygulamanın eski ağ yolu kapatılmalı ya da yalnızca acil durum hesabıyla sınırlandırılmalıdır.

Yönetim erişimi için ayrı bir geçiş hattı gerekir. Sunucu, ağ cihazı veya veri tabanı yönetimi yapan ekipler için kayıtlı oturum, süreli yetki, komut düzeyi denetim ve acil durum erişimi değerlendirilebilir. Normal kullanıcı erişimiyle yönetici erişiminin aynı politika kümesine sıkıştırılması görünürlüğü azaltır.

Performans süreklilik ve olay müdahalesi

ZTNA hizmeti kimlik sağlayıcısı, ad çözümleme, sertifika altyapısı ve uygulama geçitleri gibi birden çok bileşene bağlıdır. Tasarım, bu bağımlılıkların birinin çalışmadığı durumda ne olacağını açıklamalıdır. Kimlik hizmeti kesildiğinde mevcut oturumların ne kadar süreceği, yeni oturumların açılıp açılmayacağı ve acil erişimin nasıl doğrulanacağı önceden test edilmelidir.

Kullanıcı deneyimi uçtan uca izlenmelidir. Yalnızca geçit gecikmesi değil, kullanıcının konumu, internet yolu, kimlik doğrulama süresi ve uygulamanın kendi yanıtı aynı zaman çizelgesinde görülmelidir. Trafiği gereksiz biçimde uzak bir noktaya taşıyan mimari, güvenlik kazanımı sağlarken uygulamayı yavaşlatabilir. Geçit konumu ve bağlantı rotası gerçek kullanıcı ölçümleriyle seçilmelidir.

Olay müdahalesinde uygulama, kullanıcı, cihaz ve politika kararı tek oturum kimliğiyle ilişkilendirilmelidir. Şüpheli erişim görüldüğünde yalnızca hesabı kapatmak yerine ilgili oturumu sonlandırmak, cihazı karantinaya almak ve aynı kimlikle açılmış diğer oturumları incelemek mümkün olmalıdır. Günlüklerin saklama süresi ile erişim yetkisi, mahremiyet ve mevzuat gereksinimleriyle birlikte belirlenmelidir.

Sık yapılan hatalar

En yaygın hata, mevcut VPN kurallarını aynen yeni platforma kopyalamaktır. Geniş alt ağ izinleri uygulama bazlı modele taşındığında erişim yüzeyi küçülmez. İkinci hata, bütün kullanıcıları aynı cihaz ve risk politikasına bağlamaktır. Uygulama hassasiyeti ve görev türü farklıysa kontrol seviyesi de değişmelidir.

Diğer hatalar; uygulama sahibini sürece katmamak, yalnızca başarılı oturum sayısını izlemek, eski erişim yollarını açık bırakmak, hizmet hesaplarını insan hesabı gibi yönetmek ve acil durum senaryosunu test etmemektir. Ayrıca ZTNA, uç noktadaki zararlı yazılımı ya da uygulamanın kendi açığını ortadan kaldırmaz. Uç nokta güvenliği, güvenli yazılım geliştirme, ağ bölümlendirme ve kayıt yönetimi birlikte sürdürülmelidir.

Aşamalı uygulama planı

İlk aşamada uygulama ve erişim envanteri çıkarılır, VPN akışları doğrulanır ve ölçülecek başlangıç değerleri belirlenir. İkinci aşamada kimlik, cihaz ve günlük kaynakları bütünleştirilir. Üçüncü aşamada düşük riskli web uygulamalarıyla pilot yapılır; destek kayıtları ve kullanıcı deneyimi gözden geçirilir.

Dördüncü aşamada daha hassas uygulamalar için adım yükselten doğrulama, kısa oturum ve süreli yetki kuralları uygulanır. Beşinci aşamada taşınan uygulamaların eski ağ yolları kapatılır, kalan VPN kullanımı gerekçelendirilir ve düzenli hak gözden geçirmesi başlatılır. Son aşamada erişim politikaları olay verileri ve değişen iş gereksinimleriyle güncellenir.