Zero-Trust-Architektur

Warum Zero Trust¶

Das traditionelle Sicherheitsmodell nimmt an, dass der Netzwerkperimeter Vertrauenswuerdiges von Nicht-Vertrauenswuerdigem trennt. Die Realitaet 2025:

• Cloud-nativ — Services laufen in Azure, AWS, On-Premise. Wo ist der Perimeter?
• Remote-Arbeit — Mitarbeiter arbeiten von ueberall. VPN reicht nicht.
• Supply Chain — Drittanbieter-Integrationen, SaaS-Tools, externe APIs. Wer ist „drinnen”?
• Lateral Movement — Ein Angreifer kompromittiert einen Endpunkt und bewegt sich frei durch das Netzwerk.

Zero Trust sagt: kein implizites Vertrauen. Jede Anfrage wird verifiziert — unabhaengig davon, woher sie kommt.

Implementierungssaeulen¶

1. Identitaet & Authentifizierung¶

Benutzer: - SSO ueber Identity Provider (Azure AD, Okta, Auth0) - MFA obligatorisch fuer alle — FIDO2/WebAuthn bevorzugt (Phishing-resistent) - Conditional Access Policies — Kontext entscheidet (Geraet, Standort, Risiko-Score) - Passwortlos wo moeglich

Services (Workload Identity): - SPIFFE/SPIRE fuer Workload Identity — jeder Service hat eine kryptografisch verifizierbare Identitaet - Service Accounts mit minimalen Berechtigungen - Managed Identities (Azure MI, AWS IAM Roles) statt langlebiger Credentials - Automatische Zertifikatsrotation, ohne Downtime

2. Mutual TLS (mTLS)¶

Service-zu-Service-Kommunikation verschluesselt und beidseitig authentifiziert:

• Service Mesh (Istio, Linkerd) — mTLS transparent fuer alle Services im Cluster
• Zertifikatsverwaltung — Automatische Rotation, kurzlebige Zertifikate (24h)
• Kein Klartext — Keine unverschluesselte Kommunikation, auch nicht im internen Netzwerk
• Observability — Sie sehen wer mit wem kommuniziert und wie viele Daten fliessen

3. Mikrosegmentierung¶

Netzwerkrichtlinien auf Workload-Ebene:

• Kubernetes NetworkPolicy — Default Deny, explizite Allow-Regeln
• Cilium — eBPF-basierte Durchsetzung, L7-Policy (HTTP-Methode, Pfad)
• Service Mesh Policies — AuthorizationPolicy in Istio (wer darf wen aufrufen)
• East-West Firewall — Kontrolle des lateralen Traffics, nicht nur North-South

Beispiel: order-service darf mit inventory-service und payment-service kommunizieren. Kein anderer Service. Ein Angreifer, der notification-service kompromittiert, erreicht keine Bestellungen.

4. Minimale Berechtigung & JIT-Zugriff¶

RBAC-Granularitaet: - Rollen definiert pro Service, pro Umgebung (Dev/Staging/Prod) - Keine Wildcard-Berechtigungen (*:*:*) - Regelmaessige Zugriffspruefungen — wer hat Zugang wozu und warum

Just-in-Time (JIT) Zugriff: - Administrator braucht keinen permanenten Prod-Zugang - Zugang anfordern → Genehmigung → zeitlich begrenzte Berechtigung (2-4h) → automatischer Widerruf - Audit Trail jedes Zugriffs - PAM (Privileged Access Management) fuer kritische Systeme

5. Kontinuierliche Verifizierung¶

Zero Trust endet nicht bei der Authentifizierung:

• Device Posture — Ist das Geraet verwaltet? Aktuelles OS? Endpoint Protection laeuft?
• Verhaltensanalyse — Anomalien im Benutzerverhalten (ungewoehnliche Login-Zeit, Standort, Zugriffsmuster)
• Session-Re-Evaluation — Risiko-Score wird laufend neu berechnet, nicht nur beim Login
• Adaptive Policies — Erhoehtes Risiko → Step-up-Authentifizierung erforderlich

Implementierungsfahrplan¶

Phase 1: Transparenz (Monat 1-2)¶

• Inventarisierung aller Services, Benutzer, Datenfluesse
• Monitoring des East-West-Traffics — wer kommuniziert mit wem
• Baseline fuer normales Verhalten
• Lueckenanalyse gegen Zero-Trust-Prinzipien

Phase 2: Identitaets-Foundation (Monat 2-3)¶

• SSO + MFA fuer alle Benutzer
• Workload Identity (SPIFFE/SPIRE oder Managed Identities)
• Service Mesh Deployment (mTLS im permissiven Modus — loggt, blockiert nicht)

Phase 3: Durchsetzung (Monat 3-5)¶

• mTLS Strict Mode — unverschluesselte Kommunikation blockiert
• NetworkPolicy / AuthorizationPolicy Enforcement
• JIT-Zugriff fuer Admin-Operationen
• Audit und Remediation minimaler Berechtigungen

Phase 4: Kontinuierlich (fortlaufend)¶

• Verhaltensanalyse und Anomalie-Erkennung
• Vierteljaehrliche Zugriffspruefungen
• Policy-as-Code — GitOps fuer Sicherheitsrichtlinien
• Red-Team-Uebungen fokussiert auf Lateral Movement

Technologie¶

Istio, Linkerd, Cilium, SPIFFE/SPIRE, Azure AD / Entra ID, Okta, HashiCorp Vault, Kubernetes NetworkPolicy, Open Policy Agent (OPA), Falco, CrowdStrike, Microsoft Defender for Cloud.