Wenn sich die Bank-IT öffnet, steht das Berechtigungs­system oft auf dem Kopf

Fast alle Banken in Deutschland setzen inzwischen auf die Cloud. Die meisten arbeiten mit einem der großen Hyperscaler zusammen. Hinzu kommt Open Banking, das immer wichtiger für die Institute wird – gerade erst hat Visa die schwedische Open-Banking-Plattform Tink gekauft, um in Europa durchzustarten. Diese beiden Trends führen dazu, dass sich die Bank-IT nach außen öffnet, und das stellt die Berechtigungssysteme mitunter ganz schön auf den Kopf.

von Severin Matthes, Senior Consultant bei Senacor Technologies

Bis 2025 soll das weltweit erzeugte Datenvolumen auf jährlich 175 Zetabyte anwachsen. Das ist eine Zahl mit 21 Nullen und entspricht mehr als 55 Billionen Bibeln – für jede einzelne der 694 Sprachen, in der das vollständig übersetzte Werk inzwischen erschienen ist. Diese schiere Menge an Daten schöpft sich aus unzähligen Quellen, darunter auch aus Bankgeschäften. Vor allem digitale Zahlungen sind auf dem Vormarsch, selbst im Bargeldland Deutschland. Doch global betrachtet nimmt der Anteil an Banken, die Zahlungen auslösen, immer weiter ab. Bei den 500 größten traditionellen Instituten liegt die Quote bei nur noch 72 Prozent. Das liegt sowohl an Fintechs, die Zahlungen für ihre Kunden auslösen (PSD2), aber auch an digitalen Bezahldiensten wie sie vor allem die großen Tech-Riesen aus den USA anbieten.

Asynchrones Messaging einführen

Weil die Gelder früher oder später doch auf einem Konto landen oder von einem stammen, muss jede Bank entscheiden, welche Dienste welche Aktionen auf einem Konto durchführen dürfen – und das weitgehend in Echtzeit, will das Institut in der digitalen Welt auch künftig noch relevant bleiben. Das gilt auch für Open Banking, das eher für noch mehr als weniger Anfragen sorgen wird, ob die gewünschte Aktion erlaubt ist oder nicht.

Zudem verändert sich durch die Cloud, wie die einzelnen Module innerhalb der IT-Landschaft abgleichen, ob und wie sie sich gegenseitig aufrufen und bestimmte Transaktionen durchführen dürfen.”

Was geht und was nicht, muss die Bank deshalb in einem hochgradig skalierbaren System abbilden.

Skalierbar heißt hier vor allem, dass alle Dienste mit denselben Informationen arbeiten und das möglichst unabhängig voneinander. Sogenannte Publish/Subscribe-Patterns – oder kurz: pub/sub – eignen sich dafür besonders gut. Sie erlauben einzelnen Diensten, Daten asynchron anzunehmen und zu verteilen, beispielsweise Berechtigungen. Dafür unterscheidet das Systen zwischen Events, die ein oder mehrere Publisher erzeugen, und Abonnenten, die nur auf diese Events warten. Google verspricht dabei etwa eine Latenz von weniger als 100 Millisekunden, also praktisch Echtzeit. Die Idee: Jeder Dienst abonniert nur die Ereignisse, die dem eigenen Use Case entsprechen (vgl. Abb. 1).

Beispielsweise abonniert ein Dienst für das Kundenlogin im Online-Banking nur die dafür relevanten Events – Kundenrechte und Einschränkungen aufgrund einer Kundenklassifizierung – und speichert sie bei sich ab. Wenn ein bestimmter Kunde künftig neue Berechtigungen erhält, gibt das Berechtigungssystem dies bekannt, erzeugt dafür ein Ereignis und verlässt sich darauf, dass die Abonnenten die bereitgestellten Daten selbst auswerten. Als Alternative dazu lassen sich OAuth-Tokens nutzen. Wegen ihrer beschränkten Größe eignen sie sich aber nur für weniger komplexe Systeme. Weil zu erwarten ist, dass die Komplexität von Banksystemen eher zu- als abnimmt, ist pub/sub deshalb die bessere Wahl. REST-APIs bewältigen diese Aufgaben zwar auch, doch sie stellen einen Single Point of Failure dar.

REST-API: Single Point of Failure

Je anspruchsvoller die Umsysteme, desto mehr muss die REST-API leisten. Darüber hinaus lässt sie sich schnell überfordern, etwa durch einen Dienst, der sehr viele Anfragen in kurzer Zeit stellt. Kriminelle machen sich diese Masche zunutze, um Webseiten anzugreifen und für ihre Nutzer nicht mehr erreichbar zu machen. Wenn die API nicht mehr hinterherkommt, stellt sie den Betrieb ein (Distributed Denial of Service). Das Problem: Wenn Berechtigungen für mehrere Systeme auf diese überforderte API angewiesen sind, stehen schlimmstenfalls große Teile der Bankplattform still. Zudem nehmen APIs schnell selbst die Komplexität an, die sie abbilden sollen – und verwandeln sich unversehens in einen kleinen Monolithen.

