Die meisten Sicherheitsvorfälle beginnen nicht mit Malware. Sie beginnen mit einem Benutzerkonto, das zu viele Rechte hat. Denn Angreifer müssen sich heute oft gar nicht mehr aufwendig Zugang verschaffen. Häufig reicht es aus, vorhandene Berechtigungen auszunutzen.
Jede Berechtigung ist eine Sicherheitsentscheidung
Jeder Zugriff erlaubt Einsicht in Daten und Änderungen an Systemen. Das Problem: In vielen Unternehmen kann niemand zuverlässig beantworten, welche effektiven Rechte ein Benutzer tatsächlich besitzt und welche Möglichkeiten daraus entstehen.
Mit steigender Anzahl von Non-Human Identities wächst die Unsichtbarkeit. Studien gehen inzwischen davon aus, dass Unternehmen heute deutlich mehr technische Identitäten als menschliche Benutzer verwalten. Service-Accounts, APIs, oder Automatisierungen entstehen oft dezentral im laufenden Betrieb. Viele davon besitzen weitreichende Berechtigungen, ohne dass Verantwortlichkeiten oder tatsächliche Nutzung sauber nachvollziehbar sind.
Berechtigungswildwuchs entsteht schleichend
Die wenigsten Unternehmen vergeben absichtlich zu viele Rechte. Berechtigungen wachsen über Jahre hinweg durch Projektgruppen, temporäre Ausnahmen, Abteilungswechsel, neue Anwendungen und komplexe Gruppenverschachtelungen.
Ein typisches Muster: Ein Projekt endet, die Rechte bleiben bestehen. Ein Mitarbeitender wechselt die Abteilung, alte Berechtigungen bleiben aktiv. Neue Zugriffe kommen hinzu, alte werden nicht entfernt. Über Zeit entsteht eine wachsende Lücke zwischen dokumentierter Rolle und tatsächlichem Zugriff. Genau diese Unsichtbarkeit wird zum Problem, bei Audits ebenso wie im Sicherheitsvorfall.
KI-Agenten schaffen neue blinde Flecken
Die Entwicklung verschärft sich aktuell zusätzlich durch Automatisierung und KI-basierte Systeme. KI-Agenten greifen eigenständig auf Anwendungen, Daten oder Schnittstellen zu und agieren technisch zunehmend wie digitale Mitarbeitende. Organisatorisch werden sie jedoch häufig noch wie klassische Service-Accounts behandelt.
Durch unklare Berechtigungsumfänge, fehlende Verantwortlichkeiten, dauerhaft aktive Zugriffe und mangelnde Kontrolle entwickeln sich diese technischen Identitäten aktuell zu einem der größten blinden Flecken von Sicherheitsarchitekturen.
Rollenmodelle vs. Realität
Identity & Access Management (IAM) steuert, welche Zugriffsrechte Benutzer, technische Konten und Systeme erhalten. Grundlage dafür sind Rollenmodelle: Mitarbeitende erhalten Berechtigungen idealerweise nicht individuell, sondern über klar definierte Rollen, die sich an Aufgaben und Verantwortlichkeiten orientieren.
In der Praxis entsteht hier jedoch häufig ein organisatorischer Bruch. Die IT denkt in Gruppen und Systemrechten. Fachbereiche dagegen in Aufgaben, Prozessen und Verantwortlichkeiten. Werden beide Perspektiven nicht zusammengeführt, entstehen Rollenmodelle, die zwar technisch korrekt aussehen, operativ aber nicht funktionieren.
Die Folge: Ausnahmeregelungen und praktische Workarounds am zentralen IAM vorbei. Langfristig entsteht damit genau das, was definierte Rollenstrukturen eigentlich verhindern sollten: Kontrollverlust.
IAM klein anfangen und große Security-Wirkung erzielen
Ein sinnvoller IAM-Einstieg beginnt selten mit einer vollständigen Neuorganisation aller Berechtigungen. Deutlich praktikabler ist es, zunächst besonders kritische Bereiche zu priorisieren: administrative Konten, sensible Datenzugriffe oder zentrale Geschäftsanwendungen. In klar abgegrenzten Bereichen lassen sich Rollenmodelle übersichtlich strukturieren und Risiken damit unmittelbar reduzieren. Gleichzeitig entstehen erste Proof-of-Concepts, wertvolle Learnings und im besten Fall belastbare Standards, die sich später kontrolliert auf weitere Systeme und Prozesse übertragen lassen.
Least Privilege bedeutet nicht möglichst wenig Rechte
Damit Identitäten nicht nur verwaltet, sondern abgesichert werden können, müssen Berechtigungen nicht nur strukturiert werden, sondern auch kontrollierbar bleiben und regelmäßig überprüft werden. Das Konzept von Least Priviledge bedeutet dabei nicht, Benutzer einzuschränken. Mitarbeitende sollen arbeitsfähig bleiben. Ziel ist vielmehr, dass Benutzer exakt die Berechtigungen erhalten, die sie für ihre Aufgabe tatsächlich benötigen, ohne durch unnötige Rechte ungewollt zum Sicherheitsrisiko zu werden. Das setzt jedoch klare Strukturen, definierte Verantwortlichkeiten und regelmäßige Reviews und Rezertifizierungen voraus.
- Welche Rechte werden tatsächlich noch benötigt?
- Welche Konten besitzen unnötige Administratorrechte?
- Welche technischen Konten werden nicht mehr genutzt?
Genau hier greifen die Konzepte von IAM, IGA und PAM ineinander.
- IAM (Identity & Access Management) verwaltet Identitäten und Zugriffe.
- IGA (Identity Governance & Administration) definiert Governance und Kontrollmechanismen.
- PAM (Privileged Access Management) schützt privilegierte Zugriffe.
Die Konzepte dahinter wirken oft abstrakt. In der Praxis müssen sie jedoch in konkrete organisatorische und technische Entscheidungen übersetzt werden. Der Markt bietet dafür eine Vielzahl an Lösungen. Die eigentliche Herausforderung für mittelständische Unternehmen ist jedoch: Wie findet man einen pragmatischen Einstieg, der operativ und wirtschaftlich sinnvoll funktioniert?
Mehr zu Identity Management in der Praxis im nächsten Beitrag: >>MVP statt großer Transformation: Identity Management praxisrealistisch aufbauen<<