Maschinenidentitäten in Banken: die Konten ohne Aufnahmeverfahren

Alles, was sich ohne Menschen an der Tastatur anmeldet: Dienstkonten für Stapelverarbeitung, API-Schlüssel zwischen internen Systemen und zu einem Anbieter, TLS-Zertifikate, mit denen zwei Dienste einander vertrauen, Workload-Identitäten in einer Container-Plattform, die Zugangsdaten hinter einem Chatbot oder einem Melderoboter. Die Non-Human Identities Top 10 von OWASP beschreibt sie als Anwendungsidentitäten, die im Produktivbetrieb identifiziert werden müssen, und nennt als Beispiele Dienstkonten, API-Schlüssel, Zugriffsschlüssel, Verschlüsselungsschlüssel, Token und Zertifikate.

Diese OWASP-Liste lohnt die Lektüre als Verzeichnis der Fehlerfälle, denn ihre Einträge sind betrieblich und nicht theoretisch: unzureichendes Abschalten ungenutzter Konten und Schlüssel, Geheimnisse, die an Orten landen, die nie dafür gedacht waren, überprivilegierte Identitäten, langlebige Geheimnisse mit fernem oder fehlendem Ablauf, dieselbe Identität in Entwicklung, Test und Produktion, und Menschen, die ein Dienstkonto für Handarbeit nutzen. NIST SP 800-207 behandelt Workload-Identitäten aus demselben Grund als eigenständiges Thema in einer Zero-Trust-Architektur.

Die Frage der Steuerung ist nicht, welches Produkt diese Zugangsdaten verwaltet. Sie ist, wer namentlich für jeden einzelnen verantwortlich ist. Ein Zugang mit benanntem Verantwortlichen wird überprüft, bekommt seine Rechte gekürzt, wenn sich die Aufgabe ändert, und wird abgeschaltet, wenn das bediente System stillgelegt wird. Ein Zugang, dessen Verantwortlicher 2019 gegangen ist, erlebt davon nichts, und er funktioniert weiter, und das ist das Problem.

Diese Verantwortungsfrage ist der Kern der Darstellung zum Schutz von Banken bei wachsender Zahl nichtmenschlicher Identitäten, und sie ist ein Hebel der Steuerung und keine Beschaffung. Der Überprüfungszyklus ist derselbe wie bei den Zugriffsrechten von Mitarbeitern, und dort setzen die Leitlinien der EBA zum IKT- und Sicherheitsrisikomanagement die Erwartung an das Berechtigungsmanagement. Zero Trust in Banken behandelt die Architektur, in der diese Identitäten stehen.

Eine Bank kann nichts steuern, was sie als einen Klumpen zählt. Die Arten verhalten sich unterschiedlich: Ein Dienstkonto hat ein Passwort und einen Rechtesatz, ein API-Schlüssel ist ein Inhaberzeichen, das für jeden funktioniert, der es hat, ein Zertifikat hat ein Ablaufdatum und eine Vertrauenskette, eine Workload-Identität wird zur Laufzeit ausgegeben und lebt vielleicht Minuten. Jede braucht eine andere Kontrolle, und wer alles als „Zugangsdaten" behandelt, bekommt eine Richtlinie, die auf keine passt.

Das Verhältnis von maschinellen zu menschlichen Identitäten und seine Richtung samt den beteiligten Arten behandelt diese Darstellung des Problems der Maschinenidentitäten. Praktisch nützt eine Einteilung, weil sie sagt, welche Kontrolle zuerst zu bauen ist: Eine kurzlebige Workload-Identität braucht ein Ausgabeverfahren, ein langlebiger API-Schlüssel in einer Anbieteranbindung braucht Rotation und einen Plan für den Tag, an dem er abfließt.

Am häufigsten schmerzen Maschinenidentitäten einer Bank ganz ohne Angreifer. Ein Zertifikat erreicht sein Ablaufdatum, zwei Dienste vertrauen einander nicht mehr, und eine Zahlungsschnittstelle oder ein Kundenkanal fällt aus, meist außerhalb der Bürozeit, meist ohne jemanden in Bereitschaft, der weiß, welches Zertifikat es war.

Damit sind Verzeichnis und Agilität dasselbe Projekt. Was nicht gefunden ist, lässt sich nicht erneuern, und in einem Bestand, der sich nicht aufzählen lässt, lässt sich kein Algorithmus austauschen. Das Zertifikatsverzeichnis dient also der Verfügbarkeit und der Kryptografie gleichzeitig. Krypto-Agilität in der Finanzbranche behandelt die Algorithmusseite, und die Hinweise des BSI zu kryptografischen Verfahren sind der deutsche Maßstab für den Inhalt der Zertifikate.

