3 Tipps aus der Cloud-Praxis: Von „Customer Lockbox“(Azure) bis zu Daten “in transit” verschlüsseln

Bei Banken und Versicherern gehören Cloud-Anwendungen längst zum Alltag. Und doch gibt es bei der Umsetzung der technischen und organisatorischen Maßnahmen häufig noch Unklarheiten. Wie lassen sich diese beseitigen? 

von Gerrit Bojen, Partner im Bereich Financial Services bei KPMG

Cloud oder nicht Cloud? Das ist bei den meisten Banken und Versicherern nicht mehr die Frage. Bei vielen ist Public Cloud bei Eigenentwicklungen bereits erste Wahl. Nicht zuletzt deshalb, weil sie bereits eine gute Basis für die Cloud-Nutzung und für die Definition klarer Rahmenbedingungen geschaffen haben.

Alles im Lot, also? Das lässt sich so nicht sagen.

Denn bekanntermaßen sind Banken und Versicherungen deutlich stärker reguliert als Unternehmen anderer Branchen. Gleichzeitig liegt die Zukunft der Branche in hybriden Cloudumgebungen. So nimmt die hybride Speicherung von Unternehmensdaten in der Public-Cloud und On-Premise stetig zu, wodurch auch die Komplexität immer weiter steigt.

Gerade bei den technisch-organisatorischen Maßnahmen in der Public-Cloud gibt es daher noch viel Klärungs- und Abstimmungsbedarf.”

So steht z.B. der Datenschutz für die stark regulierte Branche klar im Vordergrund. Hier müssen Institute unter anderem Maßnahmen treffen, um der so genannten Drittlandübermittlung entgegenzuwirken, wenn ihr Cloud-Provider außerhalb der Europäischen Union beheimatet ist. Daher gilt es, alle Möglichkeiten auszuschöpfen, um zu verhindern, dass ein Mitarbeiter des Providers auf die Daten der Bank oder derer Kunden zugreifen kann.

Empfehlenswert ist deshalb zum Beispiel das Feature „Customer Lockbox“ von Microsoft Azure. Dieses baut einen Workflow auf, der den Administratoren von Microsoft den Zugriff auf die Daten zu Wartungszwecken des jeweiligen Kunden verbietet. Vor Durchführung von Wartungstätigkeiten muss Microsoft einen Antrag für temporären Zugriff bei der entsprechenden Bank stellen. Auf diese recht einfache Weise können Institute administrativen Zugriffen aus Nicht-EU-Ländern entgegenwirken.

Daten „at rest“ und „in transit“ verschlüsseln

Entscheidend ist auch, Daten „at rest“ und „in transit“ zu verschlüsseln. Dabei gibt es unterschiedliche Spielarten der Verschlüsselung. Wenn möglich, sollte die Bank selbst das Schlüsselmaterial erstellen und dann beim Cloud-Provider einlagern. Das Schlüsselmaterial der Bank wird hierbei in einem Hardware-Sicherheitsmodule (HSM) abgelegt. Diese Module sind nicht gerade günstig, sollten aber in der Architektur einer Bank in der Public-Cloud ein fester Bestandteil sein. Viele Banken haben HSM bereits in ihrer eigenen Infrastruktur implementiert, das heißt, sie übernehmen die Public Key Infrastruktur (PKI) dann selbst. Allerdings muss diese Hardware auch jemand betreiben, was im Fall von fehlerhaftem Verhalten ein großes Risiko darstellt: Der Schlüssel muss nämlich nach einer gewissen Zeit rotiert werden; wenn dabei etwas schiefgeht, kommt das schnell einem Brand im Rechenzentrum gleich, denn alle verschlüsselten Daten sind dann verloren. Daher sollte jedes Institut individuell überprüfen, wie gut es in der Lage ist, Verschlüsselungstechnologie selbst zu betreiben.

