Die meisten Unternehmen haben SSO, MFA und ein Identity-Governance-Werkzeug im Einsatz. Dennoch steigt das Identitätsrisiko weiter - statt zu sinken. Dieser Artikel beleuchtet die häufigsten Stolperfallen in der Identity Governance, die wir heute sehen - über Menschen, Prozesse und Technologien hinweg - und zeigt, welche praktischen Schritte schlanke IT-Teams unternehmen können, um sie zu beheben.

Stolperfallen in der Identity Governance heute: Die wichtigsten Fakten im Überblick

  • Mittelgroße Unternehmen arbeiten typischerweise mit 40-100+ SaaS-Anwendungen, aber nur ein Bruchteil davon ist über SCIM oder native Konnektoren automatisiert. Der Rest basiert auf Tickets, Tabellenkalkulationen und informellem Erfahrungswissen.
  • Gestohlene oder kompromittierte Zugangsdaten gehören weiterhin zu den wichtigsten Einstiegspunkten bei Sicherheitsvorfällen, und identitätsbasierte Angriffe machen inzwischen grob ein Drittel der Einbrüche aus.
  • Nicht-menschliche Identitäten (Dienstkonten, API-Schlüssel, Bots, Workloads, KI-Agenten) übertreffen die Zahl menschlicher Benutzer in den meisten Umgebungen bereits - oft im Verhältnis 20:1 oder mehr, in einigen Fällen deutlich über 80:1.
  • Untersuchungen realer Umgebungen zeigen, dass mehr als die Hälfte aller SaaS-Lizenzen ungenutzt sind - und ein großer Teil davon auf Personen entfällt, die die Rolle gewechselt oder das Unternehmen verlassen haben - klassische Symptome schwacher Offboarding-Prozesse und lückenhafter SaaS-Governance.
  • Die meisten Organisationen verlassen sich noch immer auf periodische Zugriffsüberprüfungen (z. B. vierteljährliche Rezertifizierungen) als primäre Kontrollmaßnahme, obwohl sich Zugriffsrisiken täglich verändern, wenn Menschen die Rolle wechseln, Projekte starten und neue SaaS-Werkzeuge dazukommen.

Stolperfalle 1: Identity Governance als einmaliges Projekt betrachten

Identity Governance vom Abhaken zur kontinuierlichen Risiko-Steuerung machen

Der erste und größte Fehler: Identity Governance als etwas zu behandeln, das man "einmal einführt", um einen Compliance-Rahmen zu erfüllen - und dann zur Tagesordnung übergeht.

Typisches Muster:

  • Ein Rollen-Mining-Projekt durchführen, einige Rollen und Gruppen definieren.
  • Eine IGA-Plattform aufsetzen und ein paar zentrale Systeme anbinden.
  • Vierteljährliche oder jährliche Zugriffsüberprüfungen durchführen, um Prüfanforderungen zu erfüllen.

Auf dem Papier werden damit viele Anforderungen erfüllt. In der Realität verändert sich Ihre Umgebung jedoch ständig:

  • Jeden Monat tauchen neue SaaS-Anwendungen auf.
  • Teams werden neu zugeschnitten, Rollen verändern sich.
  • Externe Mitarbeitende kommen und gehen.
  • KI-Werkzeuge und Automatisierung bringen völlig neue Klassen von Identitäten mit sich.

Das Identitätsrisiko ist dagegen kontinuierlich. Zugangsdaten sind ein bevorzugtes Ziel, weil Angreifer sich einfach als legitime Benutzer anmelden können. Vorfalldaten zeigen seit Jahren konsequent, dass der Missbrauch von Zugangsdaten und soziale Manipulation zusammen einen großen Teil der Sicherheitsvorfälle ausmachen.

Wenn Governance nicht im gleichen Tempo wie diese Veränderungen mitläuft, weicht das Bild, das Sie in Reviews zertifizieren, innerhalb weniger Wochen von der Realität ab.

Was das für Sicherheit, Compliance und Nutzen bringt

