Eine Identität für Menschen und Agenten: wer was tun darf

An einem Donnerstagnachmittag ändert sich in den Stammdaten die Bankverbindung eines Lieferanten. Der Zahlungslauf am Freitag verwendet das neue Konto. Am folgenden Dienstag ruft der Lieferant an und fragt, wo das Geld bleibt, und das Finanzteam öffnet das Prüfprotokoll, um zu sehen, wer die Änderung gemacht hat.

Das Protokoll sagt: INTEGRATION_SVC. Dieses Konto gehört der Middleware. Darüber laufen der Webshop-Abgleich, der Lagerkonnektor, ein geplantes Bereinigungsskript und, seit dem Frühjahr, zwei Agenten, die Stammdaten aktualisieren, wenn ein bestätigtes Dokument das verlangt. Sechs Prozesse, ein Name, ein Passwort, das an drei Stellen gespeichert ist. Die Änderung hat einer von ihnen gemacht, im Auftrag von jemandem, aus einem Grund, und der Datenbestand kann nicht sagen, welcher, für wen oder warum.

Das ist keine Sicherheitslücke. Jeder Prozess hat getan, wofür er konfiguriert war. Es ist ein Identitätsproblem: Das Unternehmen hat seiner Software ein gemeinsames Gesicht gegeben, und ein gemeinsames Gesicht kann man nicht befragen. Sobald Agenten zu handeln beginnen, vervielfacht sich die Zahl der Aktionen hinter diesem Gesicht, und jede einzelne ist von Haus aus anonym.

Was ein gemeinsames Servicekonto verbirgt

Den Akteur. Sechs Prozesse hinter einem Namen bedeuten, dass das Protokoll festhält, dass etwas passiert ist, und nicht, was es getan hat. Der Fehler eines Menschen, der Bug eines Skripts und die Fehleinschätzung eines Agenten sehen identisch aus und werden auf dieselbe Weise korrigiert: langsam.

Den Auftraggeber. Ein Agent, der einen Lieferanten aktualisiert, tut das, weil die Rolle eines Menschen es verlangt hat oder ein Prozess es erlaubt hat. Das Servicekonto trägt keine Spur dieser Kette, also hat auch die Frage „für wen wurde das getan“ keine Antwort.

Den Umfang. Ein Servicekonto sammelt Rechte an. Jede Integration brauchte eine Tabelle mehr, einen Endpunkt mehr, und niemand hat die entfernt, die nicht mehr gebraucht werden. Der im letzten Jahr hinzugekommene Agent hat sie alle geerbt, einschließlich des Rechts, eine Bankverbindung zu ändern, das er nie gebraucht hat.

Die Zeit. Das Konto ist gültig, seit es angelegt wurde. Der Zugang eines Menschen endet mit seinem Ausscheiden; eine delegierte Aufgabe endet, wenn sie erledigt ist. Das gemeinsame Konto endet nie, und ein einmal geleaktes Zugangsdatum ist für immer geleakt.

Die Grenze zwischen Lesen und Schreiben. Das Konto, das Aufträge für einen Bericht liest, ist dasselbe, das eine Zahlungsdatei schreibt. Ein kompromittiertes Skript, ein falsch konfigurierter Prompt, und der Lesepfad wird zum Schreibpfad. Warum das Schreiben die gefährliche Hälfte ist, steht in ein Agent schreibt ins ERP.

Berechtigungen an Tabellen. Datenbankrollen gewähren Zugriff auf eine Tabelle, nicht auf einen Kunden. Ein Agent, der die Auftragstabelle lesen darf, liest jeden Auftrag, auch die der Kundengruppe, die seine Rolle nie sehen sollte. Früher hat die Bildschirmmaske sie verborgen; der Agent benutzt die Maske nicht.

Wie die Identität eines Agenten aussehen muss

Ein eigener Name. Jeder Agent ist ein Prinzipal im Verzeichnis, wie ein Mensch und anders als ein Passwort in einer Konfigurationsdatei. Das Protokoll nennt dann den Agenten, und eine strittige Änderung lässt sich auf einen Prozess zurückführen statt auf einen Pool von sechs.

