Kalkulierter Kontrollverlust: Mitigationsmaßnahmen für Banken in der Cloud

Public-Cloud-Services galten in der Finanzbranche lange als Risiko. Doch bei richtiger Umsetzung überwiegen die Vorteile externer IT-Services. Es sind präzise abgestimmte Mitigationsmaßnahmen gefragt, um die Risiken zu minimieren, die mit der neuen Technologie einhergehen. Wer das Potenzial voll ausschöpfen will, muss seinem Anbieter gewisse Kompetenzen übertragen: Das erfordert Vertrauen.

von Daniel Wagenknecht, Partner bei KPMG

Cloudservices versprechen Unternehmen enorme Leistungssteigerungen: Von höherer Effizienz und Anpassungsfähigkeit über eine größere Mitarbeiter- und Kundenzufriedenheit bis hin zur Erschließung neuer Geschäftsfelder. Neue Technologien gehen jedoch auch mit Risiken einher, die mit geeigneten Maßnahmen mitigiert werden sollten. Das gilt vor allem für Finanzinstitute:

Die Daten der Branche sind zu sensibel und die Unternehmensprofile zu individuell, als dass auch nur ein einziges Institut ohne eigene Risikoprävention auskäme.”

Die Cloudanbieter, allen voran die drei US-amerikanischen Hyperscaler AWS, Google und Microsoft, stellen ein Baukastensystem performancestarker Services bereit. Damit Banken für sich und ihre Kunden das Maximum aus diesen Services herausholen können, sind die darauf basierenden Anwendungen skalierbar und flexibel zu entwickeln. Damit geht auch eine vielfältige Palette möglicher Mitigationsmaßnahmen einher:

Datenschutz und Informationssicherheit wollen sichergestellt, die Verschlüsselungstechnologie festgelegt sowie Compliance-Anforderungen umgesetzt werden.”

Datenschutz und Informationssicherheit

Die erste Ebene, auf der Institute in Sachen Public Cloud Risikobewertung und -management betreiben müssen, ist die des Datenschutzes und der Informationssicherheit: Neben Unternehmensdaten wie Patenten, Bilanzen oder weiteren sensiblen Informationen unterliegen Kundendaten diversen gesetzlichen, endemischen Schutzbestimmungen.

Diese Verordnungen stehen nicht selten im Widerspruch zur Rechtslage in den USA, wo die drei Hyperscaler mit zusammen rund 75 Prozent Marktanteil zuhause sind.”

Der sogenannte CLOUD (Clarifying Lawful Overseas Use of Data) Act des US-Kongresses von 2018 erlaubt amerikanischen Strafverfolgungsbehörden zum Beispiel in bestimmten Fällen den Zugriff auf im Internet gespeicherte Daten heimischer Unternehmen, also auch auf solche von AWS, Google und Microsoft.

Erfolgt dieser Zugriff auf die Daten eines europäischen Kunden, handelt es sich schnell um einen Verstoß gegen die Datenschutzgrundverordnung nach EU-Recht.”

Die Geldstrafen für solche und ähnliche Vergehen können Banken hart treffen: Im Höchstfall werden vier Prozent des Jahresumsatzes fällig.

Die wichtigste Mitigationsmaßnahme ist in puncto Datenschutzkonformität ein Vertrag zwischen Bank und Cloudprovider, in dem der Schutz von Unternehmens- und Kundendaten detailliert geregelt ist. Das klingt simpel, bringt in der Praxis aber hohe juristische Komplexität und großen bürokratischen Aufwand mit sich. Zwar gewährleisten sogenannte Standard Contract Clauses (SCC) ein gewisses Datenschutzniveau; der Europäische Gerichtshof hat jedoch entschieden, dass diese Standardrichtlinien nicht ausreichen.

Europäische Banken müssen auf der Grundlage ihres individuellen Risikoprofils technisch-organisatorische Maßnahmen (TOMs) erarbeiten, zwischen sich und dem jeweiligen Cloudprovider vertraglich kodifizieren und in der Praxis umsetzen.”

Finanzdienstleister sollten sich daher unbedingt von Datenschutz-Experten beraten lassen. Ein solcher Vertrag schützt zwar nicht vollständig vor einem Zugriff der US-Behörden im Rahmen des CLOUD Act auf die Daten in der Cloud, doch ist dies das extremste theoretische Szenario – gewissermaßen der GAU auf dem Gebiet der Datenschutzpolitik.
Zudem haben sich die Hyperscaler für solche Fälle auf die Strategie des maximalen juristischen Widerstands festgelegt.

Wahl der Verschlüsselungstechnologie

