Zero Trust Architektur: Von der Theorie zur Implementierung

“Vertraue niemandem, verifiziere alles” - das Mantra von Zero Trust klingt simpel, aber die Implementierung ist komplex. Zero Trust ist keine neue Technologie die man kaufen kann, sondern ein Paradigmenwechsel: weg vom perimeter-basierten Netzwerk (“inside = safe”) hin zu einer Welt in der jeder Zugriff explizit autorisiert werden muss, unabhängig davon ob er vom Büro, Homeoffice oder aus dem Ausland kommt.

Warum Zero Trust? Das Ende des Perimeters

Das alte Modell: Burg und Burggraben

Das klassische Perimeter-Modell sah so aus: Das Internet war außen, eine Firewall bildete die Grenze, dahinter lag das “trusted” interne Netzwerk mit Büro-PCs, Servern und dem impliziten Vertrauen, dass alle Systeme miteinander kommunizieren dürfen.

Dieses Modell scheitert an vier strukturellen Problemen:

• Problem 1: VPN-Nutzer aus dem Homeoffice befinden sich im “trusted” Netzwerk
• Problem 2: Angreifer mit gültigem Credential befinden sich ebenfalls im “trusted” Netzwerk
• Problem 3: Malware auf einem PC kann lateral zu allen anderen Systemen vordringen
• Problem 4: Cloud-Services existieren außerhalb des kontrollierten Perimeters

83 % aller erfolgreichen Angriffe nutzen kompromittierte Credentials - wer sich im Netzwerk befindet, ist also nicht per se vertrauenswürdig.

Zero Trust Grundprinzipien (NIST SP 800-207)

1. Alle Ressourcen als potenziell nicht vertrauenswürdig behandeln
2. Least-Privilege: minimale Zugriffsrechte, just-in-time vergeben
3. Alle Verbindungen explizit verifizieren (Identität + Gerät + Kontext)
4. Annahme: Ein Breach ist bereits geschehen - Lateral Movement minimieren
5. Kontinuierliche Verifizierung statt einmaligem Login
6. Umfangreiches Logging und Analyse aller Aktivitäten

Die fünf Säulen von Zero Trust

Säule 1: Identität (Identity)

Die zentrale Frage: “Wer versucht gerade zuzugreifen?”

Konkrete Maßnahmen:

• MFA für alle Nutzer - phishing-resistent mit FIDO2/Passkeys
• Privileged Identity Management mit JIT-Zugang für Admins
• Identity Risk Scoring für kontinuierliche Authentifizierung
• Service-Account-Hygiene: gMSA und kurze Credential-Lifetime
• Federation: SSO via OIDC/SAML (kein lokales Passwort mehr)

Relevante Tools: Microsoft Entra ID, Okta, Ping Identity, CyberArk.

Säule 2: Geräte (Device)

Die zentrale Frage: “Ist dieses Gerät vertrauenswürdig?”

Konkrete Maßnahmen:

• Device-Enrollment über MDM/Intune oder Jamf Pro
• Device-Compliance: Patch-Level, Antivirus, Verschlüsselung
• Certificate-basierte Geräteauthentifizierung (nicht nur User-Authentifizierung!)
• EDR: Endpoint Detection and Response (CrowdStrike, SentinelOne)
• Unmanaged Devices erhalten nur eingeschränkten Zugang (BYOD-Policy)

Conditional Access stellt sicher: Zugang wird nur gewährt, wenn Gerät UND Nutzer UND Kontext den Richtlinien entsprechen.

Säule 3: Netzwerk (Network)

Die zentrale Frage: “Ist das Verbindungsmuster normal?”

Konkrete Maßnahmen:

• Mikrosegmentierung zur Kontrolle des Ost-West-Traffics
• ZTNA statt VPN: per-App-Zugang statt Netzwerk-Zugang
• Software-Defined Perimeter (SDP): nur notwendige Verbindungen erlauben
• DNS-Sicherheit: DoH/DoT und Blocking bekannter Malicious Domains
• Verschlüsselung: TLS für alle Verbindungen - auch für interne

Relevante Tools: Zscaler ZPA, Cloudflare Access, Netskope Private Access.

Säule 4: Anwendungen (Application)

Die zentrale Frage: “Ist dieser Zugriff für diesen Kontext autorisiert?”

Konkrete Maßnahmen:

• RBAC: Role-Based Access Control (nicht IP-basiert!)
• ABAC: Attribute-Based Access Control (Zeit, Ort, Risk-Score)
• API-Security: OAuth 2.0, JWT mit kurzer Lifetime
• Application-Level Monitoring: WAF + RASP
• Privileged Access Management: Vault für Credentials

Säule 5: Daten (Data)

Die zentrale Frage: “Ist dieser Datenzugriff angemessen?”

Konkrete Maßnahmen:

