Hyperscaler Risk Assessment für Finanzunternehmen

In diesem Artikel lesen Sie,

• welche Risiken beim Einsatz von US-Hyperscalern existieren,
• was Kill-Switch-Szenarien sind
• und wie ein Hyperscaler Risk Assessment hilft, Cloud-Risiken und Vendor Lock-in zu reduzieren.

Banken spielen eine wichtige Rolle für Volkswirtschaften und sind deshalb als Teil der kritischen Infrastrukturen (KRITIS) eingestuft. Als solche unterliegen sie strengen Regularien und müssen verschiedenste Risiken evaluieren sowie bewerten. Das gilt nicht nur für das Kerngeschäft, in dem Risikomanager beispielsweise Ausfallrisiken für Kredite bewerten und über die Höhe finanzieller Rücklagen entscheiden (z.B. nach BASEL II und III).

Das gilt auch für die genutzte IT. Mit DORA, BAIT, der MaRisk und den EBA-Richtlinien der European Banking Authority existieren entsprechende Regelwerke, die spezifische Anforderungen an Banken stellen. In den „alten Zeiten“ der On-Premises-Nutzung durch (häufig) interne IT-Dienstleister oder spezielle Finanz-IT-Dienstleister ließen sich diese Regularien verhältnismäßig einfach erfüllen. Aber wenn die IT aus der Cloud kommt, braucht die Finanzbranche neue Kontrollmechanismen und -konzepte. Letzten Endes basiert die Zusammenarbeit sehr viel stärker auf Vertrauen, denn die Banken und Versicherungen begeben sich in eine Abhängigkeit von ihrem/n Cloud-Dienstleister/n.

Dieses Vertrauen gerät durch die aktuellen geopolitischen Veränderungen ins Wanken. Immer mehr Entscheidern im Finanzwesen wird klar, dass sie durch den Betrieb von Finanzprozessen in einer starken Abhängigkeit von ihrem Cloud-Dienstleister sind (Vendor Lock-in). US-basierte Cloud-Dienstleister sind beispielsweise dem US Clarifying Lawful Overseas Use of Data (CLOUD) Act unterworfen, der der US-Administration Zugang zu Daten gewährt – auch wenn sie in Europa gespeichert sind. Ein zweites Risiko ist das kurzfristige Einstellen der Services. Europäische Banken wären dann von einem Tag auf den anderen von den Cloud Services abgeschnitten und könnten Teile ihres Business nicht mehr ausüben.

Experten sprechen bei Letzterem von einem „Kill Switch“-Szenario. Eigentlich ist ein Kill Switch oder Notausschalter ein Sicherheitsmechanismus, der dazu dient, vor Gefahren zu schützen. Aber wer die Cloud einsetzt, muss wissen, dass der Cloud-Dienstleister am Schalter sitzt.

Wie realistisch ist dieses Szenario? Die Hyperscaler haben mit Sicherheit kein Interesse daran, dass solche Kill-Switch-Szenarien entstehen. Sie werden alles tun, um sie zu vermeiden. Allerdings bleibt ein Restrisiko, denn letzten Endes sitzen die US-Behörden am längeren Hebel und die US-Hyperscaler müssen deren Anforderungen Folge leisten. Dass der Kill Switch kein rein theoretisches Phänomen ist, zeigen drei Beispiele.

Nach dem Sturm auf das Kapitol am 6. Januar 2021 fanden sich auf der Social-Media-Plattform Parler zahlreiche Beiträge, die ausdrücklich zu Gewalt aufriefen – darunter Drohungen gegen Politiker, Tech-CEOs und ganze Bevölkerungsgruppen. AWS erkannte darin Verstöße gegen seine Acceptable Use Policy, insbesondere weil Parler in sieben Wochen keine effektive Moderation dieser Inhalte vornahm. Am 9. Januar teilte AWS Parler mit, dass es seine Dienste zum 10. Januar einstellt, da Risiken für die öffentliche Sicherheit bestehen. Parler war vollständig abhängig von AWS. Beim Abschalten gab es keine sofortige Alternative – weder interner eigener Rechenbetrieb noch Migration auf einen anderen Provider war kurzfristig möglich. Erst sechs Wochen später war Parler wieder online.