Um die skizzierten Maßnahmen zur Informationssicherheit technisch umzusetzen, sind grundsätzlich zwei verschiedene Strategien vorstellbar: die Verschlüsselung im eigenen Haus oder durch den Cloudprovider. Variante eins, die sogenannte On-Premise-Datenverschlüsselung, verspricht zumindest auf den ersten Blick die größte Sicherheit und maximale Kontrolle. Hat der Cloudprovider keinen Einfluss auf die Datenverschlüsselung, können seinerseits auch keine Fehler passieren, etwa durch Sicherheitslücken oder Cyberangriffe. Allerdings müssen Banken und Versicherungen dann auch auf innovative und moderne Services verzichten, deretwegen sie sich ja ursprünglich für eine Cloud entschieden hatten.

Alleinige Kontrolle über die Datenverschlüsselung und uneingeschränkte Inanspruchnahme von Public Cloud Services schließen sich aus.”

Ein weiterer Nachteil der On-Premise-Datenverschlüsselung ist, dass sie den mit Abstand größten personellen und finanziellen Aufwand verursacht. Hinzu kommt, dass die Daten bei technischen Fehlern, die durch das Institut selbst verursacht werden, unwiederbringlich verloren sind. Im Gegensatz dazu verfügen Cloudprovider in der Regel über hochstandardisierte und praxiserprobte Schutzmechanismen im Key Management, um den Super-GAU des Datenverlustes unmöglich zu machen.

Die Cloud-Anbieter bringen also nicht nur Risiken, sondern auch Verbesserungen für die Datensicherheit mit.”

Verschlüsselt der Cloud-Provider zumindest einen Teil der Daten selbst, so hat er technisch auch Zugang zum Daten-Generalschlüssel („Schlüsseltresor“). Ähnlich wie ein Vermieter zur Wohnung besitzt er einen „Zweitschlüssel“ zu den Daten, darf diesen aber nicht benutzen – und wird das aller Voraussicht nach auch nicht tun. Dennoch: eine hundertprozentige Sicherheit gibt es nicht.

Seitens der Finanzinstitute ist daher ein gewisses Vertrauen in die Sicherheitsmaßnahmen, aber auch die Zuverlässigkeit und Integrität des Cloudproviders unerlässlich, um dessen Angebot vollumfänglich zu nutzen.

Welche Datensätze intern und welche vom Provider verschlüsselt werden, können Finanzdienstleister auf Basis des eigenen Risikoappetits frei entscheiden. Oftmals ist ein Hybridmodell das Mittel der Wahl.”

Wieder sind hier Expertise und eine exzellente Beratung entscheidend. Denn: Für eine Versicherung, die cloudnative Betrugspräventionsalgorithmen nutzt, ergeben sich beispielsweise gänzlich andere Anforderungen an die Verschlüsselungsmechanismen als für eine Kredit- oder Privatbank mit kleinem Kundenstamm.

Fast so groß wie die Bandbreite der Anwendungsfälle ist die der Verschlüsselungsmechanismen. Von der BYOK- (Bring Your Own Key) bis zur Double-Key-Encryption (DKE) steht der Branche eine Vielzahl von (De-) Chiffriertechniken zur Verfügung. Zudem gibt es beispielsweise die Möglichkeit, notwendige Zugriffe externer Administratoren auf die eigenen Datensätze zeitlich zu begrenzen und zu protokollieren. So entsteht eine Gewaltenteilung, die Transparenz schafft und durch die Verantwortung im Sinne des Shared Responsibility Models eindeutig zugeordnet werden kann.

Datenschutz und Verschlüsselung – beispielsweise mittels sogenannter Hardware Security Modules (HSM) – in die Hände von Drittanbietern zu geben, ist eine zusätzliche Option.”

Allerdings sorgt diese nicht unbedingt für Entbürokratisierung und verlangt zudem ebenfalls Vertrauen in einen externen Anbieter. Egal welche Technik zum Einsatz kommt – sie sollte unbedingt den neuesten technischen Standards und Sicherheitsanforderungen genügen.

Zwar versprechen Cloudservices effiziente Strukturen und Skalierbarkeit, doch eine hauseigene State-of-the-Art-IT bleibt für Banken das Nonplusultra – natürlich in deutlich geringerer Größe verglichen mit einem Team, das für ein komplettes On-Premise-Hosten erforderlich wäre.”

Cloudprovider liefern zwar die besten verfügbaren Betriebsmittel. Mit diesen Komponenten eine Architektur zu designen, welche die gewünschte Performance liefert, bleibt aber immer Aufgabe der Banken. Deshalb ist ein kompetentes IT-Team hierfür unerlässlich. Dieses muss allerdings nicht die Größe eines herkömmlichen On-Premise-Teams haben.

