Zero-Trust-Netzwerkarchitektur: Diagramm-Vorlage

Viele Diagramme mit dem Etikett „Zero Trust“ sind Perimeter-Diagramme mit neuem Titel: eine Firewall am Rand, eine DMZ und ein vertrauenswürdiges Inneres. Ein brauchbares Zero-Trust-Architektur-Diagramm beantwortet drei Fragen auf einen Blick: Wo wird jede Zugriffsentscheidung getroffen, welche Signale fließen in diese Entscheidung ein, und wo wird sie durchgesetzt? Kann das Bild das nicht beantworten, beschreibt es den Ort im Netzwerk, nicht Vertrauen.

Im Folgenden: das logische Modell aus NIST SP 800-207, Zeichenregeln, die ein Reviewer prüfen kann, typische Fehler und eine kostenlose Vorlage, die du in Archboard kopieren kannst.

Das Modell aus NIST SP 800-207

NIST SP 800-207 definiert Zero-Trust-Architektur (ZTA) um eine Idee herum: kein implizites Vertrauen aufgrund von Netzwerkstandort oder Besitz eines Assets. Zugriff auf jede Ressource wird pro Session gewährt, durch dynamische Policy entschieden und durchgesetzt, bevor das Subjekt die Ressource erreicht.

Die drei logischen Komponenten

PE und PA bilden zusammen den Policy Decision Point (PDP). In echten Systemen steckt die PE oft in einem Identity-Aware Proxy oder in der Control Plane eines Service Mesh, und PEPs sind Gateways, Sidecars, Agents oder Proxies. Das Diagramm sollte trotzdem jede Rolle sichtbar machen, auch wenn ein Produkt zwei davon übernimmt.

Die Datenquellen hinter der Entscheidung

SP 800-207 listet die Eingaben, die eine PE nutzen kann. Diese gehören in fast jedes Diagramm:

• Identity Provider / ID-Management: Benutzer, Service-Identitäten, Gruppen, Stärke der Authentifizierung.
• Gerätezustand (CDM): Daten aus Continuous Diagnostics and Mitigation: Ist das Gerät bekannt, verwaltet, gepatcht?
• Threat Intelligence: Feeds zu neuen Angriffen, kompromittierten Konten und Schwachstellen.
• Aktivitätslogs und SIEM: gesammelte und analysierte Netzwerk- und Systemaktivität; hier beginnt die Feedbackschleife.
• Unternehmens-PKI: Zertifikate für Benutzer, Geräte und Workloads.

Der Standard nennt außerdem Datenzugriffs-Policies und Compliance-Anforderungen; zeichne sie ein, wenn sie echte Entscheidungen beeinflussen.

So zeichnest du ein Zero-Trust-Architektur-Diagramm

1. Setze einen PEP in jeden Zugriffspfad

Verfolge jeden Pfeil von einem Subjekt (Benutzer, Gerät, Service) zu einer Ressource. Jeder muss zuerst einen Enforcement Point passieren. Überspringt ein Pfeil den PEP, ist entweder das Diagramm falsch oder die Architektur hat eine Lücke. Nimm Admin-, CI/CD- und Break-Glass-Pfade mit auf, nicht nur den Benutzerpfad.

2. Zeige, wie Identitäts- und Gerätesignale in die Entscheidung fließen

Zeichne Identity Provider, Gerätezustand, Threat Intel und SIEM als Knoten mit Kanten zur Policy Engine. Beschrifte die Kanten mit dem, was fließt: „User + Gruppen (OIDC)“, „Geräte-Compliance“, „Risikosignale“.

3. Mach AuthN und AuthZ pro Session sichtbar

NIST beschreibt Zugriff als pro Session gewährt; viele Implementierungen bewerten bei jedem Request neu. In beiden Fällen zeigst du die Abfolge: Das Subjekt fordert Zugriff an, der PEP fragt den PDP, die PE bewertet, der PA konfiguriert den PEP, und der PEP lässt die Session zu oder blockiert sie. Nummerierte Kantenbeschriftungen reichen; für mehr Details ergänzt du ein kleines Sequenzdiagramm.

