Sicherheit
Nicht-menschliche Identitäten wie Firewall-Regeln steuern

Nicht-menschliche Identitäten sind die neuen Firewall-Regeln: Zugriff, der unter Termindruck erteilt wird, nie geprüft wird und still anwächst, bis ein Audit durchfällt. Eine nicht-menschliche Identität (NHI) ist jeder Akteur, der keine Person ist, ein Service-Account, ein API-Schlüssel, eine OAuth-App, ein CI-Token und jetzt ein KI-Agent. Sie übertreffen Menschen längst zahlenmäßig deutlich. Vezas Bericht „State of Identity & Access 2026“ fand heraus, dass Maschinenidentitäten Menschen im Verhältnis 17 zu 1 übertreffen, und dass nur 0,01 % der nicht-menschlichen Identitäten 80 % aller Cloud-Berechtigungen kontrollieren. KI-Agenten gießen gleich Öl in ein Feuer, das schon brannte.
Die gute Nachricht für jeden, der einen regulierten Firewall-Bestand gefahren hat: Sie kennen genau dieses Versagen bereits, und Sie besitzen das Heilmittel schon. Ungesteuerte Regeln, die niemand rezertifiziert und niemand außer Betrieb nimmt, sind der Grund, warum ein Regelwerk verrottet. Dieselbe Lebenszyklus-Disziplin, die einen Firewall-Bestand audit-fähig hält, Inventar, Eigentümerschaft, Rezertifizierung, Außerbetriebnahme, Least Privilege, Änderungssteuerung, ist es, die Maschinenidentitäten steuert. Das Vokabular ist neu. Die Kontrolle nicht.
Sie verwalten bereits Tausende Identitäten, die niemand prüft
Noch bevor ein einziger KI-Agent eintrifft, ertrinkt der durchschnittliche Bestand bereits in Maschinenidentitäten, und die meisten sind ungesteuert. Die Umfrage der Cloud Security Alliance zu nicht-menschlichen Identitäten und KI-Sicherheit 2026 fand heraus, dass sich nur 15 % der Organisationen zutrauen, einen NHI-basierten Angriff zu verhindern, und mehr als 16 % die Erstellung KI-bezogener Identitäten überhaupt nicht erfassen. Sie können nicht rezertifizieren, was nie inventarisiert wurde.
Der Wildwuchs sieht aus wie ein vernachlässigtes Regelwerk. Veza fand heraus, dass ruhende Konten bereits 38 % aller Konten ausmachen, und zählte 824.000 verwaiste Identitäten, aktive Berechtigungen ohne menschlichen Eigentümer im HR-System. Jede einzelne ist die Maschinenidentitäts-Version einer Firewall-Regel, deren Antragsteller vor drei Jahren das Unternehmen verlassen hat: lässt noch Verkehr durch, niemand will sie entfernen, ein offener Befund, der nur darauf wartet, dass der Auditor ihn bemerkt.
Das ist Firewall-Regel-Wildwuchs, exakt
Gehen Sie den Lebenszyklus einer schlechten Firewall-Regel durch, und die Parallele schreibt sich von selbst. Eine Regel kommt schnell rein, um ein Projekt zu entsperren. Sie ist breiter als nötig, weil eng länger dauert und das Änderungsfenster sich schließt. Der Antragsteller zieht weiter. Niemand ist sicher, ob sie noch gebraucht wird, also entfernt sie niemand. Wiederholen Sie das ein Jahrzehnt lang, und Sie haben ein Regelwerk, das kein Mensch versteht, voller Permit-Any-Regeln, die niemand verantworten will. Das Heilmittel für diesen Bestand haben wir im Leitfaden zur Firewall-Regel-Rezertifizierung und in der Disziplin, Regeln außer Betrieb zu nehmen beschrieben.
Lesen Sie nun denselben Absatz mit „Identität“ statt „Regel“. Ein Agent oder Service-Account bekommt schnell eine breite Rolle, um ein Projekt zu entsperren. Die Zugangsdaten sind langlebig, weil Rotieren Mühe macht. Der Entwickler, der sie erstellt hat, wechselt das Team. Niemand ist sicher, was davon abhängt, also entzieht sie niemand. So enden 0,01 % der Identitäten damit, 80 % der Berechtigungen zu halten, und deshalb fördern ein Regelwerk-Audit und ein Identitäts-Audit dieselben drei Befunde zutage: zu breite Rechte, kein Eigentümer, kein Prüftermin.
KI-Agenten machen es schlimmer, und schneller
Eine Firewall-Regel ist statisch, bis ein Mensch sie ändert. Ein KI-Agent ist es nicht. Er fordert Tools zur Laufzeit an, startet Sub-Agenten und verkettet Aktionen über Systeme, die einander nie vertrauen sollten, was bedeutet, dass der Zugriffsgraph nun zwischen Ihren Prüfzyklen von selbst wächst. Die Zugangsdaten-Exposition ist bereits messbar: GitGuardians „State of Secrets Sprawl 2026“ fand heraus, dass auf öffentliches GitHub geleakte KI-Dienst-Secrets 1,27 Millionen erreichten, ein Plus von 81 % in einem Jahr, und dass 24.008 Secrets allein in Konfigurationsdateien des Model Context Protocol auftauchten, davon 2.117 noch gültig. Der Klebecode, der Agenten an Tools anbindet, ist der neue Ort, an dem Schlüssel leaken und nie rotiert werden.
Ein Agent fällt zudem auf eine Weise offen aus, wie es eine Regel nie tut. Ein gekaperter Agent braucht keinen Privilege-Escalation-Exploit; er nutzt einfach die stehende Autorität, die Sie ihm bereits gegeben haben, das Confused-Deputy-Muster, das wir in KI-Agent-Autorisierung, die Kontrolle gegen Prompt Injection behandelt haben. Die Identität zu steuern ist der Weg, diesen Schadensradius zu begrenzen, bevor die Injection überhaupt landet. Die vollständige Aufzählung steht im KI-Agenten-Bedrohungsmodell.
Wenden Sie den Firewall-Regel-Lebenszyklus auf Maschinenidentitäten an
Jede Stufe, die Sie schon auf Regeln fahren, bildet sich eins zu eins auf Identitäten ab. Fahren Sie sie auf Ihren NHIs, und der Wildwuchs hört auf, sich aufzutürmen.
| Firewall-Regel-Lebenszyklus | Lebenszyklus nicht-menschlicher Identität | Was es verhindert |
|---|---|---|
| Regel-Inventar | Identitäts-Inventar: jeder Service-Account, jedes Token, jede OAuth-App und jeder Agent, mit dem, was er erreichen kann | Schatten-Zugriff, von dem niemand wusste |
| Regel-Eigentümer | Benannter menschlicher Eigentümer pro Identität, bei Erstellung erfasst | Das 824.000-Waisen-Problem |
| Rezertifizierung | Periodische Prüfung: wird diese Identität noch gebraucht, ist sie noch richtig gescopt | Ruhende Konten bei 38 % des Bestands |
| Außerbetriebnahme | Entziehen und entfernen bei Projektende oder Personalwechsel | Aktive Berechtigungen ohne Zweck |
| Least Privilege | Auf die Aufgabe begrenzen, kurzlebige Zugangsdaten, keine breiten kopierten Rollen | 0,01 %, die 80 % der Berechtigungen halten |
| Änderungssteuerung | Rechtevergaben werden protokolliert, geprüft, sind umkehrbar | „Ein Service-Account war es“ ohne Datensatz |
Der Punkt ist nicht, ein KI-Identitäts-Governance-Programm von Grund auf zu erfinden. Es ist, das zu erweitern, das Ihr Firewall-Bestand bereits fährt, derselbe Instinkt hinter der Optimierung eines aufgeblähten Regelwerks und der Zero-Trust-Änderungssteuerung, die regulierte Bestände bereits betreiben.
Was der Auditor fragen wird
Unter NIS2, DORA und ISO 27001 ist Zugriffssteuerung nicht durch „dem Modell wurde gesagt, was es darf“ erfüllt, ebenso wenig wie „dem Operator wurde gesagt, vorsichtig zu sein“ einen Befund zu einer Out-of-Scope-Firewall-Änderung schließt. Diese Rahmenwerke stellen Zugriffssteuerungsfragen, die für einen nicht-menschlichen Akteur genauso gelten wie für eine Person.
- NIS2 Artikel 21 verlangt Zugriffssteuerungs- und Asset-Management-Maßnahmen. Eine ungetrackte Population von Agenten- und Service-Account-Identitäten ist eine ungesteuerte Anlageklasse und eine Zugriffssteuerungslücke, dasselbe Beweis-Terrain wie bei NIS2-Firewall-Nachweisen.
- DORA fordert IKT-Risikomanagement mit Identitäts- und Zugriffssteuerung über jede Komponente, die den Betrieb einer Finanzeinheit beeinflussen kann, autonome Agenten eingeschlossen. Die Abbildung spiegelt die DORA-Firewall-Compliance.
- ISO 27001 Anhang A 5.16 und 8.2 decken Identitäts-Lebenszyklus und privilegierte Zugriffsrechte ab, ohne Ausnahme für nicht-menschliche Identitäten. Der Rezertifizierungsnachweis sieht aus wie die ISO-27001-Firewall-Audit-Checkliste, angewandt auf Konten und Agenten.
Externe Leitlinien laufen auf denselben Punkt zu. Die Non-Human-Identity-Arbeit der Cloud Security Alliance und CISAs Zero Trust Maturity Model behandeln Maschinen- und Workload-Identität beide als erstklassige Steuerungsebene, nicht als nachträglichen Gedanken.
Eine Governance-Checkliste vor Ihrem nächsten Agenten-Start
Jeder dieser Punkte sollte eine schriftliche Antwort im selben Risikoregister haben wie Ihre Firewall-Regeln.
- Inventar. Können Sie jede nicht-menschliche Identität auflisten, Agenten eingeschlossen, und was jede erreichen kann? Wenn nicht, ist das Befund eins.
- Eigentümerschaft. Hat jede Identität einen benannten menschlichen Eigentümer, bei Erstellung erfasst, oder erzeugen Sie bereits Waisen?
- Rezertifizierung. Gibt es einen Prüfzyklus, der „noch gebraucht, noch richtig gescopt“ für Maschinenidentitäten fragt, so wie Sie Regeln rezertifizieren?
- Außerbetriebnahme. Wird die Identität bei Projektende oder Mitarbeiteraustritt entzogen, oder schließt sie sich den ruhenden 38 % an?
- Least Privilege und Zugangsdaten-Lebensdauer. Sind Rechte auf die Aufgabe begrenzt mit kurzlebigen Zugangsdaten, oder breite Rollen mit langlebigen Schlüsseln?
- Audit. Können Sie rekonstruieren, welche Identität was getan hat, unter wessen Autorität, auf welche Eingabe?
Warum das wichtig ist
Die agentische Welle wird als brandneue Sicherheitskategorie verkauft, und Teile davon sind es wirklich. Aber die tragende Kontrolle ist eine, die Ihre Disziplin bereits kodiert: Zugriff wird einem benannten Eigentümer erteilt, auf einen Bedarf begrenzt, in einem Zyklus geprüft und entfernt, wenn der Bedarf endet. Firewall-Bestände, die diese Disziplin übersprangen, endeten mit Regelwerken, die niemand im Audit verteidigen konnte. Identitäts-Bestände, die sie jetzt überspringen, werden mit 824.000 Waisen enden, die von selbst handeln können. Behandeln Sie jede nicht-menschliche Identität, jeden Agenten eingeschlossen, als privilegierte Rechtevergabe mit einem Lebenszyklus, und das Audit wird zum Nachweis, den Sie bereits haben, statt zum Befund auf der Titelseite des Reports.
Bringen Sie Agenten oder Maschinenidentitäten in einen regulierten Bestand? Der kostenlose NIS2-Readiness-Check deckt genau das ab: wo Ihr nicht-menschlicher Zugriff inventarisiert, verantwortet und rezertifiziert ist, wo nicht und was ein Auditor verlangen wird.
Über den Autor
Nick Falshaw ist Principal Security Architect mit über 17 Jahren Erfahrung in Enterprise-Firewall- und Netzwerksicherheit bei Tier-1-Großkunden, KRITIS-regulierten Betreibern und EU-Finanzdienstleistern. Er ist Autor der FwChange-Methodik nach Analyse von mehr als 280 Firewall-Migrationen.

