Sicherheit und Integrität

Sicherheit und Integrität unserer Finanztransaktionen

Banken wie die unsere setzen spezialisierte Serverinfrastrukturen ein, um unterschiedliche operative Bereiche abzudecken. Je nach architektonischen Anforderungen und regulatorischen Vorgaben gehören zu den wichtigsten Servertypen:

1. Kernbankserver

Diese Server bilden das zentrale operative Rückgrat und verwalten Kundenkonten, Transaktionen und Compliance:

• Transaktionsverarbeitungsserver: Führen die Zahlungsautorisierung, Betrugsprüfungen und Abwicklungen in Echtzeit aus (z. B. SWIFT, SEPA).
• Server für die Kontoverwaltung: Sie bearbeiten Ereignisse im Lebenszyklus eines Kontos (Eröffnung und Schließung), Zinsberechnungen sowie die Überwachung der Liquidität.
• Server für aufsichtsrechtliche Compliance: Automatisierung von AML-Prüfungen (Geldwäschebekämpfung), Prüfpfaden und Berichterstattung (z. B. IFRS, DSGVO).

2. Ledger-Server

Zuständig für die Führung unveränderlicher Finanzaufzeichnungen:

• Hauptbuchserver: Erfassen die doppelte Buchführung über alle Konten hinweg und gewährleisten die Einhaltung von Rechnungslegungsstandards wie IFRS.
• Server für Distributed-Ledger-Technologie (DLT): Blockchain-basierte Systeme für grenzüberschreitende Zahlungen, KYC-Verifizierung und manipulationssichere Transaktionsprotokolle.

3. Server für die externe Kommunikation
Ermöglichen die sichere Interaktion mit externen Stellen:

• EBICS-Server: Wickeln die Kommunikation über den Electronic Banking Internet Communication Standard für SEPA-Zahlungen ab, der in Deutschland, Frankreich und der Schweiz weit verbreitet ist.
• Host-to-Host-Server (H2H): Direkte SFTP/FTPS-Verbindungen für hochvolumige Firmentransaktionen (z. B. Massenabwicklung von Gehaltszahlungen).
• API-Gateway-Server: Stellen RESTful-Schnittstellen für die Echtzeit-Zahlungsauslösung und Kontenaggregation bereit (gesichert über OAuth2/mTLS).
• Swift-Schnittstellenserver: Verbinden die Bank mit dem Swift-Netzwerk für den Nachrichtenaustausch zwischen Banken (SCORE ist die geschlossene Nutzergruppe von Swift für den Zugang von Unternehmen, kein Servertyp).

4. Datenbankserver
Zentrale Repositorien für strukturierte Finanzdaten:

• Kundendatenserver: Speichern KYC-Dokumente, Transaktionshistorien und Verhaltensanalysen.
• Produktkatalog-Server: Verwalten Angebote wie Kredite, Hypotheken und Einlagenzinssätze.

5. Sicherheits- und Infrastrukturserver
Gewährleisten die Systemintegrität und die Einhaltung regulatorischer Vorgaben:

• Hardware-Sicherheitsmodul-(HSM-)Server: Schützen kryptografische Schlüssel für digitale Signaturen und die SSL/TLS-Verschlüsselung.
• Firewall-/VPN-Server: Sie erzwingen die Netzwerksegmentierung und sichern den Fernzugriff für Mitarbeitende.
• Disaster-Recovery-Server: Hosten Ausweichsysteme zur Aufrechterhaltung des Geschäftsbetriebs bei Ausfällen.

Moderne Banken setzen häufig hybride Architekturen ein, die lokale Kernserver mit cloudbasierten DLT-Knoten kombinieren, um Skalierbarkeit zu gewährleisten. So kann eine Bank beispielsweise die lokalen Kernbankensysteme von IBM zusammen mit bei AWS gehosteten Ledger-Servern für den Abgleich in Echtzeit nutzen. Dieser modulare Ansatz bringt Compliance, Leistungsfähigkeit und Innovation in Einklang.