4. Trenne Control Plane und Data Plane

Lege PE, PA und Datenquellen in einen Bereich, Subjekte, PEPs und Ressourcen in einen anderen. Dazwischen verlaufen nur der Kontrollkanal vom PA zum PEP, die Signal-Feeds und der Log-Fluss.

5. Zeige Mikrosegmentierung und East-West-Traffic

Bei Zero Trust geht es nicht nur um Benutzer, die Apps erreichen. Für Service-zu-Service-Traffic zeichnest du:

• Workload-Identität (zum Beispiel Zertifikate, die an einen Service Account gebunden sind),
• mTLS zwischen Services und die CA oder PKI, die diese Zertifikate ausstellt,
• Segmentierungs-Policy zwischen Workloads, etwa 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

Eine NetworkPolicy wirkt auf Layer 3 und 4 und greift nur, wenn dein CNI-Plugin sie durchsetzt. Sie ist Segmentierung, keine Authentifizierung – kombiniere sie im Diagramm mit mTLS und Autorisierung an einem PEP.

6. Zeichne Secrets und Zertifikate als eigenständige Bausteine

Zeige den Vault (Secrets Manager) und die PKI als eigene Knoten. Zeichne, welche Workloads welche Secrets mit welcher Identität abrufen. Im NIST-Modell stammen sessionspezifische Credentials vom PA, also verbinde sie mit dem Entscheidungsfluss.

7. Behalte WAF und Firewalls – an der richtigen Stelle

Zero Trust schafft WAF und Firewalls nicht ab. Sie filtern weiterhin am Rand und zwischen Segmenten, aber sie treffen nicht die Vertrauensentscheidung. Zeichne sie als Filter im Pfad, nicht als Mauer um eine vertrauenswürdige Zone.

8. Schließe die Schleife mit Logging

Jeder PEP und jede Firewall sollte Logs ans SIEM senden, und die Analyse sollte zurück in die Policy Engine fließen. Ohne diese Kante fehlt im Bild das „kontinuierlich“ der kontinuierlichen Verifizierung.

Typische Fehler

• Burg und Graben, neu beschriftet. Eine dicke äußere Firewall, ein „vertrauenswürdiges internes Netz“ und keine Durchsetzung zwischen internen Services.
• Kein Policy-Entscheidungsfluss. IdP und ein Gateway sind auf dem Canvas, aber nichts zeigt, wo entschieden wird oder was die Entscheidung verarbeitet.
• Keine Feedbackschleife. Logs gehen nirgendwohin, oder das SIEM ist eine Sackgasse ohne Kante zurück zur Policy.
• Nur Nord-Süd. Benutzer zu Apps ist abgedeckt; Service-zu-Service- und Admin-zu-Infrastruktur-Pfade fehlen.
• Zonen als Vertrauen gezeichnet. Frames für Segmente sind in Ordnung, aber benenne sie als Segmente oder Enforcement-Domänen, nicht als „vertrauenswürdig“.

In Archboard umsetzen

Die eingebauten Packs decken alle Teile ab. Das Security-Pack hat Knoten für Identity Provider, WAF, Firewall, Zero-Trust-Gateway, Vault und Zertifikate. Das Network-Pack bietet Internet, DNS, Load Balancer sowie VPC und Subnet als Frames. Das Kubernetes-Pack ergänzt Namespace (als Frame gezeichnet), Service, Pod und NetworkPolicy. Knoten haben Ports, also hängt jede Kante an einer bestimmten Seite eines Knotens, statt lose auf einer Form zu liegen.

