Zero Trust Ağ Mimarisi Diyagramı Şablonu

“Zero trust” etiketli pek çok diyagram aslında yeni başlık takılmış bir çevre (perimeter) diyagramıdır: kenarda bir güvenlik duvarı, bir DMZ ve güvenilen bir iç ağ. İşe yarayan bir zero trust mimari diyagramı üç soruyu tek bakışta yanıtlar: Her erişim kararı nerede veriliyor, bu karara hangi sinyaller giriyor ve karar nerede uygulanıyor? Resim bu soruları yanıtlayamıyorsa güveni değil, ağdaki konumu anlatıyordur.

Bu yazıda NIST SP 800-207’deki mantıksal modeli, bir gözden geçirenin kontrol edebileceği çizim kurallarını, sık yapılan hataları ve Archboard’a kopyalayabileceğiniz ücretsiz bir şablonu bulacaksınız.

NIST SP 800-207 modeli

NIST SP 800-207, zero trust mimarisini (ZTA) tek bir fikir etrafında tanımlar: Ağ konumuna veya varlığın kime ait olduğuna dayanan örtük güven yoktur. Her kaynağa erişim oturum bazında verilir, dinamik politikayla kararlaştırılır ve özne kaynağa ulaşmadan önce uygulanır.

Üç mantıksal bileşen

PE ve PA birlikte Policy Decision Point’i (PDP) oluşturur. Gerçek sistemlerde PE bir kimlik farkındalıklı proxy’nin veya bir service mesh kontrol düzleminin içinde yaşayabilir; PEP’ler ise ağ geçitleri, sidecar’lar, ajanlar ya da proxy’lerdir. Tek bir ürün iki rolü birden üstlense bile diyagram her rolü görünür kılmalıdır.

Kararın arkasındaki veri kaynakları

SP 800-207, PE’nin kullanabileceği girdileri listeler. Neredeyse her diyagramda yer alması gerekenler:

• Kimlik sağlayıcı (IdP) / kimlik yönetimi: kullanıcılar, servis kimlikleri, gruplar, kimlik doğrulama gücü.
• Cihaz durumu (CDM): sürekli tanılama ve azaltım verisi; cihaz biliniyor mu, yönetiliyor mu, yamalı mı?
• Tehdit istihbaratı: yeni saldırılar, ele geçirilmiş hesaplar ve zafiyetler hakkında akışlar.
• Aktivite logları ve SIEM: toplanıp analiz edilen ağ ve sistem aktivitesi; geri besleme döngüsü burada başlar.
• Kurumsal PKI: kullanıcılar, cihazlar ve iş yükleri için sertifikalar.

Standart ayrıca veri erişim politikalarını ve uyumluluk gereksinimlerini de sayar; gerçek kararları etkiliyorlarsa bunları da çizin.

Zero trust mimari diyagramı nasıl çizilir

1. Her erişim yoluna bir PEP koyun

Bir özneden (kullanıcı, cihaz, servis) bir kaynağa giden her oku takip edin. Her biri önce bir uygulama noktasından geçmelidir. Bir ok PEP’i atlıyorsa ya diyagram yanlıştır ya da mimaride bir boşluk vardır. Sadece kullanıcı yolunu değil; yönetici, CI/CD ve acil durum (break-glass) erişim yollarını da ekleyin.

2. Kimlik ve cihaz sinyallerinin karara aktığını gösterin

Kimlik sağlayıcıyı, cihaz durumunu, tehdit istihbaratını ve SIEM’i Policy Engine’e bağlanan düğümler olarak çizin. Kenarlara akan veriyi yazın: “kullanıcı + gruplar (OIDC)”, “cihaz uyumluluğu”, “risk sinyalleri”.

3. Oturum bazında authN ve authZ’yi açıkça gösterin

NIST erişimi oturum bazında tanımlar; birçok uygulama ise her istekte yeniden değerlendirme yapar. Her iki durumda da sırayı gösterin: Özne erişim ister, PEP PDP’ye sorar, PE değerlendirir, PA PEP’i yapılandırır ve PEP oturuma izin verir ya da engeller. Numaralı kenar etiketleri yeterlidir; daha fazla ayrıntı için yanına küçük bir sequence diyagramı ekleyin.

4. Kontrol düzlemini veri düzleminden ayırın

