CLOUD get CONNECTed: Investieren in Innovation, Strategien, Sicherheit

Von Richard Werner, Business Consultant bei Trend Micro

Verändertes Kundenverhalten und der Wettbewerb mit Fintech-Anbietern treiben die digitale Transformation der Bankenbranche unaufhaltsam voran. Banken müssen sicherstellen, dass sie mit innovativen Geschäftsmodellen und Services flexibel auf die künftigen Marktherausforderungen reagieren können. Mit den bisherigen IT-Architekturen ist dieses Ziel nicht zu erreichen – deshalb müssen jetzt die Potenziale neuer Technologien (Emerging Technologies) ausgelotet und genutzt werden. Im Rahmen der CLOUD get CONNECTed berichteten Experten von Forrester Research, AWS und Trend Micro über technologische Innovationen, Strategien und Sicherheit.

Das Spektrum der neuen Technologien ist breit gefächert und nicht alle sind für Banken unmittelbar relevant. Forrester hat viele Interviews mit Bankenvertretern und bankenfokussierten Softwareanbietern geführt, um mehr als 30 Technologien zu priorisieren. Neben Machine Learning haben sich dabei insbesondere Microservices als ein Investitionsschwerpunkt der nächsten Jahre herauskristallisiert, denn mit diesem Ansatz können Banken neue Geschäftsmodelle unterstützen und somit einen klarer darstellbaren Mehrwert schaffen.

Microservice-Architekturen

Im Gegensatz zu monolithischen bestehen Microservice-Architekturen aus entkoppelten Komponenten, die sich jeweils auf spezifische Aufgaben konzentrieren, autonom funktionieren und standardisiert kommunizieren. Der Ansatz zeichnet sich durch überlegene Skalierbarkeit und Agilität aus, denn neue Funktionalität oder Updates können granular und kontrolliert eingeführt werden.

Bei der Umsetzung von Microservices im Bankenumfeld hat sich das Domain-Driven Design (DDD) als Ansatz bewährt. Eine Domäne bezeichnet einen von den Banken individuell definierten Fachbereich mit all seinen Prozessen, Elementen und Beziehungen. Ziel des DDD ist es, alle inhaltlich verwandten Aufgaben in einem Microservice bzw. einem Bündel aus Microservices zusammenzufassen, um Kundeninteraktionen End-to-End abzubilden. Änderungen und Neuerungen lassen sich so in einer Domäne konsistent und viel schneller als bisher umsetzen.

Microservice-Architekturen und DDD sind natürlich auch mit Herausforderungen verbunden: Sie erfordern ein hohes Maß an konzeptioneller Trennschärfe, denn es darf keinesfalls passieren, dass zum Beispiel der gesamte Zahlungsverkehr wieder über eine einzige Komponente abgewickelt wird. Besondere Sorgfalt erfordert zudem der Bereich der verteilten Daten, die in verschiedenen Clouds und Applikationen gespeichert sind oder in unterschiedlichen Datenbanktypen stecken, abhängig vom zugehörigen Microservice. Für eine geschmeidige Datennutzung werden hier neue Streaming-Konzepte benötigt. Trotz aller gewünschten Agilität muss auch eine gewisse Konsistenz der Microservices gewahrt bleiben, zum Beispiel bei der so genannten User Experience. Eine effiziente Governance der verschiedenen Teams trägt daher wesentlich zum Gesamterfolg bei.

Vom Monolithen zum Microservice – das Beispiel Amazon

Bis 2001 nutzte Amazon selbst eine monolithische IT-Architektur, die den Geschwindigkeitsanforderungen des Online-Handels aber nicht mehr gerecht werden konnte. Notwendige Updates etwa beanspruchten bis zu elf Stunden. Wie heute im Finanzsektor war auch damals im eCommerce absehbar, dass sich die Entwicklung weiter beschleunigen würde. Um aus dem globalen Konzern eine agile Innovationsmaschine zu machen, startete Amazon daher ab 2002 eine technische und organisatorische Umstellung auf eine Microservice-Architektur.

Mehr Agilität und kontinuierliche Innovation ist nur zu erreichen, wenn der jeweilige Microservice End-to-End betrachtet wird und verantwortliche DevOps-Teams volle Autonomie haben – „You Build It, You Run It“. Dafür stellte Amazon eine Reihe von Regeln auf: Teams müssen alle Daten über Standardschnittstellen bereitstellen und dürfen nur über diese mit anderen Teams bzw. Microservices kommunizieren. Alle anderen Formen der Interprozess-Kommunikation wurden unterbunden. Microservice-Interfaces müssen zudem ausnahmslos externalisierbar sein. Im Gegenzug erhalten Entwickler die vollkommene Freiheit bei der Technologiewahl. Diese Umstellung nahm etwas Zeit in Anspruch, aber heute sorgen mehrere Tausend autonome Teams dafür, dass Innovationen und neue Kundenanforderungen schnellstmöglich umgesetzt werden können.

