Zero Trust in der Praxis: Wie wir eine Bankinfrastruktur abgesichert haben

„Vertrauen, aber überprüfen” war lange das Mantra der Enterprise-Sicherheit. 2026 reicht das nicht mehr. Moderne Bankinfrastruktur arbeitet nach dem Prinzip never trust, always verify — jeder Request, jeder Benutzer, jeder Microservice authentifiziert und autorisiert sich, unabhängig davon, woher er kommt. So haben wir es für einen Kunden im tschechischen Bankensektor implementiert.

Warum der Perimeter im Bankwesen nicht funktioniert¶

Das traditionelle Netzwerksicherheitsmodell basiert auf einer einfachen Annahme: alles innerhalb des Unternehmensnetzwerks ist vertrauenswürdig, alles außerhalb ist eine Bedrohung. Heute sieht Bankinfrastruktur anders aus. Microservices verteilt über On-Premise und Cloud. Drittanbieter über API gemäß PSD2 angebunden. Mitarbeiter arbeiten von überall. Container, die Minuten leben.

Der Haupttreiber war DORA (Digital Operational Resilience Act), der seit Januar 2025 von Finanzinstituten verlangt, die Resilienz des gesamten ICT-Stacks nachzuweisen.

Fünf Prinzipien von Zero Trust¶

Verify Explicitly — jeder Zugriff wird anhand von Identität, Gerät, Standort und Verhalten verifiziert. Least Privilege — nur minimale nötige Berechtigungen. Assume Breach — Architektur geht davon aus, dass der Angreifer bereits drinnen ist. Mikrosegmentierung — isolierte Segmente begrenzen laterale Bewegung. Continuous Monitoring — Sessions werden kontinuierlich basierend auf einem Echtzeit-Risikoscore revalidiert.

Architektur: Identitätsbasierter Zugriff und Service Mesh¶

Kern der Implementierung ist der Wechsel von netzwerkbasierter Zugriffskontrolle zu identitätsbasierter Zugriffskontrolle. Zentraler Identity Provider auf Basis von OpenID Connect, Policy Decision Point mit OPA, versionskontrolliert in Git.

mTLS und Service Mesh¶

Sämtliche Kommunikation zwischen Microservices über mTLS. Jeder Service mit eigenem X.509-Zertifikat, automatisch alle 24 Stunden rotiert. Istio mit Envoy Proxy als Service Mesh.

Mikrosegmentierung in der Praxis¶

Segmente: DMZ/API-Gateway-Zone, Application Zone, Data Zone, Core-Banking-Zone, Management Zone, PSD2/Open-Banking-Zone. Default ist deny all. Jede Regel hat einen Eigentümer, eine Ablaufzeit und muss ein Security Review durchlaufen.

Compliance: PSD2 und DORA¶

PSD2 verlangt Strong Customer Authentication. DORA brachte ICT-Risikomanagement-Framework, Digital-Resilience-Testing und Incident-Reporting.

SIEM-Integration und Continuous Monitoring¶

SIEM-Stack auf Elastic Security. UEBA-Modelle erstellen Verhaltens-Baselines. MTTD von Stunden auf Minuten reduziert, MTTR dank SOAR-Playbooks von Stunden auf Dutzende Minuten.

Wie wir es bei CORE SYSTEMS bauen¶

Vier Phasen: Assessment & Discovery (4–6 Wochen), Architecture & Design (4–8 Wochen), iterative Implementierung (3–6 Monate), Continuous Operations (laufend). Wir übertreiben nicht — jede Phase liefert messbare Verbesserungen und funktioniert eigenständig.

Fazit: Zero Trust ist eine Reise, kein Ziel¶

Zero Trust ist kein Zustand, den man einmal erreicht und fertig ist. Es ist ein kontinuierlicher Prozess — ständige Bedrohungsbewertung, Verschärfung von Richtlinien, Resilienztests und Anpassung an neue Regulierungen. Banken, die Zero Trust als Betriebsphilosophie übernehmen — wo jedes Team die Prinzipien versteht, jeder Deploy ein Security Review durchläuft und jeder Incident eine Verbesserungsmöglichkeit ist — werden eine Infrastruktur haben, die sowohl Regulierungsbehörden als auch echten Angreifern standhält.