Was ist IGA?
Zugriffsrechte, die Sinn ergeben.

01 / Die Grundlage

Was ist Identity Governance and Administration?

Identity Governance and Administration (IGA) ist das Zusammenspiel von Richtlinien, Entscheidungen mit klarer Verantwortlichkeit und operativen Prozessen, mit denen eine Organisation steuert, wer warum Zugriff auf ihre Systeme und Daten hat und wann dieser Zugriff geändert oder beendet werden muss. Governance legt Regeln und Verantwortlichkeiten fest. Administration setzt die Änderungen an Konten und Berechtigungen um. Zusammen verbinden sie geschäftliche Entscheidungen mit den Zugriffsrechten, die tatsächlich bestehen.

Eine Identität kann für Mitarbeitende, externe Mitarbeitende, Partner oder einen nicht-menschlichen Akteur wie eine Anwendung oder ein Servicekonto stehen. Zugriff kann bedeuten, einen Kundendatensatz zu öffnen, eine Zahlung freizugeben, einen Server zu administrieren oder einen freigegebenen Ordner einzusehen. IGA überführt diese Identitäten und Berechtigungen in einen Prozess, der sich verstehen, betreiben und überprüfen lässt.

Die zentralen Fragen sind praktischer Natur: Wer ist für dieses Konto verantwortlich, was kann es, welcher geschäftliche Bedarf rechtfertigt es, wer hat es autorisiert, und gilt diese Begründung noch? Eine brauchbare Antwort enthält Nachweise aus dem Zielsystem. Eine als „genehmigt“ markierte Anfrage belegt nicht, dass der Zugriff korrekt eingerichtet oder später entfernt wurde.

Die Identity-Governance-Übersicht von Microsoft beschreibt Identitätslebenszyklus, Zugriffslebenszyklus und privilegierten Zugriff als zusammenhängende Bereiche. Wo ein Produkt endet, ist von Anbieter zu Anbieter verschieden. Das Betriebsmodell in diesem Leitfaden ist ein anbieterneutraler Weg, den gesamten Prozess zu bewerten, einschließlich der Arbeit, für die Menschen verantwortlich sein müssen.

02 / So funktioniert es

Vom Geschäftsbedarf zum geprüften Zugriff

Identity Governance ist ein fortlaufender Zyklus. Eine Änderung im Beschäftigungsverhältnis, eine Projektzuordnung oder eine Anfrage gibt Anlass, Zugriffsrechte zu bewerten. Die Organisation trifft eine Entscheidung, setzt sie um, prüft das Ergebnis und überdenkt die Entscheidung, wenn sich die Umstände ändern.

1. 01

   Bedarf feststellen

   Bestimmen Sie die Person oder den Dienst, die Ressource, den Zweck und den benötigten Zeitraum.

2. 02

   Entscheiden

   Wenden Sie Richtlinien an, lösen Sie Konflikte und holen Sie, wo erforderlich, die Genehmigung einer verantwortlichen Person ein.

3. 03

   Umsetzen

   Legen Sie Konten und Berechtigungen in den betreffenden Systemen an, ändern oder entfernen Sie sie.

4. 04

   Verifizieren

   Vergleichen Sie das Zielsystem mit dem beabsichtigten Ergebnis und beheben Sie fehlgeschlagene Aktionen.

5. 05

   Neu bewerten

   Prüfen Sie den fortbestehenden Bedarf, reagieren Sie auf Änderungen und bewahren Sie die Entscheidungshistorie auf.

Ein eigenes konzeptionelles Diagramm des Governance-Zyklus. Jeder Schritt braucht eine verantwortliche Person und ein beobachtbares Ergebnis; dies ist kein Produkt-Screenshot.

Nicht jede Vergabe von Zugriffsrechten braucht einen eigenen Klick der Führungskraft. Eine dokumentierte Richtlinie kann risikoarme Basiszugriffsrechte automatisch zuweisen, wenn verlässliche Identitätsattribute genehmigte Bedingungen erfüllen. Sensible, außergewöhnliche oder konfliktbehaftete Zugriffsrechte können eine ausdrückliche Genehmigung erfordern. Beim Design kommt es darauf an, wirksame Kontrolle dort anzusetzen, wo das Risiko es rechtfertigt, und Routinezugriffe vorhersehbar zu machen.