Delegiert von einem Menschen oder einer Rolle. Ein Agent hat keine eigenen Rechte; er handelt für jemanden. Der Einkaufsagent handelt unter der Einkaufsrolle, innerhalb dessen, was diese Rolle darf, und der Datenbestand zeigt Agent und Rolle zusammen. Verlässt der Mensch hinter der Rolle das Unternehmen, endet die Delegation mit ihm.

Rechte, die ablaufen. Eine Delegation gilt für eine Aufgabe, einen Bereich und einen Zeitraum. Offene Rechnungen für die nächsten dreißig Tage zu lesen ist ein Umfang; alles für immer zu lesen ist ein Servicekonto unter anderem Namen. Läuft der Umfang ab, fragt der Agent erneut, und das Fragen wird festgehalten.

Berechtigungen an Geschäftsobjekten, nicht an Tabellen. Hier verdient sich die Ontologie ihren Platz. Das Modell definiert einen Kunden, einen Auftrag, einen Lieferanten, eine Bankverbindung und die Aktionen, die es auf jedem gibt: lesen, vorschlagen, ändern, freigeben. Eine Berechtigung sagt dann, dass der Serviceagent Reklamationen der Kunden einer Region lesen und Antworten vorschlagen darf, nicht, dass er aus drei Tabellen selektieren darf. Dieselbe Regel gilt für Menschen, sodass ein Mensch und ein Agent in derselben Rolle exakt dasselbe sehen.

Auf dem Server durchgesetzt, für alle lesbar. Die Berechtigung liegt unterhalb des Agenten, in der Schicht, die jede Anfrage prüft, nicht in den Anweisungen des Agenten. Ein Prompt kann sich keinen Zugriff verschaffen, und wer das Modell liest, sieht, was jeder Agent darf, ohne Code zu lesen.

Dieselbe Antwort für Mensch und Agent. „Wer hat das getan, für wen, auf welcher Grundlage, und wer hat es freigegeben“ wird auf dieselbe Weise beantwortet, ob der Akteur ein Sachbearbeiter oder ein Prozess war. Kann der Datenbestand das für Mitarbeiter beantworten und für Agenten nicht, sind Agenten ein Loch in der Prüfung, nicht ein Teil davon.

Ein Test, den Sie heute machen können

Öffnen Sie das Prüfprotokoll Ihres ERP oder Ihrer Buchhaltung und filtern Sie den letzten Monat nach den technischen Konten: der Integrationsbenutzer, der API-Benutzer, alles mit „svc“, „sync“ oder „system“ im Namen. Zählen Sie die Änderungen. Nehmen Sie dann fünf davon zufällig heraus und versuchen Sie für jede zu beantworten, welcher Prozess die Änderung gemacht hat und für welchen Menschen oder welche Rolle.

Wenn Sie das nicht innerhalb weniger Minuten allein aus dem Datenbestand beantworten können, ohne die IT zu fragen, ist jede dieser Änderungen anonym. Listen Sie nun die Prozesse auf, die sich jedes technische Konto teilen, und die Rechte, die das Konto hält. Die Differenz zwischen dem, was jeder Prozess braucht, und dem, was das Konto hat, ist die Angriffsfläche, mit der Sie bisher gearbeitet haben, und es ist die Fläche, die ein Agent am ersten Tag erben würde.

In Hurukan erreicht jede Anfrage den Server mit einer Identität: ein Mensch, ein Agent, der für einen Menschen oder einen Prozess handelt, oder das System selbst. Berechtigungen werden dort geprüft, auf dem Server, gegen die Rollen und Regeln, die die Ontologie auf Geschäftsobjekten definiert, und jede Änderung wird mit dem Typ ihres Urhebers festgehalten, mit dem, was sich geändert hat, und mit der Freigabe, auf der sie beruht. Das macht einen Agenten im selben Satz rechenschaftspflichtig wie einen Mitarbeiter, und es ist die Basisschicht von Hurukan, beschrieben in Souveränität ist eine Architekturentscheidung.