Wissensraum · Deep Dive 20 von 22
Zero Trust als Governance-Architektur
Organisationales Sicherheitsprinzip jenseits von IT-Buzzwords: „Never trust, always verify“ als Rahmen für Compliance, Auditierbarkeit und regulatorische Widerstandskraft.
Fünf Säulen (Identity, Device, Network, Workload, Data) · NIS2/DORA/AI Act Alignment · Implementierungsebenen · Schweizer Kontext · M&A-Signal
1. Von Forrester bis NIST: Die Genealogie des Zero-Trust-Gedankens
Zero Trust entstand 2010 aus einer klugen Frage des Forrester-Analysten John Kindervag: Warum vertrauen wir Geräten automatisch, nur weil sie sich im Unternehmensnetzwerk befinden? Das war das Ende der Perimeter-Ära. Über zehn Jahre gingen NIST SP 800-207 (2020) und nationale Standards folgten – nicht als IT-Mode, sondern als Antwort auf reale Threats und regulatorische Anforderungen.
Der Schritt vom Buzzword zur Governance-Architektur war konsequent: Wenn Vertrauen die Wurzel der Sicherheit ist, dann muss Vertrauen überall überprüft werden. Das gilt für Nutzerzugriffe, Geräte, Netzwerkpfade, Anwendungen und Daten.
2. Die fünf Säulen: Identity, Device, Network, Workload, Data
Zero Trust baut auf fünf Verifikationssäulen auf, die zusammen ein ganzheitliches Governance-Modell ergeben:
Identity. Wer bist du wirklich? Multi-Factor Authentication, Conditional Access, und kontinuierliches Risiko-Scoring. Jede Identität – Mensch oder Service – wird einzeln verifiziert.
Device. Ist dein Gerät sicher? Hardware-Verifikation, Patch-Status, Endpoint Detection & Response (EDR). Kein Gerät genießt automatisch Vertrauen nur weil es firmeneigen ist.
Network. Über welche Route kommunizierst du? Mikrosegmentierung, Zero-Trust Network Access (ZTNA, aka BeyondCorp-Architektur). Standardmäßig verweigert, nur explizit autorisierte Verkehre passieren.
Application & Workload. Welche Anwendung oder welcher Service läuft? Workload-Identität, mTLS, API-Autorisierung. Services vertrauen einander nicht automatisch; jeden Request prüft eine Richtlinie.
Data. Wer darf auf welche Daten zugreifen, wann, wie? Attribute-based Access Control (ABAC), Encryption at rest und in transit, Data Loss Prevention (DLP). Datenzugriff ist nicht ein Ja/Nein, sondern ein kontinuierlicher Autorisierungs-Fluss.
3. Warum „Trust but Verify“ in regulierten Umfeldern scheitert
„Trust but verify“ klingt verständig, bedeutet aber: Erst vertrauen, dann nachschauen. In regulierten Branchen ist das oft zu spät.“
Der klassische Ansatz „Vertraue deinen Mitarbeitern und Systemen, überprüfe sie gelegentlich“ funktioniert in Compliance-Szenarien nicht:
Audit-Nachweise entstehen zu spät; wenn ein Sicherheitsvorfall passiert, fehlen granulare Logs.
Lateral Movement wird erst nach Tagen oder Wochen erkannt – zu spät für Notfall-Incident-Response.
Segregation of Duties (SoD) ist schwer durchzusetzen, wenn mehrere Systeme implizites Vertrauen gewähren.
Zero Trust dreht das um: Standardmäßig verweigern, kontinuierlich verifizieren, Audit-Trail von Anfang an.
4. Regulatorisches Alignment: NIS2, DORA, AI Act
NIS2 verlangt für wesentliche und wichtige Einrichtungen „angemessene Sicherheitsmassnahmen“. Zero-Trust-Prinzipien können deren Umsetzung unterstützen: kontinuierliche Zugriffskontrolle, Netzwerk-Segmentation, Identity-Governance — vorgeschrieben ist ein vollständiges Zero-Trust-Modell aber nicht.
DORA Art. 17–23 (Incident Reporting), Art. 26 (Threat-Led Penetration Testing, TLPT), Art. 9–10 (Schutz, Erkennung, Logging). Zero Trust kann unterstützen, dass:
sicherheits- und risikorelevante Zugriffe angemessen nachvollziehbar geloggt werden (Audit Trail).
Penetration-Tester Lateral Movement schnell entdecken (TLPT wird effektiver).
Incident-Response-Zeit sinkt, weil Echtzeit-Visibility über alle Überprüfungen besteht.
Art. 9 regelt das Risikomanagementsystem; Zugriffssteuerung und Cybersicherheit werden vor allem über Art. 15 konkret. Zero Trust ist keine aus Art. 9 folgende Standardarchitektur, kann aber die Zugriffs- und Modell-Governance unterstützen: Wer kann Modelle trainieren, deployen, modifizieren? Workload Identity und API-basierte Kontrolle helfen, dass nur autorisierte Operationen stattfinden.
5. Implementierungsebenen: Technisch, Organisatorisch, Strategisch
Mikrosegmentierung: Netzwerk in vertrauenslose Zonen teilen; Micro-VLANs, Software-defined Perimeter.
Multi-Factor Authentication (MFA): Mindestens zwei Faktoren (Was du kennst, was du hast, wer du bist).
Least Privilege: Standardmäßig minimale Berechtigungen; explizite Erhöhung dokumentiert.
Continuous Monitoring: EDR, SIEM, Behavioral Analytics auf allen Endpunkten.
Role-Based Access Governance (RBAC): Rollen basierend auf Job Function; reguläre Review Cycles.
Segregation of Duties (SoD): Keine Person sollte kritische Funktionen allein ausführen können (z.B. Genehmigung und Ausführung einer Zahlung).
Identity Governance Workflows: Access Requests, Approvals, Attestations (Best Practice: risiko- und kritikalitätsabhängige Frequenz, ergänzt um ereignisbezogene Reviews bei Rollenwechsel, Austritt und Änderungen kritischer Systeme).
Board-Level Accountability: Zero Trust ist nicht nur ein IT-Projekt, sondern hat eine Governance-Dimension. Je nach Rechtsform und Organisation können Gesamtleitungsorgan, CISO, CIO, CTO, Risikofunktion oder Prüfungsausschuss zuständig sein; eine allgemeingültige Rollenverteilung gibt das Gesetz nicht vor.
Audit Trail als Compliance-Beweis: Jeder Access ist verifizierbar und dokumentiert. Das ist der Unterschied zwischen „Wir haben MFA“ und „Wir können beweisen, dass nur autorisierte Nutzer auf Schema-X zugegriffen haben“.
6. Perimeter Security vs. Zero Trust: Vergleichstabelle
| Dimension | Traditionelle Perimeter-Sicherheit | Zero Trust |
|---|---|---|
| Vertrauensmodell | Implizit: Intranet = sicher; außen = unsicher | Nein: Jeder Access, jedes Gerät, jeden Moment verifizierbar |
| Zugriffskontrolle | Firewall + einfache ACLs; breite Berechtigungen nach Login | Granular + Continuous: MFA, Conditional Access, Micro-Policies |
| Lateral Movement | Schwer zu erkennen; Netzwerk-Segmentation minimal | Blockiert von Anfang an durch Mikrosegmentierung |
| Monitoring | Perimeter-Logs; wenig East-West-Sichtbarkeit | Echtzeit-Visibility auf alle Verifikations-Events |
| Incident Response | Langwierig: Erst nach Erkennung, vieles ist unklar | Schnell: Granulare Logs, klarer Audit Trail, schneller Kontext |
| Compliance-Beweis | Schwierig; Aussage „Wir schreiben Logs“ | Einfach; „Hier ist jeder autorisierte Access“ |
| Regelwerk-Alignment | Fragmentarisch; erfüllt einzelne Anforderungen | Holistisch; NIS2, DORA, AI Act gleichzeitig |
7. Schweizer Kontext: FINMA, NCSC, Sektor-Adoption
FINMA erwartet für Banken und Versicherer unter ihrer Aufsicht eine funktionierende ICT-Risk-Governance (u. a. FINMA-RS 2023/1). Sie schreibt keine bestimmte Technologie vor; Zero Trust ist ein anerkannter Architekturansatz, um diese Erwartungen zu erfüllen — eine rechtliche Pflicht zu „Zero Trust" als solcher besteht nicht.
BACS (Bundesamt für Cybersicherheit; seit 1. Januar 2024 Nachfolger des NCSC bzw. der früheren MELANI) empfiehlt explizit Zero-Trust-Prinzipien in seinen Ransomware-Defense-Richtlinien und Threat-Intelligence-Publikationen.
Der Schweizer Finanzsektor adoptiert Zero Trust verstärkt nach Ransomware-Vorfällen (z.B. UBS-News, Cantonalbanken-Vorfälle). Große Versicherungen und Vermögensverwaltungen bauen ZTNA-Infrastrukturen auf; für kleinere und mittlere Unternehmen bleibt es ein WIP.
8. Zero Trust im M&A-Kontext: Ein Marker für Operationale Widerstandskraft
M&A-Acquirer prüfen zunehmend die Zero-Trust-Reife von Targets als Proxy für operationale Resilience und Integrations-Compliance:
Incident-Response-Readiness: Hat das Target überhaupt die Infrastruktur, um schnell auf einen Vorfall zu reagieren?
Audit-Trail-Qualität: Kann das Target nachweisen, wer Zugriff hatte, wann, auf was?
Segregation of Duties: Sind finanzielle oder Daten-Controls technisch durchgesetzt?
Regulatory Alignment: Ist das Target für NIS2, DORA, AI Act vorbereitet?
Ein Zielunternehmen, das Zero Trust bereits implementiert hat, ist eine geringere Integration Risk – und wird deshalb höher bewertet.
Szenario: Mittelgroßes Schweizer Versicherungsunternehmen, 2000 Mitarbeiter, wird von Ransomware-Bande attackiert. Attacke ist erfolgreich; Daten werden exfiltriert.
Die Fehler (Vor-Zero-Trust):
• 40% der privilegierten Konten (Admin-Accounts) hatten keine MFA aktiviert.
• Lateral Movement von einem gefährdeten Desktop zu mehreren kritischen Servern dauerte 3 Wochen, bevor erkannt.
• Access Logs waren fragmentarisch; schwer zu sagen, wer auf was zugegriffen hatte.
• Incident Response Team brauchte Tage für Forensics.
Implementierung von Zero Trust (12 Monate):
• MFA für alle Privileged Access (Sofort-Priorität).
• Mikrosegmentierung des Netzwerks; nur autorisierte Services dürfen kommunizieren.
• Workload Identity für alle kritischen Applikationen (Versicherungs-Kernplattformen).
• Kontinuierliches Access Governance; vierteljährliche Reviews statt jährlich.
• SIEM + EDR Integration; Real-time-Alerts bei anomalen Aktivitäten.
Ergebnis (Post-ZT):
• Alle privilegierten Access jetzt MFA-geschützt.
• Lateral Movement wird in Minuten erkannt (nicht Wochen).
• Access Logs sind granular; jeden Access kann das Unternehmen nachweisen.
• Resilienz-Nachweis: Incident Response Plan ist NIST-aligned. Hinweis: Ein rein schweizerisches Versicherungsunternehmen ist nicht allein aufgrund seines Geschäftsmodells unmittelbar NIS2-pflichtig (Art. 21 NIS2). Direkte NIS2-Betroffenheit entsteht erst über EU-Niederlassungen/-Töchter oder – mittelbar – über vertragliche Lieferkettenanforderungen von EU-Kunden; hier dient der Standard als freiwilliger Referenzrahmen.
• DORA-vorbereitet: Audit Trails erfüllen DORA Art. 17–23; kein Compliance-Auffänger mehr für regulatorische Inspektionen.
• M&A-Faktor: Nachfolgende Erwerbungen durch größere Versicherer verlaufen flüssiger; eine belastbare Sicherheitsdokumentation kann den Due-Diligence-Prozess spürbar verkürzen (Erfahrungswert, kein garantierter Zeitgewinn).
Was bleibt