Legen Sie für jeden Schritt fest, was passiert, wenn der normale Ablauf scheitert. Fehlende Führungskräfte, mehrdeutige Identitätszuordnungen, nicht verfügbare Anwendungen und abgelehnte Änderungen sollten sichtbare Ausnahmen mit klarer Verantwortung erzeugen. Ein Prozess, der eine unvollständige Aktion offenlegt, nützt mehr als ein Dashboard, das eine gesendete Anfrage als abgeschlossenes Ergebnis behandelt.

03 / Die Grenzen kennen

IGA vs. IAM, SSO, MFA und PAM

Diese Funktionen greifen ineinander, und Anbieter bündeln teils mehrere davon in einer Plattform. Am klarsten wird der Vergleich über die Frage, die jede Funktion beantwortet. Wer eine dieser Funktionen hat, hat damit nicht automatisch auch die anderen abgedeckt.

Nehmen wir als Beispiel jemanden, der früher Finanzsysteme administriert hat und heute im Einkauf arbeitet. MFA kann diese Person korrekt authentifizieren, und SSO kann sie problemlos anmelden. Keines von beidem erklärt, warum sie noch Administrationsrechte für die Gehaltsabrechnung hat. IGA sollte den Rollenwechsel mit einer Entscheidung über die alte Berechtigung verbinden; die Anwendung oder das Zugriffskontrollsystem muss die daraus folgende Änderung durchsetzen. Das Beispiel dient der Veranschaulichung und beschreibt keinen gemeldeten Kundenvorfall.

IGA unterstützt außerdem eine Zero-Trust-Architektur durch bessere Identitäts-, Berechtigungs- und Richtlinieninformationen. IGA ist aber nicht die ganze Architektur. NIST SP 800-207 beschreibt ein umfassenderes, ressourcenorientiertes Modell, in dem Netzwerkstandort oder Eigentumsverhältnisse allein kein Vertrauen begründen. Zugriffsentscheidungen zur Laufzeit, Gerätezustand und Durchsetzung bleiben neben der Governance wichtig.

04 / Das Wesentliche im Betrieb

Was ein wirksames IGA-Programm braucht

Beginnen Sie mit den angestrebten Ergebnissen und ordnen Sie diese dann der Software zu. Die folgenden Funktionen bilden einen praxisnahen Bewertungsrahmen. Damit ist nicht gesagt, dass jedes Produkt jede Funktion umsetzt oder jede Organisation dieselbe Umsetzungstiefe benötigt.

Identitätsinventar und Korrelation

Machen Sie Konten aus wichtigen Systemen sichtbar und verknüpfen Sie sie mit einer bekannten Person oder, bei nicht-menschlichen Konten, mit einer verantwortlichen Person. Nutzen Sie stabile Kennungen und explizite Zuordnungsregeln. Eine E-Mail-Adresse kann sich ändern, und zwei Personen können denselben Namen tragen. Mehrdeutige Zuordnungen erfordern eine Klärung statt einer automatischen Zuweisung der Verantwortung.

Berechtigungskatalog und Anfragen

Beschreiben Sie Zugriffsrechte in einer Sprache, die die antragstellende Person versteht. Nennen Sie Ressource, Berechtigungsstufe, verantwortliche Person, Voraussetzungen und voraussichtliche Dauer. „Finanzberichte, nur lesen“ hilft einer Führungskraft mehr als ein unerklärter Gruppencode aus dem Verzeichnisdienst. Hinterlegen Sie die technische Zuordnung unter der fachlichen Beschreibung, damit die Umsetzung präzise bleibt.

Richtlinien und Genehmigung

Legen Sie fest, welche Zugriffsrechte per Regel zugewiesen werden können, welche eine Genehmigung brauchen und welche Kombinationen verboten sind. Geben Sie genehmigenden Personen relevanten Kontext: Zweck, Dauer, Sensibilität und bestehende Zugriffsrechte. Definieren Sie Vertretungen, Eskalation und das Vorgehen, wenn die genehmigende Person zugleich die antragstellende ist.

Provisionierung und Abgleich

Provisionierung ändert Konten und Berechtigungen. Beim Abgleich (Reconciliation) wird der tatsächlich vorgefundene Zustand im Zielsystem mit dem Zustand verglichen, den die Organisation erwartet. Beides ist wichtig, wenn die Administration Änderungen auch direkt in Anwendungen vornehmen kann. Die von Evolveum veröffentlichte midPoint-Dokumentation zur Synchronisation beschreibt Mechanismen, mit denen Änderungen auf Seiten der Ressource erkannt und verarbeitet werden; Konfiguration und Reaktion müssen im Detail zu jeder Integration passen.