Die Folgen einer "projektbasierten" Governance sind gravierend:

  • Sicherheitslücken zwischen den Reviews - Rollenwechsel, einmalige Berechtigungsvergabe, temporäre Projektrechte und Notfall-Zugriffe auf Produktionssysteme häufen sich zwischen den Zertifizierungszyklen. Bis zur nächsten Überprüfung stempeln Sie im Ergebnis nur Monate an Ausnahmen ab.
  • Trügerisches Compliance-Gefühl - Prüfungen kontrollieren oft nur, dass Reviews stattgefunden haben - nicht, ob der Zugriff über die Zeit tatsächlich angemessen war. Sie können auf dem Papier "compliant" sein und dennoch in der Praxis unnötig hohes Risiko tragen.
  • Hoher Aufwand, geringe Wirkung - Fachverantwortliche stumpfen durch lange, repetitive Review-Kampagnen ab. Sie genehmigen Zugriffe im Block, weil ihnen der Kontext fehlt, und Ihr IT-Team verbringt Wochen damit, Bestätigungen hinterherzulaufen, die kaum etwas verändern.

Wie es besser geht:

  • Behandeln Sie Identity Governance als Identitätsrisiko-Management, nicht nur als Zugriffsrezertifizierung.
  • Kombinieren Sie periodische Reviews mit ereignisgesteuerten Kontrollen: Lösen Sie Überprüfungen aus, wenn risikoreiche Änderungen passieren (Rollenwechsel, Rechteausweitung, neuer Produktionszugriff) - nicht nur nach einem starren Kalender.
  • Messen Sie Ergebnisse statt Aktivitäten: weniger verwaiste Konten, weniger überprivilegierte Administratoren, schnelleres Offboarding, weniger manuelle Tickets.

Stolperfalle 2: Bei SCIM stehenbleiben - und den Großteil des SaaS-Stacks manuell lassen

Die Lücke zwischen SSO, SCIM und Realität sichtbar machen und schließen

Viele Teams glauben, sie hätten "Identitätsautomatisierung", weil:

  • SSO im Einsatz ist (z. B. Okta, Entra ID usw.).
  • Ein Teil der Anwendungen SCIM unterstützt und an HR-gesteuerte Bereitstellung angebunden ist.

Die Realität vor Ort:

  • Nur ein Bruchteil der Anwendungen im Stack unterstützt SCIM.
  • Selbst wenn SCIM verfügbar ist, steuert es meist nur grobgranulare Gruppen-Zuordnungen, nicht detaillierte Berechtigungen.
  • Fachbereichstools und die "Long Tail"-SaaS-Landschaft werden selten automatisiert. Sie leben außerhalb der zentralen Identitätsebene und werden von Marketing, Finanzen, Produktabteilungen oder einzelnen Teams verantwortet.

So entstehen zwei Welten:

  1. Die automatisierten 20 % - Eine Handvoll SCIM-fähiger Anwendungen, bei denen On- und Offboarding halbwegs gut funktionieren.
  2. Die manuellen 80 % - Alles andere. IT-Tickets, E-Mail-Anfragen und geteilte Administrationskonten.

Das ist das Abdeckungsproblem: Sie haben die einfachen Anwendungen automatisiert, nicht die wichtigen.

Auswirkungen auf Onboarding, Offboarding und SaaS-Governance

Wenn Automatisierung bei SCIM-Anwendungen endet, zeigen sich die Folgen überall:

  • Langsames, uneinheitliches Onboarding - Neue Mitarbeitende warten Tage auf vollständigen Zugriff, weil für die Hälfte ihrer Werkzeuge nach wie vor eine manuelle Kontoanlage und Rechtezuordnung nötig ist.
  • Offboarding nach dem Hoffnungsprinzip - Beim Austritt wird zwar das zentrale Verzeichnis- oder IdP-Konto geschlossen, aber Dutzende von SaaS-Anwendungen und internen Systemen bleiben unangetastet. Ehemalige Mitarbeitende behalten Zugriff auf Slack-Arbeitsbereiche, Git-Repositorys, gemeinsame Laufwerke, interne Wikis und mehr.
  • Identitätswildwuchs und Schatten-IT - Teams beschaffen eigene Werkzeuge, wenn die zentrale IT nicht Schritt hält. Diese Tools sind selten sauber an Ihr IdP oder Ihre IGA angebunden und schaffen neue Inseln unverwalteter Identitäten.
  • SaaS-Verschwendung - Lizenzen bleiben Ex-Mitarbeitenden und inaktiven Benutzern zugeordnet. Ohne automatisierte Rückgewinnung, die an den Identitätslebenszyklus gekoppelt ist, ziehen ungenutzte Plätze und Premium-Tarife das Budget leise nach unten.

