Giriş

Bir kullanıcının kurum ağına bağlanmış olması, eriştiği her sistem için güvenilir olduğu anlamına gelir mi? Sıfır Güven mimarisi bu soruyu ele alır: Erişim kararları, kullanıcının bulunduğu ağın ötesinde kimliğini, cihazını, erişmek istediği kaynağı ve risk koşullarını dikkate almalıdır.

NIST SP 800-207, yalnızca ağ konumuna veya cihazın kuruma ait olmasına dayanarak örtük güven verilmemesini temel alır. Bu yaklaşım, korumayı kullanıcılar ve kaynaklar etrafında yeniden düzenler.

Kurumlar için asıl mesele, bu ilkeyi çalışanların işini aksatmadan uygulayabilmektir. Benim önerim, kritik bir iş akışından başlayarak erişim kararlarını görünür, gerekçeli ve denetlenebilir hâle getirmektir.

Ana bölüm

1. Koruyacağınız iş akışını tanımlayın

İlk adım, öncelikli bir uygulamayı ve bu uygulamanın bağımlılıklarını belirlemektir. Finans sistemi, yönetim arayüzü veya hassas belgelerin bulunduğu bir uygulama başlangıç için değerlendirilebilir.

Seçilen sistem için şu soruların yanıtını çıkarın:

Hangi kullanıcılar ve servis hesapları erişiyor?
Hangi veriler işleniyor?
Uygulama hangi diğer sistemlerle haberleşiyor?
Erişim kesilirse hangi iş süreci etkileniyor?
Erişim ihtiyacını kim onaylıyor?

Bu çalışma, eski bir yetkinin gerçekten gerekli olup olmadığını tartışmayı da kolaylaştırır. İş sahibiyle doğrulanmamış bir erişim listesi, politika tasarımı için eksik bir başlangıçtır.

2. Erişim kararını kimlik ve bağlamla ilişkilendirin

“Bu kullanıcı kim?” sorusuna ek olarak, hangi cihazdan ve hangi koşullarda eriştiğini değerlendirmek gerekir.

Örnek bir politika; belirli bir kullanıcı grubunun, yönetilen ve gerekli güvenlik koşullarını sağlayan cihazlardan yalnızca ilgili uygulamaya erişmesine izin verebilir. Risk durumuna göre ek doğrulama veya erişim kısıtlaması uygulanabilir.

Burada doğrulama sıklığı ve oturumun nasıl yeniden değerlendirileceği, kaynağın riskine ve teknik yeteneklere göre tasarlanmalıdır. Gereksiz doğrulama istemleri kullanıcı deneyimini zorlaştırabilir.

Politika kararını veren bileşenlerle erişimi uygulayan bileşenler arasındaki ilişki de açık olmalıdır. Kimlik sistemi, cihaz yönetimi ve güvenlik telemetrisi birlikte çalışabilmelidir.

3. Ayrıcalıklı erişimleri ve servis kimliklerini kapsayın

Çalışan hesaplarının yanında yöneticiler, otomasyonlar ve uygulamalar arası bağlantılar da kapsamda olmalıdır.

Özellikle şu alanları inceleyin:

Günlük kullanım ile yönetim işlemleri için ayrılmış hesaplar.
Göreve ve süreye göre sınırlandırılan ayrıcalıklar.
Sahibi ve kullanım amacı belli servis hesapları.
Güvenli saklanan, gerektiğinde döndürülebilen erişim sırları.
İşten ayrılma ve görev değişikliklerinde güncellenen yetkiler.

Örneğin, yalnızca rapor okuyan bir entegrasyonun veritabanında kayıt silme yetkisine sahip olması gerekmez. Yetki kapsamını iş ihtiyacına indirmek, bir hesabın kötüye kullanılması hâlinde oluşabilecek etkiyi sınırlar.

4. Segmentasyonu gerçek uygulama akışlarına göre tasarlayın

VLAN'lara ayrılmış bir ağda da gereğinden geniş erişimler bulunabilir. Mikrosegmentasyon çalışmasında uygulamalar arasındaki gerekli bağlantıların ve politika uygulama noktalarının belirlenmesi önemlidir.

