Zero Trust in der Praxis: Absicherung einer Bankinfrastruktur

„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. Firewall an der Grenze, VPN für Remote-Zugang, fertig. Dieses Modell hatte Sinn, als Anwendungen auf physischen Servern in einem einzigen Rechenzentrum liefen.

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. In dieser Umgebung existiert der Perimeter nicht — oder genauer gesagt, der Perimeter ist überall.

Als uns ein tschechisches Bankinstitut mit der Anforderung kontaktierte, die Sicherheitsarchitektur neu zu gestalten, war der Haupttreiber nicht nur Sicherheit. Es war DORA (Digital Operational Resilience Act), der seit Januar 2025 von Finanzinstituten verlangt, die Resilienz des gesamten ICT-Stacks nachzuweisen — einschließlich der Third-Party-Provider. Und das traditionelle Perimetermodell kann das einfach nicht leisten.

Fünf Prinzipien von Zero Trust¶

Zero Trust ist kein Produkt, das man kauft. Es ist ein architektonischer Ansatz, der den gesamten Stack durchdringt. Wir haben ihn auf fünf Prinzipien implementiert.

Verify Explicitly¶

Jeder Zugriff wird anhand von Identität, Gerät, Standort, Verhalten und zusätzlichem Kontext verifiziert. Kein implizites Vertrauen.

Least Privilege¶

Jeder Benutzer und jeder Service hat nur die minimalen Berechtigungen, die für seine Funktion notwendig sind. Just-in-Time und Just-Enough Access.

Assume Breach¶

Die Architektur geht davon aus, dass der Angreifer bereits drinnen ist. Wir minimieren den Blast Radius durch Segmentierung und Monitoring.

Mikrosegmentierung¶

Das Netzwerk ist in isolierte Segmente unterteilt. Die laterale Bewegung eines Angreifers ist begrenzt, selbst wenn er in ein Segment eindringt.

Das fünfte Prinzip, das oft übersehen wird: Continuous Monitoring and Validation. Authentifizierung ist kein einmaliges Ereignis. Sessions werden kontinuierlich basierend auf einem Risk Score revalidiert, der sich in Echtzeit entsprechend dem Benutzerverhalten und dem Gerätezustand ändert.

Architektur: Identitätsbasierter Zugriff und Service Mesh¶

Der Kern der gesamten Implementierung ist der Wechsel von netzwerkbasierter Zugriffskontrolle zu identitätsbasierter Zugriffskontrolle. Es spielt keine Rolle, aus welchem Netzwerk Sie kommen. Wichtig ist, wer Sie sind, welche Berechtigungen Sie haben und was der Kontext Ihrer Anfrage ist.

Identity Provider und kontextuelle Autorisierung¶

Wir haben einen zentralen Identity Provider (IdP) auf Basis von OpenID Connect eingesetzt, der als Single Source of Truth für Benutzer- und Serviceidentitäten dient. Jeder Request trägt ein JWT-Token mit Claims, die nicht nur die Identität, sondern auch den Kontext umfassen: Gerätetyp, Geo-Lokation, Risk Score und Berechtigungsscope.

Autorisierungsentscheidungen trifft der Policy Decision Point (PDP) in Echtzeit. Richtlinien sind in OPA (Open Policy Agent) definiert und in Git versioniert — jede Änderung durchläuft Code Review und einen Audit Trail. Keine Policy wird ad hoc geändert.

`# OPA Policy — Beispiel-Autorisierung für Payment-API

package banking.payments

default allow = false

allow {

input.method == "POST"

input.path == "/api/v1/payments"

input.user.role == "payment_officer"

input.user.mfa_verified == true

input.risk_score < 0.7

input.amount <= input.user.approval_limit

}

High-Value-Transaktionen erfordern Dual Approval¶

allow {

input.method == "POST"

input.path == "/api/v1/payments"

input.amount > input.user.approval_limit

input.dual_approval == true

input.approver.role == "senior_officer"

}`

mTLS und Service Mesh¶

