Zero Trust Networks
Zuletzt aktualisiert am
Zero Trust Networks stellt sicher, dass jeder Kommunikationspfad explizit erlaubt, begrenzt und beobachtbar ist statt implizit über Topologie vertraut zu werden.
Kontrollziele
Abschnitt betitelt „Kontrollziele“- Policy-gesteuerte Konnektivität: Jeder erlaubte Flow hat Owner und fachliche Begründung.
- Minimale laterale Bewegung: Ost-West-Kommunikation ist streng segmentiert.
- Expliziter Ingress und Egress: Internet- und Zonenverkehr laufen über kontrollierte Pfade.
- Kontinuierliche Verifikation: Richtlinien-Compliance wird im Betrieb überprüft.
Design-Empfehlungen
Abschnitt betitelt „Design-Empfehlungen“- Deny-by-default starten: Nur notwendige Kommunikationsbeziehungen freigeben.
- Trust-Zonen trennen: Workload-Gruppen nach Sensitivität, Laufzeitprofil und Ownership isolieren.
- Zentrale Kontrollen gezielt einsetzen: Firewall- und Routing-Governance für regulierte Pfade nutzen.
- Workload-nahe Richtlinien erhalten: Service-lokale Kontrollen nahe an APIs und Anwendungen belassen.
Umsetzungs-Checkpoints
Abschnitt betitelt „Umsetzungs-Checkpoints“- Connectivity-Matrix: Freigegebene Nord-Süd- und Ost-West-Flows mit Zweckbezug.
- Segmentierungs-Baseline: Verbindliches Zonen- und Subnetzmodell pro Landing-Zone-Typ.
- Egress-Governance: Klare Outbound-Regeln für Updates, Drittanbieter-APIs und Integrationen.
- Telemetry-Abdeckung: Protokolle für Policy-Entscheidungen, Drops und Auffälligkeiten.
STACKIT-Referenzen
Abschnitt betitelt „STACKIT-Referenzen“- Netzwerkbereich und Routing-Tabellen: Concepts und Routing Tables
- Unified Firewall: Dokumentation
Anti-Patterns vermeiden
Abschnitt betitelt „Anti-Patterns vermeiden“- Flache Trust-Zonen: Breite Erreichbarkeit zwischen fachlich unabhängigen Workloads.
- Implizites Service-Vertrauen: Ost-West-Kommunikation ohne Policy-Owner.
- Firewall-only-Denken: Zentrale Kontrollen ersetzen service-nahe und identitätsbasierte Kontrollen.