In der Theorie klingt das einfach. In der Praxis sieht es oft anders aus.

Ob diese Berechtigung zum Rollenmodell passt? Ob sie korrekt vergeben wurde? Das fällt – wenn überhaupt – erst beim nächsten Audit auf. Und bis dahin können Monate vergehen.

Dieses Muster ist kein Einzelfall. Es entsteht, weil viele IAM-Lösungen Provisionierung als einmaligen Vorgang verstehen: Aktion ausführen, Status auf „erledigt" setzen, fertig. Ob die Aktion im Zielsystem überhaupt korrekt durchgeführt wurde – ob der Account wirklich angelegt, die Berechtigung wirklich entzogen wurde – wird dabei häufig nicht geprüft. Ein typisches Szenario: Ein IAM-System löst eine Provisionierungsaktion aus, aber ein Administrator hat zwischenzeitlich direkt im Zielsystem manuell eingegriffen. Die ursprüngliche Bedingung existiert nicht mehr oder hat sich verändert – die Aktion läuft ins Leere oder erzeugt einen unerwarteten Zustand, ohne dass das IAM-System davon erfährt. Und was danach mit den Berechtigungen passiert – ob sie noch dem Soll-Zustand entsprechen, ob sich zwischenzeitlich etwas verändert hat – liegt ebenfalls außerhalb des Prozesses.

Ohne kontinuierliche Kontrolle entsteht über Zeit ein Berechtigungsdschungel – Zugriffsrechte, die niemand mehr bewusst vergeben hat und die niemand aktiv überprüft. Hinzu kommen zwei weitere Probleme: Selbst Provisionierungsaktionen, die das System als „erledigt" markiert hat, müssen nicht zwingend korrekt im Zielsystem angekommen sein. Und selbst wenn sie es waren, kann sich der Zustand danach unbemerkt verändert haben – etwa weil ein Administrator direkt im Zielsystem manuell eingegriffen hat, ohne dass das IAM-System davon erfährt. In Audits wird genau das sichtbar, was über Monate oder Jahre unbemerkt gewachsen, schiefgelaufen oder still überschrieben wurde.

Erkennen: Veränderungen im Unternehmen werden in Echtzeit erkannt – nicht nur Eintritte und Austritte, sondern auch Abteilungswechsel, Namensänderungen, Abwesenheiten oder Änderungen der Verantwortlichkeit. Für jedes dieser Ereignisse startet automatisch der passende Prozess.

Vergeben: Auf Basis des erkannten Ereignisses werden automatisch die richtigen Aktionen ausgelöst – etwa das Anlegen eines Accounts, das Zuweisen einer Gruppe oder das Entziehen einer Berechtigung. Dabei ist Provisionierung nicht auf Accounts beschränkt: Auch Security Objects (etwa Active Directory-Gruppen oder SAP-Rollen) und direkte Permissions – also Beziehungen zwischen Account und Berechtigung – können provisioniert werden. Ein konkretes Beispiel: Verlässt ein Mitarbeiter das Unternehmen früher als geplant, muss sofort gehandelt werden. Das Ereignis löst automatisch die Sperrung aller Konten der Person aus – ohne manuelle Eingriffe, ohne Verzögerung.

Prüfen: Prüfung findet auf zwei Ebenen statt. Erstens verifiziert daccord über den Collector-Abgleich mit dem Zielsystem, ob eine ausgelöste Provisionierungsaktion dort tatsächlich korrekt durchgeführt wurde – ein Task gilt erst als erledigt, wenn das Zielsystem die Änderung bestätigt. Zweitens prüft eine Policy Engine kontinuierlich, ob die tatsächlich vorhandenen Berechtigungen dem Soll-Zustand entsprechen. Dabei werden konfigurierbare Regeln gegen die aktuelle Datenlage ausgeführt – zum Beispiel: Gibt es inaktive Accounts mit noch aktiven Berechtigungen? Weichen die tatsächlichen Berechtigungen eines Accounts von den erwarteten ab?

Korrigieren: Wird eine Abweichung erkannt, kann das System auf verschiedene Arten reagieren – je nach Konfiguration und Art des Problems: Es kann die zuständigen Personen benachrichtigen, automatisch eine Korrekturmaßnahme einleiten oder die Abweichung als Schwachstelle festhalten. Auch ein Ticket kann in einem solchen Fall geöffnet werden, z.B. in JIRA. Das Ticketsystem kann daccord dann zurückmelden, ob die Aufgabe durch den Ticketbearbeiter als erledigt markiert worden ist. In jedem Fall bleibt das Problem sichtbar und nachvollziehbar – nicht erst beim nächsten Audit.

