Hyperscaler – verbotene Cloud-Frucht in der Finanzbranche?

Der Finanzsektor erlebt einen Wandel – On-Premise-Lösungen haben den Reiz verloren, cloudbasierte Dienste von Unternehmen wie Microsoft, Amazon, Google und IBM erobern den Markt. Wie man den Hyperscaler-Herausforderungen technisch begegnet, schildert Fabian Meyer, Managing Partner bei CORE SE.

von Fabian Meyer ist Managing Partner bei CORE SE

Die Finanzbranche diskutiert dabei heftig, ob Cloud- und insbesondere Hyperscaler-Lösungen KWG-konform und unter Beachtung von BAIT, DORA, MaRisk etc. eingesetzt werden können. Diese fordern insbesondere einen „risikobasierten“ Ansatz, wobei klare Regelungen fehlen, was zu einer großen Verwirrung beigetragen hat. Teilweise wird in Fachkreisen vertreten, der Einsatz von Hyperscalern sei pauschal nicht KWG-konform. Dominiert von dieser Unsicherheit werden Vorhaben zur Cloud-Transformation ausgebremst.

Ein Verbot des Cloud-Einsatzes oder der Nutzung bestimmter Anbieter findet sich jedoch in keiner offiziellen Stellungnahme von BaFin oder EZB.”

In den Erwägungsgründen zu DORA ist die Rede davon, dass es „unvorstellbar geworden ist, Finanzdienstleistungen ohne die Nutzung von Cloud-Computing-Diensten, Softwarelösungen und datenbezogenen Dienstleistungen zu erbringen“.[2]

Es stellt sich mithin nur die Frage, „wie“ eine regelkonforme Nutzung geht, nicht „ob“.”

Voraussetzungen für eine regulatorisch konforme Transformation in die Cloud

Finanzinstitute können erfolgreich Cloud-Lösungen einsetzen, wenn sie neben der Definition einer Cloud-Strategie eine Risikoanalyse durchführen, Verträge mit Cloud-Anbietern sicher gestalten (bzw. vertragliche Abweichungen einer Abwägung unterziehen), interne Vorgaben und Prozesse evaluieren, anpassen und eine zusätzliche Cloud-Ausstiegsstrategie entwickeln. Hinweise zum Vorgehen finden sich unter anderem in den in 2021 von der European Securities and Markets Authority (ESMA)[3] herausgegebenen Leitlinien zur Auslagerung an Cloud-Anbieter, welche die BaFin als Prüfungsmaßstab heranzuziehen beabsichtigt.[4]

Die Durchführung dieser Schritte stellt die Institute sodann vor die Herausforderung, auf erkannte Risiken zu reagieren und diese zu minimieren.

Autor Fabian Meyer, Managing Partner CORE

Fabian Meyer ist Managing Partner bei CORE SE und hat über 10 Jahre Erfahrung im Bereich der digitalen Transformationen. Er hat einen Master of Science in Controlling & Consulting von der Steinbeis Hochschule und weitere Qualifikationen in International Management von der Tokyo University of Agriculture and Technology und der Indiana University – Kelley School of Business. Neben seiner Haupttätigkeit ist er auch seit fast 7 Jahren Managing Director bei C3 Ventures GmbH und engagierte sich als Freiwilliger bei UN-Habitat, wo er sich für sozial und ökologisch nachhaltige Städte einsetzte.

Aus technischer Sicht gibt es hierfür folgende Ansatzpunkte:

Datenresidenz / Georedundanz: Vor Aufbau einer Cloud-Infrastruktur stellt sich die Frage nach den geographischen Standorten der Unternehmensdaten bei einem Hyperscaler. Viele Hyperscaler verfügen weltweit über Rechenzentren, in der Regel zwischen 5 und 10 Standorte in Zentraleuropa. Hier sollten mindestens eine Haupt- und eine Backup-Region in Betracht gezogen werden. Es ist ebenfalls zu erwägen, eine Kopie der wichtigsten Daten bei einem weiteren Hyperscaler oder on-premise vorzuhalten.

