Zero Trust Architektur
Kurze Zusammenfassung
Zero Trust (ZT) ist ein Sicherheitsmodell, bei dem der Netzwerkperimeter nicht mehr als vertrauenswürdige Zone betrachtet wird. Jede Anfrage (user→app, service→service, device→network) wird explizit authentifiziert, autorisiert und verschlüsselt, wobei kontextbezogene Signale (Identität, Gerätestatus, Standort, Risiko, Verhalten) berücksichtigt werden. Ziel ist es, den Blast-Radius zu minimieren, das Risiko einer lateralen Bewegung zu reduzieren und die Compliance zu vereinfachen.
Grundlagen von Zero Trust
1. Es gibt kein explizites Vertrauen: Vertrauen wird nicht vom Netzwerk/VPN/ASN geerbt.
2. Zugang minimal notwendig: Die Politik „stellt nur das zur Verfügung, was jetzt gebraucht wird“.
3. Kontinuierliche Verifizierung: Sitzungen und Token werden regelmäßig nach Risiko und Kontext neu bewertet.
4. Annahme der Kompromittierung: Segmentierung, Beobachtbarkeit, schnelle Wartung und Schlüsselrotation.
5. Verschlüsselung überall: TLS 1. 2+/1. 3 und mTLS innerhalb der Datenpläne, geschützt durch DNS, Geheimnisse im KMS/HSM.
Ziellandschaft und Kontrolldomänen
Identität: Personen (IdP: SSO, MFA, passkeys/FIDO2), Maschinen (SPIFFE/SVID, x509/mTLS).
Geräte: Richtlinienkonformität (MDM/EDR, Festplatte verschlüsselt, Patches, Jailbreak/root - verboten).
Netzwerk: Mikrosegmentierung L3/L7, ZTNA/SDP-Gateways, Service-Mesh (Envoy/Istio/Linkerd).
Anwendungen/API: mTLS, OIDC/JWT, Request Signatures (HMAC), Rate Limits, DLP/Masking.
Daten: Klassifizierung (Public/Confidential/Restricted), Tokenisierung/Verschlüsselung auf Feldebene.
Beobachtbarkeit: zentrale Authentifizierungs-/Autorisierungsprotokolle, Verhaltensanalyse, SLO/SLA.
Referenzarchitektur (im Schnitt der Ebenen)
Kontrollebene: IdP/CIAM, PDP/PEP (OPA/Envoy), Richtlinienkataloge, PKI/CA, Gerätezertifizierung.
Datenebene: Proxy-Zugriff (ZTNA), Sidecar-Proxy (Envoy) für mTLS und L7-Richtlinie, Service-Gateways/GW-APIs.
Management Plane: Service Directory, CMDB, CI/CD, Secret Management (Vault/KMS), zentrales Audit.
1. Identifizierung (SSO + phishing-resistant MFA) → 2) Gerätebewertung (MDM posture) → 3) ZTNA-Proxy setzt mTLS auf Anwendung → 4) PDP (Richtlinien) entscheidet auf der Grundlage von Attributen (ABAC/RBAC) → 5) kontinuierliche Neubewertung des Risikos (Zeit, Geo, Anomalien).
Identität und Autorisierung
IdP/SSO: OIDC/SAML, Standard-MFA, vorzugsweise FIDO2 (passkeys).
RBAC/ABAC: Rollen + Kontextattribute (Gerätestatus, Abteilung, Risikoprofil).
Just-In-Time (JIT) Zugang: temporäre Privilegien mit automatischem Widerruf; break-glass ist streng reglementiert.
mTLS für Maschinen: SPIFFE/SVID oder interne PKI mit kurzlebigen Zertifikaten; automatische Rotationsfreigabe.
Geräte und Kontext
Konformitätsprüfung (posture): OS/EDR-Version, mitgeliefertes Disk-Encripte, Firewall; non-compliant → Zugang zu einem Minimum oder Block.
Zertifizierung: device identity + signed attestations (MDM/Endpoint).
Netzwerkbeschränkungen: Tunnelblock von Drittanbietern, erzwungenes Unternehmens-DNS, Schutz vor DNS/WebRTC-Lecks.
Netzwerk und Mikrosegmentierung
Ablehnung von „flachen“ VLANs: stattdessen Segmente/VRFs und Richtlinien auf L7.
Service Mesh: Sidecar-Proxies bieten mTLS, Richtlinienautorisierung (OPA/EnvoyFilter), Telemetrie.
ZTNA/SDP: Zugriff auf eine bestimmte Anwendung, nicht auf ein Netzwerk; kliyent↔broker↔app, Politik in der PDP.
Remote Access: Ersetzen Sie ein „dickes“ VPN durch einen App-Proxy; fallback-Tunnel sind auf Routen/Häfen begrenzt.
Richtlinien und Lösungsmotor
PDP/PEP: Policy Decision Point (OPA/Styra, Cedar и пр.) + Policy Enforcement Point (Envoy/Istio/Gateway).
Richtlinienmodell: deklarative Regeln (Rego/Cedar), statische und kontextbezogene Attribute, Risikobewertung.
rego package access. http
default allow = false
allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}Entscheidungsverfolgung: Loggen Sie' input '/' result '/' explain 'für das Audit.
Standardverschlüsselung und Vertrauensstellung
TLS 1. 2+/1. 3 überall, strenge Chiffriersuite, HSTS, OCSP stapling.
mTLS intern: servis↔servis nur mit gegenseitigen Zertifikaten; Schlüssel kurz lebendig (Stunden/Tage).
Geheimnisse: KMS/HSM, dynamische Geheimnisse (Vault), kurze TTLs, least-privilege für Anwendungen.
Beobachtbarkeit, SLO und Reaktion
Metriken (Mindestsatz):- Erfolg der Authentifizierung und Autorisierung (%), p95 Entscheidungszeit PDP, p95 TLS-handshake.
- Prozentsatz der Anfragen, die von der Richtlinie blockiert wurden (Anomalien/falsch).
- Verfügbarkeit von ZTNA-Brokern und Mesh-Controller.
- Anteil der konformen Geräte und Trends.
- Verfügbarkeit von ZTNA ≥ 99. 95 %/Monat; p95 authZ decision ≤ 50 мс».
- Anteil der Anfragen mit mTLS ≥ 99. 9%».
- "Nicht mehr als 0. 1% falsche Zugangsverweigerung/Tag".
Alarting: Deny-Ausbrüche, p95-Abbau von Handshakes, nicht-valide Ketten, Rückgang des Anteils konformer Geräte, Geographie/ASN-Anomalien.
Übergang vom Perimeter zum Zero Trust: eine Roadmap
1. Bestandsaufnahme: Anwendungen, Datenströme, Verbraucher, Sensitivität (PII/Karte/Auszahlung).
2. Identität und MFA: SSO und phishing-resistent MFA für alle.
3. Gerätekontext: MDM/EDR, grundlegende Compliance-Richtlinien, Non-Compliant-Block.
4. Mikrosegmentierung von Prioritätspfaden: Zahlungen, Backoffice, Admin; Eingabe von mTLS.
5. ZTNA für Benutzerzugriff: Veröffentlichen von Anwendungen über Proxy, Entfernen von „Wide VPN“.
6. ABAC-Richtlinien: zentralisierte PDP, deklarative Regeln, Audit.
7. Erweiterung auf Service-Mesh: S2S mTLS, L7-Richtlinie, Telemetrie.
8. Automatisierung und SLO: Alerting, Policy Tests (Policy CI), Game Days "was ist, wenn IdP nicht verfügbar ist? ».
Spezifität für iGaming/Fintech
Starre Domain-Segmentierung: Payments/PII/Fraud/Content - Separate Perimeters und Policies; Zugriff nur über ZTNA.
Interaktion mit PSPs/Banken: allow-list über ASNs/Bänder, mTLS zu PSP Endpoints, Time-to-Wallet Überwachung und Fehler auf authZ.
Inhaltsanbieter und Partner: temporäre JIT-Zugriffe auf APIs, Token mit kurzen TTLs, Integrationsprüfung.
Compliance: PCI DSS/DSGVO - Datenminimierung, DLP/Pseudonymisierung, Protokollierung von Zugriffen auf sensible Tabellen.
Sicherheit in Lieferketten und CI/CD
Artefakt-Signaturen (SLSA/Provenance): Container-Signaturen (Cosign), Admission-Richtlinie im K8s.
SBOM und Schwachstellen: Generierung von SBOM (CycloneDX), Policy-Gate in der Pipeline.
Geheimnisse in CI: OIDC-Verband zu Cloud KMS; Verbot von statischen Schlüsseln.
Rotation: häufig, automatisch; erzwungene Revoke bei Vorfällen.
Typische Fehler und Anti-Muster
„ZTNA = New VPN“: Netzwerk-Veröffentlichung statt Apps ist kein Zero Trust.
Keine Geräteüberprüfung: Es gibt MFAs, aber infizierte/gerootete Geräte greifen zu.
Ein einziger Super-User: keine JIT und getrennte Rollen.
Richtlinien im Code der Dienste: Unmöglichkeit einer zentralen Prüfung/Aktualisierung.
mTLS partiell: Ein Teil der Dienste ohne mTLS → eine „undichte“ Schleife.
Null UX: redundante MFA-Anfragen, kein SSO; Das Ergebnis ist Widerstand gegen Teams.
Mini-Hyde für die Auswahl der Technologien
Benutzerzugriff: ZTNA/SDP Broker + IdP (OIDC, FIDO2 MFA).
In-Service-Sicherheit: Service Mesh (Istio/Linkerd) + OPA/Envoy authZ.
PKI: SPIFFE/SVID oder Vault PKI mit kurzen TTLs.
Richtlinien: OPA/Rego oder Cedar; in Git speichern, in CI prüfen (Policy-Tests).
Protokolle und Telemetrie: OpenTelemetry → zentralisierte Analyse, Anomaliedetektion.
Beispielkonfigurationen (Fragmente)
Envoy (mutual-TLS zwischen Diensten)
yaml static_resources:
listeners:
- name: listener_https filter_chains:
- filters:
- name: envoy. filters. network. http_connection_manager typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. network. http_connection_manager. v3. HttpConnectionManager route_config: { name: local_route, virtual_hosts: [] }
transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params: { tls_minimum_protocol_version: TLSv1_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: trueOPA/Rego: Zugriff auf Berichte nur aus „Finanzen“, von konformen Geräten, während der Geschäftszeiten
rego package policy. reports
default allow = false
allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}Checkliste für Zero Trust-Implementierung
1. Aktivieren Sie SSO und MFA- FIDO2 für alle Benutzer und Admins.
2. Geben Sie device posture (MDM/EDR) mit non-compliant lock ein.
3. Übersetzen Sie den Benutzerzugriff auf ZTNA (per-app), lassen Sie das VPN nur für enge S2S-Kanäle.
4. Innen - mTLS Standard + kurzlebige Zertifikate.
5. Richtlinien zentralisieren (PDP/OPA), in Git speichern, in CI testen.
6. Segmentieren Sie sensible Domains (Payments/PII/Backoffice) und beschränken Sie Ost-West.
7. Konfigurieren Sie Telemetrie, SLO und Alerting auf auth/authZ, mTLS-Anteil, Posture-Signale.
8. Halten Sie „Game Days“ (IdP-Ausfall, Schlüsselleck, Broker-Drop) und erfassen Sie SOP/Rollbacks.
FAQ
Ersetzt Zero Trust VPN komplett?
Für den Benutzerzugriff - ja, zugunsten von ZTNA. Für S2S-Backbones kann VPN/IPsec bleiben, aber mit mTLS oben und strengen Richtlinien.
Kann ZT die UX verschlechtern?
Wenn gedankenlos. Mit SSO + FIDO2, adaptivem MFA und Per-App-Zugriff verbessert sich UX in der Regel.
Muss Service Mesh eingeführt werden?
Nicht immer. Aber für eine große Microservice-Umgebung vereinfacht mesh mTLS/Policy/Telemetrie radikal.
Summe
Zero Trust ist kein Produkt, sondern eine architektonische Disziplin: Identität als neuer Perimeter, Gerätekontext, Application Access (ZTNA), Mikrosegmentierung und mTLS überall, zentralisierte Richtlinien und messbare Zuverlässigkeit. Indem Sie der Roadmap und der Checkliste folgen, reduzieren Sie die Angriffsfläche, beschleunigen das Audit und erhalten nachhaltige Sicherheit ohne „Standardvertrauen“.