1. Lege die Planes mit Frames an. Füge zwei Core-Frames hinzu, „Control plane“ und „Data plane“. In der Data Plane legst du pro Segment einen Frame an, zum Beispiel „Edge“, „App segment“ und „Data segment“. Für Kubernetes-Workloads nimmst du den Namespace-Knoten.
2. Füge Subjekte und die Edge hinzu. Platziere einen Internet-Knoten aus dem Network-Pack für die Benutzer, dann einen WAF-Knoten aus dem Security-Pack und den Zero-Trust-Gateway-Knoten als PEP für den Benutzerzugriff.
3. Füge die Entscheidung und ihre Eingaben hinzu. Platziere im Control-Plane-Frame den Identity-Provider-Knoten und Core-Box-Knoten mit den Beschriftungen „Policy Engine“, „Policy Administrator“, „Device posture (CDM)“, „Threat intel“ und „SIEM“.
4. Verdrahte den Entscheidungsfluss. Verbinde die Signalquellen mit der Policy Engine, die Policy Engine mit dem Policy Administrator und den Policy Administrator mit jedem PEP. Beschrifte die Kanten.
5. Füge East-West-Pfade hinzu. Lege in jeden Namespace Service- und Pod-Knoten sowie einen NetworkPolicy-Knoten. Ergänze einen Zertifikat-Knoten für den mTLS-Aussteller und einen Vault-Knoten für Secrets, mit Kanten zu den Workloads, die sie nutzen.
6. Setze Firewalls zwischen Segmente. Nutze den Firewall-Knoten aus dem Security-Pack dort, wo Traffic Segment-Frames überquert.
7. Schließe die Schleife. Zeichne Kanten von jedem PEP und jeder Firewall zum SIEM und vom SIEM zurück zur Policy Engine.
8. Halte die Annahmen auf dem Canvas fest. Nutze einen Markdown-Block für Policy-Regeln und Session-Laufzeiten und darin einen umgrenzten YAML-Codeblock für die NetworkPolicy.

Ein vollständiges Diagramm dieser Art kann das Limit des Free-Plans von 15 Diagramm-Knoten pro Diagramm überschreiten; Notizen und Texte zählen separat, bis zu 150. Im Free-Plan teilst du es in eine Übersicht und ein Kubernetes-Detaildiagramm; Pro hebt das Knotenlimit auf. Du kannst SVG oder PNG exportieren (im Free-Plan mit Wasserzeichen), einen öffentlichen Link teilen und das strukturierte JSON exportieren, um es neben deinem Infrastrukturcode abzulegen.

Die kostenlose Vorlage

Das Beispiel Zero Trust Perimeter zeigt Benutzer, die über eine Edge-WAF hereinkommen, einen per OIDC angebundenen IdP-/SSO-Knoten, ein Zero-Trust-Gateway, eine Segment-Firewall, einen Secrets-Vault und eine mTLS-PKI rund um eine private App. Öffne es und kopiere es mit Dieses Beispiel verwenden in deinen Workspace. Erweitere es dann um den Control-Plane-Frame, die Signalquellen und die Logging-Schleife aus diesem Artikel. Für das Netzwerk darunter sieh dir das Rechenzentrumsnetz-Beispiel und den Use Case für Netzwerkdiagramme an.

Checkliste und FAQ

Bevor du das Diagramm teilst, prüfe:

• Jeder Pfad vom Subjekt zur Ressource läuft durch einen PEP.
• Identitäts-, Geräte-, Threat- und Log-Signale fließen in die Policy Engine.
• Control Plane und Data Plane sind sichtbar getrennt.
• East-West-Traffic zeigt mTLS und Segmentierung.
• Secrets und PKI zeigen, wer was abruft.
• Logs von PEPs und Firewalls fließen ins SIEM und zurück in die Policy.

Ist ein Zero-Trust-Architektur-Diagramm nur ein Netzwerkdiagramm? Nein. Ein Netzwerkdiagramm zeigt, wohin Pakete gehen. Ein ZTA-Diagramm zeigt zusätzlich, wo und anhand welcher Signale über Zugriff entschieden und wo er durchgesetzt wird.

Brauche ich in einem Zero-Trust-Design noch Firewalls? Ja. Firewalls und WAFs verringern weiterhin die Angriffsfläche; sie sind nur nicht mehr der Grund, warum etwas als vertrauenswürdig gilt.

Bringt mir Kubernetes NetworkPolicy Zero Trust? Nicht allein. Sie liefert L3/L4-Segmentierung. Du brauchst trotzdem Workload-Identität, mTLS, Autorisierung an einem PEP und Logging.

Kostenlos starten – ein Platz, keine Kreditkarte.