Landing- statt Komfortzone

In puncto Regulatorik und Compliance ist die Situation besser überschaubar:

Die beste Mitigationsmaßnahme für Banken besteht darin, am Puls der Zeit zu sein.”

Die Compliance-Vorgaben, die auf europäischer Ebene von der EBA (European Banking Authority) und in Deutschland von KWG (Kreditwesengesetz) und MaRisk (Mindestanforderungen an das Risikomanagement) vorgegeben und in den BAIT (Besondere Anforderungen an die IT) konkretisiert sind, müssen von Unternehmen konsequent und möglichst unmittelbar umgesetzt werden.

Wenn die Vorgaben in einem Unternehmen beispielsweise definieren, dass Clouddaten nicht außerhalb Europas verarbeitet oder gespeichert werden dürfen, sollte das für den IT-Administrator oder IT-Entwickler auch technisch unterbunden sein. Dabei kann die Einrichtung sogenannter Landing Zones, also bestimmter IT-Umgebungen mit konkreten Vorgaben und Restriktionen, helfen. In einer solchen Umgebung kann der Zugriff aufs Internet verweigert oder nur auf On-Premise-Daten gewährt sein. Technisch ist das ohne weiteres machbar – doch es bedarf einer wachen und proaktiven Compliance-Unit innerhalb der IT. Denn Gesetze und Richtlinien sind in der Praxis immer nur so effektiv, wie die Skripte, Restriktionen und Policys sie im Cloudaccount implementieren.

Zweigleisig fahren ist kein Muss

Beschließt eine Bank, Daten in die Cloud zu migrieren, macht sie sich zu einem gewissen Grad von ihrem Cloudprovider abhängig.”

Der Einfluss der Finanzinstitute auf die Produktpalette ihrer Provider ist begrenzt. Würde Microsoft von heute auf morgen einen Service abschaffen, der in der Cloudwelt so wichtig ist wie das Office-Paket für jedes Büro – die Banken bzw. alle Unternehmen müssten damit leben. Dagegen gibt es keine klare Mitigationsstrategie. Natürlich besteht immer die Möglichkeit, IT-Services an mehr als einen Anbieter auszulagern, sodass eine Ausweichoption zur Verfügung steht und die Daten nahtlos dorthin verschoben werden können. Eine solche zweigleisige Strategie mag im Falle einiger fundamental wichtiger Services oder besonders sensibler Datensätze richtig sein. Auch bei der Anwendung von Open-Source-Software, die aus Drittquellen bezogen und nicht vom Provider mitgebracht wird, kann dies ein probates Mittel sein. Doch durch doppeltes Hosten entstehen auch die doppelten Kosten. Und der doppelte interne Aufwand.

Daher dürfte die enge und vertrauensvolle Zusammenarbeit mit einem Anbieter für den Großteil der Institute das Mittel der Wahl sein – zumindest für den Beginn ihrer Cloud-Transformation und bevor Multi-Provider-Strategien zum Tragen kommen.”

Die Gefahr, dass wichtige Funktionen durch den Provider abgeschafft werden, ist in der Praxis jedoch gering: Wenn alle Welt Office nutzt und der Anbieter damit viel Geld verdient, hat er keinen Anreiz, diesen Service vom Markt zu nehmen. Sollte ein Provider doch einen Service abschalten, der dem Finanzdienstleister fundamental erscheint, kann dies im Umkehrschluss als Gradmesser dafür dienen, ob sich die eigene Architektur noch auf der Höhe der Zeit befindet.

Ohne Schablone

Weder für die Migration in die Public Cloud noch die dafür erforderlichen Mitigationsmaßnahmen gibt es eine universell gültige Lösung.”

Was angemessen, notwendig oder finanzierbar ist, variiert von Unternehmen zu Unternehmen und muss in einem internen Prozess herausgearbeitet, risikoorientiert umgesetzt und dann feinjustiert werden.

Eine mögliche Strategie kann sein, zunächst alles aus der Public Cloud zu erlauben und nach Bedarf schrittweise straffere Mitigationsmaßnahmen und Restriktionen einzuführen. Die entgegengesetzte Strategie ist das Whitelisting von Cloud-Services: Zu Beginn werden alle Services in der Public Cloud verboten und erst nach Prüfung einzeln freigeschaltet. Letztere Herangehensweise ist sicher die umsichtigere und vorausschauendere Strategie. Welche Lösung die beste ist, hängt jedoch vom Risikoappetit des jeweiligen Instituts ab.Daniel Wagenknecht