Banken müssen die Server-Konsolidierung im Interesse der Effizienz mit der Wahrung der Isolation aus Sicherheits- und Compliance-Gründen in Einklang bringen. Nachfolgend eine Übersicht kombinierbarer und nicht kombinierbarer Server auf Grundlage technischer Vorgaben und branchenüblicher Praxis:
Server, die zusammengelegt werden können
1. Web-/Anwendungsserver

• Kombinierte Methode: Virtualisierung (VMware, KVM) oder Containerisierung (Docker/Kubernetes)
• Beispiel: Betrieb mehrerer Banking-Portale (Privatkunden, Firmenkunden, mobil) auf einem Hypervisor-Cluster mit Lastverteilung.

2. Datenbankserver

• Kombinationsmethode: Mandantenfähige Cloud-Datenbanken (AWS RDS, Azure SQL)
• Oracle-/MS-SQL-Kernbankdatenbanken können in hybriden Cloud-Umgebungen mit PostgreSQL-/MongoDB-Analysesystemen nebeneinander betrieben werden.

3. Externe Kommunikations-Gateways

• Kombinationsmethode: Einheitliche API-Gateways (Apigee, MuleSoft)
• EBICS-, SWIFT- und SFTP-Dienste können auf gemeinsam genutzter Infrastruktur mit protokollspezifischen Microservices betrieben werden.

4. Disaster-Recovery-Server

• Kombinationsmethode: Aktiv-aktive Georedundanz
• Core-Banking-Replikate und Backup-Ledger-Server können sich Disaster-Recovery-Cluster teilen.

5. Middleware-Server

• Kombinationsmethode: Enterprise Service Bus (ESB)
• Zahlungsrouting, Compliance-Prüfungen und Währungsumrechnungsdienste, gebündelt auf IBM Integration Bus/SAP PI.

Server, die isoliert bleiben sollten
1. Server für die zentrale Transaktionsverarbeitung

• Begründung: Die Trennung (physisch oder durch strikte Segmentierung) verringert den Umfang der Kontrollen nach PCI DSS und SOC 2
• Beispiel: IBM zSystems mit CICS-Transaktionsmonitoren dürfen sich die Hardware nicht mit anderen Workloads teilen.

2. Hardware-Sicherheitsmodul-Server (HSM)

• Begründung: FIPS 140-2/140-3 Level 3 schreibt dedizierte manipulationssichere Hardware vor
• Umsetzung: HSMs von Thales/Gemalto zur Verwaltung digitaler Signaturen und Verschlüsselungsschlüssel.

3. Echtzeit-Hauptbuchsysteme

• Begründung: Die doppelte Buchführung erfordert Atomarität
• Beispiel: Oracle-Financial-Services-Ledger-Server mit direkt angeschlossenem NVMe-Speicher.

4. Server für das aufsichtsrechtliche Meldewesen

• Begründung: Prüfprotokolle müssen vor Veränderungen geschützt und für die nach DSGVO und Geldwäscherecht vorgeschriebenen Zeiträume aufbewahrt werden; die Trennung erleichtert den entsprechenden Nachweis
• Einrichtung: Isolierte SQL-Server-Instanzen für MiFID-II-/FATCA-Meldungen.

5. ATM-/POS-Autorisierungssysteme

• Grund: SLA mit einer Verfügbarkeit von 99,999 % und Anforderungen an die Netzwerksegmentierung
• Architektur: IBM Power Systems mit redundanten Fibre-Channel-SANs.

Technische Beschränkungen:

• Hochvolumige Kernbankensysteme benötigen dedizierte Netzwerkverbindungen mit hoher Bandbreite
• PCI DSS verlangt, dass gespeicherte Kartennummern (PAN) unlesbar gemacht und die Umgebung für Karteninhaberdaten segmentiert wird
• Das Swift Customer Security Programme (CSP) verlangt, dass sich die Swift-Infrastruktur in einer geschützten, gesicherten Zone befindet

