Zero Trust Architecture - Vertraue niemandem, verifiziere alles

Zero Trust ist kein Produkt, das man kaufen kann - es ist ein Sicherheitsparadigma, das das veraltete Perimeter-Modell ablöst: Das Netz ist nie vertrauenswürdig, auch nicht von innen.

Das Problem des Perimeter-Modells

Warum “Trust but Verify” nicht mehr funktioniert

Das klassische Perimetermodell sieht so aus:

[Internet] - Firewall - [Internes Netz = “trusted”]

Die zugrundeliegende Annahme: Alles innerhalb der Firewall ist vertrauenswürdig. Diese Annahme hat mehrere fundamentale Schwächen:

Problem 1 - VPN-Nutzer: Ein Remote-Mitarbeiter der per VPN verbunden ist, gilt als “im Netz”. Ein kompromittierter VPN-Client versetzt damit auch den Angreifer “ins Netz”.

Problem 2 - Insider Threats: Ein Mitarbeiter ist bereits “innen” - der Perimeter bietet keinerlei Schutz.

Problem 3 - Lateral Movement: Initial Access auf eine einzelne Workstation ermöglicht freie Bewegung im Netz. Der Perimeter schützt nicht vor einem internen Angreifer.

Problem 4 - Cloud und Mobiles: Daten in AWS/Azure haben keinen Perimeter. Mitarbeiter arbeiten aus dem Homeoffice, aus Cafés, vom Flughafen. Der Perimeter löst sich auf (Dissolution of the Perimeter).

Ergebnisse realer Angriffe:

• Maersk/NotPetya 2017: einmal im Netz → 40.000 Rechner kompromittiert
• Colonial Pipeline 2021: kein MFA auf VPN → Ransomware
• SolarWinds 2020: Supply Chain → vertrauenswürdige Software umging den Perimeter

Zero Trust Kernprinzipien (NIST SP 800-207)

1. Verify Explicitly: Authentifizierung und Autorisierung immer - nicht nur beim Login, sondern laufend
2. Least Privilege Access: Minimale Berechtigungen, Just-in-Time-Zugang
3. Assume Breach: Handeln als wäre man bereits kompromittiert - Blast Radius minimieren, Ende-zu-Ende-Verschlüsselung

Zero Trust Architektur-Komponenten

Identity Provider (IdP)

“Identity is the new perimeter”

Beispiele: Azure Active Directory / Microsoft Entra ID, Okta, Ping Identity, ForgeRock.

Anforderungen:

• MFA: zwingend für alle (Ausnahmen = Risiko!)
• Conditional Access: Regeln wer wann von wo zugreift
  • “Nur von Managed Devices aus Deutschland”
  • “Administrativer Zugriff: nur aus dem Büro (IP-Range)”
  • “Hochsensible Anwendungen: MFA + Compliant Device + Insider Risk Score < Medium”

Device Trust (Gerätezustand)

MDM (Mobile Device Management):

• Intune (Microsoft), Jamf (macOS/iOS), Kandji
• Gerät registriert + richtlinienkonform → “Compliant”
• Nicht-compliant: kein Zugriff (oder eingeschränkter Zugang)

Device Health Check - Mindestanforderungen:

• OS aktuell? (kein Windows 10 End-of-Support!)
• Antivirus aktiv und aktuell?
• Disk verschlüsselt? (BitLocker/FileVault)
• Kein Jailbreak/Root-Zugang?

Hardware-Attestation:

• Windows: Trusted Platform Module (TPM) + Health Attestation
• macOS: Secure Enclave + Gatekeeper
• iOS/Android: MDM-Enrollment-Zertifikat

Network Access

Micro-Segmentierung statt VPN:

• Traditionell: VPN = Zugriff auf alles
• Zero Trust: Zugriff nur auf spezifische Anwendungen

Zero Trust Network Access (ZTNA):

• Zscaler Private Access: kein VPN, direkter App-Zugang
• Cloudflare Access: Identity-aware Proxy
• Palo Alto Prisma Access: SASE-Plattform

Connector-Modell:

Mitarbeiter → Identity Provider (Auth) → ZTNA-Broker → App-Connector → Anwendung

Kein direkter Netzwerk-Zugang. Nur verifizierte Nutzer mit compliantem Gerät erhalten Zugang.

CASB (Cloud Access Security Broker)

