Ein ausgeschiedenes Teammitglied mit noch aktivem VPN-Zugang, ein Service-Account mit globalen Admin-Rechten, ein externer Dienstleister im falschen Entra-ID-Tenant: Solche Fälle entstehen selten durch einen einzelnen technischen Fehler. Meist fehlt ein durchgängiges Modell für Identitäten, Berechtigungen und Verantwortlichkeiten. Dieser Identity Access Management Leitfaden ordnet ein, worauf es dabei strategisch und technisch ankommt.
IAM ist kein einzelnes Produkt und auch kein reines Security-Projekt. Es ist die Steuerungsschicht zwischen Menschen, Maschinen, Anwendungen, Daten und Geschäftsprozessen. Wer sie nur als Login-Problem behandelt, kann Multifaktor-Authentifizierung ausrollen und dennoch die Kontrolle über privilegierte Zugriffe, Schatten-Accounts oder verwaiste Berechtigungen verlieren.
Was Identity Access Management tatsächlich steuert
Identity Access Management umfasst den Lebenszyklus digitaler Identitäten und die Regeln, nach denen diese Identitäten auf Ressourcen zugreifen dürfen. Dazu gehören Beschäftigte, Externe, Kundenkonten, Administratoren, technische Konten, Workloads und zunehmend auch nicht-menschliche Identitäten wie APIs, Zertifikate und automatisierte Agents.
Die zentrale Frage lautet nicht: Wer darf sich anmelden? Sie lautet: Welche Identität darf unter welchen Bedingungen welche Aktion ausführen, wie wird diese Entscheidung nachvollzogen und wann wird sie wieder entzogen? Diese Perspektive verbindet Verzeichnisdienste, HR-Prozesse, Anwendungen, Cloud-Plattformen, Netzwerke und Security Operations.
Für die Organisation entstehen dabei drei Ziele, die miteinander im Spannungsverhältnis stehen. Mitarbeitende sollen arbeitsfähig sein, Sicherheitsvorgaben müssen durchsetzbar bleiben und die Administration darf nicht an jeder einzelnen Berechtigungsänderung ersticken. Gute IAM-Architektur reduziert dieses Spannungsverhältnis, hebt es aber nicht vollständig auf. Gerade bei Spezialrollen, Notfallzugängen oder Legacy-Anwendungen bleibt begründete Ausnahmebehandlung notwendig.
IAM beginnt mit dem Identitätsmodell
Bevor Du Rollen definierst oder eine neue Plattform auswählst, solltest Du klären, welche Identitäten in Deiner Organisation existieren und welches System für welche Attribute führend ist. Für Beschäftigte ist dies häufig das HR-System, für Auftragnehmer ein Lieferanten- oder Vertragsprozess. Bei technischen Identitäten liegt die Verantwortung oft bei Anwendungs- oder Plattformteams. Genau dort entstehen Lücken, wenn Ownership nicht explizit geregelt ist.
Ein belastbares Identitätsmodell unterscheidet mindestens zwischen menschlichen und nicht-menschlichen Identitäten, Standard- und privilegierten Konten sowie internen und externen Nutzern. Diese Trennung ist keine Formalität. Ein Entwicklerkonto, das E-Mails liest und Code schreibt, sollte nicht identisch sein mit dem Konto, das Produktionssysteme administriert. Ebenso braucht ein CI/CD-Workflow andere Steuerungsmechanismen als ein Mitarbeitendenkonto.
Wichtig ist auch die Eindeutigkeit: Eine Person sollte nicht über mehrere kaum zuordenbare Konten in verschiedenen Verzeichnissen und SaaS-Diensten auftreten. Technisch lässt sich Identitätsföderation einsetzen, organisatorisch bleibt jedoch die Pflicht, Namensräume, Stammdaten und Korrelation sauber zu führen. Sonst wird aus Single Sign-on lediglich ein bequemerer Weg in ein unübersichtliches Berechtigungsgeflecht.
Joiner, Mover, Leaver als operative Kernprozesse
Der Eintritt, Rollenwechsel und Austritt von Personen sind die zuverlässigsten Härtetests für IAM. Beim Eintritt geht es um rechtzeitige, aber minimale Bereitstellung. Beim Rollenwechsel müssen bisherige Rechte überprüft werden, statt nur neue zu addieren. Beim Austritt müssen Sessions, Tokens, Gruppenmitgliedschaften, Remote-Zugänge und delegierte Berechtigungen berücksichtigt werden.
In vielen Unternehmen funktioniert die Deaktivierung des zentralen Benutzerkontos, während lokale Konten in Fachanwendungen, Cloud-Subskriptionen oder Administrationsoberflächen bestehen bleiben. Daher sollte der Leaver-Prozess nicht auf eine einzelne Sperraktion reduziert werden. Er braucht eine vollständige Sicht auf angebundene Systeme und klare Fristen, insbesondere für privilegierte Zugänge.
Authentifizierung: Stark, kontextbezogen und betreibbar
Multifaktor-Authentifizierung ist heute eine grundlegende Kontrollmaßnahme, aber ihre Qualität hängt von der konkreten Umsetzung ab. Phishing-resistente Verfahren mit kryptografisch gebundenen Authentikatoren bieten typischerweise mehr Schutz als einmalige Codes, die Nutzer auf einer gefälschten Seite eingeben können. Für administrative Zugänge und besonders schützenswerte Anwendungen sollte dieses Sicherheitsniveau der Maßstab sein.
Das bedeutet nicht, jede Anwendung sofort auf denselben Mechanismus umzustellen. Legacy-Systeme, gemeinsam genutzte Arbeitsplätze oder Betriebsumgebungen ohne permanente Netzverbindung können andere Übergangslösungen verlangen. Entscheidend ist, dass diese Ausnahmen sichtbar bleiben, risikobasiert bewertet und nicht zur dauerhaften Parallelarchitektur werden.
Kontextsignale wie Gerätezustand, Standort, Netzrisiko, Zeitpunkt oder Anomalien können Zugriffsentscheidungen ergänzen. Sie ersetzen jedoch keine saubere Berechtigungspolitik. Ein vertrauenswürdiges Gerät macht übermäßige Rechte nicht weniger problematisch. Conditional Access ist deshalb eine zusätzliche Kontrollschicht, kein Ersatz für Least Privilege.
Berechtigungen: Rollen helfen, wenn sie fachlich stimmen
Role-Based Access Control, kurz RBAC, bleibt für viele Unternehmensanwendungen das praktikabelste Modell. Rollen bündeln typische Aufgaben und machen Berechtigungen verständlicher als individuell gepflegte Einzelrechte. Der häufige Fehler liegt nicht im Modell selbst, sondern in Rollen, die zu grob, zu zahlreich oder ohne fachlichen Eigentümer definiert sind.
Eine Rolle wie „Vertrieb“ oder „IT-Admin“ ist selten präzise genug. Besser funktionieren Rollen, die an klaren Tätigkeiten, Verantwortungsbereichen und Systemgrenzen ausgerichtet sind. Je näher Berechtigungen an tatsächlichen Geschäftsaufgaben liegen, desto besser lassen sie sich überprüfen und genehmigen. Das erfordert Mitarbeit der Fachbereiche, nicht nur der IAM- oder Security-Teams.
Wo Regeln stärker aus Attributen, Mandanten, Datenklassifizierung oder Projektzugehörigkeit abgeleitet werden sollen, kann Attribute-Based Access Control sinnvoll sein. In hybriden Umgebungen entsteht in der Praxis oft eine Kombination: Rollen strukturieren Standardzugriffe, Attribute verfeinern Entscheidungen. Das erhöht Flexibilität, fordert aber reife Datenqualität und ein klares Governance-Modell.
Privilegierte Zugriffe verdienen eine eigene Architektur
Privilegierte Konten sind kein Sonderfall am Rand des IAM, sondern ein eigener Risikobereich. Wer Produktionsdatenbanken, Cloud-Organisationen, Verzeichnisdienste, Netzwerkkomponenten oder Security-Tools administriert, kann Kontrollen oft selbst verändern oder umgehen. Dauerhafte globale Rechte sind deshalb bequem, aber schwer zu rechtfertigen.
Ein belastbarer Ansatz trennt Standard- und Administrationsidentitäten, vergibt höhere Rechte zeitlich begrenzt und protokolliert privilegierte Aktionen nachvollziehbar. Just-in-time-Berechtigungen und kontrollierte Freigabeworkflows reduzieren die Angriffsfläche, sofern sie im Betrieb nicht so umständlich sind, dass Teams auf inoffizielle Wege ausweichen.
Notfallkonten bleiben notwendig, etwa bei Störungen des zentralen Identity Providers. Gerade deshalb brauchen sie besonders strikte Regeln: wenige berechtigte Personen, gesicherte Zugangsdaten, dokumentierte Nutzung und regelmäßige Tests. Ein ungetesteter Break-Glass-Prozess ist keine Resilienzmaßnahme, sondern eine Annahme.
Der unterschätzte Bereich: Maschinenidentitäten
Während menschliche Zugriffe meist durch HR-Prozesse angestoßen werden, entstehen technische Identitäten häufig direkt in Projekten. Service-Accounts, API-Keys, Secrets, Zertifikate und Workload-Identitäten werden angelegt, kopiert und in Pipelines hinterlegt. Ihr Lebenszyklus ist oft schlechter dokumentiert als der von Benutzerkonten, obwohl sie weitreichende Rechte besitzen können.
Hier reichen jährliche Access Reviews nicht aus. Teams brauchen Ownership, Ablaufdaten, automatisierte Rotation und eine nachvollziehbare Zuordnung zwischen Workload, Geheimnis und Berechtigung. Wo die Plattform es ermöglicht, sind kurzlebige Tokens und föderierte Workload-Identitäten statischen Zugangsschlüsseln vorzuziehen. Das verschiebt Komplexität in die Plattform- und Entwicklungsprozesse, senkt aber das Risiko langfristig gültiger Geheimnisse.
Governance: Entscheidungen müssen prüfbar bleiben
IAM-Governance wird häufig mit Rezertifizierung gleichgesetzt. Regelmäßige Reviews sind sinnvoll, doch sie werden wirkungslos, wenn Führungskräfte lange Listen ohne Kontext bestätigen sollen. Eine brauchbare Prüfung zeigt, welche Rechte kritisch sind, wofür sie benötigt werden, wer sie beantragt hat und ob Nutzung oder Rollenwechsel Anlass zur Neubewertung geben.
Du brauchst außerdem eindeutige Verantwortlichkeiten. Die Security-Funktion definiert Leitplanken und kontrolliert Risiken. Die IT betreibt Integrationen und Plattformen. Fachliche Eigentümer verantworten, ob ein Zugriff für eine Aufgabe erforderlich ist. Interne Revision und Datenschutz können zusätzliche Anforderungen einbringen. Wenn diese Rollen nicht geklärt sind, wird IAM schnell zum Ticketsystem ohne echte Entscheidungskompetenz.
Kennzahlen sollten nicht nur die Zahl angebundener Anwendungen feiern. Aussagekräftiger sind etwa die Zeit bis zur Entziehung von Zugängen nach einem Austritt, der Anteil privilegierter Rechte mit Ablaufdatum, verwaiste Konten, nicht verantwortete technische Identitäten oder die Quote automatisierter Provisionierung. Solche Kennzahlen machen sichtbar, ob Kontrolle tatsächlich besser wird.
Identity Access Management Leitfaden für die Umsetzung
Ein sinnvoller Einstieg ist kein Big-Bang-Programm, sondern eine Priorisierung nach Risiko und Abhängigkeit. Beginne mit zentralen Identitätsquellen, administrativen Zugängen, Remote Access und Anwendungen mit schützenswerten Daten. Parallel solltest Du klären, welche Prozesse heute manuell, welche Systeme nicht integriert und welche Ausnahmen nicht dokumentiert sind.
Danach lohnt sich eine Zielarchitektur, die nicht nur Produkte, sondern Integrationsprinzipien beschreibt: führende Datenquellen, Authentifizierungswege, Provisionierungsstandards, Rollenmodell, Protokollierung, Privileged Access und Umgang mit Maschinenidentitäten. Sie muss zur Cloud-Strategie, zur Anwendungslandschaft und zum Betriebsmodell passen. Ein stark zentralisiertes Modell kann bei stark autonomen Produktteams an Grenzen stoßen, während zu viel Dezentralität Governance und Incident Response erschwert.
Die beste nächste Maßnahme ist oft erstaunlich unglamourös: Sorge dafür, dass jede kritische Identität einen Eigentümer, jedes privilegierte Recht ein Ablaufdatum und jeder Austrittsprozess einen nachweisbaren Kontrollpunkt hat. Von dort aus lässt sich IAM schrittweise zu einer Steuerungsfähigkeit entwickeln, die Security, Betrieb und Arbeitsfähigkeit gleichermaßen ernst nimmt.
