Cloud Services – rechtliche Herausforderungen und Strategien für die Bankenpraxis

Chancen der Cloud

Angesichts des hohen Taktschlags bei aufsichtlichen und betriebswirtschaftlichen Neuerungen und Anforderungen an Banken ist es für die Institute herausfordernd, zeitnah und adäquat darauf zu reagieren und insbesondere interne Prozesse und IT-Strukturen sowie notwendige Tools zur Analyse aufzusetzen. Zumal Eigenentwicklungen teuer und eigene, oft historisch gewachsene, Rechenzentren partiell wenig flexibel sind.

Hier bieten Clouds mit

• skalierbaren Infrastrukturen, unter anderem mit „Pay per Use“,
• hoher Flexibilität in Struktur und unterstützter Software,
• Wahloptionen zu Self- vs Cloud-Managed Services,
• Redundanz in Datenhaltung und Services sowie
• Performanz bei hoher Verfügbarkeit

eine moderne technische Alternative.

Zudem verfügen Clouds über diverse Migrationsstrategien von bestehender Software, wie beispielsweise Rehosting (Lift and Shift) oder Replatform (mittels Container).

Da Institute zudem auf Angebote starker Partnern, wie beispielsweise die msg-Gruppe, zugreifen können, haben sie die Möglichkeit, die Instituts-IT ohne traditionelle Installation im eigenen Rechenzentrum zu entkoppeln. Diese können Lösungen für einen größeren Kundenkreis entwickeln und das Deployment standardisiert durchführent. Große Institutsaufwände seitens der IT, wie sie gegebenenfalls bei einer Installation von Drittanbieter-Software anfallen würden, sind in der Cloud ebenfalls kein Thema.

Ein Blick auf die rechtlichen Anforderungen

Die Nutzung von Cloud-Diensten hat in den letzten Jahren einen enormen Aufschwung erlebt und ist inzwischen auch für Finanzdienstleister äußerst attraktiv geworden. Dabei spielt die Resilienz von großen Hyperscalern eine entscheidende Rolle für die Stabilität und Verfügbarkeit von Cloud-Diensten. Da diese Unternehmen über umfangreiche Redundanzsysteme, hochverfügbare Rechenzentren und Notfallwiederherstellungspläne verfügen, können sie auf Ausfälle und Störungen in der Regel effektiv reagieren und den Betrieb aufrechterhalten. Dies ist für Finanzdienstleister, die auf eine kontinuierliche Verfügbarkeit ihrer Dienste angewiesen sind, um Handelsgeschäfte abzuwickeln, Kundenanfragen zu bearbeiten und regulatorische Anforderungen zu erfüllen, von entscheidender Bedeutung.

Um die Sicherheit und Integrität ihrer sensiblen Finanzdaten zu gewährleisten, müssen gerade Finanzdienstleister bei der Implementierung von Cloud-Technologien einige anspruchsvolle aufsichtsrechtliche Anforderungen berücksichtigen. Dazu zählen neben der Datensicherheit, bei der sichergestellt werden muss, dass in der Cloud gespeicherte Daten angemessen geschützt sind, auch die Implementierung strenger Zugriffskontrollen. Durch spezifische Zertifizierung und Audits durch Dritte können Cloud-Provider die Einhaltung dieser Vorschriften nachweisen. Dies beinhaltet auch den Nachweis der Datenlokalisierung, falls es konkrete Anforderungen an die Speicherung in geografischen Regionen gibt.

Zusätzlich dazu sollten Finanzinstitute einen klaren Plan für das Risikomanagement in der Cloud entwickeln. Dies beinhaltet sowohl die Identifizierung potenzieller Risiken als auch die Implementierung von Sicherheitsvorkehrungen zur Risikominimierung sowie einen Notfallwiederherstellungsplan, um auf unvorhergesehene Ereignisse reagieren zu können.

Die nachfolgende Abbildung zeigt zusammenfassend das Zusammenspiel der zu berücksichtigenden aufsichtsrechtlichen Anforderungen.

Dabei müssen insbesondere die Themen

• Identitäts- und Zugriffsmanagement,
• Verschlüsselung,
• Security Information und Event Management,
• Firewalls und Intrusion Detection,
• Auslagerungsaspekte,
• Prozesse und Kontrollen für die Datensicherheit

sowie die kontinuierliche Überwachung des IT-Betriebs und Weiteres reflektiert werden.

Was garantieren und bieten die Clouds rechtlich?