Das Handeln von AWS war definitiv gut begründet, integer und sinnvoll. Nichtsdestotrotz veranschaulicht der Fall die Macht des Cloud-Providers. Nun lässt sich trefflich über den Business-Wert von Social-Media-Plattformen diskutieren, aber in einem zweiten Fall war eine Bank das Ziel des Kill Switch, die europäische Amsterdam Trade Bank . Sie war eine Tochter der russischen Alfa-Bank. 2022 wurde sie das Ziel der internationalen Sanktionen wegen des Ukrainekriegs. AWS und Microsoft entzogen ihr den Zugang zu Daten und Services – darunter Kernbankensysteme, Datenbanken und Kundenzugänge. Wenige Wochen später war die Bank bankrott. In diesem Fall handelten die Cloud-Anbieter im Sinne der internationalen Sanktionen. Aber auch hier wird klar: Der Abzug der Cloud Services zerstörte innerhalb kurzer Zeit ein finanziell solides Unternehmen.

Die Meinungen über die beiden Kill-Switch-Ereignisse und ob sie adäquat waren, werden in Europa kaum auseinandergehen. Anders liegt der Fall des Chefanklägers des Internationalen Strafgerichtshofs (IStGH), Karim Khan . Microsoft sperrte auf Anweisung der US-Administration aus politischen Gründen den Zugriff auf sein Konto. Liegt die Latte für den Kill Switch damit niedriger?

Hyperscaler-Risiken lassen sich grob in vier Kategorien unterteilen. Die Hyperscaler-Abhängigkeit kreiert rechtliche, technische, strategische und finanzielle Risiken.

Die bereits angesprochenen Kill-Switch-Szenarien fallen in die Kategorie der technischen Risiken. Aber auch Service Downtimes, die dazu führen können, dass Dienste temporär unverfügbar werden, müssen hier bedacht werden. Downtime-Szenarien können in der Regel durch Redundanz vermieden werden (im Idealfall mit Multi-Cloud-Konzepten). Darüber hinaus stellen Cloud Services lohnende Ziele für Hacker dar. Dieses Risiko lässt sich z.B. über Verschlüsselung minimieren. Datenresidenz bei globalen Cloud-Anbietern fällt ebenfalls in die Kategorie technische Risiken.

Das prominenteste rechtliche Risiko der Hyperscaler-Nutzung entsteht durch den US CLOUD Act. Mit der Nutzung der Hyperscaler schaffen Anwender einen europäischen Brückenkopf, der US-Behörden Zugriffsmöglichkeit auf „europäische“ Daten bietet. Denn die US-Behörden betrachten, vereinfacht gesagt, den US-Hyperscaler als virtuelles US-Territorium. 

Neben dem US CLOUD Act muss auch die europäische Regulatorik berücksichtigt werden: Das wichtigste Gesetz hier ist die EU-DSGVO zum Schutz der Personendaten europäischer Bürger. In der Vergangenheit entschieden europäische Gerichte, dass US-Dienste nicht den Datenschutzanforderungen Europas genügen. Dafür müssen Cloud-Anwender dann spezifische Lösungen schaffen. Banken müssen zusätzlich die üblichen branchenspezifischen Regularien und BaFin-Vorgaben berücksichtigen.

Bei den strategischen Risiken der Hyperscaler-Abhängigkeit sind vor allem die Ausprägungen des Vendor Lock-in zu nennen. Hierbei stellt sich die Frage, ob die genutzten Services langfristig verfügbar bleiben und was bei einem Wechsel des Anbieters passiert. Hyperscaler erproben häufig neue Services – und stellen diese bei nicht ausreichender Akzeptanz wieder ein. Was aus betriebswirtschaftlicher Anbietersicht vernünftig ist, stellt die Nutzer der Services vor ein Risiko. Sie müssen im Zweifelsfall Alternativen finden. Anwender können die Entwicklung der Cloud-Plattform nur sehr bedingt beeinflussen und verlieren deutlich an Kontrolle.

Wenn es notwendig ist, den Anbieter zu wechseln, stellen sich nicht nur finanzielle Fragen, sondern auch das Problem, dass Daten nicht von allen Cloud Services problemlos zu einem anderen Anbieter migriert werden können, z.B. Daten-Pipelines, Entwicklungsumgebungen, IAM-Tools. Auch hieraus kann sich ein erhebliches Risiko ergeben.

Hyperscaler bieten zwar Tools an, die Kosten protokollieren, allerdings ist für einen kosteneffizienten Betrieb immer ein Kostenmonitoring via FinOps notwendig. Zusätzlich sollten Banken allerdings auch einschätzen, wie hoch die Risiken von Preissteigerungen, oder auch die Kosten bei einer Migration aus der Cloud zu beziffern sind. Dass diese Risiken nicht unrealistisch sind, zeigt die Diskussion um Zölle mit den USA.