Gerade kleine Institute sollten hier die Risiken genau abwägen: Besitzt meine Organisation die Fähigkeit die PKI-Infrastruktur selbst zu betreiben? Wie stark wiegt das Risiko eines OpRisks, z.B. einen kompletten Datenverlust zu erleiden? Kann ich die PKI-Infrastruktur durch einen Managed-Cloud Service Provider betreiben lassen, oder kann ich Managed Services des Public-Cloud-Betreibers einsetzen? Nicht zu unterschätzen ist auch die Gefahr eines Ransomware-Angriffs. Hier sollten Institute unbedingt vorbereitet sein. So kann es auch in der Cloud passieren, dass Kriminelle versuchen, Daten zu verschlüsseln. Um dies zu verhindern, lohnt sich der Einsatz getrennter Backup-Accounts und sogenannter Object Locks für die Speicher der Backups, sodass immer nur einmalige Schreibzugriffe erlaubt sind und die Löschung der Backups verhindert wird.

Ein weiteres wichtiges Thema ist Continuity:

Denn auch in der Cloud kann ein Rechenzentrum ausfallen. Daher ist es immer ratsam, nach hochverfügbaren Lösungen zu suchen, die redundant sind.”

Die Verantwortung dafür diese Redundanzen aufzubauen, liegt dabei auf der Seite der Bank. Wichtig ist etwa die Frage, wie lange es dauert, um alle Daten im Ernstfall wieder zurückzuspielen, insbesondere wenn das Backup in der Cloud und das System On-Premise liegt. Viele Häuser testen dieses Szenario nicht vollumfänglich. Banken sollten also nicht nur über ein Back-up verfügen, sondern auch proben, wie lange es im Ernstfall dauern würde, es wieder zurückzuspielen. So sind die Verantwortlichen angehalten, Lösungen von vornherein so zu konzipieren, dass sie die in der der Schutzbedarfsanalyse ermittelte MTTR (Mean-time-to-repair) erreicht und das durch einen Test auch belegt ist.

Generell gibt es drei verschiedene Wege, um Ressourcen in der Cloud bereitzustellen: Erstens über Nutzeroberflächen des Cloud Providers, zweitens über Skript-Sprachen, die jeder Provider selbst bereitstellt, sowie drittens über eine unabhängige Skript-Sprache wie z.B. „Terraform“. Den Weg über Cloud-Portale sollte man hier unbedingt vermeiden, da diese Lösung nicht reproduzierbar ist. Auch Variante zwei ist nicht empfehlenswert, da hier der sogenannte Vendor Lock-in der Cloud Provider befördert wird, wenngleich hier die jeweils neuesten Services sehr früh verfügbar sind. Im Markt zeichnet sich als Best-Practice der Einsatz von Terraform ab.

Von Cloud Providern werden stets auch Managed Services angeboten, beispielsweise „Azure Machine Learning“ von Microsoft. Hier ist alles bereits vorpaketiert, sodass Banken sich auf die fachlichen Inhalte und weniger auf die technische Infrastruktur konzentrieren können.

Die Alternative ist, sich lediglich die Infrastruktur in der Cloud zu beschaffen und die Lösung eigenständig aufzubauen. Verantwortliche in der IT präferieren diese Variante häufig, da sie mehr Freiheitsgrade verspricht und dem Vendor-Lock-in entgegenwirkt.”

Der Nachteil ist allerdings, dass dies die Betriebskosten erhöht, zudem geht mit der Eigenentwicklung viel wertvolle Zeit verloren. Diese Entscheidung sollte daher vorab gut abgewogen werden.

Nicht alles muss in die Cloud

Allerdings müssen auch gar nicht alle Daten und Anwendungen einer Bank in die Cloud. Wenn eine Software auf die Vorteile der Cloud eingeht, ist diese dort jedoch sehr gut aufgehoben. Dazu zählen moderne Lösungen, die auf dem Cloud-Native-Konzept basieren und beispielsweise extra für den Container-Orchestrator Kubernetes gebaut wurden. Unterstützt eine Software dieses Architektur-Paradigma, ist sie prädestiniert für die Cloud und Banken sollten nicht versuchen, sie in der Private Cloud zu betreiben.