• Sichtbarkeit und Kontrolle über Cloud-Nutzung
• Shadow IT erkennen: welche Cloud-Apps nutzen Mitarbeiter?
• DLP für Cloud: keine Kundendaten in persönlichem Dropbox
• Beispiele: Microsoft Defender for Cloud Apps, Netskope, McAfee MVISION

Zero Trust Implementierung (Maturity Model)

Das CISA Zero Trust Maturity Model definiert fünf Säulen, jeweils mit drei Reifegraden:

Säule 1: Identity

Traditional (Start):

• Passwort-basierte Authentifizierung
• MFA nur für Admins

Advanced (Ziel):

• MFA für alle (Conditional Access)
• Continuous Identity Verification
• Privileged Identity Management (PIM)
• Risikobasierte Authentifizierung (Insider Risk Score)

Optimal (Best Practice):

• Passwordless (FIDO2/Windows Hello)
• Adaptive MFA (hohes Risiko = stärkere Prüfung)
• Identity Threat Detection (ITDR)

Säule 2: Devices

Traditional:

• Keine Geräteverwaltung (unmanaged Geräte haben Zugriff)

Advanced:

• MDM für alle Geräte
• Compliance als Zugriffs-Voraussetzung
• EDR auf allen Endpoints

Optimal:

• Hardware Attestation (TPM)
• Continuous Device Health Monitoring
• Zero-Touch Provisioning (Autopilot)

Säule 3: Networks

Traditional:

• Flat Network, VPN für Remote

Advanced:

• VLAN-Segmentierung
• Micro-Segmentierung (Ost-West)
• ZTNA statt VPN

Optimal:

• SASE (Secure Access Service Edge): SD-WAN + Security
• Universal ZTNA (auch interne Nutzer!)
• DNS Security, Encrypted DNS

Säule 4: Applications

Traditional:

• Anwendungen netzwerk-erreichbar

Advanced:

• Application-level Access Control
• API Gateway mit Auth
• WAF

Optimal:

• Application Threat Protection
• Continuous Application Monitoring
• DevSecOps Integration

Säule 5: Data

Traditional:

• Keine Datenklassifizierung

Advanced:

• Datenklassifizierung implementiert
• DLP Policies
• Verschlüsselung at rest + in transit

Optimal:

• Information Protection (Microsoft Purview Labels)
• Rights Management (Datei bleibt verschlüsselt auch außerhalb!)
• Data Access Governance

Praktische Roadmap

Monat 1-3 (Quick Wins):

• MFA für alle Benutzer (auch interne!)
• Conditional Access: unbekannte Geräte = kein Zugriff
• MDM-Enrollment aller Firmengeräte

Monat 4-6:

• Netzwerksegmentierung grundlegend (VLANs)
• ZTNA für Remote Access (statt VPN)
• Privileged Identity Management (JIT Admin-Zugriff)

Monat 7-12:

• Microsegmentierung (kritische Server)
• CASB-Einführung (Cloud-Sichtbarkeit)
• Datenklassifizierung + DLP

Jährlich:

• Reifegrad-Assessment (CISA Maturity Model)
• Penetrationstest (Zero-Trust-Wirksamkeit prüfen!)
• Anpassung der Richtlinien

Google BeyondCorp als Vorbild

Die originale Zero-Trust-Implementierung

Google BeyondCorp (2011-heute):

• Hintergrund: 2010 kompromittierte die Operation Aurora (chinesischer APT) Google-Systeme. Das Ergebnis war ein Zero-Trust-Neukonzept.
• 2014: BeyondCorp Paper veröffentlicht
• Heute: Google-intern für alle 100.000+ Mitarbeiter im Einsatz

Kernprinzipien BeyondCorp:

1. Kein “privilegiertes” Netz: LAN = Internet = gleiches Risiko
2. Zugriff basiert auf Gerät + User (nicht auf Netzzugehörigkeit)
3. Alle Anwendungen über Internet erreichbar (kein VPN!)
4. Zugriffsentscheidung: Identität + Device Health + Kontext

Technische Komponenten:

• Trust Engine: bewertet Gerät und User kontinuierlich
• Access Proxy: alle Anfragen werden durch einen Proxy geleitet
• Device Inventory: alle Geräte registriert mit Health-Score
• Certificate-based Auth: kein Passwort direkt am Gerät

BeyondCorp Enterprise (Google Cloud)

Kommerzielles Produkt basierend auf den BeyondCorp-Prinzipien: Identity-Aware Proxy + Chrome Enterprise. Integration mit Google Workspace sowie anderen IDPs (Okta, Azure AD).