Empfehlungen für den Start

  • Am Anfang steht immer die Frage nach dem Geschäftsnutzen: Welche Teilbereiche verhindern, dass neue Services an den Markt gehen? Dabei sollte es nicht zu schnell um Architekturdetails gehen, sondern es empfiehlt sich im Rahmen eines DDD auf die fachliche Prozessebene zu blicken.
  • Welcher Fachprozess soll zuerst aus dem Monolithen gelöst werden? Dann müssen die zentralen Services identifiziert werden, über die zumeist extrem viel abläuft. Werden die noch in vollem Umfang verstanden?
  • Erst wenn diese Fragen erschöpfend geklärt sind, beginnt die Suche nach den richtigen Werkzeugen. Dieser Prozess ist hochindividuell, „One Size Fits All“ geht eigentlich nie.

Das Zerlegen einer gewachsenen monolithischen Struktur benötigt Zeit und Ausdauer. In den meisten Fällen ist daher eine Warmup-Phase sinnvoll, in der ein dediziertes Team nach geeigneten Startpunkten sucht und auch erste Erfolge generiert. Wichtig ist hier die Begrenzung des Risikos. Für den Einstieg bieten sich nach Erfahrung von AWS insbesondere API-Management und Identity Nexus-Management an. Erst wenn sich alle Beteiligten thematisch sicher fühlen, beginnt die eigentliche Architekturphase, gefolgt von Migration und Entwicklung.

Im Wesentlichen gibt es drei Strategien, die AWS alle unterstützt: Zunächst können an einen stabil laufenden Monolithen einzelne Mehrwert-Services für Kunden angedockt werden. Oftmals wird auch der gesamte Monolith in die Cloud migriert, um ihn dort zu optimieren und gleichzeitig Infrastrukturkosten zu senken. Außerdem kann der gesamte Core durch klare, einzelne Microservices ersetzt werden, zum Beispiel mithilfe des Serverless Lambda Services oder anderer Technologien.

Bankenmodernisierung aus Sicht der IT-Sicherheit

Der Bankensektor ist aufgrund seiner zentralen Funktion für das Gemeinwesen deutlich stärker reguliert als andere Branchen. Ohne umfassende und nachweisbare Sicherheit können keine neuen Services oder Funktionalität eingeführt werden, denn sonst drohen Strafen der Regulierungsbehörden und somit empfindliche Reputationsverluste. Die bisher eingesetzten Sicherheitslösungen sind aber für die dynamische Welt der Cloud, Container und Microservices ungeeignet. Modernisierung der Banken-IT bedeutet also zwingend auch Modernisierung der Banken-IT-Sicherheit.

Sicherheitslösungen müssen die Transformation in die Cloud unterstützen und sich nahtlos in Cloud-Services integrieren, um nicht die gewonnene Effizienz- und Flexibilitätsvorteile wieder zunichte zu machen. Des Weiteren ist das Thema Datenschutz und Compliance enorm wichtig, da hier der Aufwand durch die Regulierungsauflagen und die Komplexität der Cloud-Infrastrukturen stark gestiegen ist. Moderne Sicherheitswerkzeuge müssen in der Lage sein, Datenschutzverstöße oder auch Fehlkonfigurationen in solchen komplexen Umgebungen automatisiert zu erkennen und schnellstmöglich zu beheben.

Fazit: Automatisierung der IT-Sicherheit

Herkömmliche Sicherheitslösungen konzentrieren sich meist auf einen bestimmten Aufgabenbereich und korrelieren Daten nicht über alle Infrastrukturebenen hinweg. In komplexen Cloud- und Container-Umgebungen werden dadurch paradoxerweise zu viele Alarme produziert, während gleichzeitig akute Bedrohungen aufgrund des fehlenden Kontexts unentdeckt bleiben. Security-Fachkräfte mit aktuellem Know-how, die zur Analyse der Alarme benötigt werden, sind nur sehr schwer zu finden. Nur durch weitestgehende Automatisierung und umgebungsweite Sichtbarkeit können Security-Teams die Lage beherrschen.

Hier können sich Anwender auf Trend Micro Cloud One™ verlassen, eine automatisierte, flexible Komplettlösung für Sicherheitsservices auf AWS. Sie vereint auf einer einzigen Plattform ein vollständiges Spektrum von Sicherheitsleistungen für alle Anforderungen, von der Migration über die Entwicklung Cloud-nativer Anwendungen bis zur Cloud Operational Excellence.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.