Ein Agent, der ein Postfach liest, ein System abfragt und eine Antwort entwirft, braucht eine Identität wie jede andere Last. Ein Agent, der eine Zahlung auslösen, ein Limit ändern oder eine Sperre aufheben kann, braucht drei Dinge: eine eigene Identität, ein Mandat, das mit ausdrücklichen Grenzen festhält, was er darf, und eine Spur von jeder Handlung zurück zu der Person, die sie verantwortet.

Das Letzte geht leicht verloren. Ein Agent, der unter einer von einem Menschen gesetzten Richtlinie handelt, nimmt diesem Menschen die Verantwortung nicht, und das ist das Argument der These, dass KI-Agenten auf menschlicher Identitätssteuerung aufbauen. Die KI-Verordnung der EU verlangt menschliche Aufsicht über Hochrisikosysteme, für eine Bank ist die Verantwortungskette also eine Rechtspflicht und keine Vorliebe der Technik. KI-Agenten im Finanzwesen behandelt, was diese Agenten tun, die KI-Verordnung im Finanzwesen die Regulierung, KI-Compliance in Deutschland den Umgang der BaFin damit.

Das ist kein unreguliertes Neuland, das auf eine Regel wartet. DORA verlangt IKT-Risikomanagement, Schutzmaßnahmen einschließlich Zugangsrechten und Identitätsverwaltung sowie Richtlinien zu kryptografischen Kontrollen und zur Schlüsselverwaltung, und keine dieser Vorschriften unterscheidet zwischen Zugangsdaten eines Menschen und solchen eines Dienstes.

Ein Bestand verwaister Dienstkonten ist damit heute eine Feststellung und kein Risiko für einen künftigen Aufsichtszyklus. DORA in Deutschland behandelt die Verordnung, Cybersecurity in der deutschen Finanzbranche das Sicherheitsbild, und Open Banking in Deutschland die Schnittstellen, an denen viele dieser Zugangsdaten eine Institutsgrenze überschreiten.

Bei den Zugängen, die Geld bewegen oder Kundendaten erreichen können, und jedem davon einen benannten Verantwortlichen, einen dokumentierten Zweck und ein Ablaufdatum geben. Das ist eine kurze Liste gegenüber dem ganzen Bestand, und es ist die Liste, um die ein Vorfall gehen würde.

Danach die Klassen angehen, die den wiederkehrenden Schmerz verursachen: Zertifikate ohne Erneuerungsverfahren, Geheimnisse in Code-Ablagen und Konfigurationsdateien, und Konten, deren letzte verzeichnete Nutzung älter ist als die heutige Plattform. KI im Banking in Deutschland behandelt die Richtung, die die Zahl weiter erhöht, und das ist der Grund, das Verfahren vor dem Mengenanstieg richtig zu bauen.

Jeder Zugang, der sich ohne Menschen an der Tastatur bei einem System anmeldet: ein Dienstkonto, ein API-Schlüssel, ein TLS-Zertifikat, eine Workload-Identität in einer Container-Plattform, ein Bot-Zugang. OWASP nennt sie nichtmenschliche Identitäten und behandelt sie als Anwendungsidentitäten, die im Produktivbetrieb identifiziert werden müssen.

Weil jede Anbindung, jeder Dienst, jeder Job und jede Automatisierung mindestens eine anlegt, während ein Mensch eine anlegt. Microservice-Architekturen, Cloud-Plattformen und Anbieteranbindungen vervielfachen die Zahl jeweils, und fast nichts entfernt sie wieder, denn die Stilllegung eines Systems umfasst selten den Widerruf der genutzten Zugangsdaten.

Ja, und die Zugangsdaten eines Menschen mitzunutzen ist der Entwurf, den man vermeidet, denn die Prüfspur sagt dann, eine Person habe etwas getan, was sie nicht getan hat. Der Agent braucht eine eigene Identität, ein Mandat mit ausdrücklichen Grenzen und eine festgehaltene Verbindung zu der Person, die seine Handlungen verantwortet. Für Hochrisikoanwendungen macht die KI-Verordnung mit ihrer Pflicht zur menschlichen Aufsicht daraus eine Rechtsfrage.

Ja. Die Anforderungen von DORA an IKT-Risikomanagement, Schutzmaßnahmen, Zugangsrechte und Identitätsverwaltung sowie kryptografische Kontrollen und Schlüsselverwaltung unterscheiden nicht zwischen menschlichen und maschinellen Zugangsdaten. Ein verwaistes Dienstkonto und ein ungesteuerter Zertifikatsbestand fallen damit unter die bestehenden Pflichten.