Bir web uygulamasında ön uç, uygulama sunucusu ve veritabanı arasındaki izinleri ayrı değerlendirin. Yedekleme, izleme, DNS ve yönetim bağlantılarını da hesaba katın.

Önce akışları gözlemleyin, ardından uygulama sahibiyle gerekliliklerini doğrulayın. İzinleri daraltırken test ve geri dönüş adımları belirleyin. Eksik bağımlılık bilgisiyle devreye alınan sıkı bir kural, kritik hizmeti kesintiye uğratabilir.

5. ZTNA'yı mimarinin içindeki rolüyle değerlendirin

Sıfır Güven Ağ Erişimi (ZTNA), uygulamaya özel erişim sağlamak için kullanılabilir. VPN'den ZTNA'ya geçişin kapsamı belirlenirken uygulamanın protokolü, cihaz desteği, yönetici erişimi ve kullanıcı deneyimi incelenmelidir.

NIST SP 1800-35, farklı teknolojilerin bir araya getirildiği uygulama örnekleri sunar. Bu, kurumdaki kimlik, ağ, uç nokta ve izleme yeteneklerinin birlikte değerlendirilmesi için yararlı bir referanstır.

Eski uygulamalarda doğrudan entegrasyon mümkün olmayabilir. Bu durumlarda erişim ağ geçidi veya kontrollü yönetim sunucusu gibi seçenekler değerlendirilebilir. Kimlik sağlayıcıya ya da erişim bileşenlerine ulaşılamadığında ne olacağı ve acil erişimin nasıl denetleneceği de tasarlanmalıdır.

6. Bir tedarikçi erişimini baştan sona ele alın

Bir bakım firmasının yalnızca belirli bir sunucuda çalışması gerektiğini düşünelim.

Bu iş için örnek bir erişim tasarımı şöyle olabilir:

İsimli ve süreli bir hesap oluşturulur.
Güçlü kimlik doğrulama uygulanır.
Erişim, onaylanan hedef ve yönetim protokolüyle sınırlandırılır.
Oturum kayıtları ve ilgili güvenlik olayları izlenir.
Bakım tamamlandığında yetki kaldırılır.

Tedarikçinin diğer sunuculara veya yedekleme altyapısına erişmesi işin gereği değilse bu yollar kapalı tutulur. Böylece verilen yetki, bakım görevinin sınırlarıyla eşleşir.

7. Geçişi ölçülebilir bir pilotla yönetin

Kurumun ölçeğine göre uyarlanabilecek örnek bir başlangıç planı:

İlk 30 gün: Bir uygulamanın kullanıcılarını, bağımlılıklarını ve mevcut erişimlerini çıkarın.
31–60. günler: Küçük bir kullanıcı grubunda politikaları deneyin; destek taleplerini ve iş akışına etkisini izleyin.
61–90. günler: Gereksiz yetkileri kaldırın, istisnaları gözden geçirin ve genişleme kararını sonuçlara göre verin.

Bu süreler bir standart zorunluluğu değildir; planlama örneğidir. Başarıyı, kaldırılan gereksiz erişimler, sahibi belirlenen hesaplar, yetki iptal süresi ve kullanıcıların işlerini sorunsuz tamamlayabilmesi üzerinden değerlendirin.

Sonuç

Sıfır Güven mimarisine geçiş, erişimlerin neden verildiğini ve hangi koşullarda sürdürüleceğini açıklayabilen bir yapı kurmayı gerektirir. Kimlik, cihaz, uygulama ve izleme yetenekleri bu ortak amaç etrafında çalışmalıdır.

Başlamak için kritik bir uygulama seçin ve şu soruyu sorun: “Bu kaynağa bugün kimler, hangi gerekçeyle ve hangi koşullarda erişebiliyor?” Yanıtı doğruladıktan sonra gereksiz yetkileri daraltın ve seçtiğiniz politikayı küçük bir grupta deneyin.

İlk somut kazanım, o uygulamada hangi erişimlerin gerekli olduğunu bilmek ve bu sınırları uygulayabilmektir.

Cybersecurity

Cybersecurity

18 October 2026

5 min

Transitioning to a Zero Trust Architecture

Recent Posts

Transitioning to a Zero Trust Architecture

Categories

Tags

Technical Depth Strategic Vision