Wie hoch ist das Risiko einer Kill-Switch-Situation für einen europäischen Finanzdienstleister? Höchstwahrscheinlich minimal. Allerdings bestehen Risiken immer aus zwei Elementen: der Wahrscheinlichkeit des Auftretens des Ereignisses und dessen Auswirkungen. Insbesondere Unternehmen, die Cloud-Dienste intensiv nutzen, sollten regelmäßig die Cloud-Risiken abwägen und bewerten – und dabei steht sicher nicht das Extremszenario Kill Switch im Mittelpunkt.

Klar ist, dass ein Vendor Lock-in auch „kleinere“ Risiken erzeugt – wie zuvor beschrieben. Beispielsweise wenn der Provider eine Datenbank oder APIs abkündigt, die Preise erhöht oder Drittdienste nicht mehr unterstützt. Auch das kann den Betrieb der Services beeinträchtigen. Gut also, wenn man als Finanzdienstleister auch diese Risiken kennt, entsprechend bewertet und einen Plan B in der Schublade hat oder gar eine Cloud-Exit-Strategie – für den Fall der Fälle.

Idealtypisch deckt ein Hyperscaler Risk Assessment drei Dimension ab. Es bewertet die Vendor-Lock-in-Risiken, stellt diesen die Cloud-Souveränitätsanforderungen des Anwenderunternehmen gegenüber und erzeugt aus den beiden Komponenten eine Cloud-Risikomanagement-Strategie.

Die starke Abhängigkeit von einem Provider (z.B. durch Nutzung nativer, proprietärer Dienste) erschwert die Migration von Workloads und kann die Business Continuity beeinflussen. Bei einem Wechsel der Cloud-Provider sind auch nicht-technische Themen wie Zertifizierungen und Vertragskonditionen zu beachten.

Eingeschränkte Kontrolle über Daten und Services kann zu Compliance-Risiken führen. In diesem Punkt ist es auch wichtig, die Kritikalität der Daten und genutzten Dienste zu kennen. Die Bewertung des Risikos hängt hier auch wesentlich vom Vertrauen in den Cloud-Anbieter ab. Geopolitische Änderungen können diese Vertrauensbasis beeinflussen. Welchen Grad an Kontrolle (Souveränität) wollen Cloud-Anwender haben, welche zusätzlichen Mechanismen müssen dafür implementiert werden?

Aus den beiden Komponenten entsteht eine Bewertung von Souveränität und Vendor Lock-in mithilfe einer Heatmap. Sie zeigt den Abhängigkeitsgrad pro Team/Dienst in der Bank vom jeweiligen Cloud-Anbieter. Basierend auf diesen Ergebnissen geben die Berater Empfehlungen für die Risikominimierung. Dies beinhaltet sowohl Quick Wins als auch langfristige Verbesserungen, z.B. die Migration auf eine Multi-Cloud-Lösung.

Mithilfe der Unternehmensberatung Detecon entsteht innerhalb von neun Wochen (abhängig von der Größe der Infrastruktur) eine aussagekräftige Bewertung der Cloud-Risiken von Banken. 

Zwei Wochen davon fließen in die Vorbereitungsphase. Hier werden die Geschäftsstrategie, das Cloud-Betriebsmodell und die relevanten KPIs identifiziert. Üblicherweise sollten dafür Daten aus etwa einem Dutzend Schlüsselprojekten evaluiert werden. In einer 4-wöchigen Analyse- und Bewertungsphase entsteht die Heatmap mit der Risikobewertung und den Mitigationsempfehlungen. Eine 3-wöchige Qualifikationsphase schließt das Assessment ab. Hier entsteht der Abschlussbericht mit der Machbarkeitsanalyse, einer Kostenschätzung für Schulungen und neue Technologien oder Plattformen.

Häufig empfehlen die Berater von Detecon Multi-Cloud-Konzepte („... legen Sie nicht alle Eier in einen Korb ...“), um die existierenden Risiken zu minimieren. Insbesondere können auch souveräne, europäische Cloud-Angebote in diesen Multi-Cloud-Ansätzen eine relevante Rolle spielen. Hier kommt die Open Telekom Cloud in Spiel. Sie ist laut unabhängigen Analysten eine der führenden europäischen Clouds. Sie basiert auf Open-Source-Technologien und ermöglicht dadurch eine starke Interoperabilität. Die Open Telekom Cloud ist damit eine gute Ergänzung für US-Hyperscaler, um das Souveränitätslevel zu erhöhen und eine erweiterte Hyperscaler-Unabhängigkeit zu erzielen.

Ergänzend gilt auch auf der Applikationsebene: Minimierung der Abhängigkeit von spezifischen Plattformen. Wo immer möglich, sollte auf plattform-proprietäre Dienste verzichtet werden. Auch der Container-Einsatz schafft eine erweiterte Unabhängigkeit von spezifischen Anbietern.