Zugriffsüberprüfungen und Nachweise

Fragen Sie die verantwortlichen Prüfenden, ob Zugriffsrechte weiterhin angemessen sind, geben Sie ihnen genug Kontext für die Entscheidung und setzen Sie die Änderungen um, die ihre Entscheidungen erfordern. Speichern Sie eine zusammenhängende Historie, die Identität, Anfrage, Genehmigung, Richtlinie, Umsetzung, Ausnahme und Überprüfung verknüpft. Berichte sollten sowohl erfolgreiche Aktionen als auch offene Aufgaben ausweisen.

05 / Zugriff folgt Veränderung

Eintritte, Wechsel und Austritte

Der Identitätslebenszyklus beginnt mit einer verlässlichen Quelle für organisatorische Fakten. HR liefert in der Regel Beschäftigungsstatus, Eintrittsdatum, Führungskraft und Abteilung. Daten zu externen Mitarbeitenden können aus dem Einkauf oder von einem Sponsor stammen. Legen Sie fest, welche Quelle für welche Angabe maßgeblich ist und wie widersprüchliche Aktualisierungen aufgelöst werden, bevor Sie darauf basierende Entscheidungen automatisieren.

Für Stellenwechsel braucht es ein eigenes Konzept. Wenn jede Versetzung nur Berechtigungen hinzufügt, häufen sich Zugriffsrechte an, auch wenn jede einzelne Vergabe zu ihrer Zeit vernünftig war. Legen Sie fest, welche Rechte zur alten Stelle gehören, welche zu einem laufenden Projekt und welche eine neue Entscheidung erfordern. Eine Versetzung mit Stichtag kann dann die passenden Änderungen auslösen, ohne davon auszugehen, dass alle alten Zugriffsrechte ungültig sind.

Offboarding erfordert eine Überprüfung in jedem einzelnen Zielsystem. Die Microsoft-Anleitung zum Entzug von Zugriffsrechten erklärt, dass eine Anwendung eine von ihr ausgestellte Sitzung unabhängig vom Identity Provider steuern kann. Das Deaktivieren eines zentralen Kontos beweist daher für sich allein nicht, dass jede bestehende Sitzung beendet ist. Lokale Konten, API-Zugangsdaten, Geräte und physischer Zugang können eigene Maßnahmen erfordern.

Legen Sie Zielzeiten für den Abschluss nach Risiko und Systemklasse fest und messen Sie die Zeit vom maßgeblichen Ereignis bis zum verifizierten Abschluss. Setzen Sie keine pauschale Frist für alle Austritte an. Für den detaillierten Ablauf nutzen Sie unseren Leitfaden zum Offboarding von Mitarbeitenden.

06 / Unter der Oberfläche

Wie IGA an Ihre Anwendungslandschaft angebunden wird

Eine typische Architektur besteht aus vier Teilen: maßgeblichen Identitätsquellen, einem Governance-Dienst, Integrationsmechanismen und den Systemen, die Zugriffsrechte durchsetzen. Der Governance-Dienst führt Identitätsdatensätze, Richtlinien und Entscheidungen zusammen. Konnektoren oder kontrollierte manuelle Aufgaben übertragen diese Entscheidungen an Verzeichnisdienste, SaaS-Anwendungen, Datenbanken und Infrastruktur.

Dokumentieren Sie die Integrationstiefe für jedes System. Konten zu lesen ist etwas anderes, als sie anzulegen; Gruppenmitgliedschaften zu ändern ist etwas anderes, als feingranulare Geschäftsrollen zu verwalten; ein Konto zu deaktivieren ist etwas anderes, als eine Sitzung zu widerrufen. Eine Liste von Konnektornamen ersetzt keinen Test, der jede Operation einzeln prüft.

SCIM, spezifiziert in RFC 7644, stellt ein HTTP-basiertes Protokoll für die domänenübergreifende Verwaltung von Identitätsressourcen bereit. Es kann helfen, Integrationen zu standardisieren, doch unterstützte Ressourcentypen und Operationen müssen im jeweiligen Dienst trotzdem geprüft werden. Dass ein Konnektor existiert, bedeutet nicht, dass die gesamten Anforderungen der Organisation an Genehmigung, Berechtigungen und Entzug unterstützt werden.

