Zero Trust: Pazarlama mı, Mimari mi?

NIST SP 800-207'nin PE, PA ve PEP modeliyle Zero Trust'ı bir ürün değil mimari olarak ele alıyor; NAC, VLAN, firewall ve VPN'in hangi gereksinimleri karşıladığını, ZTNA'nın neyi eklediğini ve neyi eklemediğini, olgunluğu CISA ZTMM v2.0 ile nasıl ölçeceğinizi gösteriyor.

Standartlar ve çerçeveler NIST SP 800-207 (Ağustos 2020); NIST SP 1800-35 (Haziran 2025); CISA Zero Trust Maturity Model v2.0 (Nisan 2023, CISA tarafından arşivlenmiş içerik olarak işaretli)
Resmi dokümana göre
Cisco Identity Services Engine Administrator Guide, Release 3.3 (Compliance; Segmentation, TrustSec)
Resmi dokümana göre
Fortinet FortiOS 7.6.4 Administration Guide (Zero Trust Network Access introduction)
Resmi dokümana göre
HPE Aruba Networking AOS 10 tasarım belgesi, User-Based Tunneling (rol atama ve gateway uygulaması)
Resmi dokümana göre
Huawei Info-Finder, What Is Free Mobility? (iMaster NCE-Campus denetleyici rolü)
Resmi dokümana göre

Ağ segmentasyonu ve DMZ yazısı “hiçbir segmente varsayılan olarak güvenme” fikrini ayrı bir yazıya bırakmıştı. Bu fikrin adı Zero Trust ve bugün neredeyse her güvenlik ürününün tanıtımında geçiyor. Sahada en sık duyulan cümle de şu: “ZTNA aldık, artık Zero Trust’ız.”

Bu yazı o cümleyi sınamak için bir ölçü veriyor. Ölçü NIST SP 800-207’nin mimarisi: politika motoru (PE), politika yöneticisi (PA) ve politika uygulama noktası (PEP). Olgunluğu ölçmek için ise ayrı bir çerçeve kullanılıyor: CISA’nın Zero Trust Maturity Model’i (ZTMM) v2.0. Yazıda yapılandırma örneği yok; amaç, mevcut kontrollerin ve satın alınacak ürünlerin hangi işlevi gördüğünü ayırmak.

Zero Trust bir ürün değil, bir dizi ilke

NIST SP 800-207 (Ağustos 2020) Zero Trust’ı, ağın zaten ele geçirilmiş olabileceği varsayımıyla her erişim isteğinde en az yetkiyle ve olabildiğince kesin karar vermeyi amaçlayan kavramlar bütünü olarak tanımlar. Belge bir ürün tarif etmez. Mimarisi mantıksal bileşenlerden oluşur ve bu bileşenler farklı ürünlerle kurulabilir. NIST’in uygulama rehberi SP 1800-35 (Haziran 2025), 24 üreticiyle 19 farklı örnek uygulama gösterir.

NIST’in ilkelerinden tasarım kararlarını en çok etkileyenler şunlar:

  • Ağdaki konum güven vermez. Kurum ağının içinden gelen istek, dışarıdan gelenle aynı güvenlik koşullarını sağlamalıdır.
  • Erişim kaynak başına ve oturum başına verilir. Bir kaynağa yetkilendirilmek başka bir kaynağa erişimi kendiliğinden açmaz.
  • Politika dinamiktir. Kararda kullanıcının kimliği, uygulama ve isteği yapan cihazın durumu kullanılır; davranış ve ortam bilgisi de eklenebilir.
  • Hiçbir cihaz doğası gereği güvenilir değildir. Kurum, cihazlarının bütünlüğünü ve güvenlik durumunu izler; durumu bozuk cihaza farklı davranabilir.
  • Kimlik doğrulama ve yetkilendirme süreklidir. Erişim verildikten sonra da politika gerektirdiğinde, örneğin yeni bir kaynak istendiğinde ya da anormal davranış görüldüğünde, yeniden değerlendirilir.
  • Kurum durumu ölçer. Cihazlardan, ağ trafiğinden ve erişim isteklerinden toplanan veri politikayı iyileştirmekte kullanılır.