Wie es besser geht:

  • Streben Sie vollständige Abdeckung an, nicht nur "SCIM-Abdeckung". Ihr Governance-Modell sollte SCIM- und Nicht-SCIM-Anwendungen, interne Systeme und Cloud-Plattformen umfassen.
  • Setzen Sie Verbindungstechnologien oder Orchestrierung ein, die auch dann mit Anwendungen arbeiten können, wenn keine APIs oder SCIM-Schnittstellen verfügbar sind.
  • Standardisieren Sie Joiner-Mover-Leaver-Workflows über Ihren gesamten Stack, damit On- und Offboarding deterministisch und nicht ticketgetrieben ablaufen.
  • Behandeln Sie SaaS-Governance als Teil der Identity Governance: Zugriffe steuern Lizenzzuweisung und Rücknahme - nicht umgekehrt.

Stolperfalle 3: Nicht-menschliche Identitäten (Dienstkonten, Bots und KI-Agenten) ignorieren

Maschinenidentitäten in Ihr Governance-Programm einbinden

Über Jahre konzentrierte sich Identity Governance fast ausschließlich auf Menschen. Diese Zeit ist vorbei.

Heute übertreffen nicht-menschliche Identitäten - Dienstkonten, API-Schlüssel, Workload-Identitäten, Zertifikate, RPA-Bots, CI/CD-Pipelines und KI-Agenten - in vielen Umgebungen die Zahl menschlicher Benutzer um ein Vielfaches.

Dennoch tun die meisten Organisationen Folgendes:

  • Sie führen diese Konten - wenn überhaupt - in improvisierten Tabellen.
  • Sie nutzen geteilte Dienstkonten über mehrere Anwendungen und Umgebungen hinweg.
  • Sie vergeben breite, statische Berechtigungen "weil sonst etwas kaputtgehen könnte".
  • Sie rotieren Geheimnisse manuell, unregelmäßig oder gar nicht.

Viele große Sicherheitsvorfälle betreffen mittlerweile kompromittierte Maschinenidentitäten oder Geheimnisse. Angreifer lieben sie, weil:

  • sie oft hohe oder nahezu unbegrenzte Rechte haben (Datenbank-Admin, Produktions-Cluster-Admin, Cloud-Root-Zugriff),
  • sie rund um die Uhr laufen und keinem menschlichen Nutzungsverhalten folgen, was Auffälligkeiten schwerer erkennbar macht,
  • sie in Standard-Zugriffsreviews selten berücksichtigt werden.

Produktions- und OT-Risiken durch unsichtbare Konten senken

Das Ignorieren nicht-menschlicher Identitäten hat direkte Folgen:

  • Unsichtbare Angriffsfläche - Was Sie nicht kennen, können Sie nicht schützen. Wenn Sie nicht wissen, wie viele Dienstkonten existieren, wem sie gehören und was sie dürfen, sind Sie faktisch blind.
  • Überprivilegierte Infrastruktur - Viele Dienstkonten erhalten "Gottmodus"-Zugriff auf Produktion, OT-Systeme und sensible Daten, einfach weil niemand das Risiko eines Ausfalls eingehen möchte.
  • Veraltete und verwaiste Geheimnisse - Token und Schlüssel ehemaliger Mitarbeitender, stillgelegter Anwendungen oder alter Pipelines bleiben aktiv, lange nachdem ihr Zweck entfallen ist.

Wie es besser geht:

  • Behandeln Sie Maschinenidentitäten als gleichberechtigte Objekte in Ihrer Identity-Governance-Strategie.
  • Erfassen Sie Dienstkonten, API-Schlüssel, Workload-Identitäten und Bots in einem Inventar. Weisen Sie jedem eine klare verantwortliche Person und einen geschäftlichen Zweck zu.
  • Wenden Sie das Minimalprinzip auch auf nicht-menschliche Identitäten an: Gehen Sie von den tatsächlich genutzten Berechtigungen aus und entfernen Sie alles Überflüssige.
  • Automatisieren Sie den Lebenszyklus: Anlage, Rotation, Entzug und Bestätigung von nicht-menschlichen Identitäten - genauso wie bei menschlichen Benutzern.
  • Führen Sie Maschinenidentitäten in derselben zentralen Ansicht wie Benutzerkonten, damit Prüfungen und Untersuchungen nicht drei Werkzeuge und fünf Teams durchqueren müssen.

Stolperfalle 4: Minimalprinzip auf Folien, nicht in der Produktion