Für ein System ohne geeignete API kann eine gesteuerte manuelle Aufgabe eine vertretbare Übergangskontrolle sein. Benennen Sie die ausführende Person, beschreiben Sie die genaue Aktion, setzen Sie eine Frist und verlangen Sie einen Nachweis aus dem Zielsystem. Weisen Sie dieses System als manuell gesteuert aus, nicht als automatisch abgedeckt. Priorisieren Sie Automatisierung dort, wo Volumen, Sensibilität oder Verzögerungen den Aufwand rechtfertigen.

Schützen Sie auch die IGA-Plattform selbst. Ihre Konnektoren können administrative Berechtigungen besitzen. Begrenzen Sie die Rechte von Servicekonten, schützen Sie Secrets, beschränken Sie administrative Rollen, protokollieren Sie Änderungen und testen Sie die Wiederherstellung. Eine Governance-Plattform braucht dieselbe Disziplin bei Verantwortung und Überprüfung, die sie an anderer Stelle einführt.

07 / Bessere Zugriffsentscheidungen

Rollen, Attribute, minimale Rechtevergabe und Funktionstrennung

Eine Berechtigung ist ein konkretes Zugriffsrecht, etwa die Mitgliedschaft in einer Gruppe oder die Befugnis, Rechnungen freizugeben. Eine Rolle bündelt zusammengehörige Zugriffsrechte zu etwas, das die Organisation zuweisen und pflegen kann. Attributbasierte Regeln nutzen Fakten wie Abteilung, Standort oder Beschäftigungsstatus, um Voraussetzungen oder Zugriffsrechte zu bestimmen. Diese Ansätze lassen sich kombinieren.

Halten Sie das Modell verständlich. Eine kleine Basis mit klarer Verantwortung und ausdrücklichen Ausnahmen ist als Einstieg oft die bessere Empfehlung als eine große Rollenhierarchie, die niemand erklären kann. Jede Rolle braucht einen Zweck, eine verantwortliche Person, ein Berechtigungsinventar und einen Überprüfungsprozess. Attributregeln brauchen verlässliche Quelldaten und Tests für Änderungen, fehlende Werte und Ausnahmen.

Die Dokumentation zu Rollen und Richtlinien von Evolveum unterscheidet Rollen, die Zugriffsrechte oder Verantwortlichkeiten gewähren, von Richtlinien, die regeln, wie Zugriff vergeben, überprüft oder genehmigt wird. Diese Unterscheidung hilft beim Entwurf der Verantwortlichkeiten. Eine Geschäftsrolle und die daran geknüpften Bedingungen sind zusammenhängende Entscheidungen, keine austauschbaren Objekte.

Minimale Rechtevergabe (Least Privilege) bedeutet, Zugriffsrechte auf das zu beschränken, was die Arbeit erfordert. Wenden Sie das Prinzip auf Berechtigungsstufe, Ressourcenumfang und Dauer an. Lesezugriff kann ausreichen, wo bisher einfach der Schreibzugriff einer Kollegin oder eines Kollegen kopiert wurde. Ein befristetes Projekt kann ein Ablaufdatum statt einer dauerhaften Mitgliedschaft rechtfertigen.

Funktionstrennung (Separation of Duties, SoD) betrifft Kombinationen von Verantwortlichkeiten, die nicht ohne geeignete Kontrolle ausgeübt werden sollten. Eine Organisation kann zum Beispiel verbieten, dass dieselbe Person einen Lieferanten anlegt und auch die Zahlung an diesen Lieferanten freigibt. Diese Regel dient der Veranschaulichung. Der tatsächliche Konflikt hängt von Prozess, Berechtigungen und Risikobewertung ab. Wo eine Ausnahme nötig ist, dokumentieren Sie Begründung, genehmigende Person, kompensierende Kontrolle und Enddatum.

08 / Zugriffsrechte angemessen halten

Zugriffsüberprüfungen mit echten Entscheidungen

Eine Zugriffsüberprüfung fragt, ob eine Identität eine Berechtigung behalten soll. Die prüfende Person braucht mehr als einen Benutzernamen und ein Kontrollkästchen. Stellen Sie die geschäftliche Bedeutung, die Herkunft der Vergabe, die verantwortliche Person, Sensibilität, Begründung, Datumsangaben und, soweit verfügbar, relevante Nutzungsnachweise bereit. Fehlende Nutzungsdaten müssen als fehlend erkennbar bleiben; sie dürfen nicht zu einem erfundenen Wert für „zuletzt genutzt“ werden.