Verschlüsselung: Mit dem Wegfall von On-premise-Infrastruktur rückt die Verschlüsselungsarchitektur der Daten in den Vordergrund. Hier ist zu evaluieren, ob Daten in der Cloud mit einem Plattform Managed Key (PMK), einem Customer Managed Key (CMK) oder einem „Bring your Own Key“ (BYOK)-Szenario verschlüsselt werden sollen. Es besteht zudem die Möglichkeit, verwaltete oder dedizierte Hardware-Sicherheitsmodule (HSM) zu nutzen und somit Kompatibilität mit Anforderungen bis FIPS 140-3 zu erfüllen.

IAM

In den allermeisten Fällen werden durch Finanzdienstleister bereits Identitätsmanagement-Lösungen verwendet. Die Verwaltung muss hier, wenn möglich, auf Identitätslösungen der Hyperscaler erweitert werden, sodass die IAM-Lösung gemäß regulatorischer Anforderungen weiterhin die Single Source of Truth bleibt und alle IAM-Prozesse, etwa die Re-Zertifizierung, auch die Cloud-Infrastruktur abbilden. Eine IAM-Lösung muss die verschiedenen Identitätstypen der Hyperscaler (bspw. Benutzer, Gruppen, Serviceprinzipale) mindestens unterstützen, idealerweise aber auch anlegen, ändern und löschen können.

Infrastructure as Code

Bei Nutzung von Hyperscalern sollte von Anfang an auf Infrastructure as Code gesetzt werden, um manuelle Eingriffe und damit Fehlerquellen zu reduzieren. Auch eine schnelle Bereitstellung von Cloud-Services bei verschiedenen Hyperscalern wird so ermöglicht.

Die Infrastruktur sollte daher basierend auf Automatisierungssprachen wie Terraform oder Pulumi aufgeplant werden, um eine spätere komplexe Templatisierung existierender Infrastruktur zu vermeiden.”

Hiermit können zum Beispiel auch technische Policies ausgerollt werden, die die Unternehmensrichtlinien bei Erstellung, Betrieb und Dekomissierung von Cloud-Infrastruktur und Dienstleistungen durchsetzen.

Dediziertes WAN zum Hyperscaler

Zur Gewährleistung der Verbindungsstabilität, der geringstmöglichen Latenz und einer sicheren verschlüsselten Verbindung zwischen Finanzinstituts- und Mitarbeiterstandorten sowie dem oder den Hyperscalern ist die Einrichtung einer dedizierten WAN-Verbindung zum Hyperscaler empfehlenswert. Dienste wie ExpressRoute (Azure), Direct Connect (AWS) oder InterConnect (GCP) arbeiten mit einer Großzahl von ISPs und Rechenzentren zusammen.

Multicloud und cloudagnostische Infrastruktur

Aufgrund der Anforderung, eine Exit-Strategie zu entwickeln und in Hinsicht auf das Risiko- und Business-Continuity-Management ist es angezeigt, mehr als einen Hyperscaler für den Cloud-Betrieb zu berücksichtigen.

Folgende Anhaltspunkte sind zu beachten (Auszug):

1. Datenreplikation zwischen Cloud-Providern (bspw. im Master-Slave-Prinzip) zur schnellen Verfügbarkeit von Datenbanken oder Daten
2. Nutzung von etablierten Standards und Protokollen, um cloud-übergreifend arbeiten zu können und einen Vendor-Lock-In zu vermeiden (bspw. Kubernetes, OpenID Connect)
3. Die Nutzung eines plattformübergreifenden Data Plane / Service Mesh als solides Fundament für den Datenaustausch zwischen Services und Servicearten der Hyperscaler
4. Die Nutzung der durch Hyperscaler bereitgestellten Dienste zur Unterstützung von Multicloud, bspw. WAN-Verbindungen zwischen Hyperscalern, die Nutzung eines einzigen Identitätsanbieters (z.B. Azure AD) bei mehreren Hyperscalern sowie von weiteren Diensten, die Hyperscaler übergreifend bereitstellen (z.B. Monitoring/Logging, Bereitstellung von Datenbanken etc.)
5. Das Wissen für alle genutzten Hyperscaler muss in Entwicklungs-, Betriebs- und Compliance-Teams vorgehalten werden