Minimalprinzip von einem Grundsatz zu durchsetzbaren Richtlinien machen

Das "Minimalprinzip" (Least Privilege) ist eines der meistzitierten Sicherheitskonzepte - und eines der am wenigsten umgesetzten.

Typische Symptome:

  • Große "Sammelgruppen" (z. B. Engineering - Alle, Finanzen - Alle) mit Zugriff auf deutlich mehr Anwendungen und Daten als nötig.
  • Admin-Rechte, die "temporär" zur Fehlersuche vergeben und nie wieder entzogen werden.
  • Breite Produktionsrechte für ganze Teams statt enger, prüfbarer Rollen.
  • Verstöße gegen Funktionstrennung (Segregation of Duties, SoD), die als Ausnahme genehmigt und anschließend vergessen werden.

Mit der Zeit wachsen Berechtigungen nur in eine Richtung: nach oben. Mitarbeitende wechseln Positionen, Teams, übernehmen temporäre Aufgaben - ihre Berechtigungen werden aber selten reduziert. Das Ergebnis ist Identitätswildwuchs auf der Berechtigungsebene.

Wie adaptive Zugriffe und feingranulare Steuerung das Risiko verändern

Wenn das Minimalprinzip nicht durchgesetzt wird, passiert Folgendes:

  • Angriffe dringen schneller, tiefer vor - Wird ein einziges überprivilegiertes Konto kompromittiert, erhalten Angreifer rasch weitreichenden Zugriff auf Systeme.
  • Untersuchungen werden schwieriger - Wenn "alle" breite Rechte haben, ist kaum noch nachvollziehbar, wer zu einem bestimmten Zeitpunkt welchen Zugriff haben durfte.
  • Compliance-Schmerzen nehmen zu - SoD-Verstöße, überzogene Admin-Rechte und unklare Rollendefinitionen tauchen in Prüfungen immer wieder als Feststellungen auf.

Wie es besser geht:

  • Beginnen Sie mit höchstrisikobehafteten Systemen - Produktionsumgebungen, Finanzsysteme, Kundendatenbanken. Kartieren Sie konkrete Berechtigungen (Projekte, Repositorys, Kanäle, Rollen) und ordnen Sie sie klar definierten Zugriffsrichtlinien zu.
  • Gehen Sie über reine rollenbasierte Zugriffssteuerung hinaus und ergänzen Sie attribut- oder richtlinienbasierte Zugriffe, wo es sinnvoll ist: Umgebung (Produktion vs. Entwicklung), Standort, Vertrauensstufe des Geräts, Tageszeit oder Risikosignale.
  • Nutzen Sie adaptive Zugriffe für sensible Aktionen: zusätzliche Authentifizierung oder Just-in-Time-Erhöhung statt dauerhafter Admin-Rechte.
  • Werten Sie Nutzungsdaten kontinuierlich aus, um Zugriffe zurechtzustutzen. Wird eine Berechtigung seit Monaten nicht genutzt, ist sie ein Kandidat zur Entfernung.

Minimalprinzip ist keine einmalige Aufräumaktion, sondern eine laufende Rückkopplung zwischen Richtlinien, Telemetrie und Automatisierung.

Stolperfalle 5: Offboarding nach dem Hoffnungsprinzip und verwaiste Konten

Offboarding als deterministischen, automatisierten Ablauf gestalten

Stellen Sie Ihrem Team eine einfache Frage: "Wenn jemand das Unternehmen verlässt, sind wir zu 100 % sicher, dass wir wirklich jeden Zugriff entfernen, den diese Person je hatte?"

In den meisten Organisationen lautet die ehrliche Antwort: "Nein."

Typisches Offboarding sieht so aus:

  • HR schließt den Datensatz im Personalverwaltungssystem.
  • Die IT deaktiviert das zentrale Verzeichnis- oder IdP-Konto.
  • Jemand entfernt vielleicht noch ein paar offensichtliche Anwendungskonten.

Was oft übersehen wird:

  • Fachbereichs-SaaS, die von den Teams selbst verwaltet werden.
  • Externe Kollaborationsräume (Kunden, Partner, Lieferanten).
  • Privilegierte Zugriffe in Cloud-, OT- und Produktionssystemen.
  • Nicht-menschliche Identitäten, die von dieser Person angelegt oder genutzt wurden (persönliche Zugriffstoken, Automatisierungsskripte, API-Schlüssel).

