Zero Trust Technologienfeedback
Dieses Dokument ist ein früher Entwurf (Early Draft) und befindet sich noch in der aktiven Bearbeitung.
Erstellt am: 12. März 2026 | Zuletzt geändert: 13. März 2026 | Autor: Matthias, Enrico (GitLab)
info 1. Einleitung & Kontextfeedback
Die Grundidee von Zero Trust besagt, dass "kein Vertrauen als Voreinstellung" (Never trust, always verify) gilt. Es existieren keine implizit vertrauenswürdigen Netzwerke mehr. Dies erfordert radikale Paradigmenwechsel gegenüber klassischen Perimeter-Security-Ansätzen (Behördennetzwerke mit Firewall).
Die Zero-Trust-Eckpunkte des Bundes (V1.0, August 2025) definieren fünf Eckpunkte als Zielkorridor für die Weiterentwicklung der IT-Sicherheitsarchitektur des Bundes. Die Anforderungsprofile werden durch den IT-Grundschutz++ definiert.
Zentrale Maximen nach BSI und NIST:
- Explizite Verifizierung: Jeder Zugriff wird anhand aller verfügbaren Datenpunkte (Identity, Device-State, Location, Anomaly Detection) geprüft (Siehe auch SCS & DVC für infrastrukturseitiges Trusting).
- Least Privilege: Zugriff wird auf das absolut Notwendige (Just-In-Time und Just-Enough-Access) limitiert.
- Assume Breach: Proaktive Annahme von Sicherheitsvorfällen; stetige Netzwerküberwachung, Ende-zu-Ende-Verschlüsselung und Micro-Segmentation zur Eindämmung von Lateral Movement.
Abgleich mit GovStackfeedback
Wie bereits im Management Summary beschrieben, fokussiert sich das GovStack-Universum primär auf den reinen Aspekt der föderierten Identität (Identity Building Block). Dies hinterlässt eklatante Lücken in der Sicherheitsarchitektur. Für den Beweisrahmen deploymentfähiger Strukturen wie den D-Stack muss zwingend ein weitreichenderer, auf BSI und NIST basierender Rahmen gespannt werden.
shield 2. ZT-Architektur: Die 6 Säulenfeedback
Basierend auf den Prinzipien des CISA Zero Trust Maturity Models (siehe Best Practices) definiert der D-Stack sechs wesentliche Architektur-Säulen.
Kurzübersichtfeedback
Die Kurzdarstellung fasst die sechs Säulen kompakt zusammen. Sie ist als Orientierung für Entscheider gedacht.
1️⃣ Identity
- Kontinuierliche Verifizierung aller Identitäten (User, Services, Machines)
- Phishing-resistentes MFA (FIDO2)
- Risikobasierte Zugriffskontrolle (Risk-Based Access)
- Zentralisiertes Identity Governance System
2️⃣ Devices
- Echtzeit-Gesundheitsprüfung (Health Check) aller Endgeräte
- Mobile Device Management (MDM)
- Endpoint Detection & Response (EDR)
- Hardware-gestützte Vertrauensanker (TPM, Secure Boot)
3️⃣ Networks
- Interne Netzwerke gelten als untrusted
- Ende-zu-Ende-Verschlüsselung überall
- Micro-Segmentation nach Application-Clustern
- Eindämmung von Lateral Movement
4️⃣ Applications
- Cloud Workload Protection (CWPP)
- Permanente Container-Image / IaC-Scans (Shift-Left Security)
- Zertifizierte SBOM-Lieferkette für gehärtete Images
- Web Application Firewall (WAF) mit L7-Analyse
5️⃣ Data
- Hochgradige Verschlüsselung im Ruhezustand (Data at Rest)
- Verschlüsselung auf dem Übertragungsweg (Data in Transit)
- Data Leakage Prevention (DLP)
- Klassifizierung & Policy-Enforcement nach Sichtbarkeit
6️⃣ Visibility
- Continuous Adaptive Risk and Trust Assessment (CARTA)
- Zentrale Telemetrie (Logs, Metrics, Traces)
- Security Information & Event Management (SIEM)
- Security Orchestration, Automation & Response (SOAR)
- Anomalie-Erkennung & proaktive Reaktion
Detail-Anforderungenfeedback
- Identity (Identität): Kontinuierliche Evaluierung (User, Services, Maschinen) mit starkem, phishing-resistentem MFA (z.B. FIDO2) und zentralisierter Governance.
- Devices (Endgeräte): Echtzeit-Health-Checks für jedes zugreifende Gerät, MDM, EDR und Hardware-Trust-Anchor (TPM).
- Networks (Netzwerke): "Untrusted" als Standard. Ende-zu-Ende-Verschlüsselung und strikte Micro-Segmentation.
- Applications & Workloads: Eigenständige Absicherung in der DVC durch CWPP, Shift-Left Security Scans und WAF. Einsatz ausschließlich gehärteter Images mit nachvollziehbarer und prüfbarer SBOM-Lieferkette.
- Data (Daten): Umfassende Verschlüsselung (At Rest & In Transit), DLP und striktes Policy-Enforcement.
- Visibility & Analytics (CARTA): Zentrale Telemetrie (SIEM) und automatisierte Reaktion (SOAR) für proaktive Anomalie-Erkennung.
policy Policy-as-Code Umsetzungfeedback
Damit die Zero-Trust-Empfehlungen direkt durchsetzbar sind, werden sie als Policy-as-Code umgesetzt (z. B. OPA/Gatekeeper oder Kyverno). Konkrete Templates und Beispiele stehen im Baustein Zero-Trust-Policy-Engine.
Typische Regeln:
- Nur signierte Images aus freigegebenen Registries
runAsNonRootund minimale Linux-Capabilities- Netzwerkzugriffe nur über definierte Service-Identitäten
bug_report 3. Schwachstellenanalyse: Das CA-Problemfeedback
Unter der Oberfläche von Zero Trust verbergen sich oft implizite und ungeprüfte Vertrauensanker wie CAs (Certificate Authorities). Das System hat hier ein fundamentales Design-Problem:
- Single Point of Failure: Alle CAs sind oft gleichwertig vertrauenswürdig. Ein Kompromiss einer einzigen CA gefährdet das gesamte Vertrauensnetzwerk.
- Inkonsistente Qualität: CAs operieren weltweit unter verschiedenen Jurisdiktionen und Standards.
- Audit-Lücken: Selbst Audits (z.B. WebTrust) verhindern keine katastrophalen Fehler (Bsp. DigiNotar).
- Revocation-Probleme: Fehlerhafte Revocation-Mechanismen können Millionen Zertifikate betreffen (Bsp. Let’s Encrypt Bug 2020).
Fazit: Die CA ist oft der blinde Fleck. Man vertraut einem System bedingungslos, das die Grundlage für „never trust, always verify” bildet.
lightbulb 4. Lösungsansätze: Attestierung statt statischem Vertrauenfeedback
Die technische Antwort: SPIFFE/SPIREfeedback
Dieser Teil erklärt, wie SPIFFE/SPIRE das Trust-Problem löst. Er zeigt, warum Workload-Identitäten für Zero Trust zentral sind.
SPIFFE (Secure Production Identity Framework for Everyone) und dessen Referenzimplementierung SPIRE adressieren das CA-Problem durch Identity-Attestation. Statt statischer Zertifikate werden kurzlebige, kryptografisch attestierte Workload-Identitäten (SVIDs) ausgestellt.
| Merkmal | Klassische CA | SPIFFE/SPIRE |
|---|---|---|
| Gültigkeit | Langlebige Zertifikate (1–2 Jahre) | Kurzlebige SVIDs (Minuten bis Stunden) |
| Ausstellung | Manuelle Ausstellung | Automatische Attestierung via Runtime |
| Schadensfall | Kompromiss = langfristiger Schaden | Ablauf = auto-invalidiert |
| Vertrauen | Einzelner Vertrauensanker | Dezentrale Trust Domains |
| Resilienz | CA-Ausfall = kompletter Ausfall | Resilientes Mesh |
Integration:
- Cloud-Native: Red Hat OpenShift nutzt SPIRE für Zero Trust Workload Identity Management.
- Data Spaces: Für Dataspace-Connectoren ist eine zusätzliche Absicherung der Laufzeitumgebung über SPIFFE architektonisch denkbar. Die öffentlich dokumentierten Identitätsmechanismen in Eclipse Dataspace Components bzw. DSP basieren jedoch primär auf DIDs, Verifiable Credentials und OAuth2-Token.
code 5. Referenzimplementierungen & Standardsfeedback
Erfolgreiche Zero-Trust-Architekturen stützen sich auf validierte Modelle und Standards.
NIST & NCCoEfeedback
Das NCCoE-Projekt „Implementing a Zero Trust Architecture" hat gemeinsam mit 24 Technologiepartnern 19 vollständige ZTA-Beispielimplementierungen in Laborumgebungen erarbeitet und in NIST SP 1800-35 (finalisiert Juni 2025) dokumentiert. Die vollständige Online-Dokumentation enthält Referenzarchitekturen, Konfigurationsanleitungen und Testergebnisse.
Struktur des Leitfadens:
| Band | Inhalt |
|---|---|
| A, Executive Summary | Überblick, Projektmotivation, zentrale Ergebnisse |
| B, Architecture & Builds | Referenzarchitekturen, Bedrohungsmodelle, Pillar-Mapping nach SP 800-207 |
| C, How-To Guides | Schritt-für-Schritt-Anleitungen für jede Implementierung |
| D, Functional Demonstrations | Testergebnisse der Use Cases und Szenarien |
| E, Risk & Compliance | Mapping auf NIST CSF 1.1/2.0 und SP 800-53r5 |
Vier ZTA-Ansätze:
| Ansatz | Beschreibung | Fokus |
|---|---|---|
| EIG (Enhanced Identity Governance) | Identität als primäres Zugriffssteuerungskriterium; ICAM als PDP | Identitätszentriert |
| SDP (Software-Defined Perimeter) | Dynamische, tunnelbasierte Verbindungen zwischen Subject und Ressource | Netzwerkzentriert |
| Mikrosegmentierung | Feingranulare Aufteilung in isolierte Netzsegmente auf Basis von Maschinenidentitäten | Applikationszentriert |
| SASE (Secure Access Service Edge) | Cloud-basierte Durchsetzung von Sicherheitsrichtlinien am Netzwerkrand | Cloud-zentriert |
Die 19 Referenzimplementierungenfeedback
Die 19 Builds verteilen sich auf vier Laborumgebungen (Enterprise 1–4) und durchlaufen drei Phasen: EIG Crawl (Basisfähigkeiten mit vorhandener ICAM-Infrastruktur), EIG Run (erweitert um Cloud-Ressourcen und dedizierte PDP-Komponenten) und SDP/Mikrosegmentierung/SASE (vollständige Referenzarchitektur).
| Build | Phase / Ansatz | Kernfähigkeiten |
|---|---|---|
| E1B1 | EIG Crawl | ICAM als PE, Endpoint-Schutz, Identity Governance, SIEM |
| E2B1 | EIG Crawl | Föderierte Identität, ICAM als PE, Netzwerk-Firewall |
| E3B1 | EIG Crawl | Conditional Access als PE, Endpoint-Schutz, Mobile Threat Defense |
| E1B2 | EIG Run | Dedizierter SDP-Controller als PE, Cloud-Ressourcen, Tunneling |
| E3B2 | EIG Run | Conditional Access + UEM + Device Discovery als PEs |
| E4B3 | EIG Run | Cloud-Identity-Verification als PE, Datenverschlüsselung, UEM |
| E1B3 | SDP | SDP-Controller als PE, Cloud-IaaS, ZTNA-Tunnel |
| E2B3 | Mikrosegmentierung | Netzwerk-Identitätsdienst + Workload-Schutz als PEs |
| E3B3 | SDP + Mikrosegmentierung | Conditional Access + UEM + SIEM + Device-Compliance als PEs, DLP |
| E1B4 | SDP | Dedizierter SDP-Controller und Gateway, Mobile Threat Defense |
| E2B4 | SDP + SASE | Cloud-SWG, ZTNA, CASB als PEs, DLP |
| E3B4 | SDP | Reverse Proxy + Application Delivery als PEs, Device-Compliance |
| E4B4 | SDP + Mikrosegmentierung + EIG | UEM + Access Gateway + Netzwerkvirtualisierung als PEs |
| E1B5 | SASE + Mikrosegmentierung | NGFW + Cloud-SASE als PEs, SD-WAN |
| E2B5 | SDP + SASE | Security Service Edge (SSE) + Cloud-Identity als PEs |
| E3B5 | SDP + SASE | Conditional Access + SSE (Private/Internet Access) als PEs, DLP |
| E4B5 | SDP + Mikrosegmentierung | Cloud-nativer Verified Access + Service Mesh als PEs |
| E1B6 | SDP + Mikrosegmentierung | ZTNA-Gateway + Identity-Cloud als PEs |
| E2B6 | SASE | Cloud-Enterprise-Browser + Context-Manager als PE |
Alle Builds verwenden die NIST SP 800-207 Referenzarchitektur mit Policy Engine (PE), Policy Administrator (PA) und Policy Enforcement Point (PEP). Die funktionale Evaluation umfasst Use Cases wie Fernzugriff, BYOD, Branch-Office-Anbindung und Cloud-Ressourcenzugriff.
PDP/PEP-Architekturmuster:
Ein zentrales Architekturmuster in SP 1800-35 ist die strikte Trennung von Entscheidungs- und Durchsetzungslogik:
- Der Policy Decision Point (PDP) evaluiert alle Zugriffsanfragen anhand aktueller Kontextdaten (Identität, Gerätezustand, Netzwerklage, Datensensitivität).
- Der Policy Enforcement Point (PEP) setzt die Entscheidung inline durch; kein Zugriff ohne explizite PDP-Freigabe.
- Policies werden als Code verwaltet (Policy-as-Code), sodass Änderungen nachvollziehbar versioniert, getestet und auditiert werden können.
US DoD Zero Trust Strategyfeedback
Das US-Verteidigungsministerium (DoD) treibt mit seiner Zero Trust Strategy die wohl größte ZTA-Transformation voran.
- Roadmap: Umsetzung von 91 spezifischen ZT-Fähigkeiten (Target Level).
- Evolution: Ablösung klassischer PKI durch attestierungsbasierte Identitäten (wie im CA-Kapitel thematisiert).
- Aktualität: Laufende Weiterentwicklung (ZT Strategy 2.0 angekündigt für 2026/27).
Best Practices erfolgreicher Implementierungenfeedback
- CA-Abhängigkeit minimieren: Kurzlebige Tokens statt langlebiger Zertifikate.
- Hardware-Roots of Trust: Nutzung von TPM, HSM und FIDO2 als unveränderliche Anker.
- Policy Decision Point (PDP): Zentrale, echtzeitfähige Instanz für Zugriffsentscheidungen.
- Messbarkeit: Fokus auf Metriken (z.B. Ticket-Reduktion, Time-to-Detect) statt reiner Compliance.
public 6. Adaption im Behördenkontext (Deutschland / EU)feedback
NIST SP 1800-35 ist primär für den US-Bundeskontext (FISMA, FedRAMP) entwickelt worden. Die Übertragung auf deutsche Behörden erfordert gezielte Anpassungen. Das Eckpunktepapier Zero Trust V1.0 definiert die fünf Eckpunkte und 15 Anforderungen für die IT-Sicherheitsarchitektur des Bundes. Der IT-Grundschutz++ liefert die zugehörigen Anforderungsprofile.
Regulatorisches Alignmentfeedback
| NIST SP 1800-35 | Deutsches / EU-Äquivalent |
|---|---|
| FISMA / FedRAMP | BSI IT-Grundschutz / Grundschutz++, BSI C5-Testat |
| Identity Pillar (OIDC/SAML, MFA) | BundID, EUDI-Wallet, EfA-SSO als föderale Identitätsanker |
| Device Compliance (MDM, EDR) | BSI-Grundschutz IT-Betrieb, BSI C5-konforme Cloud-MDM |
| Continuous Monitoring / SIEM | BSI IT-Sicherheitsgesetz 2.0, SIEM-Pflichten für KRITIS |
| Data-centric Protection | DSGVO/BDSG: Datensparsamkeit, Verarbeitungsverzeichnis, Privacy by Design |
| NATO Zero Trust Policy | Eckpunkte Zero Trust V1.0: 6 NATO-Prinzipien, 5 Eckpunkte |
| Vendor-Mix (kommerziell) | Open-Source-Stack möglich (Keycloak, OPA, Istio) + BSI-Zulassungsanforderungen |
Föderale Identitätsarchitekturfeedback
Anders als im US-Modell mit einem zentralen Identitätsprovider erfordert die bundesstaatliche Struktur Deutschlands einen föderalen Identitätsverbund:
- BundID als Basisbürgerkonto für Verwaltungsleistungen
- EUDI-Wallet (EU Digital Identity) als künftiger grenzüberschreitender Identitätsnachweis
- EfA-SSO (Einmal-für-Alle) für behördenübergreifende Single-Sign-On-Szenarien
- Identitätsentscheidungen müssen DSGVO-konform protokolliert werden; personenbezogene Log-Daten sind zweckgebunden zu verarbeiten
DSGVO-spezifische Besonderheitenfeedback
Continuous Monitoring ist regulatorisch sensibel: Verhaltensbasiertes Nutzermonitoring und UEBA (User and Entity Behavior Analytics), wie es SP 1800-35 empfiehlt, läuft in Deutschland schnell in Konflikt mit dem Datenschutz. Folgende Maßnahmen sind erforderlich:
- Technisch-organisatorische Maßnahmen (TOMs) für jedes Monitoring-System
- Einbeziehung des/der Datenschutzbeauftragten (DSB) in die ZTA-Architektur
- Pseudonymisierung von Nutzerdaten in SIEM/SOAR-Systemen
- Löschkonzept für Protokolldaten (i.d.R. 3–6 Monate)
Souveränitäts- und Beschaffungsanforderungenfeedback
- Cloud-Souveränität: Zero-Trust-Kernkomponenten (PDP/PEP, SIEM) sollten auf BSI-zertifizierter oder EU-souveräner Infrastruktur betrieben werden, um US-Cloud-Act-Exposition zu vermeiden.
- BSI-Technische Richtlinien: TR-02102 (Kryptographische Verfahren) und TR-03116 (Kryptographische Anforderungen für eGovernment) definieren verbindliche Algorithmen und Schlüssellängen.
- ENISA-Leitlinien ergänzen die BSI-Vorgaben auf EU-Ebene, insbesondere für grenzüberschreitende Dienste.
- Open-Source bevorzugt: Der D-Stack priorisiert quelloffene ZTA-Komponenten (Keycloak, OPA/Gatekeeper, Istio, SPIRE), um Vendor-Lock-in zu vermeiden und unabhängige Sicherheitsaudits zu ermöglichen.
summarize 7. Fazitfeedback
Zero Trust ist keine Produkt-Kategorie, sondern eine Architektur-Philosophie. Für den D-Stack bedeutet dies:
- GovStack ist nicht genug: Die Identitäts-Bausteine müssen durch ein striktes Zero-Trust-Rahmenwerk (NIST/BSI) gehärtet werden.
- Moderne Identity-Konzepte: Weg von statischen Zertifikaten hin zu dynamischer Attestierung (SPIFFE/SPIRE).
- Ganzheitlichkeit: Sicherheit muss über alle 6 Säulen (Identity, Device, Network, App, Data, Visibility) synchronisiert werden.
- 19 NIST-Referenzimplementierungen liefern validierte Architekturmuster für EIG, SDP, Mikrosegmentierung und SASE, die als Blaupause für bundesspezifische Umsetzungen dienen.
arrow_forward Weiterführende Dokumentefeedback
- Zero-Trust-Eckpunkte Bund (V1.0) – Fünf Eckpunkte und 15 Anforderungen für die IT-Sicherheitsarchitektur des Bundes
- IT-Grundschutz++ – Anforderungsprofile für Zero Trust
- Fachanwendungen absichern – Praktische Absicherungsmuster mit ZTA-Komponenten
- Sicherheit und Compliance – Übergeordnete Sicherheitsvorgaben
- NIST SP 1800-35 Online – Vollständige Dokumentation der 19 Referenzimplementierungen