Es hat sich viel getan im Thema Cloud: Die Hyperscaler (Google Cloud, Azure, AWS) bieten umfangreiche Nachweise und Maßnahmen wie zum Beispiel zu BAIT, ISO-Zertifizierungen, MaRisk etc. an. Darüber hinaus existieren diverse weitere Cloud-Anbieter auch mit regionalen Wurzeln. Ebenfalls werden Multicloud- sowie Hybridlösungen mit On-Premise- und Cloud-Anteilen unter anderem von den Hyperscalern angeboten. Solche Lösungen bieten häufig die Chance, Infrastrukturen im lokalen Rechencenter des Instituts oder verschiedener Clouds analog aufzusetzen oder aber nur bestimmte Teile von Anwendungen in einer externen Cloud zu nutzen.

Am Beispiel von Google zeigt sich, dass

• Mapping MaRisk und BAIT auf Maßnahmen direkt abrufbar sind,
• ISO/IEC-27001, -27017-, -27018-Zertifizierungen nachgewiesen werden können,
• BSI Critical Infrastructure (KRITIS) für Rechenzentren in Deutschland relevant ist.

Zudem bietet/garantiert Google SLAs (Service Level Agreements), KPIs (Key Performance Indicators) und KRIs (Key Risk Indicators), die es ermöglichen, die Auslagerungsanforderungen hinsichtlich der Verfügbarkeit zu prüfen.

Die Hyperscaler Azure und AWS bieten analoge Informationen auf ihren Webseiten an.

Zusammenfassend lässt sich festhalten, dass es seitens der Hyperscaler inzwischen eine große Abdeckung der rechtlichen Anforderungen gibt. Um jedoch sicherzustellen, dass keine Sicherheitslücken durch die Ausgestaltung des jeweiligen Anbieters für die Institute relevant werden, führt an einer detaillierten Betrachtung und Überprüfung der jeweiligen Anwendung beziehungsweise der einzelne Service kein Weg vorbei.

Praxisorientierte Lösungsstrategien

Bei den umfassenden Compliance-Garantien der Cloud stellt sich die Frage, wo die offenen Flanken sind und wie sichergestellt werden kann, dass in der gewählten Cloud-Umsetzung auch alle relevanten Compliance-Einstellungen abgedeckt werden. Hierbei sei angenommen, dass der spezifische Code keine eklatante Sicherheitsmängel aufweist, gegen die grundsätzlich nur eine robuste und technisch abgeschottete Lösung eine gewisse Resilienz liefern kann.

Eines vorweg: Das Thema Patriot Act der USA oder auch nationale Durchgriffe zum Beispiel europäischer Staaten kann für die Cloud-Anbieter, abhängig von der Art der gespeicherten Daten und der technischen Umsetzung, relevant werden. In der Praxis sind diese aber auch bestrebt, im Einzelfall rechtlich gegen derlei Anforderungen vorzugehen. Am Beispiel des US Patriot Acts zeigt sich außerdem, dass richterliche Einzelfallanordnungen vorliegen müssen, wenn auf Daten zugegriffen werden soll. Dies führt direkt zur Frage, ob die gespeicherten Daten überhaupt rechtlich angefordert werden können, wenn ein Hyperscaler gar kein Wissen darüber hat, dass eine Bank bei ihm auch Kontodaten zur entsprechenden Person hält. Das Thema sieht im Einzelnutzerangebot der Clouds natürlich anders aus. Das heißt, eine Person, die ihre eigenen Daten in einer Cloud speichert, ist einem Hyperscaler bekannt. Somit können deren Daten explizit, wenn auch nur mit richterlicher Aufforderung, angefordert werden.

In den folgenden Anwendungen sind beispielhaft zwei Cloudarchitekturen für einen einfachen As- a-Service-Dienst skizziert, der beispielsweise Analysen auf Institutsdaten ausführen könnte und die Ergebnisse als Monitoring in Dashboards oder als Wordberichte bereitstellt. Im ersten Fall liegt der Fokus klar auf eine hohe Abdeckung der rechtlichen Anforderungen, im zweiten wird die Kritikalität eingewertet und auf eine preisgünstigere, wartungsärmere Lösung abgestellt.

Beschreibung der Abbildung: Zur Sicherstellung einer abgeschotteten Kommunikation wurden in dieser Darstellung alle Komponenten als Container geführt. Diese haben zudem eine eigene Prüfung der Zugriffsrechte und eigene Verschlüsselung, damit auch als Administrator der Infrastruktur in der Cloud kein Zugriff möglich ist. Zudem wurde alle Container in einer Virtual Private Cloud mit RAM-Verschlüsselung und private Tennant sowie shielded Virtual Machines umgesetzt. Hierdurch wird ein Eindringen kaum möglich und etwaige Softwareseite Sicherheitslücken werden schwerer angreifbar. Wie auch in der nachfolgenden Abbildung ist es notwendig vorher die Container auf Schwachstellen zu überprüfen, wie es grundsätzlicher Standard in der Softwareentwicklung ist.