PE, PA ve veri kaynaklarını bir bölgeye; özneleri, PEP’leri ve kaynakları başka bir bölgeye yerleştirin. Bu iki bölge arasında yalnızca PA–PEP kontrol kanalı, sinyal akışları ve log akışı geçmelidir.

5. Mikro segmentasyonu ve doğu-batı trafiğini gösterin

Zero trust yalnızca kullanıcıların uygulamalara erişmesiyle ilgili değildir. Servisler arası trafik için şunları çizin:

• iş yükü kimliği (örneğin bir service account’a bağlı sertifikalar),
• servisler arasında mTLS ve bu sertifikaları üreten CA veya PKI,
• iş yükleri arasında segmentasyon politikası, örneğin Kubernetes NetworkPolicy.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: orders-allow-from-checkout
  namespace: orders
spec:
  podSelector:
    matchLabels:
      app: orders
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: checkout
          podSelector:
            matchLabels:
              app: checkout
      ports:
        - protocol: TCP
          port: 8443

NetworkPolicy 3. ve 4. katmanda çalışır ve yalnızca CNI eklentiniz onu uyguluyorsa etkili olur. Bu bir segmentasyondur, kimlik doğrulama değil; bu yüzden diyagramda mTLS ve bir PEP’teki yetkilendirmeyle birlikte gösterin.

6. Secret’ları ve sertifikaları birinci sınıf parçalar olarak çizin

Vault’u (secret yöneticisi) ve PKI’yı ayrı düğümler olarak gösterin. Hangi iş yükünün hangi secret’ı hangi kimlikle aldığını çizin. NIST modelinde oturuma özel kimlik bilgileri PA’dan gelir; bu yüzden onları karar akışına bağlayın.

7. WAF ve güvenlik duvarlarını doğru yerde tutun

Zero trust, WAF’ı veya güvenlik duvarlarını ortadan kaldırmaz. Kenarda ve segmentler arasında filtrelemeye devam ederler, ama güven kararını onlar vermez. Onları güvenilen bir bölgenin etrafındaki duvar olarak değil, yol üzerindeki filtreler olarak çizin.

8. Döngüyü loglama ile kapatın

Her PEP ve güvenlik duvarı loglarını SIEM’e göndermeli, analiz sonuçları da Policy Engine’e geri beslenmelidir. Bu kenar yoksa sürekli doğrulamanın “sürekli” kısmı resimde eksik kalır.

Sık yapılan hatalar

• Yeniden etiketlenmiş kale ve hendek. Kalın bir dış güvenlik duvarı, “güvenilen iç ağ” ve iç servisler arasında hiçbir uygulama noktası yok.
• Politika karar akışı yok. IdP ve bir ağ geçidi tuvalde var, ama kararın nerede verildiğini ya da neyi kullandığını gösteren hiçbir şey yok.
• Geri besleme döngüsü yok. Loglar hiçbir yere gitmiyor ya da SIEM politikaya geri dönmeyen bir çıkmaz sokak.
• Yalnızca kuzey-güney. Kullanıcıdan uygulamaya yollar var; servisten servise ve yöneticiden altyapıya yollar yok.
• Güven olarak çizilmiş bölgeler. Segmentler için Frame kullanmak iyidir, ama onları “güvenilen” diye değil, segment veya uygulama alanı olarak adlandırın.

Archboard’da oluşturun

Yerleşik paketler tüm parçaları karşılar. Security paketinde kimlik sağlayıcı, WAF, güvenlik duvarı, zero trust ağ geçidi, vault ve sertifika düğümleri vardır. Network paketinde Internet, DNS, yük dengeleyici ve frame olarak VPC ile subnet bulunur. Kubernetes paketi Namespace (frame olarak çizilir), Service, Pod ve NetworkPolicy ekler. Düğümlerin portları vardır; böylece her kenar bir şeklin üzerinde serbestçe durmak yerine düğümün belirli bir kenarına bağlanır.

