Zero Trust in Banken: wenn das interne Netz nicht mehr sicher ist
Eine Bank, die davon ausgeht, dass ein Angreifer schon drin ist, darf Zugriff nicht länger danach entscheiden, woher eine Anfrage kommt. Diese eine Änderung schreibt um, wie Systeme miteinander sprechen, und die ehrliche Fassung des Projekts beginnt damit, zu wissen, was geschützt werden soll, nicht mit einem Produkt.
Hier stehen: das Prinzip und die Norm dahinter, die zwei Schritte vor jeder Technik, die Identitäts- und Berechtigungskontrollen, auf denen das Modell ruht, die Altlast, die die meisten Banken auf halbem Weg hält, und die DORA-Pflichten, die diese Arbeit beantwortet. Das deutsche Lagebild behandelt Cybersecurity in der deutschen Finanzbranche.
Kein Vertrauen aus der Netzposition
Der Bezugstext ist NIST SP 800-207, Zero Trust Architecture vom August 2020. Er beschreibt Zero Trust als eine sich entwickelnde Menge von Paradigmen, die die Verteidigung von festen netzbasierten Perimetern zu Nutzern, Assets und Ressourcen verschiebt, und sagt ausdrücklich, dass eine Organisation Assets oder Konten nicht automatisch nach Netzposition oder Eigentümerschaft vertrauen soll. Authentifizierung und Autorisierung von Subjekt und Gerät sind eigene Funktionen, ausgeführt bevor eine Sitzung zu einer Ressource aufgebaut wird.
Eine Bank verliert dadurch die bequeme Annahme, dass eine Anwendung im Rechenzentrum mit einem Kollegen spricht. Sie muss nun jedes Mal fragen, wer anfragt, von welchem Gerät, in welchem Zustand, für welche Ressource. Das BSI ordnet das Modell in seinen eigenen Hinweisen für deutsche Organisationen ein, was zählt, wenn die Architektur einer Prüfung erklärt werden muss, die einen deutschen Bezug sehen will.
Schutzfläche und Flussdiagramm kommen zuerst
Was Zero Trust von einer Beschaffung unterscheidet, ist der Schritt, zuerst festzulegen, was geschützt wird, bevor etwas gekauft wird, um es zu schützen. Das bedeutet, die Daten, Anwendungen, Assets und Dienste zu benennen, deren Verlust wirklich weh täte, eine viel kleinere Menge als der ganze Bestand, und danach abzubilden, wie Transaktionen sie erreichen: welches System welches aufruft, in welcher Reihenfolge, mit welchen Zugangsdaten.
Die Reihenfolge in den fünf Schritten von DXC für Finanzdienstleister lautet Schutzfläche, Transaktionsflüsse, Architektur, Richtlinie, Überwachung, in dieser Folge. Die Reihenfolge trägt, weil eine ohne Flussdiagramm geschriebene Richtlinie den Zahlungslauf zum Monatsende blockiert und die Organisation daraus lernt, dass Zero Trust Dinge kaputt macht. Mit dem Flussdiagramm vorab wird daraus eine Entwurfsfrage mit bekannter Antwort.
Identitäten und privilegierte Zugänge tragen das Modell
Wenn die Netzposition keinen Zugriff mehr gewährt, muss die Identität das Gewicht tragen, und das heißt: ein Verzeichnis darüber, wer und was sich anmelden kann, mit einem Verantwortlichen je Eintrag und einer Überprüfung, die Einträge auch entfernt. Privilegierte Zugänge sind die Spitze: Administratorkonten, Notfallkonten, das Dienstkonto, das 2014 für eine Migration angelegt und nie abgeschaltet wurde.
Die Funktionstrennung gehört in dasselbe Gespräch, denn die Kontrolle, die verhindert, dass eine Person eine Zahlung anlegt und freigibt, ist ein Entwurf von Berechtigungen und kein Richtlinienpapier. DORA zählt IKT-Risikomanagement und Zugangsrechte zu den Pflichten eines europäischen Finanzunternehmens, und die Leitlinien der EBA zum IKT- und Sicherheitsrisikomanagement setzen die aufsichtliche Erwartung genauer. Zugangsdaten, bei denen sich nie ein Mensch anmeldet, sind ein eigenes Thema auf Maschinenidentitäten in Banken, und die phishingresistente Anmeldung behandelt Passkeys im Banking.
Mikrosegmentierung und der Teil, der sich nicht segmentieren lässt
Mikrosegmentierung heißt, dass ein übernommenes System nur erreicht, was es erreichen sollte, und so wird aus einem Fußabdruck kein bankweiter Vorfall. Sie trifft auch auf die älteste Maschine im Haus. Eine Kernbankplattform oder ein Großrechner, der älter ist als der Begriff, kann oft keine Autorisierung pro Anfrage erzwingen, und die Anwendungen darum herum wurden in der Annahme geschrieben, das Netz bürge für sie.
Die Hürden in der Darstellung von WWT zu Zero-Trust-Einführungen sind alte Zugriffswege, Betriebsumgebungen, in denen Änderungen aus guten Gründen abgelehnt werden, und ein fehlendes vollständiges Identitätsverzeichnis als Startpunkt. Das ist der ehrliche Grund, warum die meisten Banken auf halbem Weg stehen: Für den alten Kern ist die Antwort meist eine gehärtete Grenze davor mit überwachten, namentlichen Zugriffswegen, während der neuere Bestand das vollständige Modell bekommt. Kernbanksysteme in Deutschland behandelt die Plattformseite.
Was die deutsche Aufsicht erwartet, über DORA und davor BAIT
Deutsche Institute begegnen diesen Erwartungen nicht erst seit DORA. Die bankaufsichtlichen Anforderungen an die IT der BaFin, kurz BAIT, trugen die Erwartungen an Berechtigungsmanagement, Zugriffsrechte und IT-Governance über Jahre, und DORA hat dieses Feld in unmittelbar geltendes europäisches Recht überführt. Dass Menschen nach dem Verhältnis beider suchen, zeigen die Autocomplete-Daten, und für ein Projekt lautet die praktische Antwort: Die Kontrollziele haben den Übergang überlebt, auch wo sich die Fundstelle geändert hat.
Für ein Architekturpapier heißt das, einen Zero-Trust-Entwurf auf benannte Pflichten abbilden zu können, statt ihn als gute Praxis zu verteidigen. DORA in Deutschland behandelt die Verordnung und die Aufsicht durch die BaFin, Risikomanagement in Frankfurt die Risikofunktion drumherum.
Wo Zero Trust auf die Frage nach der Cloud trifft
Zero Trust beantwortet, wer eine Ressource erreichen darf. Zu der Frage, wo die Ressource liegt und welche Rechtsordnung Zugriff erzwingen kann, sagt es nichts, und beides wird häufiger in derselben Besprechung verwechselt, als gut ist.
Eine Bank kann eine vorbildliche Zero-Trust-Architektur in einer Cloud betreiben, deren Betreiber einer fremden Offenlegungsanordnung unterliegt, und die Architektur hilft dagegen nicht. Souveräne Cloud in Banken behandelt Ort und Kontrolle, Rechenzentren für die Finanzbranche in Frankfurt die physische Seite.
Was ist eine Zero-Trust-Architektur in einer Bank?
Ein Ansatz, bei dem keine Anfrage wegen ihrer Herkunft Vertrauen genießt, sodass jede Anfrage an eine Ressource gegen aktuelle Angaben zu Nutzer und Gerät authentifiziert und autorisiert wird. In einer Bank wird er angewandt, indem die schützenswerten Systeme festgelegt, die Transaktionsflüsse dorthin abgebildet und danach Entscheidungen pro Anfrage erzwungen werden. Die ältesten Plattformen bekommen stattdessen meist eine gehärtete, überwachte Grenze.
Verlangt DORA Zero Trust?
DORA benennt Pflichten, keine Architekturen. Verlangt werden IKT-Risikomanagement, Schutzmaßnahmen und kontrollierte Zugangsrechte, und ein Zero-Trust-Entwurf ist ein Weg, diese Pflichten sauber abzubilden. Eine Bank, die dieselben Ziele anders erreicht, ist konform. Auslassen kann sie die Ziele nicht.
Wo fängt eine Bank mit Zero Trust an?
Bei der Schutzfläche: der kurzen Liste von Daten und Systemen, deren Kompromittierung wirklich weh täte. Danach das Flussdiagramm der Transaktionen für diese Systeme. Entscheidungen über Technik folgen auf beides, denn eine ohne die Flüsse geschriebene Richtlinie blockiert rechtmäßige Arbeit und kostet das Projekt seine Unterstützung.
Geht Zero Trust mit einem Großrechner?
Teilweise, und das ist der übliche Zustand. Eine Plattform, die keine Autorisierung pro Anfrage bewerten kann, erhält eine gehärtete Grenze mit namentlichen, überwachten und befristeten Zugriffswegen, während der Bestand drumherum das vollständige Modell fährt. Der Fehlerfall ist, die Ausnahme zu verschweigen, denn ein Angreifer, der sie erreicht, findet die eine Stelle, an der das Netz noch für alle bürgt.
Zero Trust in Banken und Finance Loop
Finance Loop ist der Ort, an dem die Architekten, die Zugriffe in einer Bank neu ziehen, auf die Risikoverantwortlichen treffen, die den Entwurf vertreten müssen, und auf die Betreiber, die die alte Plattform am Laufen halten. Finance Loop ist der Treffpunkt für Sicherheit und digitale Infrastruktur in der deutschen Finanzbranche, mit Meetups und Konferenzen zu Cloud, Resilienz und der Regulierung beider. Finance Loop führt diese Termine im Veranstaltungskalender.
Finance Loop ist ein Experten-Netzwerk mit dem Ziel, neue Technologien in der Finanzbranche in die Anwendung zu bringen, etwa KI, Tokenisierung, Stablecoins und DeFi. Finance Loop hilft seinen Mitgliedern, Wissen und persönliche Netzwerke in diesen Feldern aufzubauen: Investment & Digital Assets, Payments & digitales Geld, digitale Infrastruktur & Souveränität sowie Risk & Compliance.