Wir haben 80 % der nicht kritischen Server (Web/Anwendung/Middleware) erfolgreich konsolidiert, während Kernsysteme, HSM und Hauptbuchsysteme vollständig isoliert bleiben.

Die Absicherung von Hauptbuchservern in der Cloud erfordert mehrschichtige Schutzmaßnahmen, die auf die Sensibilität von Finanzdaten zugeschnitten sind. Auf der Grundlage bewährter AWS-Sicherheitspraktiken und bankspezifischer Umsetzungen empfiehlt sich folgendes strukturiertes Vorgehen:

1. Unveränderbare Ledger-Technologie
Einsatz speziell entwickelter Ledger-Datenbanken mit kryptografischer Verifizierung jeder Transaktion:

• Kryptografische Verkettung: Jede Transaktion wird gehasht und mit dem vorherigen Eintrag verknüpft, wodurch ein unveränderlicher Prüfpfad entsteht.
• Integrierte Integritätsprüfungen: Die Datenbank überprüft ihren eigenen Verlauf automatisch und verhindert so Manipulationen.
• SQL-ähnliche Abfragen: Wahrt die Kompatibilität mit bestehenden Finanzsystemen und ergänzt sie um blockchainähnliche Sicherheit.

2. Netzwerkisolierung

• VPC-Architektur: Betreiben Sie Ledger-Server in privaten Subnetzen ohne öffentlichen Internetzugang.
• Sicherheitsgruppen: Beschränken Sie eingehenden Datenverkehr auf bestimmte Ports (z. B. PostgreSQL/Aurora) aus vorab genehmigten IP-Bereichen.
• VPC-Endpunkte: Nutzen Sie AWS PrivateLink für die sichere Kommunikation zwischen Ledger-Servern und Diensten wie S3/KMS, ohne Daten dem öffentlichen Internet auszusetzen.

3. Verschlüsselung

• Im Ruhezustand: Von AWS KMS verwaltete Schlüssel verschlüsseln die Hauptbuchdaten in Amazon Aurora, mit automatischer Schlüsselrotation.
• Bei der Übertragung: TLS 1.3 für sämtliche Client-Server- und dienstübergreifenden Kommunikationsverbindungen erzwingen.
• Clientseitige Verschlüsselung: Sensible Felder (z. B. Kontostände) vor der Speicherung mit dem AWS Encryption SDK vorab verschlüsseln.

4. Zugriffskontrolle

• IAM-Rollen: Vergeben Sie granulare Berechtigungen (zum Beispiel Rollen, die ausschließlich das Einfügen von Daten erlauben), um versehentliches oder böswilliges Löschen von Daten zu verhindern.
• Temporäre Zugangsdaten: AWS STS für zeitlich befristeten Zugriff während Wartungsarbeiten verwenden.
• MFA-Durchsetzung: Hardware-Token (YubiKey) für Root- und Administratorkonten verlangen.

5. Überwachung und Prüfung

• Echtzeit-Warnmeldungen: Konfigurieren Sie AWS CloudWatch so, dass bei ungewöhnlichen Transaktionsmustern (z. B. Überweisungen von mehr als 1 Mio. EUR) Warnmeldungen ausgelöst werden.
• Aktivitätsprotokolle: Alle Änderungen am Hauptbuch werden über AWS CloudTrail in Verbindung mit SIEM-Werkzeugen nachverfolgt.
• Automatisierte Prüfungen: Führen Sie wöchentlich AWS-Config-Regeln aus, um den Verschlüsselungsstatus und die Netzwerkrichtlinien zu überprüfen.

6. Compliance und Governance

• Zonenbasierte Segmentierung: Getrennte DEV-/TEST-/PROD-Ledger-Umgebungen unter Verwendung von AWS Organizations.
• Automatisierte Berichte: Erstellung von PCI-DSS-/DSGVO-Compliance-Berichten über AWS Audit Manager.
• Prüfungen durch Dritte: Planen Sie jährliche Penetrationstests mit von AWS zugelassenen Partnern ein.

7. Notfallwiederherstellung