Es empfiehlt sich, Cloud-(Betriebs-)Prozesse, -Dienste und -Tools hyperscaler-unabhängig und universell nutzbar zu planen. Hierzu gehören bspw. cloud-übergreifende (Sicherheits-)Richtlinien, ein cloud-übergreifendes Gesamt-Monitoring oder die sicherheitstechnische Überwachung aller Hyperscaler in einem übergreifenden Security Operations Center (SOC).

Diese Maßnahmen und Vorgaben müssen in die internen Prozesse gemäß schriftlich fixierter Ordnung integrierbar sein, wofür letztere nötigenfalls angepasst oder ergänzt werden müssen.

Fazit und Hinweise zum Projektaufsatz

Langfristig ist eine Auseinandersetzung mit und der Einsatz von Cloud-Technologien für die meisten Institute aus Wettbewerbssicht unumgänglich. Um schwerwiegende Konsequenzen in Folge regulatorischer Verstöße zu vermeiden, müssen Cloud-Vorhaben auf Basis einer Cloud-Strategie ausreichend geplant und streng gesteuert werden. Nur so werden Compliance-Aspekte durchgängig berücksichtigt und unterstützen zusätzlich die Umsetzung der IT- und Cloud-strategischen Leitlinien. Geschieht dies nicht, entstehen sogenannte Compliance-Schulden: Erst später wird visibel, dass eine bereits erfolgte (technische) Umsetzung nicht alle regulatorischen Anforderungen erfüllt. Diese während der Transformation oder gar im Nachhinein zu korrigieren, gestaltet sich schwieriger und kostspieliger als zu Beginn. Insbesondere noch nicht oder unzureichend umgesetzte technologische Compliance-Aspekte sind mit hohen Kosten für die Nachbesserung verbunden.

Dabei wird bei behördlichen Prüfungen häufig ein unzureichendes Risikomanagement aufgrund fehlender frühzeitiger Erkennung und Minderung der Risiken bemängelt.”

Dies kann zu gravierenden Sanktionen der Aufsichtsbehörden führen, die von Risikorückstellungen bis hin zu Wachstumsbeschränkungen reichen.[5]

Der Einsatz eines End-to-End-Compliance-Streams sowie die konstante Planung technologischer Lösungsarchitektur im Transformationsprozess sind somit wesentliche Maßnahmen, um den Beweis zu führen, dass eingehalten wird, was die einschlägigen Normen vehement verlangen: ein starkes Risikobewusstsein und -management.Fabian Meyer, Managing Partner CORE

[1] Flexera, 2022, https://info.flexera.com/FLX1-REPORT-State-of-Tech-Spend

[2] s. Erwägungsgrund 79 der DORA

[3] ESMA50-164-4285, 2021, https://www.esma.europa.eu/sites/default/files/library/esma_cloud_guidelines_de.pdf

[4] ESMA50-164-4285, 2021, https://www.esma.europa.eu/sites/default/files/library/esma_cloud_guidelines_de.pdf; BaFin, 2021, https://www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Meldung/2021/meldung_ 2021_06_29_Anwendung_ESMA_Leitlinien.html

[5] Bußgelder der BaFin erreichen mitunter Millionenhöhe. Eine Übersicht verhängter Sanktionen findet sich auf der Webseite der BaFin hier.

 
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/163488

• teilen 
• teilen 
• teilen 
• teilen 
• teilen 
• RSS-feed 
• E-Mail 
• drucken