Kurumsal ağlar uzun süre bir kale gibi tasarlandı. Google'ın 2014'te yayımladığı BeyondCorp makalesi çevre modelini bu benzetmeyle anlatır: Surların dışındaki her şey tehlikeli sayılır, asma köprüyü geçen herkes…
Kurumsal ağlar uzun süre bir kale gibi tasarlandı. Google'ın 2014'te yayımladığı BeyondCorp makalesi çevre modelini bu benzetmeyle anlatır: Surların dışındaki her şey tehlikeli sayılır, asma köprüyü geçen herkes içerideki kaynaklara ulaşabilir. NIST SP 800-207 bu modelin iki zayıflığını yazar. Uzak çalışanlar ve bulut servisleriyle büyüyen bir kurumda tek ve kolayca tanımlanabilen bir çevre kalmadı; çevre bir kez aşıldığında da saldırganın ağ içindeki yanal hareketi (lateral movement) engellenmiyor. BeyondCorp makalesi ayrıca iç ağın public internet kadar tehlikeli kabul edilmesi gerektiğini savunur.
Zero Trust bu soruna erişim kararının yerini değiştirerek cevap verir. Ağ konumu tek başına güven gerekçesi sayılmaz, her kaynak erişimi ayrı ayrı değerlendirilir ve verilen güven oturum sürdükçe yeniden gözden geçirilir. Bu son kısım sektörde continuous authentication adıyla anılır, ama kaynaklar farklı terimler kullanır. NIST SP 800-63B-4 aynı uygulamaya session monitoring der ve bazen continuous authentication diye anıldığını not eder; SP 800-207 ise güvenin sürekli (continual) değerlendirilmesinden söz eder.
NIST'in Ağustos 2020'de yayımladığı SP 800-207, Zero Trust'ı sistem tasarımı ve operasyon için yol gösterici ilkeler bütünü olarak tanımlar. Zero Trust Architecture (ZTA) ise kurumun bu ilkelerle hazırladığı siber güvenlik planıdır. Dokümana göre amaç, ağın ele geçirilmiş kabul edildiği bir ortamda her istek için doğru ve en az yetkiye dayalı erişim kararı verirken belirsizliği azaltmaktır.
Doküman implicit trust zone kavramını havalimanı örneğiyle anlatır. Güvenlik kontrolünden geçen herkes biniş alanında güvenilir sayılır. Kontrol noktası kendi konumunun ötesinde politika uygulayamadığı için Zero Trust, karar ve uygulama noktalarını korunan kaynağa yaklaştırmayı amaçlar. Yedi temel ilke şöyledir:
NIST bu ilkelerin ideal hedef olduğunu ve her stratejide en saf haliyle uygulanamayabileceğini kabul eder.
SP 800-207, Policy Decision Point'i (PDP) ikiye ayırır. Policy Engine (PE), bir subject'in (erişim isteyen kullanıcı, servis ya da cihaz) kaynağa erişimi için son kararı verir ve kararı kayda geçirir. Policy Administrator (PA) bu kararı uygular: Policy Enforcement Point'lere (PEP) komut göndererek iletişim yolunu açar ya da kapatır, oturuma özgü token'ı üretir. PEP ise subject ile kaynak arasındaki bağlantıyı açıp izleyen, gerektiğinde sonlandıran bileşendir; dizüstü bilgisayardaki bir agent ile kaynağın önündeki gateway olarak ikiye bölünebilir. Bu bileşenler, uygulama trafiğini taşıyan data plane'den mantıksal olarak ayrılmış bir control plane üzerinden haberleşir. PE'nin girdileri arasında cihazın yama düzeyini bildiren continuous diagnostics and mitigation (CDM) sistemi ve threat intelligence beslemeleri de var.
PE'nin karar mantığı trust algorithm'dir. Criteria-based bir algoritma tanımlı bütün koşullar karşılandığında erişim verir. Score-based bir algoritma ise bir güven düzeyi hesaplayıp kaynağın eşik değeriyle karşılaştırır; eşiğin altında kalan istek reddedilir ya da yetkisi daraltılır, örneğin dosyada yazma izni verilmeden okuma izni verilir. Singular algoritma her isteği tek başına değerlendirirken contextual algoritma subject'in yakın geçmişine de bakar. NIST ideal olarak contextual algoritmayı önerir, çünkü ele geçirilmiş kimlik bilgileriyle yapılan olağan dışı erişimi yakalama ihtimali daha yüksektir; kurumun mevcut altyapısının buna her zaman izin vermeyebileceğini de not eder.
BeyondCorp bu bileşenlerin sahadaki karşılığını gösterir. Rory Ward ve Betsy Beyer'e göre kurumsal uygulamalara yalnızca kurumun yönettiği cihazlar erişebilir ve her cihaz, envanter kaydına bağlı bir cihaz sertifikasıyla tanınır. SSO sistemi kullanıcının iki faktörünü doğrulayıp kısa ömürlü token üretir. Bütün uygulamalar internete açık bir access proxy'nin arkasındadır; proxy içindeki Access Control Engine kullanıcının grubunu, cihaz kaydını ve çıkarımla belirlenen güven düzeyini her istekte değerlendirir. Makaledeki bir örnekte, hata takip sisteminde bir kaydı görüntülemek güncellemekten daha gevşek bir kurala bağlanabiliyor.
Çevre tabanlı modelde güven giriş anında kurulur ve oturum bitene kadar değişmez. SP 800-207 bu varsayıma karşı uyarır: Subject temel bir kimlik doğrulamayı geçti diye sonraki bütün isteklerin aynı derecede geçerli olduğu varsayılmamalıdır. Altıncı ilkenin açıklamasına göre izleme kullanıcı işlemleri boyunca sürer, politikanın tanımladığı durumlarda yeniden kimlik doğrulama ve yetkilendirme yapılabilir. Doküman bu durumlara dört örnek verir: süreye bağlı tetikleyiciler, yeni bir kaynağın istenmesi, kaynağın değiştirilmesi ve olağan dışı aktivite. PA da gerektiğinde oturumu yeniden doğrulama için bekletebilir ya da sonlandırabilir.
Temmuz 2025'te yayımlanan SP 800-63B-4 konuyu uygulama katmanında ele alır. Session monitoring'i, oturum sırasında olası sahtekarlığı tespit etmek için oturum özelliklerinin sürekli değerlendirilmesi olarak tanımlar. Değerlendirilebilecek özellikler arasında kullanım örüntüleri, kullanımın hızı ve zamanlaması, yazma ritmi gibi davranışsal biyometrik özellikler, cihaz ve tarayıcı bilgileri, coğrafi konum ve IP adresinin kötüye kullanımla bilinen bir bloğa ait olup olmadığı var. Sahtekarlık şüphesinde relying party'nin (RP), Identity Provider (IdP) ile eşgüdüm içinde oturumu yeniden doğrulaması, sonlandırması ya da destek ekibine haber vermesi önerilir.
Aynı doküman kullanıcıdan kimlik bilgilerini durmadan yeniden istemek yerine oturum yönetimini tercih eder, çünkü kötü kullanılabilirlik kullanıcıları kimlik doğrulamayı boşa çıkaran geçici çözümlere iter. CISA'nın Zero Trust Maturity Model v2.0'ı ise kimlik sütununun en ileri aşamasını, kimliğin ilk erişimden sonra da phishing-resistant MFA ile doğrulanmaya devam etmesi olarak tarif eder.
SP 800-63B-4'e göre oturum, kimlik doğrulama anında üretilen bir session secret ile sürer ve iki zaman aşımına bağlıdır. Overall timeout kimlik doğrulamadan sonraki toplam süreyi sınırlar, inactivity timeout hareketsiz kalan oturumu kapatır.
Continuous authentication'ı zayıflatabilecek bir ayrıntı token ömrüdür. Doküman, RP'nin bir OAuth access token'ın varlığını başka sinyal olmadan kullanıcının hala orada olduğuna kanıt saymamasını ister ve access ile refresh token'ların oturum bittikten çok sonra da geçerli kalabileceğini hatırlatır. Federasyonda IdP ve RP oturumları birbirinden bağımsızdır; IdP'de kapanan oturum RP'dekini kendiliğinden kapatmaz. SP 800-63C-4 bu boşluk için shared signaling'i tarif eder: IdP, hesap askıya alındığında, ele geçirildiğinden şüphelenildiğinde ya da authenticator'ları değiştiğinde RP'ye sinyal göndermelidir. Uygulama tarafında yapılacak iş, bu hesap olaylarını oturumları iptal eden bir işleme bağlamaktır. Bağlantı kurulmazsa Policy Engine'in "erişimi kes" kararı, uygulamada açık kalan oturuma ulaşmayabilir.
SP 800-207'nin saydığı tetikleyiciler ve yukarıdaki sinyaller bir kurum politikasına örneğin şöyle çevrilebilir; tepkinin seçimi kurumun risk değerlendirmesine bağlıdır.
| Tetikleyici | Örnek tepki |
|---|---|
| Oturumun toplam süresi ya da hareketsizlik süresi doldu | Oturum kapanır, kullanıcı yeniden kimlik doğrular |
| Daha hassas bir işlem istendi (ör. okumadan yazmaya geçiş) | Yeni yetkilendirme kararı, gerekirse daha güçlü authenticator ile step-up |
| CDM cihazda eksik yama bildirdi | Yetki daraltılır ya da cihaz, BeyondCorp'taki gibi bir düzeltme ağına (remediation network) alınır |
| Olağan dışı kullanım örüntüsü, konum ya da IP | Ek doğrulama ya da oturumun sonlandırılması |
| IdP hesabın ele geçirilmiş olabileceğini bildirdi | Uygulama oturumu kapanır, hesabın son işlemleri incelenir |
Oturum izlemede kullanılan sinyallerin çoğu kişisel veridir. SP 800-63B-4, bu özelliklerin işlenmesini gizlilik risk değerlendirmesine dahil etmeyi şart koşar. Türkiye'de faaliyet gösteren bir kurum için 6698 sayılı KVKK'nın 4. maddesindeki "işlendikleri amaçla bağlantılı, sınırlı ve ölçülü olma" ilkesine uymak zorunludur; hangi davranış sinyalinin toplanacağına bu ölçüye göre karar verilmelidir.
CISA'nın olgunluk modeli uygulamayı beş sütuna ayırır: Identity, Devices, Networks, Applications and Workloads ve Data.
CISA'nın modelinde dağınık kimlik depoları ileri aşamalarda birleştirilir. Kimlik doğrulamada model, ileri aşamada FIDO2 ya da PIV tabanlı parolasız, phishing-resistant MFA'ya geçişi tarif eder. SP 800-63B-4'e göre senkronize edilebilen (syncable) authenticator'lar özel anahtarın dışa aktarılabilmesini gerektirdiği için en yüksek authentication assurance level olan AAL3'te kullanılamaz. Erişim yönetiminde geleneksel aşama süresiz erişim ve periyodik gözden geçirmedir, en ileri aşama ise just-in-time ve just-enough erişimdir. SP 800-207 geliştirici ve sistem yöneticisi gibi yetkili hesaplara rol atanırken ek inceleme ister; servis hesapları da subject sayılır ve envantere girer.
Kurum, kendi yönettiği cihazları ve bunların güncel güvenlik durumunu ayırt edebilmelidir. SP 800-207 bu ayrımın kurumun verdiği credential'larla yapılmasını, MAC adresi gibi taklit edilebilen bilgilere dayanılmamasını ister. BeyondCorp'taki cihaz sertifikası cihazı tanımlar ama tek başına yetki vermez; cihaz hakkındaki bilgilere ulaşmak için anahtar görevi görür. Yönetilmeyen ya da bilinen açığı olan cihazların bağlantıları tamamen reddedilebilir.
SP 800-207'ye göre kurumsal kaynaklara bir PEP'ten geçmeden ulaşılamamalıdır. Uzaktaki bir kullanıcı da public cloud'daki bir servise ulaşmak için önce VPN ile kurum ağına dönmek zorunda kalmamalıdır. CISA'nın ağ sütununda en ileri aşama, uygulama profillerine göre kurulmuş micro-segmentation'dır.
Servisler arası trafik için NIST SP 800-207A, IP adresi yerine servis kimliğine dayanan identity-tier politikaları tarif eder. Dokümandaki örnekte "192.168.10.0/24 subnet'inden 10.0.0.31'e gelen çağrılara izin ver" network-tier, "sipariş işleyen front-end servisi envanter back-end servisiyle konuşabilir" identity-tier politikadır. 800-207A'ya göre her servis kısa ömürlü ve kriptografik olarak doğrulanabilen bir kimlik sunmalıdır. Kimliği her istekte doğrulamak uygulamanın yanıt süresini çok aksatacağı için doğrulama bağlantı kurulurken mTLS ile yapılır ve bağlantılar uzun süre açık tutulmaz. Kullanıcı kimliği için doküman, dış kullanıcıların kısa ömürlü token'larının her adımda doğrulanabilen bir JWT'ye çevrilmesini önerir.
Istio service mesh kullanan bir Kubernetes ortamında ilk kaynak orders namespace'inde mTLS'i zorunlu kılar, ikincisi varsayılan reddi kurar, üçüncüsü yalnızca order-frontend servis hesabının inventory servisindeki rezervasyon yollarına erişmesine izin verir:
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: orders
spec:
mtls:
mode: STRICT
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
namespace: orders
spec:
{}
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
name: inventory-from-order-frontend
namespace: orders
spec:
selector:
matchLabels:
app: inventory
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/orders/sa/order-frontend"]
to:
- operation:
methods: ["GET", "POST"]
paths: ["/reservations*"]Istio dokümanına göre STRICT modda istemcinin sertifika sunduğu bir mTLS tüneli zorunludur. principals alanı kimliği peer sertifikasından türettiği için mTLS gerektirir. Bir iş yükü için ALLOW politikası varsa ve istek hiçbiriyle eşleşmiyorsa istek reddedilir; kuralı olmayan allow-nothing politikası varsayılan reddi bu yolla kurar. Bu ret, her iş yükü için açık bir ALLOW politikası tanımlanana kadar order-frontend dahil namespace'teki bütün iş yüklerine gelen trafiği kapsar. Düz metin ve mTLS trafiğini birlikte kabul eden PERMISSIVE moddan başlayıp trafik doğrulandıktan sonra STRICT'e geçmek, aşağıda anlatılan "önce gözlem, sonra zorlama" yaklaşımının ağ katmanındaki karşılığıdır.
CISA'nın uygulama sütununda erişim kararı başlangıç aşamasında istek başına bağlamsal bilgiye ve bir son kullanma koşuluna dayanır; en ileri aşamada erişim gerçek zamanlı risk analitiğiyle sürekli yetkilendirilir. Kurumsal uygulamalarda bu karar bir API gateway ya da reverse proxy'de uygulanabilir; BeyondCorp'taki access proxy de aynı rolü üstlenir. Bunun için arkasındaki API'lerin sözleşmesi belli olmalıdır; bu disiplin API-First tasarım yazımızın konusuydu.
Veri sütununda CISA, statik erişim kontrollerinden kimliği ve cihaz riskini birlikte değerlendiren, gerektiğinde süreyle sınırlı otomatik kontrollere geçişi tarif eder. İleri aşamada anahtarlar kodun içine gömülmez ve düzenli olarak döndürülür. Anahtarların kimin kontrolünde olduğu ve değiştirilemez erişim kayıtları Hybrid Cloud mimarilerinde veri egemenliği yazısında ayrıntılı olarak ele alındı.
Yedinci ilke gereği toplanan log ve trafik verisi politikaya geri döner. SP 800-207 burada bir riski de hatırlatır: Saklanan trafik verisi saldırgana mimariyi ve hedef alınabilecek varlıkları, erişim politikalarını yöneten araç ise ele geçirmeye en değer hesapları gösterebilir. Bu yüzden ikisine de yalnızca belirlenmiş yönetici hesaplarından erişilmelidir.
SP 800-207'ye göre çoğu kurum belirsiz bir süre Zero Trust ile çevre tabanlı mimarinin birlikte çalıştığı hibrit bir düzende kalacak ve geçiş her seferinde bir iş süreci ele alınarak ilerleyebilir. Başlangıç koşulu envanterdir. NIST'in tarif ettiği döngü şöyle:
CISA'nın modeli aynı geçişi Traditional başlangıç noktasından Initial, Advanced ve Optimal aşamalarına uzanan bir ölçekle izler. Model her sütunun, sütunlar arası koordinasyon gerekene kadar kendi hızında ilerleyebileceğini söyler. Pratik bir başlangıç, beş sütunun her biri için kurumun bugünkü aşamasını işaretlemek ve en geride kalan sütunu ilk aday sürecin ihtiyacıyla eşleştirmektir.
Google'ın geçişi de aşamalıydı. BeyondCorp makalesine göre uygulamalar önce ayrıcalıklı ağdan ve VPN'den, sonra access proxy'den de, en sonunda yalnızca access proxy üzerinden erişilebilir oldu. Kullanıcı cihazlarındaki bir trafik izleyici önce logging modunda yeni kurallara uymayan trafiği kaydetti, ardından enforcement modunda bu trafiği düşürdü. Eski ve yeni yolun bir süre yan yana çalıştığı bu yaklaşım, uygulama modernizasyonundaki Strangler Fig Pattern ile aynı mantığı taşır.
Zero Trust erişim kararını ağın kenarından Policy Engine'e taşıdığında bu bileşen kurum için kritik bir sisteme dönüşür. NIST, PE, PA ve PEP'lerin her iş sürecinin anahtar bileşeni haline geldiğini ve bunlara ulaşılamamasının iş akışını doğrudan etkileyeceğini yazar. Continuous authentication'da da her ek sinyal güven kararını keskinleştirebilir, ama kullanılabilirlik ve gizlilik yükünü artırır. Tasarım aşamasında iki soru birlikte cevaplanmalıdır: Hangi sinyal hangi erişim kararını değiştirecek ve karar noktasına ulaşılamadığında iş süreci nasıl davranacak.