Software ist immer ein bewegliches Ziel. Software kann niemals komplett „fertig“ sein, sondern unterliegt einem ständigen Wandel durch Weiterentwicklungen und Erweiterungen. Selbst Microsoft kündigt nach dem Versprechen einer endgültigen Version 10, mit schrittweisen Upgrades, eine neue Windows-Version an. Im AML Compliance-Bereich, d.h. AML, KYC und Transaktionsscreening, befindet sich das nächste Upgrade- oder Migrationsprojekt nach einem erfolgreichen Go-Live schon fast in der Vorbereitung, da neue Vorschriften und Sicherheitsfunktionen immer erweiterte Versionen erfordern. Bei der Auswahl eines neuen Compliance-Systems stellen sich viele Fragen - eine davon ist die "Cloud-Frage", zu der ich mit diesem Beitrag kurz einige wichtige Aspekte für die Entscheidungsfindung liefern möchte. Es gibt viele Cloud-Versprechen, wie niedrigere Kosten, schnellere Bereitstellung, Skalierbarkeit, Flexibilität, Zukunftssicherheit u.v.m., die man in verschiedenen Varianten auf den Webseiten aller Cloud-Software-Anbieter finden kann.
Je nach Rechtsraum müssen verschiedene Restriktionen und Gesetze im Zusammenhang mit der Speicherung sensibler Daten in der Cloud beachtet werden. Ich werde diesen Themenkomplex nicht einmal oberflächlich umreißen, werde aber dennoch zwei wichtige Vorschriften benennen. Die DSGVO und all ihre Aspekte können leicht eine Woche voller Workshops füllen, die MaRisk (siehe BaFin AT9) machen es schwieriger, compliant zu sein. Ein wichtiger Punkt ist der Standort der Cloud-Server. Es kann notwendig oder zumindest vorteilhaft sein, dass die Daten das Land nicht verlassen. Kommerzielle Cloud-Plattformen wie AWS, Google und Azure bieten ihre Dienste in länderübergreifenden Regionen an, was für Unternehmen in kleineren Ländern ein K.o.-Kriterium darstellen könnte. Wenn eine geeignete Region gefunden ist, die außerhalb der Hauptregionen (wie USA, Vereinigtes Königreich) liegt, kann es auch vorkommen, dass nicht alle Cloud-Dienste aktuell angeboten werden.
Der nächste wichtige Faktor ist die Erfahrung. Ist im Unternehmen (jenseits von Office365) bereits Cloud-Software im Einsatz und ist die jeweilige Compliance-Software, z. B. das Screening-, Monitoring- oder Research-System, Cloud-ready oder vorzugsweise Cloud-nativ? Die Compliance-Abteilung sollte aufgrund ihrer übergeordneten Bedeutung nicht in eine Position gebracht werden, neue Technologien zu pilotieren, sondern eher der Strategie folgen als sie zu definieren. Die kniffligere Frage ist die letztgenannte: Ist die Software Cloud-nativ? Da es sich bei den meisten Lösungen um Closed-Source-Software handelt, anbei einige Anhaltspunkte, wie dies festgestellt werden kann:
- Integrierte Skalierbarkeit und Hochverfügbarkeit
- Eine überzeugende Anzahl von bestehenden Installationen
- Eine vollständig automatisierte Deploymentpipeline
- Aufgeteilt in Microservices statt monolithischer Blöcke
- Open-Source-Nutzung mit adäquaten Versionen (OpenJDK 12 vs. Oracle Java 8, oder PostgreSQL vs. Oracle Database)
In der Vergangenheit galt Open-Source-Software aufgrund von Sicherheits- und Support-Problemen oft als ein „No-Go“ im Banken- und Compliance-Bereich. Es gibt kontroverse Diskussionen darüber, ob Closed- oder Open-Source-Software als sicherer angesehen wird. Die meisten Linux-Distributionen bieten kommerziellen Support an. Auch bei Datenbanksystemen wie Mongo, PostgreSQL oder Couchbase stehen Unternehmen hinter der Entwicklung, deren Geschäftsmodell darin besteht, kostenpflichtigen Support zu leisten. Diese Unternehmen können durch Kunden gezwungen werden, Schutz gegen etwaige Sicherheitsschwachstellen zu bieten und Sicherheitslücken gleich zu schließen. In gewissem Sinne kann dieser Trend als "das Beste aus beiden Welten" betrachtet werden: Der Code ist immer noch frei verfügbar, aber man kann dennoch Enterprise Level Support erwarten.
Der Betrieb von Legacy-Software in einer Cloud-Umgebung ist möglich, vereint aber in gewisser Weise „das Schlechteste aus beiden Welten“. Der Einrichtungsprozess kann komplex sein. Es können Abhängigkeiten zu Datenbanken und (Windows-) Betriebssystemen bestehen. Die Hardwarekosten könnten viel höher ausfallen, da virtuelle Maschinen anstelle von leichtgewichtigen Containern verwendet werden. Eines der größten Versprechen der Cloud sind Kostensenkungen. Letztendlich kostet ein virtueller Server mit echten CPUs und exklusiv reserviertem Speicher bei eigenem Hosting viel mehr, gerade wenn ein Dritter auch noch seinen Anteil daran haben möchte. Für einen schnellen Vergleich geht man einfach zu ein paar Webhosting-Unternehmen und vergleicht deren Serverkosten z. B. AWS EC2 oder Microsoft Azure VM (die nicht einmal Speicherplatz inkludieren). Daher sollte man sorgfältig zwischen dem Betrieb virtueller Maschinen im "Internet" und Cloud-nativen Lösungen unterscheiden. Erstere helfen niemals Kosten zu sparen, letztere haben das Potenzial Kosten zu senken. Es ist sehr wichtig, ein Konzept für die laufenden Kosten der Lösung zu haben, die direkt oder indirekt von der Bank gezahlt werden müssen.
Ein weiterer wichtiger Aspekt ist die Performance der Lösung. Garantiert der Anbieter Antwortzeiten und Betriebszeiten (und werden diese vom Cloud-Lieferant im Hintergrund abgedeckt)? Bei Kauf von Software-as-a-Service sind alle diese Aspekte idealerweise im Vertrag und im Verantwortungsbereich des Software-Anbieters enthalten.
Insbesondere wenn das Backend der Umgebung für den Endnutzer oder das technische Team der Bank nicht zugänglich ist, ist es wichtig, gute APIs für die Extraktion von Berichten, Protokollen und Audit-Trails zu haben. Das Compliance-Team der Bank bleibt verantwortlich für die Einhaltung der Vorschriften, daher sollten die verfügbaren Berichte gut aufgebaut und getestet sein. Niemand möchte eine solche imaginäre Unterhaltung hören:
F: Sehr geehrter Anbieter, können Sie bitte einen Bericht über alle auffällig gewordenen Transaktionen der letzten 13 Monate und die jeweiligen Nutzer, die an diesen Auffälligkeiten arbeiten, zur Verfügung stellen?
A: Sehr geehrter Kunde, wir verweisen auf das von Ihnen bestellte Standard-API-Paket, das keine Transaktionsdetails enthält.
Wenn die Lösung vor Ort betrieben wird, könnten technisch versierte Berater hinzugezogen werden, die in der Lage sind, ein paar Ad-hoc-Auszüge aus der Datenbank zu generieren und den Prüfer zufriedenzustellen. Ein solcher Backend-Zugriff ist bei einer echten Cloud-Lösung höchstwahrscheinlich nicht möglich - insbesondere nicht mit der zeitlichen Einschränkung wie in der imaginären Situation.
Bei Tendenz in Richtung Cloud-Implementierung ist ein potenzielles Anbieter-Lock-In zu berücksichtigen. Ist es beispielsweise möglich und machbar von AWS zur Google Cloud zu wechseln? Alle großen Cloud-Angebote verfügen über Hunderte von speziellen Diensten, auf denen die Anwendungsarchitektur aufgebaut werden kann. Die Nutzung dieser Dienste für die Entwicklung einer Cloud-Lösung mag intelligent und modern sein, aber wenn der Cloud-Anbieter sich als „böse“ erweist oder einfach zu teuer wird, könnte es schwierig oder gar unmöglich werden, den Anbieter zu wechseln. Es gibt auch Software-Anbieter für Anwendungs-Middleware, wie dapr.io und ähnliche Frameworks, um die Flexibilität bezüglich AWS/Google/Azure zu erhalten und Lock-in-Effekte zu vermeiden.
Die Hybrid-Cloud könnte eine dritte Option sein, insbesondere für zustandslose Anfragen wie das Screening von Namen und Transaktionen in Echtzeit. In diesem Szenario wird das Benutzer-Frontend vor Ort gehostet und die CPU/IO-Schwerstarbeit wird in der Cloud erledigt. Aufgrund der nahezu unbegrenzten Hardware-Flexibilität könnte es eine gute Idee sein, die Cloud auch für zeitlich begrenzte Projekte wie Parallelbetrieb und Systemmigrationen zu nutzen.
Die Antwort auf die Cloud-Frage lautet höchstwahrscheinlich "es kommt darauf an". Neu gegründete Unternehmen tendieren dazu, von Anfang an auf Cloud-native zu setzen. Größere Organisationen bauen gerne eigene Cloud-Umgebungen auf, da Cloud nicht unbedingt bedeutet, einen der großen Anbieter einzukaufen, sondern eher ein Deployment- und Software-Design-Muster einzusetzen. Für das Finden der richtigen Antwort in diesem Bereich sind meine msg Rethink Compliance Kollegen und ich bestens gerüstet. Wir verfügen über fundierte Erfahrungen mit Cloud-, Hybrid-Cloud- und On-Premise-Implementierungen, um unsere Kunden bei solch einer wegweisenden Entscheidung optimal zu unterstützen.