Die Lifecycle Extension erkennt Ereignisse aus drei verschiedenen Quellen und startet für jedes automatisch den passenden Workflow. Erstens aus HR-Systemen: klassische Lebensereignisse wie Eintritt, Austritt oder Organisationswechsel. Zweitens aus direkten Aktionen: etwa wenn ein Austrittsdatum nachträglich geändert wird und sofort eine neue Prozesskette ausgelöst werden muss. Drittens aus der Policy Engine: Meldet eine Richtlinie einen Missstand – etwa eine Abweichung vom Soll-Zustand – kann auch das eine Lifecycle-Aktion anstoßen. Das Bindeglied über alle drei Wege ist ein Event-Stream über Kafka: Jede relevante Änderung löst unmittelbar die nächste Stufe aus.

Damit keine Änderung unbemerkt bleibt, ist eine Neo4j Extension als TransactionEventListener direkt in der Datenbank registriert. Sie triggert bei jeder Transaktion – unabhängig davon, ob die Änderung über die Benutzeroberfläche, eine Schnittstelle oder direkt in der Datenbank stattfindet.

Die Policy Engine schließt den Kreislauf auf der Kontrollseite. Policies sind konfigurierbare Abfragen gegen die Graph-Datenbank und können sowohl zeitgesteuert als auch event-getriggert ausgeführt werden. Sie sind der Catch-All-Mechanismus: Sie finden auch Probleme, die durch Events nicht erkannt wurden.

Der Provisioning Type bestimmt, wie eine Provisionierungsaufgabe für ein bestimmtes System behandelt wird: vollautomatisch direkt ins Zielsystem (via LDAP, JDBC oder API), als sofortige Benachrichtigung für eine manuelle Bearbeitung, oder als gebündelte Sammelaufgabe nach einer konfigurierbaren Verzögerung. Provisionierungsanfragen können dabei nicht nur durch Lifecycle-Ereignisse oder Richtlinien ausgelöst werden, sondern auch manuell über das Portal – etwa wenn ein Benutzer die Deaktivierung eines bestimmten Kontos beantragt (Provisioning Request). Das ermöglicht flexible Prozesse – von der vollautomatischen Provisionierung bis hin zu genehmigungspflichtigen Workflows, je nach Sicherheitsanforderung des Unternehmens.

Die Confirmation Strategy schließt den Kreis auf einer weiteren Ebene – und ist einer der zentralen Unterschiede von daccord. Nach jeder Provisionierungsaktion importiert daccord die Daten direkt aus dem Zielsystem zurück. Dieser Import spiegelt die tatsächliche Situation im Zielsystem wider – nicht den angenommenen Soll-Zustand, sondern den realen Ist-Zustand. Erst durch den Abgleich zwischen ausgelöster Aktion und zurückgemeldetem Ergebnis gilt ein Task als wirklich erledigt. Was viele IAM-Systeme als „done" markieren, ohne je nachzusehen ob die Aktion angekommen ist, prüft daccord aktiv nach. Das bedeutet: Abweichungen, manuelle Eingriffe im Zielsystem oder fehlgeschlagene Aktionen werden nicht einfach übersehen – sie werden sichtbar. Operationen, die sich nicht über einen Import verifizieren lassen – etwa Passwortänderungen – können alternativ mit der Strategie "none" konfiguriert werden: Der Task wird dann unmittelbar nach erfolgreichem Handler-Aufruf abgeschlossen.

Compliance: Abweichungen vom Soll-Zustand werden sofort sichtbar – nicht erst, wenn der Auditor fragt. Gleichzeitig ist jede Provisionierungsaktion durch den Zielsystem-Abgleich lückenlos nachvollziehbar: Es lässt sich jederzeit belegen, ob eine Aktion korrekt durchgeführt wurde oder nicht. Das reduziert den Aufwand für Rezertifizierungsprozesse erheblich, weil viele Probleme bereits vor dem Review erkannt und behoben sind.

Sicherheit: Überflüssige oder falsch vergebene Berechtigungen werden frühzeitig erkannt und korrigiert, bevor sie zum Risiko werden. Das gilt besonders für verwaiste Accounts – aktive Zugänge ohne aktiven Nutzer – die eine der häufigsten Schwachstellen in Berechtigungsstrukturen darstellen.

Effizienz: Der manuelle Aufwand für periodische Berechtigungsreviews sinkt, weil das System kontinuierlich im Hintergrund prüft und Violations dokumentiert.