KRITIS-relevante Cloud-Transformationen: Nichtfachliche Anforderungen bergen größtes Risiko

Eine moderne Zahlungsverkehrsplattform in der Cloud besteht meist aus 400 bis 500 sogenannten Pods. Jeder dieser Pods enthält entweder eine fachliche Kernapplikation oder Komponenten, die für einen reibungslosen Betrieb benötigt werden, wie Middleware, Netzwerkzugänge oder eine Datenbank. Ein digitaler Dirigent, beispielsweise Kubernetes, steuert diese Pods und stellt sicher, dass alle erforderlichen Ressourcen gestartet und wieder freigegeben werden. Einer der wesentlichen Vorteile solcher Architekturen liegt darin, dass sich ohne Weiteres zusätzliche Pods einer Kernapplikation starten lassen, um aufkommende Lastspitzen aufzufangen. 

Große Service-Architekturen wie eine Zahlungsverkehrsplattform brauchen deshalb nicht mehr auf permanent vorgehaltene Maximallast ausgelegt werden, sondern lassen sich an Normallast ausrichten, wobei erforderliche Verarbeitungskapazitäten bedarfsgesteuert erhöht werden. Wenn davon gesprochen wird, dass Anwendungen in der Cloud besser skalieren als monolithische Anwendungen, dann spielt dieser Effekt dabei eine maßgebliche Rolle. Dies setzt jedoch etwas Konzeptionsarbeit voraus, um alle Vorteile einer Cloud-Architektur voll auszuspielen.

Richtig vorbereitet, lassen sich komplette Service-Architekturen in wenigen Stunden deployen und nahezu vollständig durch den Orchestrator (Kubernetes) steuern. Um dies zu erreichen, müssen die fachlichen Anwendungen von allem befreit werden, was über ihre rein fachliche Aufgabe hinausgeht. Beispielsweise dürfen die benötigte Middleware oder Konfigurationen keinesfalls mehr fest in den Applikationen „verbaut“ sein. Vielmehr steuert der Orchestrator diese bedarfsweise zu. Im Betrieb ergeben sich daraus gleich mehrere Vorteile, die sich anderenfalls nicht realisieren ließen:

• Auf jeder Stage – von der Entwicklung bis zur Produktion – lassen sich die jeweils benötigten Konfigurationen und Zugangsdaten individuell den Pods zusteuern.
• Konfigurationen lassen sich vollständig automatisieren, wodurch das Deployment auf unterschiedlichen Stages transparent und wiederholbar in derselben Qualität abläuft
• Versionsupdates durchzuführen und neue Features einzuführen, gelingt im laufenden Betrieb, was bei Echtzeitsystemen wie Instant Payments unerlässlich ist
• Unterschied zwischen technischen und fachlichen Konfigurationen: Technische werden individuell pro Stage festgelegt, während die fachliche unverändert bleibt, sodass sich ein abgenommenes System unverändert in Produktion bringen lässt.

Letzteres gibt den Ausschlag dafür, dass sich die Service-Architektur innerhalb der Cloud automatisiert aufbauen lässt. Infrastructure as Code und ein eigens entwickeltes Software-Werkzeug („Stagedive“) führen inzwischen dazu, dass auf den von PPI für verschiedene Banken betriebenen Zahlungsverkehrsplattformen manuelle Fehler, insbesondere beim Staging (vgl. Abb. 2) kaum noch auftreten können, weil alles automatisiert abläuft.

Kompliziert wird es jedoch durch die nichtfachlichen Anforderungen. Wer die Architektur zuerst an den fachlichen Applikationen ausrichtet und erst danach die insbesondere von den Gesetzgebern auf EU- und Bundesebene vorgegebenen Anforderungen betrachtet, handelt sich womöglich mehr als nur technische Schulden ein. Das Projekt könnte sogar scheitern, weil die nichtfachlichen Anforderungen einen so großen Anteil ausmachen. Zu bedenken ist dabei, dass diese Anforderungen keinesfalls Features sind, die in die fachlichen Applikationen integriert werden, sondern meist selbst querschnittliche Applikationen darstellen. Sie wirken sich folglich auch auf andere Applikationen aus, die etwa das Monitoring oder das Logging übernehmen.

Nichtfachliche Anforderungen stellen also für sich genommen bereits eine zusätzlich zu beachtende Herausforderung für die Gesamtarchitektur dar. Sie strahlen aber auch auf die übrigen Komponenten ab. Dies gilt umso mehr, falls Services von Drittanbietern integriert werden sollen, die mit Verfügbarkeiten und Service Level Agreements (SLA) ausgestattet sind, welche möglicherweise von den für die Plattform geforderten abweichen. Zu den wesentlichen nichtfachlichen Anforderungen gehören:

1. US-Bezüge: Die größten Cloud-Anbieter (Hyperscaler) erzeugen einen US-Bezug, der wirksam mitigiert werden muss, um Cloud-Plattformen sicher zu betreiben. Sämtliche Daten sollten sowohl in den Ablagen („Data at Rest“) als auch auf dem Transportweg („Data in Transit“) mit einem geeigneten Verfahren verschlüsselt werden. Gleichzeitig empfiehlt es sich, die Schlüssel dafür ausschließlich selbst zu verwalten („Hold your own key“).
2. Zugriff: Hierbei sind zwei grundlegende Aspekte zu betrachten. Erstens Prinzipien wie das „Need to know“ einzuhalten und zweitens eine Authentifizierung vorzusehen, die anwendungsübergreifend funktioniert. Grundlage dafür bildet das vorhandene Rollen- und Rechte-Konzept. Über einen zentralen Identity-Provider wie Kexcloak erfolgt die einheitliche Authentifizierung und Zuordnung zu einer Rolle. Jede Rolle wird während des Deployments mit den zugehörigen anwendungsspezifischen Rechten versehen, sodass nur im Rahmen der Rolle agiert werden kann.
3. Support: Vereinbarte Reaktionszeiten mit Kunden sowie die technischen Hilfsmittel, mit denen die Mitarbeiter im Support ausgestattet werden, wirken sich ebenfalls auf die Cloud-Plattform insgesamt aus. Von Software über Netzwerke bis hin zur erforderlichen Bandbreite muss alles aufeinander abgestimmt sein, um die benötigten Informationen vertragsgemäß und effizient bereitzustellen.
4. Ausfallsicherheit: KRITIS-relevante Systeme dürfen ausschließlich für eine vereinbart minimale Zeit ausfallen und müssen im Ernstfall gewährleisten, möglichst wenig Daten zu verlieren. Dies wird durch die beiden Kennzahlen RTO (Recovery Time Objective) und RPO (Recovery Point Objective) beschrieben. In der Praxis werden ausgefallene Plattformen in einem entfernen Rechenzentrum wieder gestartet („Georedundanz“). Die Herausforderung: In der durch RTO vorgegebenen Zeit muss die Plattform mit einem durch RPO vorgegebenen gültigen Datenbestand wieder funktionsfähig sein.

Vor allem der letzte Punkt hat es mitunter in sich, weil der Datentransfer und das Deployment der ersatzweise gestarteten Service-Architektur in kürzester Zeit abgeschlossen sein müssen. Steigt die Komplexität der Plattform, steigt folglich auch das Risiko, im Katastrophenfall zu spät oder mit einem unzureichenden Datenbestand wieder online zu gehen. Darum ist es unerlässlich, von vornherein ein Gesamtkonzept zu entwickeln, um die Service-Architektur richtig aufzubauen.