• Regionenübergreifende Replikation: Verschlüsselte Ledger-Replikate werden in den AWS-Regionen Frankfurt und Stockholm vorgehalten.
• Point-in-Time-Recovery: Aktivieren Sie kontinuierliche Sicherungen, um Daten auf jeden beliebigen Zeitpunkt innerhalb der Aufbewahrungsfrist (bis zu 35 Tage) sekundengenau wiederherzustellen.
• Air-Gapped-Sicherungen: Quartalsweise Ledger-Snapshots werden im AWS Backup Vault mit einer Aufbewahrungsfrist von 7 Jahren gespeichert.

Um zu verhindern, dass sich schädliche Einträge auf Disaster-Recovery-Server (DR) ausbreiten, setzen Banken mehrschichtige Sicherheitsstrategien ein, die Sicherungen isolieren, strenge Zugriffskontrollen durchsetzen und die Datenintegrität validieren. Nachfolgend eine technische Aufschlüsselung der wichtigsten Maßnahmen:
1. Unveränderliche Sicherungen mit WORM-Konfiguration (Write Once, Read Many)

• Zweck: Verhindern, dass Ransomware Sicherungsdaten verändert oder verschlüsselt.

Umsetzung: Nutzen Sie AWS S3 Object Lock oder Azure Blob Immutable Storage, um Löschung und Veränderung für einen festgelegten Aufbewahrungszeitraum zu verhindern. Wenden Sie kryptografische Hashverfahren (SHA-256) auf Sicherungsdateien an; jede Manipulation macht den Hashwert ungültig und löst Warnmeldungen aus.
2. Air-Gapped- und Offline-Replikation

• Netzwerkisolierung: DR-Server in einem separaten VPC/VLAN ohne eingehenden Internetzugang betreiben. Unidirektionale Replikation (Primärsystem → DR) mittels Werkzeugen wie AWS Storage Gateway oder Azure Site Recovery einsetzen und eine Rücksynchronisation sperren.
• Physische Netztrennung (Air-Gapping): Für kritische Systeme sind Bandsicherungen oder Offline-Speicher vorzuhalten, die nur während planmäßiger Replikationsfenster verbunden werden.

3. Zero-Trust-Zugriffskontrollen

• Authentifizierung: Setzen Sie die Multi-Faktor-Authentifizierung (MFA) für alle DR-Verwaltungsschnittstellen durch (z. B. AWS SSO, Azure AD Conditional Access). Weisen Sie IAM-Rollen mit minimal erforderlichen Berechtigungen zu (z. B. ausschließlich `s3:GetObject`).
• Netzwerksicherheit: Beschränken Sie den Replikationsverkehr auf IPsec-VPN-Tunnel oder AWS Direct Connect/Azure ExpressRoute. Setzen Sie Intrusion-Detection-Systeme (IDS) wie Snort oder Suricata zur Überwachung der Replikationskanäle ein.

4. Validierung der Datenintegrität

• Prüfungen vor der Replikation: Quelldaten vor der Replikation mit Werkzeugen wie ClamAV oder CrowdStrike Falcon auf Schadsoftware prüfen. Prüfsummen vor und nach der Übertragung vergleichen, um Manipulationen zu erkennen.
• Audits nach der Replikation: Setzen Sie AWS Config oder Azure Policy ein, um Verschlüsselungs- und Zugriffsrichtlinien auf den Disaster-Recovery-Servern durchzusetzen. Planen Sie tägliche Integritätsprüfungen mittels Skripten (z. B. Validierung per `sha256sum`).

5. Logisch getrennte Umgebungen

6. Automatisierte Failover-Tests

• Simulierte Angriffe: Einsatz von Werkzeugen wie Chaos Monkey, um Ransomware-Infektionen zu simulieren und die Resilienz der Disaster-Recovery-Server zu überprüfen. Messung der Recovery-Time-Objectives (RTO) und Recovery-Point-Objectives (RPO) während der Übungen.
• Forensische Analyse: VPC-Flow-Logs und CloudTrail-Ereignisse sind 90 Tage aufzubewahren, um Auffälligkeiten bei der Replikation nachzuvollziehen.

