Zero Trust Architektur

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. Die Bank 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.

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.

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 heißt, dass ein übernommenes System nur erreicht, was es erreichen sollte, und so wird aus einem Fußabdruck kein bankweiter Vorfall. Mikrosegmentierung 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.

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. Projekte müssen weiterhin kontrollierte Zugriffe und Berechtigungen nachweisen und die für das jeweilige Institut geltenden Regeln zuordnen.

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.

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.

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.

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.

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.

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.