Sämtliche Kommunikation zwischen Microservices läuft über mTLS (mutual TLS). Jeder Service hat ein eigenes X.509-Zertifikat, ausgestellt von einer internen CA, das automatisch alle 24 Stunden rotiert wird. Das ist keine Option — ein Service ohne gültiges Zertifikat kann einfach nicht mit anderen kommunizieren.

Als Service Mesh haben wir Istio mit Envoy Proxy gewählt. Der Envoy Sidecar an jedem Pod übernimmt mTLS-Terminierung, L7-Autorisierung, Rate Limiting und Telemetrie — transparent, ohne Änderungen am Anwendungscode. Für Entwickler ändert sich nichts: Sie rufen HTTP-Endpoints wie bisher auf. Aber unter der Haube ist jeder Call verschlüsselt, authentifiziert und autorisiert.

Mikrosegmentierung in der Praxis¶

Mikrosegmentierung ist das Herzstück von Zero Trust. Statt flacher Netzwerke, in denen jeder Server jeden anderen sehen kann, erstellen wir isolierte Sicherheitszonen mit expliziten Regeln für die Kommunikation zwischen ihnen.

In der Bankumgebung haben wir folgende Segmente definiert:

• DMZ / API-Gateway-Zone: Öffentlich zugängliche Endpoints, WAF, Rate Limiting
• Application Zone: Business-Logic-Microservices, nur vom API Gateway aus erreichbar
• Data Zone: Datenbanken, Message Broker — Zugang nur aus der Application Zone über definierte Ports
• Core-Banking-Zone: Legacy-Systeme, ISO 8583-Verarbeitung — strengste Isolation
• Management Zone: CI/CD, Monitoring, SIEM — getrennt vom Produktionsverkehr
• PSD2 / Open-Banking-Zone: TPP (Third Party Provider) Endpoints mit eigenem Rate Limiting und Consent Management

Regeln zwischen den Zonen sind als Kubernetes NetworkPolicies und Istio AuthorizationPolicies definiert. Der Default ist deny all — wenn eine Regel die Kommunikation nicht explizit erlaubt, wird sie nicht durchgelassen. Jede Regel hat einen Eigentümer, eine Ablaufzeit und muss ein Security Review durchlaufen.

Compliance: PSD2 und DORA¶

Sicherheitsarchitektur im Bankwesen kann nicht im Vakuum existieren — sie muss den regulatorischen Anforderungen entsprechen. Zwei Schlüsselregulierungen haben unsere Implementierung geprägt:

PSD2 und Strong Customer Authentication¶

PSD2 verlangt Strong Customer Authentication (SCA) für elektronische Zahlungen. Das bedeutet mindestens zwei von drei Faktoren: etwas, das der Benutzer weiß (Passwort), hat (Telefon) und ist (Biometrie). In einer Zero-Trust-Architektur ist SCA eine natürliche Erweiterung — Multi-Faktor-Authentifizierung ist keine Ausnahme, sie ist der Standard für jeden Zugriff auf sensible Daten.

Für die Open Banking API (Drittanbieterzugriff auf Kontodaten) haben wir OAuth 2.0 mit PKCE und Dynamic Client Registration implementiert. Jeder TPP hat seine eigene Identität im IdP, eigene Rate Limits und sein Zugriff ist auf den vom Benutzer-Consent definierten Scope beschränkt. Alles geloggt, alles auditierbar.

DORA — Digital Operational Resilience Act¶

DORA brachte seit Januar 2025 die Pflicht zu einem ICT-Risikomanagement-Framework, Digital-Resilience-Testing und Incident-Reporting. Zero-Trust-Architektur adressiert DORA natürlich:

• ICT-Risikomanagement: Continuous Monitoring, Risk Scoring, automatisiertes Vulnerability Scanning
• Incident-Reporting: SIEM mit automatisierten Playbooks für Klassifizierung und Reporting innerhalb von 4 Stunden
• Digital Resilience Testing: Regelmäßige Penetrationstests, Red-Team-Übungen, Chaos Engineering
• Third-Party-Risiko: Jeder TPP und Vendor hat ein definiertes Risikoprofil und seine Zugriffe werden in Echtzeit überwacht