Die Übersicht zu Zugriffsüberprüfungen von Microsoft beschreibt die wiederkehrende Bewertung von Mitgliedschaften sowie von Anwendungs- oder Rollenzugriffen. Für den Betrieb folgt daraus, sowohl den Entscheidungsprozess als auch die anschließenden Schritte festzulegen. Eine Entscheidung zum Entzug ist erst abgeschlossen, wenn die entsprechende Entfernung umgesetzt und geprüft wurde.

Wählen Sie Umfang und Häufigkeit von Überprüfungen nach geltenden Pflichten, Sensibilität und Änderungsdynamik. Trennen Sie hochriskante administrative Zugriffe von einer risikoarmen allgemeinen Kollaborationsgruppe, wenn diese unterschiedliche Entscheidungen erfordern. Legen Sie fest, was passiert, wenn eine prüfende Person nicht reagiert, und werten Sie Schweigen nicht kommentarlos als Genehmigung.

Messen Sie offene Entscheidungen, überfällige Entfernungen und Berechtigungen, die nach einem Entzug wieder auftauchen. Diese Werte zeigen, ob der Prozess Zugriffsrechte in der Praxis verändert. Eine Kampagne, in der jede Zeile geprüft wurde, kann dennoch ein erhebliches Risiko hinterlassen, wenn fehlgeschlagene Entfernungen offen bleiben.

Erfahren Sie, wie Zugriffsprüfungen in easyIGA die Person, ihre Berechtigung und die verfügbaren Nachweise zusammenführen.

09 / Die Menschen hinter der Richtlinie

Wer sollte Identity Governance verantworten?

IGA ist gemeinsame Arbeit mit klar zugewiesener Verantwortung. Die IT betreibt die Integrationen, kann aber nicht jeden geschäftlichen Bedarf beurteilen. Führungskräfte kennen die Aufgaben einer Person; Anwendungsverantwortliche kennen die Rechte innerhalb eines Systems; die IT-Sicherheit legt die Kontrollanforderungen fest; HR oder der Vertrags-Sponsor liefert die Lebenszyklusdaten.

Weisen Sie jeder operativen Warteschlange eine tatsächlich verantwortliche Person und eine Vertretung zu. „Die Fachabteilung“ ist kein Eskalationsziel. Legen Sie fest, wer eine Ausnahme genehmigen und wer sie anfechten darf. Überprüfen Sie auch die Rechte der Governance-Administration selbst in einem Prozess, der unkontrollierte Selbstgenehmigung ausschließt.

10 / Über Mitarbeitende hinaus

Externe, Servicekonten und nicht-menschliche Identitäten

Externe Mitarbeitende brauchen einen Sponsor, einen Zweck und ein voraussichtliches Enddatum. Verlässt der Sponsor die Organisation, braucht die Zugriffsbeziehung trotzdem eine verantwortliche Person. Beziehen Sie Verlängerungen, Personalwechsel beim Dienstleister und Projektabschlüsse in den Lebenszyklus ein, statt darauf zu warten, dass eine periodische Bereinigung sie aufdeckt.

Erfassen Sie für Servicekonten, Anwendungen und automatisierte Agenten die fachlich und die technisch verantwortliche Person, den Zweck der Workload, die erreichten Systeme, den Berechtigungsumfang und die Bedingungen für die Stilllegung. Wenn eine Person ausscheidet, sollte das eine Neuzuweisung oder Überprüfung der nicht-menschlichen Identitäten auslösen, für die sie verantwortlich ist, statt diese Identitäten stillschweigend unbeaufsichtigt zu lassen.

Zugangsdaten und Identitäten hängen zusammen, sind aber unterschiedliche Objekte. Ein Token oder Schlüssel autorisiert den Zugriff für eine Identität oder Workload; wird die Mitgliedschaft einer Person in einem Passwort-Tresor entfernt, macht das ein Secret, das sie zuvor abgerufen hat, nicht ungültig. Verbinden Sie Identitätsentscheidungen, wo nötig, mit der Rotation und dem Widerruf von Zugangsdaten.

Bewerten Sie bei der Produktauswahl ausdrücklich, wie weit nicht-menschliche Identitäten abgedeckt sind. Fragen Sie, ob das System diese Identitäten erkennen, Verantwortlichkeiten abbilden, Berechtigungen überprüfen und unterstützte Änderungen anstoßen kann. Nehmen Sie nicht an, dass eine Governance-Funktion für die Belegschaft automatisch jede Cloud-Workload oder jeden KI-Agenten verwaltet. Dokumentieren Sie die Grenze und binden Sie bei Bedarf spezialisierte Werkzeuge an.

