Verwaiste Zugänge: die stille Cyber-Lücke

Service-Accounts, API-Schlüssel und KI-Agenten übersteigen menschliche Konten oft um ein Vielfaches. Viele dieser Zugänge entzieht niemand. Genau dort öffnet sich das nächste Einfallstor: abseits des gehärteten Endpoints.

Verwandt:Welche Steuerung bleibt nach dem Agenten-Rollout  /  Kimi stoppt Abos: 7 Checks fürs KI-Capex

Warum die Zahl der Maschinen-Identitäten aus dem Ruder läuft

Jede Cloud-Migration, jeder neue Microservice und jede Automatisierung erzeugt Identitäten. Ein Deployment-Pipeline braucht einen Token, um Code auszurollen. Ein Monitoring-Dienst braucht einen Schlüssel, um Metriken zu lesen. Eine Integration zwischen zwei SaaS-Plattformen legt im Hintergrund ein technisches Konto an. Nichts davon taucht in klassischen HR-Prozessen auf, denn hinter diesen Zugängen steht kein Mensch, der onboarded oder offboarded wird.

In vielen Organisationen übersteigen nicht-menschliche Identitäten die menschlichen deutlich. Entscheidend ist weniger die exakte Relation als die Wachstumsdynamik. Menschliche Identitäten wachsen linear mit der Belegschaft. Maschinen-Identitäten wachsen mit jeder Architektur-Entscheidung, mit jedem Tool im Stack und inzwischen mit jedem KI-Agenten, der eigenständig auf Systeme zugreift. Der Bestand skaliert schneller, als die meisten Identity-Programme mitwachsen.

Das Problem verschärft sich, weil diese Identitäten schlecht dokumentiert sind. Ein API-Schlüssel wird schnell erstellt, um eine Integration zum Laufen zu bringen. Er landet in einer Konfigurationsdatei, einem Skript oder einem Secrets-Manager und wird danach selten wieder angefasst. Wer ihn erstellt hat, welchen Zweck er erfüllt und ob er noch gebraucht wird, weiß nach ein paar Personalwechseln oft niemand mehr.

Beim Austritt greift der Offboarding-Reflex. Maschinen-Konten leben oft weiter, bis sie jemand angreift.

Verwaiste Zugänge bleiben nach dem Projekt aktiv

Wenn eine Mitarbeiterin das Unternehmen verlässt, greift ein etablierter Prozess. Konto sperren, Geräte einziehen, Rechte entziehen. Bei Maschinen-Identitäten fehlt dieser Reflex fast vollständig. Ein Service-Account, den ein längst ausgeschiedener Entwickler für ein Projekt angelegt hat, bleibt aktiv. Der Token einer abgeschalteten Anwendung wird nie widerrufen. Der Testschlüssel, der es versehentlich in die Produktion geschafft hat, gilt weiter.

Diese verwaisten Zugänge sind für Angreifer besonders attraktiv. Sie sind oft mit weitreichenden Rechten ausgestattet, weil Least Privilege bei technischen Konten seltener durchgesetzt wird als bei Menschen. Sie werden kaum überwacht, denn niemand erwartet an ihnen verdächtiges Verhalten. Und sie umgehen viele Schutzmechanismen, die auf menschliche Nutzer ausgelegt sind. Multi-Faktor-Authentifizierung greift bei einem statischen API-Schlüssel nicht. Ein gestohlenes Token verhält sich technisch wie ein legitimes Token.

Kompromittierte Zugangsdaten und schlecht verwaltete Geheimnisse gehören zu den wiederkehrenden Angriffsvektoren. Oft betroffen sind Schlüssel und Tokens, die im Code, in einem Repository oder in einer Log-Datei liegen: jenseits des menschlichen Passworts. Wer nur die menschliche Seite absichert, verteidigt den kleineren Teil der Angriffsfläche.

Vier Schritte, um Identity-Sprawl in den Griff zu bekommen