• Data Classification: Sensibilität jeder Datei und Tabelle kennen
• DLP: Data Loss Prevention verhindert unbeabsichtigte Exfiltration
• Verschlüsselung at-rest und in-transit
• Rights Management: Dokumente mit Ablaufdatum (EDRM)
• Zero-Standing-Privileges: kein dauerhafter Datenzugriff

NIST SP 800-207 Referenzarchitektur

Policy Decision Point (PDP): Das Gehirn

Der PDP wertet Zugriffsanfragen aus und berücksichtigt dabei Identität, Gerät, Kontext, Richtlinien und Risk-Score. Die Entscheidung lautet: Allow, Deny oder Allow with conditions (z. B. MFA-Step-Up). Beispiele: Microsoft Entra ID Conditional Access, Zscaler Policy Engine.

Policy Enforcement Point (PEP): Der Türsteher

Der PEP setzt PDP-Entscheidungen durch, blockiert oder erlaubt Verbindungen und steht inline zwischen Client und Ressource. Beispiele: Zscaler Client Connector, Cloudflare Tunnel, Next-Generation Firewall.

Datenquellen für PDP-Entscheidungen

Datenquelle	Information
Identitätssystem	Wer ist der Nutzer? Welche Gruppen und Rollen?
MDM/EDR	Ist das Gerät konform? AV aktiv? Patches aktuell?
Threat Intelligence	Ist die IP oder Domain als malicious bekannt?
SIEM/UEBA	Hat der Nutzer anomales Verhalten gezeigt?
Context	Zeit, Ort, Netzwerktyp (Corporate, VPN, Public)

Zero Trust Entscheidungsmatrix

Richtlinien werden kontextabhängig formuliert:

• Nutzer-Risiko Low + Gerät Compliant + Standort Corporate Network → Zugang ohne zusätzliche Prüfung
• Nutzer-Risiko Medium oder Standort Public Internet → MFA-Reauthentifizierung erforderlich
• Nutzer-Risiko High oder Gerät Unknown → Zugang verweigern oder nur lesender Zugriff auf nicht-sensitive Daten
• Standort Anomalous (Impossible Travel) → Reauthentifizierung erzwingen + SOC alarmieren

ZTNA - Zero Trust Network Access

Klassisches VPN: Das Problem

Ein VPN-Tunnel bedeutet Zugang zum gesamten Unternehmensnetzwerk. Ein kompromittierter VPN-Client ermöglicht Lateral Movement zu allen Ressourcen. Das VPN-Gateway ist ein Single Point of Failure, und alle Traffic muss über ein zentrales Gateway geleitet werden. App-Granularität existiert nicht: entweder Zugang zu allem oder gar nichts.

ZTNA: Die Lösung

Eine ZTNA-Verbindung erlaubt nur den Zugang zu explizit autorisierten Anwendungen - nie zum gesamten Netzwerk. Granulare Per-App-Autorisierung über Micro-Tunnel statt Netzwerk-Tunnel ist das Kernprinzip. Die interne Anwendung ist nicht direkt aus dem Internet erreichbar. Nur der ZTNA-Connector (outbound!) stellt die Verbindung her.

ZTNA-Architektur (Cloud-basiert, Beispiel Cloudflare Access):

[Client] ─── TLS ─── [Cloudflare Edge] ─── [Cloudflare Tunnel] ─── [Interne App]
                           ↑
                      Identity Check (Okta/Entra ID)
                      Device Check (Intune/MDM)
                      → Access Token bei Erfolg

Die interne App hat keine öffentliche IP. Der Client sieht nur die Cloudflare-IP.

ZTNA-Produkte im Vergleich

Cloudflare Access (Cloud-delivered): Einfachste Implementierung. Cloudflare Tunnel stellt eine outbound-only-Verbindung vom Server her. Alle OIDC-Provider werden unterstützt (Entra ID, Okta, Google). Kostenlos bis 50 Nutzer - ideal für den Remote-Zugang im KMU.

Zscaler Private Access (Enterprise): Vollständiges Zero Trust Network Access mit granularen App-Segmentation-Policies. Deception-Funktionen (Honey-User und Honey-App) und Integration mit CrowdStrike und SentinelOne.

Microsoft Entra Private Access: Native Microsoft-365-Integration mit direkter Anbindung an Entra ID Conditional Access. Ideal für Microsoft-zentrierte Umgebungen.

BeyondCorp (Google): Googles eigene Zero-Trust-Implementierung, als BeyondCorp Enterprise auch für externe Kunden verfügbar.

Mikrosegmentierung

Das Problem ohne Mikrosegmentierung

Wenn alle Server im gleichen Netzwerksegment laufen, kann ein kompromittierter Webserver direkt den Datenbank-Server, den HR-Server und den Finance-Server ansprechen. Laterale Bewegung im internen Netz ist unkontrolliert möglich.

Mikrosegmentierung: Der Ansatz

Mit Software-Defined Segmentierung erhält jede Applikation ihr eigenes Segment:

• Web-Server: darf nur API-Server und Load-Balancer erreichen
• API-Server: darf nur DB-Server und Cache erreichen
• HR-Datenbank: ausschließlich vom HR-App-Server erreichbar
• Finance-Datenbank: kein Zugang aus dem Web-Segment

Implementierungsoptionen

1. Netzwerk-basiert (VLAN/Firewall): Traditionell und statisch. Ein VLAN pro Applikation mit Firewall-Rules zwischen VLANs. Problem: Bei vielen Micro-Services entstehen hunderte VLANs und tausende Rules.

2. Software-Defined (empfohlen) mit Tools wie Illumio, Guardicore oder NSX: Label-basierte Segmentierung vergleichbar mit Kubernetes Network Policies. Policy-Beispiel: “Erlaubt Tier=web → Tier=api auf Port 8080”. Automatisch auf alle Workloads mit dem entsprechenden Label angewendet. Funktioniert in Cloud, VM und Container-Umgebungen.

3. Kubernetes Network Policies:

# Nur API-Server darf DB-Pod auf Port 5432 erreichen:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-access
spec:
  podSelector:
    matchLabels:
      role: database
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api-server
    ports:
    - port: 5432

4. Service Mesh (Istio/Linkerd): mTLS zwischen allen Services automatisch. Traffic-Policies für Retry, Circuit-Breaker und Rate-Limiting. Vollständige Observability aller Service-Verbindungen. Zero-Trust im Kubernetes-Cluster.

Zero Trust Migration Roadmap

Phase 1: Inventar und Assessment (Monate 1-3)

• Alle Anwendungen inventarisieren: intern oder Cloud?
• Alle Nutzergruppen und Zugriffsberechtigungen kartieren
• Netzwerk-Topologie dokumentieren: wo laufen Daten hin?
• Sensitive Daten und kritische Assets identifizieren
• Zero-Trust-Reifegrad bewerten (CISA ZT Maturity Model)

Phase 2: Identität modernisieren (Monate 3-6)

• MFA für alle Nutzer einführen (FIDO2 für Admins ist Pflicht!)
• SSO/Identity-Provider: alle Apps über OIDC/SAML anbinden
• Privileged Identity Management: JIT-Admin-Zugang implementieren
• Service-Account-Audit: unnötige Accounts löschen
• Erste Conditional Access Policies einführen (Compliant Device als Bedingung)

Phase 3: Geräte absichern (Monate 6-9)

• MDM-Enrollment: alle Corporate-Geräte einschreiben
• Compliance-Policies: Patch-Stand, Antivirus, Verschlüsselung durchsetzen
• BYOD-Strategie definieren: MDM-Profil oder ZTNA-only
• Device-Certificates für EAP-TLS und mTLS einrichten

Phase 4: Netzwerk modernisieren (Monate 9-15)

• ZTNA pilotieren: 10-20 % der Remote-Nutzer als erste Gruppe
• Mikrosegmentierung für kritische Anwendungen einführen
• DNS-Security: DoH/DoT und Domain-Filtering aktivieren
• VPN schrittweise ablösen - nicht alles auf einmal!
• Interne Verschlüsselung: TLS auch für interne Verbindungen einführen

Phase 5: Daten und Anwendungen (Monate 15-24)

• Data Classification: alle sensitiven Daten klassifizieren
• DLP: Exfiltrations-Prävention aktivieren
• App-Level Authorization: RBAC/ABAC für alle Anwendungen implementieren
• API Security: OAuth 2.0 und JWT mit kurzer Lifetime einführen
• PAM: Privileged Access Management für Server-Zugang

Erfolgsmessung mit KPIs

KPI	Ziel
Anteil Nutzer mit MFA	100 %
Anteil Geräte unter MDM	> 95 %
Anteil Apps hinter ZTNA	Stetig wachsend
Lateral Movement Incidents	Sinkender Trend
MTTD für Credential-Misuse	Unter Zielwert

Häufige Fehler bei Zero-Trust-Projekten

• “Wir kaufen ein Zero-Trust-Produkt” - Zero Trust ist eine Architektur, kein Produkt
• Zu schneller Rollout - User-Akzeptanz leidet, Rollback wird nötig
• Nur technisch gedacht - Prozesse und Schulungen werden vergessen
• Kein Fallback-Konzept - bei Ausfall sind alle Nutzer ausgesperrt
• Legacy-Systeme vergessen - SAP, AS/400 und ähnliche erfordern durchdachte Ausnahmen

---

Zero Trust ist ein mehrjähriges Transformationsprojekt - kein Overnight-Switch. Unternehmen die Zero Trust konsequent implementieren, reduzieren den Blast Radius von Kompromittierungen drastisch: auch wenn ein Angreifer ein Credential stiehlt, kommt er nicht weit. AWARE7 begleitet Zero-Trust-Implementierungen von der Architekturplanung bis zum operativen Betrieb.

Zero Trust Assessment anfragen | ISO 27001 Beratung