Es ist keine Seltenheit, aktive Konten und Token ehemaliger Mitarbeitender zu finden, die das Unternehmen vor Monaten oder Jahren verlassen haben. Diese verwaisten Konten sind für Angreifer ein Ziel mit geringem Aufwand und potenziell hoher Wirkung.

Warum vollständige Entprovisionierung die günstigste Risikoreduzierung ist

Die Kosten unvollständigen Offboardings sind hoch:

  • Direktes Einbruchsrisiko - Ehemalige Mitarbeitende (oder jemand, der ihre Konten kompromittiert hat) können weiterhin Slack, GitHub, interne SaaS oder Cloud-Konsolen nutzen.
  • Compliance-Verstöße - Vorschriften erwarten, dass Sie nachweisen können, dass Zugriffe bei Austritt zeitnah entzogen werden. Verwaiste Konten untergraben diese Behauptung.
  • SaaS-Überausgaben - An Ex-Mitarbeitende gebundene Lizenzen verlängern sich unbemerkt weiter.

Wie es besser geht:

  • Machen Sie Offboarding zum stärksten und am stärksten automatisierten Teil Ihres Lebenszyklus. Wenn HR einen Austritt markiert, sollte dies:
    • die automatische Entprovisionierung über IdP, zentrale SaaS-Anwendungen und Long-Tail-Apps auslösen,
    • Token widerrufen, Dienstkonten deaktivieren, die mit dieser Identität verbunden sind, und Geheimnisse bei Bedarf rotieren.
  • Binden Sie bei Dienstleistern Zugriffe an Vertragsenddaten und verlangen Sie explizite Neugenehmigung bei Verlängerung.
  • Erstellen Sie für jeden Offboarding-Fall eine einheitliche Prüfspur: Was wurde wann und wo entfernt?

Wenn Sie im nächsten Quartal nur eine Sache anpacken können, ist durchgängiges Offboarding in der Regel die Maßnahme mit dem höchsten Verhältnis von Nutzen zu Aufwand.

Stolperfalle 6: Zersplitterte Werkzeuge und keine zentrale Sicht

Identitätsflüsse orchestrieren statt Werkzeuge von Hand zusammenzuflicken

Identität spannt sich heute über ein unübersichtliches Gemisch von Systemen:

  • HR- und ITSM-Werkzeuge, in denen Benutzer und Tickets geführt werden.
  • IdPs und SSO für Authentifizierung.
  • IGA- oder ältere IAM-Plattformen für bestimmte Systeme.
  • Cloud-IAM für IaaS/PaaS.
  • SaaS-Admin-Konsolen, VPNs, OT-Systeme und Eigenentwicklungen.

Die meisten Teams enden mit Skripten, Einzellösungen und manueller Arbeit, um all das zusammenzuhalten. Niemand kann einfache Fragen aus einem Guss beantworten wie:

  • "Wer hat im Moment Zugriff auf die Produktion?"
  • "Welche menschlichen und nicht-menschlichen Identitäten können auf dieses kritische System zugreifen?"
  • "Zeige mir jeden Ort, an dem dieser Benutzer Zugang hatte, und belege, dass beim Austritt alles entzogen wurde."

Diese Zersplitterung macht es nahezu unmöglich, einheitliche Richtlinien umzusetzen oder saubere, vertrauenswürdige Prüfungsnachweise zu erzeugen.

Wie "gut" aussieht: Einheitliche Sichten, Automatisierung und prüffähige Nachweise

Um aus dieser Falle herauszukommen, brauchen Sie nicht zwangsläufig eine weitere riesige Plattform - aber Sie brauchen Orchestrierung und Sichtbarkeit:

  • Eine zentrale Ansicht, die Identitäten (menschlich und nicht-menschlich), Berechtigungen und Aktivitäten über Ihre wichtigsten Systeme hinweg zeigt.
  • Identitätsorchestrierung, die HR-Ereignisse, Zugriffsanträge, Genehmigungen, Bereitstellung und Reviews zu End-to-End-Workflows verbindet - statt isolierter Einzelschritte in verschiedenen Werkzeugen.
  • Identitätsautomatisierung für wiederkehrende Muster: Joiner-Mover-Leaver-Flows, Erhöhung von Produktionszugriffen, Rückgewinnung von SaaS-Lizenzen und Sammlung von Nachweisen für Zugriffsreviews.
  • Unveränderliche Prüfspuren, die festhalten, wer was genehmigt hat, wann Zugriffe vergeben oder entzogen wurden und wie Richtlinien durchgesetzt wurden.

