Können Banken genau so schnell agieren wie Amazon & Co. und damit ihre Zukunft in Zeiten von Mobile Banking und Digitaler Transformation sichern? Durchaus, wenn sie moderne Technologieansätze wie DevOps für die Entwicklung ihrer Anwendungen nutzen.
Compliance-Vorgaben wie BAIT lassen sich mit DevOps besser umsetzen.
Partner des Bank Blogs
Geschäftsfelder von Internetfirmen und Banken lassen sich sicherlich nicht eins zu eins vergleichen, dennoch gibt es auffällige Parallelen. Ob ein Unternehmen Milliarden Suchanfragen pro Tag beantwortet oder eine Bank Millionen von Finanztransaktionen durchführt: Am Ende des Tages zählen Geschwindigkeit, Benutzerfreundlichkeit und Zuverlässigkeit. Im internationalen Vergleich waren die deutschen Banken beim Thema Digitalisierung bisher eher zurückhaltend.
Das lag jedoch nicht in erster Linie an mangelnder Innovationsfreude, sondern vor allem an der strengen Regulierung der Branche. Mittlerweile holen die Finanzinstitute hierzulande den Rückstand aber auf und auch hier spielt die Regulierung eine Rolle: Aktuelle Themen wie das Geldwäschegesetz, KYC oder auch der Schutz personenbezogener Daten gemäß der DSGVO erfordern eine leistungsfähige IT. Technologien wie Cloud-Computing und Methoden wie DevOps helfen dem Bankensektor, agiler und flexibler zu werden.
DevOps als Basis für Continuous Delivery
Voraussetzung dafür ist bezogen auf die eingesetzte IT maximale Skalierbarkeit und ein unterbrechungsfreier Betrieb, im Branchenjargon “Continuous Delivery” genannt. Die Realität sieht aber oft noch anders aus: Viele Banken kämpfen immer noch mit über Jahrzehnten gewachsenen IT-Infrastrukturen, komplexen Plattformen und komplizierten Schnittstellen-Architekturen. Als wäre das nicht genug, werden die Compliance-Vorgaben immer komplexer, bestes Beispiel dafür sind die Ende 2017 von der BaFin eingeführten BAIT (Bankaufsichtliche Anforderungen an die IT). Um vor diesem HIntergrund Continuous Delivery umzusetzen, führt an DevOps kein Weg vorbei. Der Ansatz bildet die Basis für agile Weiterentwicklung, umfangreiche Sicherheit, Nachverfolgbarkeit, Einhaltung von Compliance und flexible Skalierbarkeit.
Ein typisches Beispiel verdeutlicht die Herausforderungen von Continuous Delivery und die Möglichkeiten, die DevOps in diesem Bereich eröffnet: Eine Großbank bietet ihren Kunden weltweit eine mobile Banking-App, die mit dem zentral verwalteten Kernbankensystem kommuniziert. Der „Kern” der App ist in allen Ländern gleich, wird jedoch durch landesspezifische Module an die lokalen Gegebenheiten angepasst. Neue Funktionen oder gesetzliche Vorgaben müssen täglich, Sicherheitsupdates teilweise stündlich, weltweit ausgerollt werden. Dafür müssen auf der einen Seite die Apps auf den mobilen Endgeräten, auf der anderen Seite die Server in der jeweiligen Niederlassung aktualisiert werden. Hinzu kommt, dass je nach Zuspruch der Endkunden die Zahl der verfügbaren Server in der jeweiligen Cloud herauf- oder heruntergesetzt werden muss.
Mit DevOps lässt sich Software schneller entwickeln, testen und im Markt ausrollen.
Ein derartiges Entwicklungstempo kollidiert mit traditionellen Betriebskonzepten, bei denen jedes Release manuell vom Betriebsteam auf einer Staging-Umgebung getestet und dann auf das Live-System ausgerollt wird. Bei einem monatlichen Release könnte dies noch funktionieren, aber nicht bei täglichen oder stündlichen Updates.
Automatisierte Templates statt manueller Änderungen
Soll eine neue Software auf allen Servern installiert werden, war in der Vergangenheit viel manuelles Arbeiten angesagt. Der Administrator musste die Software für jedes System anpassen, sich sukzessive auf allen diesen Systemen einloggen, die entsprechende Datei installieren, das System eventuell neu starten, kontrollieren ob alles läuft – und nicht vergessen, sich am Ende wieder auszuloggen. Sämtliche Vorgänge müssen dabei natürlich protokolliert werden, damit andere Admins diese nachverfolgen können und sie BAIT-konform sind. Entweder erfolgt das über einen protokollierenden Gatekeeper, auf dem sich der Admin einloggt und von dort aus auf die Systeme zugreift. Oder die Änderungen erfolgen manuell und müssen dann auch händisch dokumentiert werden – ein Prozedere, dass hinsichtlich der Compliance zumindest fragwürdig, aber sicherlich fehlerträchtig ist.
All das lässt sich mit DevOps abstrahieren und automatisieren. Die Administratoren müssen sich nicht mehr mit jedem einzelnen System beschäftigen, stattdessen werden Templates erstellt und ausgespielt. Änderungen erfolgen nur noch an den Vorlagen und können problemlos revisionssicher dokumentiert werden.Es besteht auch die Möglichkeit, die Änderungen zuerst auf ein Testsystem aufzuspielen und dort automatisierte Security-Tests anzustoßen. Damit lässt sich das Security-Framework durchlaufen und so automatisch feststellen, ob das geplante Vorgehen den Sicherheitsrichtlinien der Bank entspricht und bekannte Sicherheitslücken schließt (Vulnerability Management). Erst wenn die Tests erfolgreich durchlaufen sind, erfolgt eine Rückmeldung an das Automatisierungstool, im Fall von Adacor etwa die Open-Source-Software Ansible von Red Hat. Diese ermöglicht das Lifecycle-Management von Apps durch Anwendungsverteilung, Netzwerkautomation, Konfigurationsmanagement und Workflow-Orchestrierung. Zum Abschluss sorgt Ansible zusätzlich für die Ausspielung der Änderungen auf allen Servern. Auf diese Weise kann ein aufwändiger Prozess so automatisiert und verschlankt werden, dass ein Admin im Idealfall gar keinen direkten Zugriff mehr auf Server, Dateien oder personenbezogene Daten hat – und somit auch keine Änderungen mehr dokumentieren muss.
Playbooks definieren feste Regeln
DevOps ist eine bewährte Methode, aber kein DevOps-Projekt gleicht dem anderen. Um das Rad nicht immer wieder neu zu erfinden, können Unternehmen so genannte Playbooks einsetzen. Das Know-how und die Ergebnisse der Kooperation von Systemadministratoren und Entwicklern werden bei der Nutzung des entsprechenden Tools beispielsweise in Ansible-Playbooks gebündelt. Dieses Playbook beinhaltet alle Befehle und Parameter, um ein neues System, eine neue Release oder einen Service online stellen zu können. Bei Adacor existiert mittlerweile eine ganze Bibliothek von Playbooks, auf deren Basis die Bereitstellung von Services – wie zum Beispiel Webserver, Application Server oder Datenbankserver – vollständig automatisiert erfolgen kann.
Bei allen genannten Vorzügen ist DevOps aber sicher nicht die Lösung aller Probleme. Bei allen IT-Projekten sollte am Anfang eine Analyse stehen: In welchen Umgebungen ergibt DevOps grundsätzlich Sinn, in welchen nicht? Für eine extrem sicherheitskritische Transaktionssoftware eignet sich DevOps unter Umständen eher weniger, für mobile Apps hingegen passt es hervorragend. Erfahrungsgemäß funktioniert DevOps am besten dort, wo Prozesse in einer Private oder Public Cloud laufen. Und last but not least dürfen Verantwortliche natürlich auch das Thema Rentabilität nicht aus den Augen verlieren werden. Bisherige Ergebnisse sind aber auch in dieser Hinsicht durchweg positiv zu bewerten.