NIST bu ilkelerin ideal hedef olduğunu ve her stratejide en saf biçimiyle uygulanamayabileceğini açıkça belirtir.

Örtük güven alanı. NIST’in temel kavramlarından biri budur: son kontrol noktasından geçen her şeyin aynı düzeyde güvenilir sayıldığı alan. NIST’in örneği havalimanıdır: Güvenlik kontrolünden geçen herkes bekleme salonunda serbestçe dolaşır. Zero Trust, kontrol noktasını kaynağa yaklaştırarak bu alanı olabildiğince küçültmeyi hedefler. Bu yazıdaki bütün değerlendirmeler aynı soruya dayanır: Kontrolden sonra örtük güven alanı ne kadar büyük?

Mimari: PE, PA ve PEP

NIST, erişim kararını iki mantıksal bileşene böler ve kararın uygulandığı yeri ayrı tutar:

  • Policy Engine (PE): Bir öznenin bir kaynağa erişip erişemeyeceğine son kararı verir. Kurum politikasını ve dış kaynaklardan gelen veriyi bir güven algoritmasında kullanır; kararı onaylar, reddeder ya da geri alır ve kayda geçirir.
  • Policy Administrator (PA): PE’nin kararını uygular. Özne ile kaynak arasındaki iletişim yolunu PEP’lere komut vererek açar ya da kapatır; gerekirse oturuma özel kimlik bilgisi ya da token üretir.
  • Policy Enforcement Point (PEP): Bağlantıyı açar, izler ve sonlandırır. İstemcideki bir ajan ile kaynağın önündeki bir gateway’e bölünebilir ya da tek bir portal olabilir. PEP’in arkası güven alanıdır.

PE ve PA birlikte, istek ve kararların taşındığı kontrol düzlemini oluşturur. Uygulama verisi ayrı bir veri düzleminde akar. PE’nin kararını besleyen veri kaynakları da mimarinin parçasıdır: kimlik yönetimi, PKI, cihaz durumunu izleyen sistemler (NIST bunlara CDM der), tehdit istihbaratı, ağ ve sistem logları, SIEM ve erişim politikaları.