SIEM-Integration und Continuous Monitoring¶

Zero Trust ohne Monitoring ist nur Marketing. Die gesamte Architektur generiert enorme Mengen an Telemetrie — und diese müssen zentral verarbeitet, korreliert und ausgewertet werden.

Wir haben einen SIEM-Stack (Security Information and Event Management) auf Elastic Security mit eigenen Detection Rules implementiert. Wesentliche Datenquellen:

• Envoy Access Logs: Jeder Request zwischen Services — wer, wohin, wann, mit welchem Ergebnis
• IdP Audit Logs: Anmeldungen, MFA-Events, fehlgeschlagene Versuche, Session-Revalidierung
• OPA Decision Logs: Jede Autorisierungsentscheidung mit vollem Kontext
• Kubernetes Audit Logs: API-Server-Operationen, RBAC-Änderungen, Pod-Lifecycle
• Application Logs: Business-Level-Events, Transaktions-Logs

Das Schlüsselelement ist UEBA (User and Entity Behavior Analytics). ML-Modelle erstellen eine Verhaltens-Baseline für jeden Benutzer und Service. Anomalien — ungewöhnliche Zugriffszeiten, atypische Datenmengen, Zugriff auf ungewöhnliche Ressourcen — erhöhen automatisch den Risk Score und können Step-up-Authentifizierung oder Blockierung auslösen.

Die durchschnittliche MTTD (Mean Time To Detect) haben wir durch Automatisierung von Stunden auf Minuten reduziert. MTTR (Mean Time To Respond) von Stunden auf Dutzende Minuten dank SOAR-Playbooks, die die ersten 80 % des Incident-Response-Prozesses automatisieren.

Wie wir es bei CORE SYSTEMS bauen¶

Eine Zero-Trust-Implementierung im Bankwesen ist kein Drei-Monats-Projekt. Es ist ein Transformationsprogramm, das einen systematischen Ansatz erfordert. Unser Vorgehen hat vier Phasen.

1. Assessment & Discovery (4–6 Wochen): Kartierung der bestehenden Infrastruktur, Datenflüsse, Identitäten und Zugriffsmuster. Identifikation der Crown Jewels — Systeme und Daten, die den höchsten Schutz erfordern. Gap-Analyse gegen DORA und PSD2.
2. Architecture & Design (4–8 Wochen): Entwurf der Ziel-Zero-Trust-Architektur, Definition des Segmentierungsmodells, Auswahl des Technologie-Stacks. Proof of Concept auf einem ausgewählten Segment.
3. Iterative Implementierung (3–6 Monate): Schrittweises Deployment segmentweise, beginnend mit den kritischsten Systemen. Jede Iteration umfasst Deployment, Tests, Security Review und Dokumentation.
4. Continuous Operations (laufend): Monitoring, Incident Response, regelmäßige Penetrationstests, Policy Review und Evolution der Architektur basierend auf neuen Bedrohungen und regulatorischen Änderungen.

Wichtiger Aspekt: wir übertreiben nicht. Zero Trust wird nicht über Nacht im Big-Bang-Ansatz implementiert. Jede Phase liefert messbare Verbesserungen der Sicherheitslage und funktioniert eigenständig. Der Kunde sieht Mehrwert vom ersten Sprint an — nicht erst nach einem Jahr Arbeit.

Unser Team kombiniert Spezialisten für Netzwerksicherheit, Identity Management, Kubernetes und Service Mesh und Compliance. Wir sind nicht nur Berater, die ein PowerPoint liefern — wir bauen Infrastruktur, schreiben Policies und betreiben Monitoring. Und dann übergeben wir es an das interne Team des Kunden mit allem, was sie brauchen: Dokumentation, Runbooks und Hands-on-Training.

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 es als Technologieprojekt mit klarem Ende betrachten, werden enttäuscht sein. Diejenigen, 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.