Die Umsetzung unveränderlicher Backups ist entscheidend, um Daten vor Ransomware, versehentlichem Löschen und Compliance-Verstößen zu schützen. Auf Grundlage von Branchenstandards und Werkzeugen wie AWS, Veeam und Azure gelten folgende bewährte Verfahren:
1. Unveränderlichkeit auf der Speicherebene durchsetzen

• Nutzen Sie WORM-Konfigurationen (Write-Once-Read-Many) über Objektspeicher mit S3 Object Lock (AWS), Azure Immutable Blob Storage oder Veeam Hardened Repositories.
• Aktivieren Sie Aufbewahrungssperren, um ein vorzeitiges Löschen oder Ändern zu verhindern – auch durch Administratoren.

2. Eine 3-2-1-1-Backup-Strategie anwenden

• 3 Datenkopien (Primärkopie + zwei Sicherungskopien)
• 2 Speichermedientypen (z. B. Festplatte + Cloud)
• 1 externe Kopie (geografisch getrennt)
• 1 unveränderliche Kopie (physisch vom Netz getrennt oder WORM-fähig).

3. Strikte Zugriffskontrollen implementieren

• Rollenbasierter Zugriff (RBAC): Berechtigungen werden über IAM-Rollen beschränkt (z. B. Zugriffsrichtlinien für AWS-Backup-Vaults).
• Multi-Faktor-Authentifizierung (MFA): Für die Verwaltungsschnittstellen der Datensicherung verbindlich vorschreiben (z. B. Azure AD Conditional Access).
• Netzwerkisolierung: Sicherungskopien in privaten Subnetzen/VPCs ohne öffentlichen Internetzugang speichern.

4. Daten durchgängig verschlüsseln

• Ruhende Daten: AES-256 oder KMS-verwaltete Schlüssel (AWS, Azure) verwenden.
• Bei der Übertragung: TLS 1.3 für Replikationskanäle.
• Clientseitige Verschlüsselung: Sensible Felder vor der Sicherung verschlüsseln (z. B. AES-256 von Veeam mit vom Nutzer verwalteten Schlüsseln).

5. Aufbewahrung und Validierung automatisieren

• Aufbewahrungsrichtlinien: RPO/RTO festlegen und Lebenszyklusregeln automatisieren (z. B. 7-jährige Aufbewahrung im AWS Backup Vault).
• Prüfsummenvalidierung: Überprüfung der Integrität vor und nach der Replikation (z. B. mittels SHA-256-Hashing).
• Regelmäßige Prüfungen: Nutzen Sie Tools wie AWS Config oder Veeam SureBackup, um Wiederherstellungen zu testen.

6. Mehrschichtige Sicherheit für hybride Umgebungen

7. Compliance und Unwiderruflichkeit sicherstellen

• Unveränderbarkeitseinstellungen nach den Tests sperren (z. B. den Status „Enabled and locked“ bei Azure).
• Regulatorische Vorgaben erfüllen: Richten Sie sich mithilfe von Werkzeugen wie AWS Audit Manager an der DSGVO, HIPAA oder SOX aus.
• Prüfungen durch Dritte: Planen Sie jährliche Penetrationstests (z. B. mit von AWS zugelassenen Partnern).

Beispiel-Workflow mit AWS und Veeam
1. Primäre Sicherung: Veeam Backup & Replication in einen S3-Bucket mit Object Lock.
2. Replikation: AWS DataSync in eine sekundäre Region (Frankfurt → Stockholm).
3. Validierung: Tägliche CloudTrail-Protokolle + vierteljährliche Wiederherstellungstests.
4. Aufbewahrung: 90-tägige Unveränderlichkeitsfrist mit KMS-Verschlüsselung.

Durch die Kombination aus Unveränderbarkeitsmerkmalen, Zugriffskontrollen und hybrider Redundanz können Organisationen ransomware-resistente Datensicherungen erreichen und zugleich die Compliance-Anforderungen erfüllen.