11 / Nachweise und Pflichten

Wie IGA Compliance unterstützt, ohne sie zu versprechen

IGA kann einer Organisation helfen, zugriffsbezogene Kontrollen umzusetzen und nachzuweisen. Eine Plattform ist kein Compliance-Zertifikat. Anwendbarkeit, Angemessenheit der Kontrollen und rechtliche Auslegung hängen von der Organisation und den jeweiligen Vorschriften ab.

• NIS2: Art. 21 Abs. 2 Buchst. i nennt die Sicherheit des Personals, Konzepte für die Zugriffskontrolle und das Management von Anlagen unter den Risikomanagementmaßnahmen im Bereich der Cybersicherheit. Die nationale Umsetzung und der Anwendungsbereich müssen geprüft werden. Lesen Sie dazu die Richtlinie und unseren ausführlichen NIS2-Leitfaden.
• Datenschutz-Grundverordnung (DSGVO): Art. 5 Abs. 2, Art. 24 und Art. 32 behandeln die Rechenschaftspflicht, die Pflichten des Verantwortlichen und geeignete Sicherheitsmaßnahmen. Die Governance von Zugriffsrechten kann diese Pflichten unterstützen; die DSGVO schreibt kein bestimmtes IGA-Produkt vor. Den vollständigen Kontext finden Sie in der Verordnung.
• Kontroll-Frameworks: NIST SP 800-53 enthält in der Kontrollfamilie Zugriffskontrolle (Access Control) die Kontoverwaltung, die Funktionstrennung und die minimale Rechtevergabe. Welche Kontrollen eine Organisation übernimmt und wie sie diese umsetzt, erfordert einen definierten Umfang und eine Bewertung.

Für Anforderungen im Finanzsektor lesen Sie weiter in unserem Leitfaden zu DORA und Zugangskontrolle. Halten Sie rechtliche Anforderungen getrennt von empfohlenen Umsetzungsmustern und Produktfunktionen.

Ein brauchbares Nachweispaket verknüpft das maßgebliche Identitätsereignis, die Zugriffsentscheidung, die geltende Richtlinie, die Aktion im Zielsystem, die Verifizierung und gegebenenfalls die Ausnahme. Bewahren Sie Einträge nach einem angemessenen Aufbewahrungsplan und mit Zugriffsbeschränkungen auf. Nachweise brauchen genug Kontext, um die Kontrolle zu erklären, ohne unnötige personenbezogene Daten zu erfassen.

12 / Ein praxisnaher Startplan

Wie Sie IGA in überschaubaren Etappen einführen

Die folgende Abfolge ist ein empfohlener Planungsansatz, kein garantierter Lieferzeitplan. Umfang, Integrationsqualität und organisatorische Verantwortung bestimmen den Aufwand. Geben Sie jeder Etappe ein Abnahmekriterium, damit Fortschritt ein nachgewiesenes Ergebnis bedeutet.

1. Ein Ziel festlegen

   Wählen Sie ein wesentliches Problem, etwa nicht verifiziertes Offboarding, langsame Genehmigungen von Zugriffsrechten oder eine Überprüfung, die keine Nachweise liefern kann. Benennen Sie den verantwortlichen Sponsor, die betroffene Personengruppe und die Zielsysteme. Dokumentieren Sie die aktuellen Fehlerbilder, bevor Sie Werkzeuge auswählen.

2. Verlässliche Identitätsdaten schaffen

   Bestimmen Sie maßgebliche Felder, stabile Kennungen und Verantwortliche für Ausnahmen. Testen Sie Namensänderungen, Versetzungen, Wiedereinstellungen, mehrere Verträge und fehlende Führungskräfte. Korrigieren Sie die Daten, die der erste Anwendungsfall braucht, statt alle Arbeit aufzuschieben, bis jeder Datensatz perfekt ist.

3. Zugriffsrechte und Verantwortung erfassen

   Inventarisieren Sie Konten und Berechtigungen in den ausgewählten Systemen. Benennen Sie Anwendungsverantwortliche, beschreiben Sie sensible Berechtigungen und ermitteln Sie direkte administrative Zugriffswege. Dokumentieren Sie, welche Vorgänge sich automatisieren lassen und welche kontrollierte manuelle Arbeit brauchen.