Diese Schicht macht aus Ihrem Flickenteppich von Systemen ein Identitätsgewebe statt eine Sammlung zufälliger Silos.

Wie es weitergeht: Konkrete nächste Schritte

Identity Governance lässt sich nicht dadurch lösen, dass man ein weiteres Werkzeug kauft und auf das Beste hofft. Sie lösen sie, indem Sie bewusst entscheiden, womit Sie anfangen.

Eine pragmatische Reihenfolge, die sich für schlanke IT-Teams bewährt, sieht so aus:

  1. Ihre Identitätslandschaft abbilden

    • Listen Sie Ihre 20-30 geschäftskritischsten Systeme auf (einschließlich SaaS, Cloud und OT, sofern relevant).
    • Erfassen Sie für jedes: Identitätsquelle, Bereitstellungsmodell (manuell, SCIM, individuell), wer Zugriffe genehmigt und wie Offboarding abläuft.

  2. Ihre Abdeckungslücke sichtbar machen

    • Markieren Sie, welche Systeme vollständig automatisiert, teilweise automatisiert oder manuell sind.
    • Heben Sie Systeme hervor, bei denen das Offboarding manuell oder unklar ist. Diese sind ideale Kandidaten für Sicherheitsvorfälle und Prüfungsfeststellungen.

  3. Mit ein oder zwei Workflows mit hoher Wirkung starten

    • Häufige Startpunkte: Onboarding neuer Mitarbeitender für Ihren Kernanwendungs-Satz; vollständiges Offboarding; Erhöhung von Produktionszugriffen.
    • Definieren Sie den Idealablauf (Auslöser, Genehmigungen, Provisionierung, Protokollierung) und automatisieren Sie ihn End-to-End, bevor Sie weitergehen.

  4. Nicht-menschliche Identitäten früh in den Scope nehmen

    • Erfassen Sie Dienstkonten und Token in Ihren kritischsten Umgebungen.
    • Weisen Sie Verantwortliche zu, kartieren Sie Berechtigungen und beginnen Sie dort mit Rotation oder Einschränkung, wo das Risiko offensichtlich hoch ist.

  5. Governance am Risiko ausrichten, nicht am Kalender

    • Behalten Sie periodische Reviews bei, ergänzen Sie aber ereignisgesteuerte Reviews bei Rollenwechseln und hochriskanten Berechtigungen.
    • Messen Sie den Erfolg an der Reduktion verwaister Konten, überprivilegierter Rollen und manueller Tickets - nicht nur an der Zahl "abgeschlossener Reviews".

  6. In Orchestrierung und Sichtbarkeit investieren, nicht nur in weitere Einzellösungen

    • Ob Sie einen bestehenden IGA-Stack erweitern oder eine moderne Governance-Plattform einführen: Priorisieren Sie vollständige Abdeckung (SCIM und Nicht-SCIM), feingranulare Steuerung und eine Bedienbarkeit, die Ihr kleines Team realistisch leisten kann.

Identity Governance wird niemals "fertig" sein. Aber mit dem richtigen Fokus und der passenden Automatisierung kann sie sich von einer ständigen Sorge zu einer leisen, verlässlichen Kontrollinstanz entwickeln, die mit Ihrem Geschäft skaliert.

Häufige Fragen zu Stolperfallen in der Identity Governance

Worin unterscheidet sich Identity Governance von Identity- und Zugriffsmanagement (IAM)?

Identity- und Zugriffsmanagement ist der übergeordnete Fachbereich, der Authentifizierung (Anmeldungen), Autorisierung und Kontenverwaltung umfasst. Identity Governance ist die Governance-Schicht darüber: Sie definiert und erzwingt, wer welchen Zugriff warum und wie lange haben sollte - und liefert die Nachweise, um dies zu belegen.

In der Praxis gilt:

  • IAM kümmert sich um die Mechanik des Zugriffs (SSO, MFA, Verzeichnisdienste, Basis-Provisionierung).
  • Identity Governance kümmert sich um Entscheidungen und Kontrolle (Richtlinien, Genehmigungen, Reviews, Prüfspuren und risikobasierte Kontrollen).

Beides ist nötig. SSO ohne Governance macht es lediglich einfacher, sich bei Dingen anzumelden, auf die man womöglich gar keinen Zugriff haben sollte.