Der Weg aus dem Wildwuchs führt über einen strukturierten Umgang mit dem Bestand. Ein weiteres Sicherheitsprodukt allein löst das nicht. Vier Schritte bilden ein belastbares Programm.

Erstens, Discovery und Inventur. Bevor irgendetwas abgesichert wird, braucht es einen Überblick. Welche Service-Accounts, Schlüssel, Tokens und Bots existieren, in welchen Systemen, mit welchen Rechten. Cloud-Plattformen, CI/CD-Pipelines, Secrets-Manager und SaaS-Integrationen sind die typischen Fundorte. Eine erste manuelle Sichtung ist besser als das Warten auf das perfekte Werkzeug.

Zweitens, Ownership zuweisen. Jede Maschinen-Identität braucht einen menschlichen Verantwortlichen. Ein Konto ohne Besitzer ist ein Konto, das niemand deaktivieren wird, weil sich niemand zuständig fühlt. Ownership macht aus einem anonymen Token eine nachvollziehbare Entscheidung, die geprüft und widerrufen werden kann.

Drittens, Least Privilege und Rotation. Technische Konten erhalten oft mehr Rechte als nötig, weil das schneller geht. Jede Identität sollte nur die Berechtigungen tragen, die ihre Aufgabe verlangt. Statische, unbefristete Geheimnisse gehören durch kurzlebige, automatisch rotierende Zugangsdaten ersetzt. Ein Schlüssel, der alle paar Stunden neu ausgestellt wird, ist ein deutlich kleineres Ziel.

Viertens, Lifecycle und Deprovisioning. Maschinen-Identitäten brauchen denselben Lebenszyklus wie menschliche. Wird eine Anwendung abgeschaltet, ein Projekt beendet oder eine Integration entfernt, muss der zugehörige Zugang automatisch mitverschwinden. Ein regelmäßiger Abgleich deckt Konten auf, die seit Monaten keine Aktivität mehr zeigen. Solche Karteileichen sind die ersten Kandidaten für den Entzug.

KI-Agenten multiplizieren denselben Lifecycle-Fehler

Die nächste Welle kommt aus der eigenen Innovationsabteilung. Autonome KI-Agenten, die Aufgaben eigenständig ausführen, brauchen Zugriff auf Systeme, Daten und andere Dienste. Jeder dieser Agenten ist eine neue Maschinen-Identität, oft mit weitreichenden Rechten, damit er flexibel arbeiten kann. Anders als ein starres Skript trifft ein Agent Entscheidungen zur Laufzeit. Sein Verhalten ist schwerer vorherzusagen und damit schwerer zu überwachen.

Wer Identity-Sprawl heute nicht in den Griff bekommt, importiert das Problem mit jeder KI-Initiative in verschärfter Form. Ein Agent mit übergroßen Rechten, den niemand einem Besitzer zugeordnet hat, ist genau die Art von Zugang, die in zwei Jahren als verwaist auffällt. Die Disziplin, die heute für Service-Accounts gilt, ist die Voraussetzung dafür, KI-Agenten überhaupt sicher einzusetzen.

Der erste Schritt in den nächsten 90 Tagen

Der Einstieg ist unspektakulär und gerade deshalb wirksam. Eine Inventur der nicht-menschlichen Identitäten in den kritischsten Umgebungen, beginnend bei der Cloud-Plattform und den zentralen Pipelines. Jede gefundene Identität bekommt drei Angaben: Zweck, Besitzer und letzte Aktivität. Alles ohne klaren Zweck oder ohne Aktivität in den vergangenen Monaten kommt auf eine Prüfliste. Aus dieser Liste folgt die erste Aufräumaktion und daraus wiederum eine Regel für die Zukunft. Kein neuer technischer Zugang entsteht ohne benannten Besitzer und ohne definierte Ablaufbedingung. Die Zahl der Maschinen-Identitäten wird weiter steigen. Ob sie kontrolliert oder unkontrolliert wächst, entscheidet sich an dieser Disziplin.

Häufig gestellte Fragen

Bildquelle: KI-generiert (Juli 2026)