4. Den gesamten Ablauf aufbauen und testen

   Konfigurieren Sie eine kleine Auswahl an Richtlinien, Anfragen, Genehmigungen und Aktionen in Zielsystemen. Testen Sie erfolgreiche Änderungen, Ablehnung, Ablauf, nicht verfügbare Systeme und falsche Identitätszuordnungen. Prüfen Sie den Zustand im Zielsystem und die Nachweise, die eine prüfende Person erhält.

5. Pilot mit echten Nutzenden

   Lassen Sie Führungskräfte, prüfende Personen und Support-Mitarbeitende repräsentative Aufgaben erledigen. Beobachten Sie, wo Katalognamen und Genehmigungskontext verwirren. Beheben Sie diese Probleme, dokumentieren Sie die Wiederherstellung und legen Sie die Übergabe in den Regelbetrieb fest.

6. Anhand gemessener Lücken erweitern

   Ergänzen Sie Systeme und Personengruppen nach Risiko und nachgewiesenem Nutzen. Überprüfen Sie wiederkehrende Ausnahmen, überfällige Entfernungen und manuellen Aufwand. Planen Sie Verantwortung, Katalogqualität und Kontrolltests fest im Betriebsbudget ein.

Der erste Produktivumfang sollte klein genug sein, um ihn zu verstehen, und wichtig genug, um etwas zu bewirken. Er sollte trotzdem den vollständigen Kontrollpfad durchlaufen. Ein reines Konnektor-Pilotprojekt belegt die Konnektivität; es belegt nicht, dass fachliche Genehmigungen, Fehlerbehandlung und Nachweise zusammen funktionieren.

13 / Mit Nachweisen bewerten

Wie Sie eine IGA-Lösung auswählen

Bringen Sie repräsentative Szenarien aus Ihrer Systemlandschaft in die Evaluierung ein. Bitten Sie den Anbieter, zwischen allgemein verfügbaren Funktionen, Preview-Funktionen, Konfigurationsaufwand und geplanter Entwicklung zu unterscheiden. Eine Funktionsbezeichnung sagt weniger aus als ein beobachtetes Ergebnis in einer unterstützten Konfiguration.

Bewerten Sie die Kosten über die gesamte Betriebsdauer der Lösung. Berücksichtigen Sie Lizenzen, Infrastruktur, Integration, Datenbereinigung, das Design von Geschäftsrollen, Schulung, Support, Upgrades und das Team, das Ausnahmen verantwortet. Software auf Basis von open source kann manche Lizenzbeschränkungen verringern, erfordert aber dennoch Investitionen in Implementierung und Betrieb.

Erstellen Sie einen Business Case auf Basis Ihrer eigenen Messungen. Schätzen Sie das Volumen wiederkehrender Anfragen und den Bearbeitungsaufwand, und bewerten Sie Risiko- und Nachweislücken getrennt davon. Machen Sie aus einer nicht belegten Senkung der Wahrscheinlichkeit einer Sicherheitsverletzung keine präzise Einsparsumme. Ein glaubwürdiger Vorschlag legt seine Annahmen offen und gibt der kaufenden Organisation die Möglichkeit, sie zu prüfen.

14 / Ihr nächster Arbeitstermin

Eine Checkliste für den IGA-Start

Gehen Sie diese Fragen mit HR, IT, IT-Sicherheit und den Anwendungsverantwortlichen durch. Halten Sie für jeden offenen Punkt eine verantwortliche Person und den nächsten Schritt fest. Die Checkliste ist ein Gesprächseinstieg, keine Reifegradbewertung und keine Compliance-Prüfung.

• Wir wissen, welche Quelle für den Status von Mitarbeitenden und externen Mitarbeitenden maßgeblich ist.
• Wir können Konten in wichtigen Systemen einer Identität oder einer verantwortlichen Person zuordnen.
• Anwendungsverantwortliche können sensible Berechtigungen in fachlicher Sprache erklären.
• Für Eintritte, Wechsel und Austritte sind Stichtage und Zuständigkeiten festgelegt.
• Wir unterscheiden genehmigte, versuchte, abgeschlossene und verifizierte Änderungen an Zugriffsrechten.
• Befristete Zugriffsrechte und Ausnahmen haben Ablaufdaten und Verantwortliche für die Nachverfolgung.
• Prüfende Personen erhalten genug Kontext für fundierte Entscheidungen.
• Entscheidungen zum Entzug werden bis zur tatsächlichen Entfernung nachverfolgt.
• Nicht-menschliche Identitäten und gemeinsam genutzte Zugangsdaten sind Teil des Umfangs.
• Wir können die Nachweise für einen vollständigen Zugriffslebenszyklus reproduzieren.