Woran erkenne ich, dass Identitätswildwuchs in meinem Unternehmen ein Problem ist?

Warnsignale für Wildwuchs bei Identitäten und Zugriffsrechten sind:

  • Kein zentrales Inventar von Anwendungen, Administratoren oder Dienstkonten.
  • Unterschiedliche Antworten aus verschiedenen Teams auf die Frage "Wer ist für dieses System verantwortlich?"
  • Zugriffsanträge, die über E-Mail oder Chat laufen statt über einen strukturierten Workflow.
  • Schwierigkeiten, Prüfungsfragen wie "Wer hatte im letzten Quartal Zugriff auf dieses System?" zu beantworten.
  • Regelmäßige Überraschungen, wenn alte Konten ehemaliger Mitarbeitender oder längst abgereister Dienstleister entdeckt werden.

Wenn es länger als ein paar Minuten dauert, die Frage "Wer hat jetzt gerade Zugriff auf X?" belastbar zu beantworten, haben Sie bereits ein Problem mit Identitätswildwuchs.

Wo sollten wir anfangen, wenn wir uns keine komplette IGA-Rundumerneuerung leisten können?

Sie brauchen kein sechsmonatiges Programm, um Fortschritte zu erzielen. Starten Sie mit:

  1. Nur kritischen Systemen - Wählen Sie drei bis fünf: HR, IdP/SSO, Ihre wichtigsten Kollaborationswerkzeuge im SaaS-Bereich und Ihre zentrale Produktionsumgebung.
  2. Einem Lebenszyklusablauf - Oft vollständiges Offboarding, da hier Risiko und Nutzen am größten sind.
  3. Einfacher Automatisierung zuerst - Schon einfache Regeln wie "Wenn HR einen Mitarbeitenden als ausgeschieden markiert, SSO deaktivieren, diese fünf Kernanwendungen entprovisionieren und das Ergebnis protokollieren" können das Risiko drastisch senken.

Sobald Sie auf einem klar abgegrenzten Bereich nachweisbaren Nutzen gezeigt haben, ist es leichter, die Ausweitung der Abdeckung und Investitionen in tiefere Automatisierung zu begründen.

Wie sollten wir nicht-menschliche Identitäten in der Praxis handhaben?

Behandeln Sie nicht-menschliche Identitäten wie sehr mächtige, aber sehr langweilige Mitarbeitende:

  • Geben Sie ihnen einen Verantwortlichen - Eine Person oder ein Team, das für diese Identität und ihre Berechtigungen einsteht.
  • Definieren Sie Zweck und Umfang - Auf welches System greift sie zu? Wozu? Von wo? Mit welchen maximalen Rechten?
  • Automatisieren Sie den Lebenszyklus - Anlage, Rotation und Löschung müssen klaren Richtlinien folgen, nicht improvisierten Skripten.
  • Regelmäßig überprüfen - Beziehen Sie sie in Zugriffsreviews ein, insbesondere bei Produktions-, OT- und hochsensiblen Systemen.

Das Ziel ist einfach: Es darf keine anonyme, verwaiste oder überprivilegierte Maschinenidentität in Ihrer Umgebung geben.

Reicht mein SSO (Okta, Entra ID usw.) nicht für Identity Governance aus?

SSO und moderne IdPs sind essenziell, aber sie lösen ein anderes Problem.

Sie sind stark darin:

  • Authentifizierung zu zentralisieren und MFA zu erzwingen.
  • Anmeldeerlebnisse für Benutzer zu vereinfachen.
  • Einfache, gruppenbasierte Zugriffe für bestimmte Anwendungen abzubilden.

Typischerweise bieten sie nicht:

  • Vollständige Abdeckung über Nicht-SCIM-Anwendungen, Schatten-IT und interne Systeme hinweg.
  • Feingranulare Berechtigungen bis hinunter zu Kanälen, Repositorys, Projekten oder konkreten Datensätzen.
  • Durchgängige Joiner-Mover-Leaver-Workflows über alle Anwendungen und Identitätstypen.
  • Umfassende Zugriffsreviews, Richtliniendurchsetzung und prüfbereite Nachweise.

Betrachten Sie Ihren IdP als Haustür - und Identity Governance als die Regeln, wer welche Schlüssel zu welchen Räumen erhält, wie lange sie gültig sind und wie Sie das gegenüber Prüfern und Sicherheitsteams belegen.