Veri kaynakları (PE'nin girdileri) kimlik · PKI · cihaz durumu (CDM) · tehdit istihbaratı · loglar ve SIEM · erişim politikası KONTROL DÜZLEMİ Policy Engine (PE) 3 · izin · ret · geri al Policy Admin. (PA) yolu açar / kapatır karar VERİ DÜZLEMİ Özne kullanıcı + cihaz PEP ajan · gateway · port 2 isteği iletir 4 PEP'i ayarlar 1 erişim isteği güven alanı Kaynak uygulama · veri 5 oturum Örnek PEP: switch portu (802.1X), firewall, ZTNA gateway. PEP'in arkası güven alanıdır; Zero Trust bu alanı olabildiğince küçültmeyi hedefler.
PE karar verir, PA kararı PEP'e uygulatır, PEP bağlantıyı açar ya da keser. Karar kontrol düzleminde, uygulama verisi veri düzleminde taşınır.

NIST bu bileşenlerin ayrı ürünler olması gerekmediğini de belirtir. Tek bir sistem birden çok bileşenin işini yapabilir; piyasadaki bazı ürünler PE ile PA’yı tek serviste birleştirir. Bir ürünü değerlendirirken sorulacak soru bu yüzden “Zero Trust ürünü mü?” değil, “Hangi bileşenin işini görüyor ve hangi veriyi kullanıyor?“dur.

Üç yaklaşım. NIST’e göre bir mimari, ağırlığı üç yaklaşımdan birine verebilir: genişletilmiş kimlik yönetimi, mikro segmentasyon ya da ağ altyapısı ve yazılım tanımlı çevre (SDP). Mikro segmentasyon yaklaşımında akıllı switch’ler, router’lar, yeni nesil firewall’lar ya da özel gateway’ler PEP görevi görür. NIST, tam bir çözümün üç yaklaşımın öğelerini de içereceğini belirtir.

Mevcut kontroller neyi karşılıyor?

Çoğu kurumda Zero Trust’ın parçaları zaten çalışıyor, ama birbirinden kopuk. Aşağıdaki değerlendirme, sitenin öğretici kampüs topolojisi üzerinden yapılıyor: kullanıcılar VLAN 20’de (10.0.20.0/24), sunucular VLAN 30’da (10.0.30.0/24), VLAN’lar arası yönlendirme core switch’te, firewall internet sınırında.

NAC (802.1X, RADIUS, CoA). NAC yazısındaki yapı, NIST modelinin ağ kenarındaki bir örneğidir: RADIUS sunucusu karar verir, switch portu uygular, CoA ile karar sonradan değiştirilebilir.

  • Karşılar: Bağlanan kullanıcının ve cihazın kimliği doğrulanır; posture kontrolü yapılabilir; sonuç dinamik VLAN, ACL ya da rol olarak uygulanır.
  • Karşılamaz: Karar ağa bağlanma anı içindir, tek tek kaynaklar için değil. Doğrulanan kullanıcı VLAN 20’ye alındıktan sonra o VLAN’ın erişebildiği her şeye erişir. Cihaz durumu da sürekli izlenmeyebilir. Örneğin Cisco ISE 3.3’te posture lease süresince ISE son bilinen durumu kullanır ve cihazı yeniden kontrol etmez. Lease bittiğinde de yeniden doğrulamayı kendiliğinden başlatmaz; posture, cihaz yeniden kimlik doğruladığında çalışır.

VLAN. Yayın alanını ve adres planını ayırır, ama kimliğe bakmaz. Aynı VLAN’daki iki cihaz arasında varsayılan olarak hiçbir kontrol yoktur. VLAN’ın tek başına neden güvenlik olmadığı segmentasyon yazısında anlatıldı. CISA ZTMM’de büyük çevreler ve segment içinde neredeyse hiç kısıtlama olmaması, Networks sütununun Traditional aşamasının tanımıdır.

Firewall ve zone politikası. Bölgeler arasındaki akış için iyi bir PEP’tir; kurallar dar yazılmışsa segmentler arasında en az yetkiyi uygular. Ancak kurallar IP adresine dayanıyorsa karar yine konuma göre verilir. Firewall kimlik ya da etiket bilgisi almıyorsa “bu istek kimden ve hangi durumdaki cihazdan geliyor?” sorusunu soramaz. Ayrıca yalnızca üzerinden geçen trafiği görür. Bu topolojide VLAN 20 ile VLAN 30 arasındaki trafik core’da yönlendirildiği için sınırdaki firewall’a hiç uğramaz.

Uzaktan erişim VPN’i. VPN yazısındaki tünel, kullanıcıyı bağlantı kurulurken doğrular; MFA da eklenebilir. Bu senaryoda ise tünel açıldıktan sonra kullanıcıya 10.0.0.0/16’nın tamamı açılıyor. Bu, örtük güven alanını kullanıcının dizüstü bilgisayarına kadar genişletmektir. Bu VPN’in kaçınılmaz bir sonucu değildir: VPN mimarilerinde de kullanıcı ya da grup bazlı ACL, MFA, cihaz durumu kontrolü ve kaynak bazlı erişim politikaları uygulanabilir. ZTMM’nin Networks sütunu da birden çok servisi tek bir toplu VPN tüneliyle taşımayı Traditional aşamada sayar; uzaktan erişimde geniş bir ağ aralığı açmak aynı mantıktır.

1 · GENİŞ YETKİLİ UZAKTAN ERİŞİM VPN'İ (BU SENARYO) Kullanıcı + dizüstü VPN gateway girişte doğrular tünel örtük güven alanı: 10.0.0.0/16 Web uygulaması 10.0.30.40 Dosya sunucusu 10.0.30.50 DNS/DHCP 10.0.30.11 RADIUS 10.0.30.20 Bu senaryoda tünel 10.0.0.0/16'nın tamamını açıyor; kontrol yalnızca girişte. 2 · ZTNA: UYGULAMA BAZINDA ERİŞİM Kullanıcı kimlik + cihaz ZTNA gateway PEP, uygulama başına PE / politika rol + cihaz etiketi Web uygulaması 10.0.30.40 Dosya sunucusu 10.0.30.50 izin ret Yayımlanmayan sunucular (DNS/DHCP, RADIUS) görünmez. Erişim ağ aralığına değil uygulamaya verilir. Politika "herkes → her uygulama" ise fark kaybolur.
Bu senaryodaki geniş yetkili VPN'de kontrol tünel girişindedir ve tünelin açtığı 10.0.0.0/16 örtük güven alanıdır; VPN'lerde de grup bazlı ACL, MFA ve cihaz durumu kontrolü uygulanabilir. ZTNA'da karar her uygulama için verilir; kazanç politikanın ne kadar dar yazıldığına bağlıdır.

ZTNA neyi ekler, neyi eklemez?

ZTNA, erişimi ağ aralığı yerine uygulama düzeyinde veren bir PEP yaklaşımıdır. Fortinet’in FortiOS 7.6.4 belgesi bunu somut olarak tarif eder: FortiClient EMS, cihazdan kullanıcı ve güvenlik durumu bilgisini toplar, kurallara göre cihazı etiketler ve bir istemci sertifikası verir. FortiGate’teki uygulama gateway’i, istemciyi sertifikasıyla tanır ve ZTNA politikasındaki etiketlere göre tek tek uygulamalara erişim verir. NIST’in diliyle gateway bir PEP’tir; EMS ve politika ise karara veri sağlar.

ZTNA’nın kattığı değer gerçektir: kullanıcı yalnızca izin verilen uygulamayı görür, cihaz durumu kararın parçası olur ve kurum ağına toplu bir tünel açılmaz. Ama ZTNA satın almak tek başına Zero Trust mimarisi kurmak anlamına gelmez:

  • Politika kötü yazılırsa kazanç kaybolur. “Bütün kullanıcılar → bütün uygulamalar” kuralı, VPN’in taşıma yöntemi değişmiş hâlidir. En az yetki, ürünle değil, kimin neye erişmesi gerektiğini bilen bir politikayla gelir.
  • Kampüsün içini kapsamayabilir. ZTNA çoğunlukla kullanıcıdan uygulamaya giden akışı korur. Sunucudan sunucuya trafik, ajan kurulamayan yazıcı ve IoT cihazları ya da VLAN içindeki yatay hareket ayrı kontroller ister.
  • Kimlik ve envanter sorununu çözmez. Hesap yaşam döngüsü, kimlik avına dayanıklı MFA, varlık envanteri ve akış haritası ürünün değil kurumun işidir. NIST de ciddi bir geçişten önce varlıkların, öznelerin, iş süreçlerinin ve trafik akışlarının kataloglanmasını önkoşul sayar.
  • Yeni bir kritik bileşen ekler. NIST’e göre PE ve PA’nın yönetimi ele geçirilirse ya da bunlara erişim kesilirse kurumun erişimi etkilenir. Bu risk eski VPN’lerde de vardır, ama ortadan kalkmaz.

Karar bileşeni erişilemezse. Yeni erişim istekleri ile kurulmuş oturumlar aynı şekilde davranmak zorunda değildir. PE ya da PA’ya ulaşılamadığında yeni oturumların kabul ya da reddedilmesi, mevcut oturumların sürmesi ya da kesilmesi; PEP’in önceki kararları önbellekte tutup tutmadığına, politikanın geçerlilik süresine ve üreticinin yapılandırmasına bağlıdır. Bu yüzden fail-open ya da fail-closed davranışı, karar bileşenlerinin yüksek erişilebilirliği ve acil durum erişim politikası tasarımdan önce kararlaştırılmalıdır. Bu, CIA ve AAA yazısındaki fail-open ve fail-closed tartışmasının Zero Trust’taki karşılığıdır.

Üreticiler: hangi işlevi görüyor?

Dört üreticinin çözümleri burada marka olarak değil, NIST’teki işlevlerine göre ele alınıyor. Grup tabanlı segmentasyonun ayrıntısı segmentasyon yazısındaydı; burada yalnızca karar ve uygulamanın nerede durduğu ele alınıyor.

  • Karar ve politikanın dağıtılması (PE/PA işlevi): Cisco ISE 3.3, kimlik doğrulama sonucunda kullanıcıya ya da cihaza bir güvenlik grubu etiketi (SGT) atar ve posture uyumluluğunu yönetir. HPE Aruba Networking’in AOS 10 tasarım belgesinde rol, RADIUS sunucusu (Aruba-User-Role özniteliği) ya da Central NAC tarafından atanır; ClearPass ile roller switch’e indirilebilir. Huawei’de iMaster NCE-Campus, Free Mobility çözümünde kullanıcıları doğrulayan ve politikayı ağ cihazlarına dağıtan denetleyicidir. Fortinet’te FortiClient EMS cihaz durumunu etiketlere çevirir; karar FortiGate’teki ZTNA politikasında bu etiketlerle verilir.
  • Uygulama (PEP işlevi): Erişim switch’leri ve kablosuz altyapı 802.1X ile bağlanmayı, SGACL ya da rol politikasıyla akışları denetler. Aruba’nın belgesi önemli bir farkı açıkça yazar: switch’ler yalnızca durumsuz (stateless) ACL uygular, user-based tunneling ile gateway’e taşınan trafikte ise gateway durumlu ve uygulama farkındalıklı bir firewall çalıştırır. Huawei’de kullanıcı haklarını switch’ler ve firewall’lar uygular. FortiGate’in uygulama gateway’i HTTPS, TCP yönlendirme ve SSH erişim proxy’si olarak çalışır.

Bu işlevlerin hiçbiri tek başına NIST’in bütün ilkelerini ya da ZTMM’nin bütün sütunlarını karşılamaz. NIST’in uyardığı bir risk de burada önem kazanır: Kararı besleyen sistemler ortak ve açık bir standartla bilgi alışverişi yapmıyorsa kurum birkaç sağlayıcıya bağımlı kalabilir; politika kurallarını bir biçimden ötekine taşımak uzun bir geçiş gerektirebilir. Bu yüzden bir ürünün mevcut bileşenlerle RADIUS, SAML ve sertifika gibi açık arayüzler üzerinden konuşup konuşamadığı sorulmalıdır.

Olgunluğu ölçmek: CISA ZTMM v2.0

NIST mimariyi tanımlar; CISA’nın Zero Trust Maturity Model’i ise kurumun nerede olduğunu ölçmek için ayrı bir çerçevedir. ZTMM v2.0 Nisan 2023’te yayımlandı ve ABD federal yönergesi OMB M-22-09 ile uyumlandı. CISA bu sayfayı bugün arşivlenmiş içerik olarak işaretliyor; bu yüzden model, yürürlükteki bir zorunluluk olarak değil, bir değerlendirme aracı olarak kullanılmalıdır.

Model beş sütundan oluşur: Identity, Devices, Networks, Applications and Workloads ve Data. Bunları üç ortak yetenek keser: görünürlük ve analitik, otomasyon ve orkestrasyon, yönetişim. Her sütunda dört aşama vardır: Traditional, Initial, Advanced ve Optimal. Kısa örnekler:

  • Identity, kimlik doğrulama: Traditional aşamada parola ya da statik erişimli MFA vardır. Advanced aşamada kimlik avına dayanıklı MFA’ya geçilmeye başlanır. Optimal aşamada kimlik yalnızca erişim anında değil, sürekli doğrulanır.
  • Devices, kaynak erişimi: Traditional aşamada kaynağa erişen cihazdan görünürlük istenmez. Initial aşamada bazı cihazların özelliklerini bildirmesi ve bunun erişim onayında kullanılması beklenir. Advanced aşamada ilk erişim doğrulanmış cihaz bilgisine dayanır.
  • Networks, segmentasyon: Traditional aşamada büyük çevreler, segment içinde az kısıtlama ve toplu VPN tünelleri vardır. Initial aşamada kritik iş yükleri yalıtılır ve bağlantı en az işlev ilkesine göre daraltılır.

Değerlendirme her sütun için ayrı yapılır. Bir kurum Networks’te Initial, Identity’de Traditional olabilir. ZTNA almak Networks ve Applications sütunlarında ilerleme sağlayabilir; Identity ya da Data sütununu tek başına değiştirmez.

Geçiş: bir iş süreciyle başlamak

NIST, Zero Trust’a geçişi bir altyapı değişimi değil, bir yolculuk olarak tanımlar ve kurumların belirsiz bir süre karma bir mimariyle çalışacağını kabul eder. Önerdiği yol, geçişi her seferinde bir iş sürecinde yapmaktır. Kampüs topolojisinde bu şöyle sıralanabilir:

  1. Bir kritik uygulama seçmek ve akışlarını çıkarmak: Kim, hangi cihazdan, hangi porta erişiyor?
  2. Kimliği güçlendirmek: Bu uygulamaya erişen hesaplar için MFA, yöneticiler için kimlik avına dayanıklı MFA.
  3. Uygulamanın önüne kimlik ve cihaz bilgisi kullanan bir PEP koymak: Bu, kimlik bilgisi alan bir firewall kuralı ya da bir ZTNA gateway’i olabilir. Ardından bu uygulama için geniş VPN ve VLAN erişimini kaldırmak.
  4. Uygulama segmentinde yatay erişimi daraltmak, logları SIEM’e almak ve aşamayı ZTMM’ye göre yeniden değerlendirmek.

802.1X ve VLAN’lar bu süreçte kaldırılmaz. Bunlar ağa bağlanma anının kontrolü olarak kalır; Zero Trust, bu kontrolün ardından kalan örtük güven alanını küçültür.

Kendinizi deneyin

Alıştırma 1: Bir teklif “ZTNA ürünümüz kurumunuzu Zero Trust’a taşır” diyor. Ürünün özellikleri şunlar: (1) Dizüstü bilgisayardaki ajan, bağlantı sırasında disk şifrelemesini ve antivirüs durumunu kontrol ediyor. (2) Kullanıcılar kurumun kimlik sağlayıcısına SAML ve MFA ile giriş yapıyor. (3) Bir gateway üç web uygulamasını yayımlıyor. (4) Varsayılan politika “bütün kullanıcılar → bütün yayımlanan uygulamalar”. (5) Cihaz durumu yalnızca oturum açılırken kontrol ediliyor. (6) Loglar ürünün kendi panelinde kalıyor; SIEM entegrasyonu yok. NIST’in bileşenlerine ve ilkelerine göre değerlendirin.

Cevap ve açıklama
  • Karşılananlar: Gateway (3) uygulama başına çalışan bir PEP’tir. Kimlik (2) ve cihaz durumu (1), PE’nin kullandığı verilerdir. Bu, VPN ile bir ağ aralığı açmaya göre örtük güven alanını küçültür.
  • En az yetki yok: (4) “bütün kullanıcılar → bütün uygulamalar” kuralı, kaynak başına ve en az yetkiyle erişim ilkesini boşa çıkarır. Hangi rolün hangi uygulamaya erişeceği tanımlanmadan ürün, VPN’in taşıma yöntemi değişmiş hâlidir.
  • Değerlendirme sürekli değil: (5) Cihaz durumu yalnızca girişte kontrol ediliyor. NIST, erişim verildikten sonra da politikaya göre yeniden değerlendirme bekler; oturum sırasında antivirüsü kapanan cihaz erişimini korur.
  • Veri toplama eksik: (6) Loglar politikayı iyileştirmek ve öteki kontrollerle ilişkilendirmek için kullanılmıyor.
  • Kapsam dar: Yalnızca üç web uygulaması korunuyor. Geri kalan uygulamalar, sunucular arası trafik ve kampüs içindeki erişim aynı kalıyor.
  • Sonuç: Ürün bir PEP ve PE’ye veri sağlayan parçalar getiriyor; bir mimari getirmiyor. Teklif ancak rol bazlı politika, oturum içinde yeniden değerlendirme, log entegrasyonu ve kalan akışlar için bir plan ile değerlendirilebilir.

Alıştırma 2: Kampüs topolojisinde kullanıcılar 802.1X ile doğrulanıp VLAN 20’ye (10.0.20.0/24) alınıyor. Sunucular VLAN 30’da (10.0.30.0/24); aralarında RADIUS (10.0.30.20) ve DNS/DHCP (10.0.30.11) sunucuları var. VLAN’lar arası yönlendirme core switch’te yapılıyor ve core’da ACL yok. Firewall yalnızca internet sınırında. Uzaktan çalışanlar IPsec VPN ile bağlanıyor ve 10.0.0.0/16’ya erişiyor. (a) Örtük güven alanları nerede? (b) ZTMM’nin Networks sütununda segmentasyon hangi aşamada? (c) İlk iki adım ne olmalı?

Cevap ve açıklama
  • (a) Üç örtük güven alanı var. Birincisi VLAN 20’nin kendisi: 802.1X geçildikten sonra VLAN içindeki cihazlar arasında kontrol yok. İkincisi VLAN 20’den VLAN 30’a giden yol: Trafik core’da ACL olmadan yönlendirildiği ve firewall’a uğramadığı için ağ katmanında doğrulanmış kullanıcıları sunucu portlarından ayıran bir kontrol yok. Erişimi yalnızca sunucuların kendi host firewall’ları kısıtlayabilir. Üçüncüsü VPN: Bu senaryodaki politika tünel açıldıktan sonra 10.0.0.0/16’nın tamamını açıyor.
  • (b) Traditional. Büyük segmentler ve segment içinde neredeyse hiç kısıtlama olmaması, ZTMM’nin bu aşama için verdiği tanımla örtüşür; VPN’in bütün ağ aralığını açması da toplu tünel mantığıdır. 802.1X olması bu sonucu değiştirmez, çünkü kontrol yalnızca ağa bağlanma anında yapılıyor.
  • (c) İlk adım: Kullanıcı VLAN’ları ile sunucu VLAN’ı arasına bir PEP koymak. Sunucu VLAN’ına giden trafik firewall üzerinden yönlendirilebilir ya da core’da NAC’ın atadığı rol veya gruba dayalı bir politika uygulanabilir. Kurallar akış haritasına göre yazılır: Kullanıcıların DNS ve DHCP sunucusuna yalnızca ilgili portlardan erişmesi gerekir; RADIUS sunucusuyla konuşması gerekenler kullanıcılar değil, switch’ler ve kablosuz controller’lardır.
  • (c) İkinci adım: VPN’deki 10.0.0.0/16 erişimini daraltmak. Kullanıcı gruplarına yalnızca gereken uygulamalar açılır; bu, uygulama bazlı bir ZTNA gateway’iyle ya da grup başına dar VPN politikalarıyla yapılabilir. Bu erişim için MFA zorunlu tutulur.
  • 802.1X kalır: 802.1X kaldırılmaz; ağa kimin bağlandığını belirleyen kontrol olarak kalır. Değişen, bağlandıktan sonra erişilebilen alanın küçülmesidir.

Kaynaklar

#zero-trust#ztna#nac#segmentasyon#nist

Kemal Keleş

Network & Security Engineer · CCNA · HCSA · NSE 3

Switching, routing, firewall ve kampüs ağlarında presales ve saha deneyimimi, teknik araştırmalarımı ve üretici dokümantasyonlarını bir araya getirerek pratik, üreticiden bağımsız içerikler hazırlıyorum.

Aynı konudan