Wenn mehrere Antworten unklar sind, widerstehen Sie der Versuchung, mit einem sehr großen Rollenmodell zu beginnen. Wählen Sie eine wichtige Personengruppe und Anwendung, klären Sie die Verantwortung und weisen Sie den Lebenszyklus nach. So entsteht eine brauchbare Grundlage für die Entscheidung, wo Software, Prozessänderungen oder bessere Quelldaten die größte Wirkung haben.

15 / Fragen vor der Kaufentscheidung

Häufige Fragen zu IGA

16 / Wo easyIGA ansetzt

Eine fachliche Ebene über midPoint

easyIGA ist als Governance-Ebene für die Fachbereiche positioniert und setzt auf midPoint auf. midPoint ist open source. Die Produktübersicht gliedert die Nutzung in die Schritte Beantragen, Genehmigen, Provisionieren, Überprüfen und Nachweisen. So arbeiten die Fachbereiche mit Zugriffsrechten, während midPoint die zugrunde liegenden Identitätsvorgänge übernimmt.

Die Nachweisübersicht erklärt, wie easyIGA Anfragen und erfasste Genehmigungsstufen protokolliert, an anderer Stelle vergebene Berechtigungen erkennt und fehlende historische Informationen kennzeichnet. Prüfungen auf Richtlinienkonflikte zum Entscheidungszeitpunkt sind verfügbar; das Erstellen und Simulieren von Regeln innerhalb von easyIGA ist geplant. Ein Pilotprojekt verbindet diese Funktionen mit Ihren eigenen Anwendungen, einschließlich des Umgangs mit fehlgeschlagenen Änderungen und unvollständigen Einträgen.

Unser Team hat mindestens 14 midPoint-Einführungen umgesetzt. Diese Erfahrung prägt, wie wir easyIGA auf alltägliche Zugriffsaufgaben ausrichten. Beginnen Sie mit einem schwierigen Zugriffsszenario aus Ihrer Organisation und verfolgen Sie in einer Live-Demo Entscheidung, Ergebnis und Nachweise.

Quellenverzeichnis

Quellen und redaktionelle Angaben

Produktumfang und redaktionelle Formulierungen wurden am 12. Oktober 2026 aktualisiert. Die ursprünglichen Prüfdaten der Quellen sind unten weiterhin angegeben.

Primärquellen geprüft am 8. Oktober 2026. Checklisten zur Implementierung und Bewertungskriterien sind redaktionelle Empfehlungen. Abbildungen sind erläuternde Beispiele, keine Kundenergebnisse.

1. Identity governance overview, Microsoft Learn; aktualisiert am 8. Mai 2026. Geprüft am 12. September 2026.
2. SP 800-207: Zero Trust Architecture, NIST; August 2020. Geprüft am 12. September 2026.
3. SP 800-53 Rev. 5: Security and Privacy Controls, NIST; September 2020; aktueller Veröffentlichungseintrag eingesehen. Geprüft am 12. September 2026.
4. midPoint roles and policies, Evolveum; aktualisiert am 1. August 2025. Geprüft am 12. September 2026.
5. midPoint synchronisation, Evolveum; fortlaufend gepflegte Dokumentation, Version 4.10. Geprüft am 12. September 2026.
6. RFC 7644: SCIM Protocol, RFC Editor; September 2015. Geprüft am 12. September 2026.
7. Access reviews overview, Microsoft Learn; fortlaufend gepflegte Dokumentation. Geprüft am 12. September 2026.
8. Revoke user access in an emergency, Microsoft Learn; fortlaufend gepflegte Dokumentation. Geprüft am 12. September 2026.
9. Richtlinie (EU) 2022/2555, Artikel 21, Europäische Union; 14. Dezember 2022. Geprüft am 12. September 2026.
10. Verordnung (EU) 2016/679, Artikel 5, 24 und 32, Europäische Union; 27. April 2016. Geprüft am 12. September 2026.
11. Produktumfang und Integrationsstatus, easyIGA; aktuelle Live-Seite. Geprüft am 12. September 2026.
12. Unternehmenshintergrund und Erfahrung, easyIGA; aktuelle Live-Seite. Geprüft am 12. September 2026.

Foto: Vitaly Gariev / Unsplash, veröffentlicht am 26. September 2025; Unsplash License (geprüft am 12. September 2026). Die abgebildeten Personen dienen der Veranschaulichung und sind weder als unsere Mitarbeitenden noch als unsere Kundschaft ausgewiesen.