Fachbeitrag · Wirtschaftsinformatik ·
Unbeaufsichtigte Automatisierung: Warum ein Bot eine eigene technische Identität braucht
Ein automatisierter Ablauf kann jahrelang dieselben Arbeitsschritte ausführen und trotzdem überraschend ausfallen, sobald das Konto einer beschäftigten Person geändert wird. Passwortwechsel, Rollenwechsel oder ein Austritt betreffen dann plötzlich den gesamten Prozess. Für unbeaufsichtigte Automatisierung reicht es deshalb nicht, einen funktionierenden Benutzerzugang zu hinterlegen. Die technische Identität muss mit ihrem Zweck, ihren Berechtigungen und ihrem Lebenszyklus zum automatisierten Dienst passen.
Identität und Anmeldung getrennt betrachten
Die Identität beschreibt, welcher technische Akteur eine Aktion ausführt. Das verwendete Kennwort, Zertifikat oder kurzlebige Zugriffstoken ist lediglich ein Mittel zur Anmeldung. Der Austausch dieses Mittels sollte nicht automatisch die fachliche Zuordnung des Dienstes verändern. Wo eine Plattform geeignete verwaltete Identitäten oder vergleichbare Mechanismen anbietet, können sie den Umgang mit langlebigen Geheimnissen reduzieren. Ob das möglich ist, hängt jedoch von den angebundenen Zielsystemen und deren tatsächlich unterstützten Anmeldeverfahren ab.
Abhängigkeiten vor dem Wechsel erfassen
Ein Beispiel ist ein nächtlicher Bot, der Lieferstatus aus einem Fachsystem liest und einen Arbeitsbestand aktualisiert. Sein technischer Zugang benötigt möglicherweise Leserechte in einem System und eng begrenzte Schreibrechte in einem anderen. Vor einer Änderung werden beide Verbindungen, Laufzeiten, verantwortliche Personen und Rückfallmöglichkeiten erfasst. Ein Zugangstest allein genügt nicht: Der Probelauf muss auch die fachlich erforderlichen Aktionen ausführen, ohne dabei einen zusätzlichen produktiven Vorgang auszulösen oder bestehende Ergebnisse unbeabsichtigt zu überschreiben.
Rotation als Betriebsablauf planen
Ein Wechsel von Anmeldemitteln braucht einen kontrollierten Übergang. Je nach System kann dafür zeitweise ein zweites gültiges Anmeldemittel erforderlich sein. Neue Abläufe werden damit geprüft, bevor das alte Mittel außer Betrieb geht. Überwachung sollte fehlgeschlagene Anmeldungen von fachlichen Verarbeitungsfehlern unterscheiden. Ein wiederholter Start mit abgelaufenem Zugang behebt die Ursache nicht. Geheimnisse gehören in geeignete Geheimnisverwaltung, nicht in Ablaufbeschreibungen, Quelltext, frei lesbare Protokolle oder gemeinsam versendete Tabellen.
Verantwortung bleibt eine menschliche Aufgabe
Auch eine sauber getrennte Dienstidentität braucht eine verantwortliche Stelle. Sie prüft regelmäßig, ob der Ablauf noch benötigt wird, ob seine Rechte angemessen sind und welche weiteren Prozesse von ihm abhängen. Wird eine Automatisierung stillgelegt, erfolgt die Abschaltung abgestimmt mit ihren Abnehmern. Eigene Identitäten verhindern nicht automatisch Fehlbedienung oder überbreite Rechte. Sie schaffen zunächst eine klare technische Zuordnung, auf deren Grundlage Zugriff, Änderungen, Betrieb und spätere Stilllegung nachvollziehbar gestaltet werden können.
Technical insight · Business information systems ·
Unattended automation: Why a bot needs its own technical identity
An automated workflow can repeat the same tasks for years and still fail unexpectedly when an employee account changes. A password change, role change or departure can suddenly affect the entire process. Unattended automation therefore needs more than a working user login stored somewhere. Its technical identity must match the automated service in purpose, permissions and lifecycle.
Distinguish identity from authentication
An identity describes the technical actor performing an action. A password, certificate or short-lived access token is only a way of authenticating that actor. Replacing the credential should not automatically change the service’s business ownership. Where a platform supports suitable managed identities or similar mechanisms, they can reduce reliance on long-lived secrets. Whether they are usable depends on the connected systems and the authentication methods those systems actually support.
Record dependencies before making a change
Consider a nightly bot that reads delivery statuses from a business application and updates a work queue. It may require read access in one system and narrowly defined write access in another. Before changing its account, record both connections, operating times, responsible owners and fallback options. A login test is not enough: the trial must also exercise the required business actions without creating another production transaction or unintentionally overwriting existing results.
Treat rotation as an operational procedure
Changing authentication material requires a controlled transition. Depending on the system, a second valid credential may temporarily be needed. New executions can be tested with it before the old credential is retired. Monitoring should distinguish failed authentication from business processing errors. Repeatedly restarting a job with an expired credential cannot fix the underlying problem. Secrets belong in suitable secret management, not in workflow descriptions, source code, openly readable logs or spreadsheets distributed to several people.
Ownership remains a human responsibility
Even a separate service identity needs an accountable owner. That owner periodically checks whether the automation is still required, whether its permissions remain appropriate and which other processes depend on it. Retiring an automation requires coordination with its consumers. Dedicated identities do not automatically prevent mistakes or excessive access. They first establish clear technical attribution, providing a basis for traceable access control, changes, operations and eventual retirement.