Eine pub/sub-Architektur lässt sich auch leichter erweitern als ein Berechtigungssystem, das auf REST-APIs setzt. Beispiel: Im Online-Banking ist relevant, ob ein eingeloggter Kunde die SEPA-Überweisung ausführen darf. Ein Mitarbeiter möchte hingegen alle Berechtigungen im Berechtigungssystem angezeigt bekommen, über die ein bestimmter Kunde verfügt. Die BaFin wiederum fragt eine Liste aller Kunden an, die über ein Konto verfügen dürfen. In der pub/sub-Welt lassen sich für jeden dieser drei Fälle die jeweils abgespeicherten Rechtesets aufrufen und abgleichen. In der REST-Welt entstehen dadurch gleich drei einzelne Endpunkte. Das wird schnell unhandlich und verleitet womöglich auch dazu, es mit der Sorgfalt nicht mehr so genau zu nehmen.

Wie gefährlich das ist, soll folgendes Gedankenspiel zeigen: Eine Bank möchte zusätzlich zu den Berechtigungen am Produkt auch Berechtigungen an einem Vertrag regeln, der mehrere Produkte umfasst. Bei REST-APIs entstehen dadurch nicht nur eine neue Berechtigungsart, sondern darüber hinaus drei neue Endpunkte, um Berechtigungen abzurufen, aufzusetzen und zu löschen – eventuell sogar mehrere Endpunkte für jede einzelne dieser Aktionen. Das kostet Performance, ist fehlernfällig und treibt den Aufwand hoch, um später die API zu pflegen und zu warten.

Wie die Orgelpfeifen in der Kirche

Pub/sub-Systeme dagegen skalieren vergleichsweise problemlos und sind resilienter, weil die Dienste unabhängig voneinander auf das reagieren, was auf dem Event-Bus passiert. Wenn es an einer Stelle doch mal hakt, betrifft das nicht automatisch gleich alle angebundenen Dienste und Anwendungen.”

Wer die Qualität des Berechtigungssystems weiter steigern möchte, sollte jedoch auch darüber nachdenken, wie die einzelnen Rechte verwaltet werden, um das System insgesamt flexibel zu halten. Jedes Recht auf granularer Ebene festzulegen, also ganz unten, wäre dermaßen aufwändig, dass die Bank zu nichts anderem mehr käme. Bewährt hat sich vielmehr, Rechte in vier Schichten zu organisieren, ähnlich wie bei einer Orgel.

Alle Berechtigungen zusammen entsprechen in diesem Bild den Pfeifen, die das Klangspiel erzeugen. Jede Orgel verfügt zusätzlich über sogenannte Register, die bestimmte Pfeifen öffnen oder verschließen. Ein Register fasst etwa alle Pfeifen – beziehungsweise Berechtigungen – zusammen, die ein Kunde spielen können muss, um via SEPA über sein Geld zu verfügen. SEPA und Auslandsüberweisungen gehören zu übergeordneten Kombinationen, die sowohl den Kunden wie auch dem Organisten erlauben, Muster zu spielen, die ständig wiederkehren. Im beschriebenen Fall spiegelt das wie komplette Kontoverfügung wider. Manuale bilden auf die gleiche Weise verschiedene Arten von Berechtigungen ab, wie Berechtigungen am Produkt oder am Vertrag. Vor der Orgel sitzt dann der Organist oder die Organistin, haut in die Tasten und erzeugt so den gewünschten Ton beziehungsweise führt die gewünschten Aktionen aus (vgl. Abb. 2).

Damit keine schiefen Töne entstehen, sollte eine Bank wirklich nur diejenigen Pfeifen auf die Orgel montieren, die etwas mit Berechtigungen im Berechtigungssystem zu tun haben. Was vom Produkt abhängt und nicht von einer Berechtigung, etwa ob das Sparbuch eine Auslandsüberweisung erlaubt oder nicht, gehört nicht dazu. Genau wie bei der Orgel sollte keine Pfeife doppelt existieren, es gilt also, Redundanzen zu minimieren und dafür zu sorgen, dass sich Berechtigungen gegenseitig nicht bedingen. Beispiel: Berechtigungen am Produkt dürfen nicht zugleich auch noch von der Kundengruppe abhängen. Wer solche Einschränkungen benötigt, legt sie idealerweise in einer separaten Datenhaltung fest, deren Events die betroffenen Services zusätzlich abonnieren und auswerten (siehe oben Abb. 1).

Schließlich sollte das System die Berechtigungen von Kunden und Mitarbeitern sowie technischen Benutzern identisch abbilden.

Ausblick

Wer diese „pub/sub-Orgel“ baut, verfügt über ein Berechtigungssystem, das leicht zu pflegen ist, schnell skaliert und die Bank auf das kommende Open-Banking-Zeitalter vorbereitet. Bald schon dürfte es so weit sein, dass die von extern eingehenden Anfragen rapide ansteigen.

Eine Bank, die darauf nicht in Echtzeit antworten kann, gerät ins Hintertreffen gegenüber agileren Instituten, die nahtlos Drittdienste integrieren und Berechtigungen unkompliziert prüfen.”

Das findet auch die BaFin gut, die nach den derzeit noch konsultierten BAIT etwa verlangt, neue, veränderte, deaktivierte und gelöschte Berechtigungen überall umgehend bekannt zu machen (Tz. 6.4). Offensichtlich gelingt das am ehesten, wenn die betreffenden Systeme, Module und Anwendungen selbst darüber informieren, was sie wem erlauben.Severin Matthes, Senior Consultant bei Senacor