Beschreibung der Abbildung: Abweichend zur vorherigen Abbildung wurde nun eine weniger komplexe Architektur gewählt. Das Frontend wird containerisiert mittels des serverlosen Ansatzes CloudRun als managed Service bereitgestellt (Pay per Use). Dank der separaten Authentifizierung wird sichergestellt, dass die formale Administration der Cloud losgelöst ist vom Nutzerzugriff. Firebase wäre die Wahl für GoogleCloud als Benutzerverwaltung, wenn ein Institut nicht selbst die Rechteverwaltung über ihre eigenen Server bereitstellen wird (zum Beispiel mittels LDAP, Keycloak). Neben dem Frontend gibt es keine im öffentlichen Internet bereitgestellten Schnittstellen, ein Login ist nur über Authentifizierung möglich. Das Frontend kommuniziert nun mit dem Backend (ebenfalls serverless), das für Auslastungsverwaltung, Datenablage und Ergebniserstellung verantwortlich ist. Als Datenablage wurde hier ein Datalake, konkret Cloud Storage (optional ergänzt mit SQL-Metadatenbank mittels Cloud SQL) genutzt. Dieses Beispiel zeigt, dass mittels Googles IAM und Serviceaccounts mit begrenzten Rechten authentifizierte, autorisierte, verschlüsselte Kommunikation zwischen den verschiedenen Komponenten stattfindet. Abhängig davon, ob die Gefahr des Patriot Acts besteht oder nicht, kann der Schutz mittels selbst bereitgestellter Schlüssel für diese Kommunikation erhöht werden, denn sowohl der Datalake als auch alle Cloud Run sind grundsätzlich auch von den Administratoren der Cloud erreichbar.

Folgende technische Mittel stehen beispielsweise zur Wahl:

• Nutzung der Verschlüsselungsschlüssel der Hyperscaler oder Bereitstellung eigener Verschlüsselungsschlüssel
• Nutzung der einzelnen Tools der Cloud oder Verwendung von abgeschotteten Containern mit entsprechenden Mehrkosten und gegebenenfalls Performanceeinbußen
• Aktivierung von zusätzlichen Schutzmaßnahmen gegen Mehrkosten:
  • Confidential Cloud: Verschlüsselung des Arbeitsspeichers gegen Cold-Boot-Attacks oder illegale Zugriffe
  • Shielded Virtual Machines: Überwachung der Instanzen auf Auffälligkeiten und abweichende Software
  • Private Tennant: Sicherstellung, dass keine fremde Instanz auf den gleichen physischen Rechnern agiert
  • Virtual Private Cloud: Sicherstellung, dass bei Kommunikationen im Netzwerk aus Virtual Machines nur Zugriffe gemäß Firewallregeln möglich sind, trotz möglicherweise gleichzeitig laufender Anwendungen von anderen Kunden der Hyperscaler auf dem gleichen physischen Knoten.

Ebenfalls können IP-Bereiche eingeschränkt und verschlüsselte getunnelte Kommunikationen zwischen Institut und Cloud aufgesetzt werden (zum Beispiel Peering mittels High-availability (HA-)Cloud VPN, durch Subnetze getrennte Topologien), um noch höhere Sicherheit zu gewährleisten.

Ferner ist zu entscheiden, ob auf vollständig von den Hyperscalern gewartete Dienste abgestellt wird, die wie zum Beispeil Cloud Run (ein Serverless-Ansatz) Container ausführen. Eine solche Lösung stellt sicher, dass Patches immer aktuell gehalten werden und nur das Patchen der eigenen Container an sich, sprich der eigenen Softwarekomponente, bleibt. Bei virtuellen Maschinen hingegen muss das Patchen selbst sichergestellt werden. Daneben gibt es noch die Zwischenstufe von Kubernetes und anderen Diensten.

Fazit

Das Aufsetzen neuer Services wie auch die Migration der IT-Landschaft in die Cloud ist für Banken komplex und birgt zahlreiche Herausforderungen. Die sensibelsten Themen sind Sicherheit, Datenschutz und Regulatorik. Doch auch die Planung und Durchführung solcher Projekte sowie deren Umsetzung stellen für viele IT-Teams eine Herausforderung dar.

In diesem Beitrag haben wir anhand von zwei konkreten technischen Cloudarchitekturen die technische Machbarkeit von Software as a Service im regulatorischen Umfeld adressiert und Lösungsstrategien aufgezeigt.

Nach unserer Einschätzung dominieren die Vorteile der Cloud und die Experten von msg for banking stehen Ihnen als starke Partner sowohl im Thema Migration als auch in den Themen Software und Tools in der Cloud zur Seite. Hierdurch kann Ihr Institut die Synergien aus unserem fachlichen und technischen Know-how vollständig nutzen.