1. Düzlemleri Frame’lerle yerleştirin. İki Core Frame ekleyin: “Control plane” ve “Data plane”. Veri düzleminin içine her segment için bir Frame ekleyin, örneğin “Edge”, “App segment” ve “Data segment”. Kubernetes iş yükleri için Namespace düğümünü kullanın.
2. Özneleri ve kenarı ekleyin. Kullanıcılar için Network paketinden bir Internet düğümü, ardından Security paketinden bir WAF düğümü ve kullanıcı erişimi için PEP olarak zero trust ağ geçidi düğümünü yerleştirin.
3. Kararı ve girdilerini ekleyin. Kontrol düzlemi frame’ine kimlik sağlayıcı düğümünü ve “Policy Engine”, “Policy Administrator”, “Device posture (CDM)”, “Threat intel” ve “SIEM” etiketli Core Box düğümlerini yerleştirin.
4. Karar akışını bağlayın. Sinyal kaynaklarını Policy Engine’e, Policy Engine’i Policy Administrator’a, Policy Administrator’ı da her PEP’e bağlayın. Kenarları etiketleyin.
5. Doğu-batı yollarını ekleyin. Her Namespace içine Service ve Pod düğümleri ile bir NetworkPolicy düğümü ekleyin. mTLS sertifika üreticisi için bir sertifika düğümü, secret’lar için bir vault düğümü ekleyin ve bunları kullanan iş yüklerine bağlayın.
6. Segmentler arasına güvenlik duvarı koyun. Trafiğin segment frame’leri arasında geçtiği yerlerde Security paketinin güvenlik duvarı düğümünü kullanın.
7. Döngüyü kapatın. Her PEP’ten ve güvenlik duvarından SIEM’e, SIEM’den de Policy Engine’e kenar çizin.
8. Varsayımları tuvale yazın. Politika kuralları ve oturum süreleri için bir Markdown bloğu kullanın; NetworkPolicy için de bu bloğun içine çitli (fenced) bir YAML kod bloğu ekleyin.

Bu kadar eksiksiz bir diyagram, Free planın diyagram başına 15 diyagram düğümü sınırını aşabilir; notlar ve metinler ayrı sayılır, 150’ye kadar. Free planda diyagramı bir genel bakış ve bir Kubernetes ayrıntı diyagramı olarak ikiye bölün; Pro düğüm sınırını kaldırır. SVG veya PNG dışa aktarabilir (Free’de filigranlı), herkese açık bir bağlantı paylaşabilir ve yapılandırılmış JSON’u altyapı kodunuzun yanında saklamak için dışa aktarabilirsiniz.

Ücretsiz şablon

Zero Trust Perimeter örneği, kullanıcıların bir edge WAF üzerinden girişini, OIDC ile bağlı bir IdP / SSO düğümünü, bir zero trust ağ geçidini, bir segment güvenlik duvarını, bir secret vault’unu ve özel bir uygulamanın etrafındaki mTLS PKI’yı gösterir. Açın ve Bu örneği kullan ile çalışma alanınıza kopyalayın. Ardından bu yazıdaki kontrol düzlemi frame’i, sinyal kaynakları ve loglama döngüsüyle genişletin. Alttaki ağ için veri merkezi ağı örneğine ve ağ diyagramları kullanım senaryosuna bakın.

Kontrol listesi ve SSS

Diyagramı paylaşmadan önce şunları kontrol edin:

• özneden kaynağa giden her yol bir PEP’ten geçiyor,
• kimlik, cihaz, tehdit ve log sinyalleri Policy Engine’e akıyor,
• kontrol düzlemi ve veri düzlemi görsel olarak ayrı,
• doğu-batı trafiği mTLS ve segmentasyonu gösteriyor,
• secret’lar ve PKI, neyi kimin aldığını gösteriyor,
• PEP ve güvenlik duvarı logları SIEM’e ve oradan politikaya geri akıyor.

Zero trust mimari diyagramı sadece bir ağ diyagramı mı? Hayır. Ağ diyagramı paketlerin nereye gittiğini gösterir. ZTA diyagramı buna erişimin nerede, hangi sinyallerle kararlaştırıldığını ve nerede uygulandığını ekler.

Zero trust tasarımında hâlâ güvenlik duvarına ihtiyacım var mı? Evet. Güvenlik duvarları ve WAF’lar saldırı yüzeyini azaltmaya devam eder; yalnızca bir şeyin güvenilir sayılmasının nedeni olmaktan çıkarlar.

Kubernetes NetworkPolicy tek başına zero trust sağlar mı? Hayır. Size L3/L4 segmentasyonu verir. Yine de iş yükü kimliğine, mTLS’e, bir PEP’te yetkilendirmeye ve loglamaya ihtiyacınız vardır.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.