Kein Vorteil ist hingegen, eine Software einfach vom eigenen Server in die Cloud zu verlagern. Aufgrund ihrer stets beschränkten Ressourcen sollten sich Banken vielmehr auf die wertschöpfenden Anwendungen fokussieren. Auch eigene Software-Entwicklungen zählen hierzu, da diese perspektivisch in der Cloud am schnellsten sind. Dabei sollte unbedingt in Automatisierung in Form von DevOps investiert werden:

Denn wenn ein neues Code-Artefakt programmiert wird, wird es automatisch in der Cloud kompiliert. Gleichzeitig laufen automatische Sicherheitschecks, die beispielsweise herausfinden, ob alle verwendeten Open-Source-Lizenzen richtig angewendet werden.”

Sinnvolle Tools sind hier beispielsweise WhiteSource und SonarQube, deren Einsatz den Entwicklungsprozess massiv beschleunigen kann und darüber hinaus die Sicherheit erhöht. Da modulweise vorgegangen wird, kann das Deployment auch nur für den Teil vorgenommen werden, der gerade verändert wurde. Das eröffnet auch neue Möglichkeiten in Bezug auf AB-Testing. Für Entwicklungsgeschwindigkeit sorgt die sehr leichtgewichtige und schnelle Programmiersprache „Go“, die in einer dezentralen, skalierbaren Welt wie der Public Cloud besonders gut funktioniert. Besonders bei rechenintensiven Neuentwicklungen ist diese einen Blick wert.

Dezentral und heterogen denken

Wer als Bank seine Cloud richtig nutzt, erlaubt jedem Projekt gewisse Freiheitsgrade. So dürfen Cloud-Projekte beispielsweise die Programmiersprache nutzen, mit der sie bevorzugt und am schnellsten arbeiten.”

Zudem sollte es für ein Projekt möglich sein, ein eigenes Kubernetes-Cluster zu verwenden, falls es gegenüber der Bereitstellung eines zentralen Kubernetes-Clusters vorteilhaft ist. Die Bereitstellung von wiederkehrenden Services setzt dabei auf zentral bereitgestellten Blueprints auf.

In Banken existieren in der Regel mehrere Cloud-Projekte, zwischen denen es immer wieder die gleichen Anfragen gibt – beispielsweise eine DevOps-Pipeline. Diese sollte idealerweise in einem Marketplace zur Verfügung gestellt werden, aus der sich mit einem Klick der passende Service konfigurieren lässt. Auch Kubernetes-Cluster oder Datenbanken sollten in einem Shop bereitgestellt werden, der bereits von der Bank-Security unter die Lupe genommen wurde.

Derlei technische Fragen sollten stets in einen Change-Prozess im Unternehmen eingebettet sein. Laut der Umfrage „Cloud Transformation in Financial Services“ von KPMG sind für eine erfolgreiche Cloud-Transformation geschulte Mitarbeitende und reibungslose Prozesse entscheidend. Dabei kommt es vor allem auf eine enge Abstimmung zwischen den Beteiligten an. Insbesondere IT und Mitarbeitende der Vorgaben-gebenden Seite (2nd Line of Defence – 2nd LoD) müssen intensiv zusammenarbeiten. Zudem sollte der Vorstand von Beginn an eingebunden werden, um für einen hohen Stellenwert für Cloud-Projekte in der Unternehmensagenda zu sorgen. Für reibungsloses Arbeiten in der Cloud sollten die Projekte kontinuierlich durch Change-Management in den Fachbereichen begleitet werden.

Alles in allem lässt sich feststellen:

Bei der Implementierung der Cloud gibt es keinen Königsweg, der für alle Banken und Versicherungen gleichermaßen passt.”

Jeder ist hier individuell gefordert, seinen eigenen Weg zu finden und zu gehen. Das ist nicht immer leicht, am Ende steht dann aber eine Lösung, auf die das jeweilige Haus dann auch bauen kann.Gerrit Bojen, KPMG