Identity Governance
Berechtigungen prüfen, nicht nur vergeben
Ein Rollenmodell ist am Tag der Einführung richtig. Governance ist das, was dafür sorgt, dass es zwei Jahre später noch stimmt - mit benannter Verantwortung, wiederkehrender Prüfung und einem Nachweis, der ohne Nacharbeit vorliegt.
Worum es geht
Identity Governance beantwortet nicht die Frage, wer worauf zugreifen darf - das tut das Berechtigungskonzept. Sie beantwortet die Frage danach: Stimmt es noch, wer hat das zuletzt bestätigt, und woran ist das zu erkennen?
In der Praxis scheitert das selten an fehlender Technik. Es scheitert daran, dass niemand benannt ist, der eine Rolle verantwortet, dass die Prüfung einmal jährlich als Liste durch die Fachbereiche geht, und dass der Nachweis erst kurz vor der Prüfung aus mehreren Systemen zusammengesucht wird.
Wir setzen deshalb an der Zuständigkeit an, nicht am Werkzeug. Eine Rezertifizierung ohne benannte Verantwortliche erzeugt Bestätigungen, aber keine Entscheidungen - und eine Bestätigung ohne Entscheidung ist im Zweifel wertlos.
Ausgangslage
Kommt Ihnen das bekannt vor?
Keiner dieser Punkte entsteht durch Nachlässigkeit. Sie entstehen, weil Systeme mitwachsen und niemandem allein gehören.
Niemand ist zuständig
Rollen haben keine benannte fachliche Verantwortung. Bei jeder Rückfrage sucht die IT jemanden, der die Frage beantworten könnte - und entscheidet am Ende selbst.
Prüfung als Sammelbestätigung
Einmal im Jahr geht eine Liste durch die Fachbereiche. Ohne Kontext wird pauschal bestätigt; abgehakt ist die Pflicht, nicht das Risiko.
Anträge außerhalb des Systems
Zugriffe werden per Mail, Ticket oder Zuruf beantragt. Wer sie freigegeben hat und warum, lässt sich Monate später nicht mehr rekonstruieren.
Nachweis erst kurz vor der Prüfung
Die Belege entstehen im Nachhinein aus Exporten mehrerer Systeme. Das kostet jedes Mal Wochen und beweist streng genommen nur den Zustand am Exporttag.
Im Einzelnen
Die Themen, um die es geht
Je Bereich: worin das Problem besteht, was wir übernehmen und was danach anders ist.
Rollenverantwortung
- Ausgangslage
- Eine Rolle gehört niemandem. Wenn eine Zuweisung fragwürdig ist, gibt es keine Stelle, die sie fachlich beurteilen kann - also bleibt sie bestehen.
- Was wir tun
- Wir benennen je Rolle eine verantwortliche Person aus dem Fachbereich und beschreiben, wofür sie einsteht: Zuschnitt der Rolle, Freigabe von Zuweisungen, Entscheidung in der Rezertifizierung. Die IT betreibt das Verfahren, sie entscheidet es nicht.
- Ergebnis
- Jede Rolle hat eine Adresse. Entscheidungen fallen dort, wo die fachliche Kenntnis liegt.
Access Reviews und Rezertifizierung
- Ausgangslage
- Die Prüfung fragt "darf Person X das?" und liefert eine Liste technischer Bezeichner. Die Antwort ist erwartungsgemäß ein pauschales Ja.
- Was wir tun
- Wir gestalten die Kampagne um den Entscheider herum: Zusammenhang statt Bezeichner - Aufgabe, Rolle, Abweichung vom Regelfall, Datum der letzten Änderung. Der Turnus richtet sich nach dem Risiko, nicht nach dem Kalender: kritische Rechte öfter, unkritische seltener.
- Ergebnis
- Eine Prüfung, in der tatsächlich entzogen wird - und die deshalb etwas belegt.
Antrags- und Genehmigungswege
- Ausgangslage
- Zugriffsanträge laufen an mehreren Stellen vorbei, mit unterschiedlichen Regeln je Abteilung und ohne einheitliche Spur.
- Was wir tun
- Wir führen Antrag, Prüfung und Freigabe in einen definierten Weg zusammen: Wer darf beantragen, wer genehmigt, was geschieht bei Abwesenheit, welche Anträge laufen automatisch, welche brauchen eine Einzelentscheidung - und was passiert, wenn niemand reagiert.
- Ergebnis
- Zugriffe entstehen nachvollziehbar. Die Begründung steht beim Vorgang, nicht in einem Postfach.
Entitlement Management
- Ausgangslage
- Was ein einzelnes Anwendungsrecht fachlich bedeutet, weiß oft nur die Anwendung selbst. In der Prüfung steht ein technischer Name ohne Bedeutung.
- Was wir tun
- Wir übersetzen technische Berechtigungen in fachlich beschriebene Bausteine, kennzeichnen kritische darunter und ordnen sie den Rollen zu. Was nirgends zugeordnet ist, wird sichtbar - und ist meist der interessanteste Teil.
- Ergebnis
- Ein Katalog, in dem Berechtigungen etwas bedeuten. Kritisches ist als kritisch erkennbar.
Funktionstrennung (SoD)
- Ausgangslage
- Dass niemand gleichzeitig anlegen und freigeben darf, steht in der Richtlinie. Ob es zutrifft, prüft niemand - und Ausnahmen sind nirgends erfasst.
- Was wir tun
- Wir formulieren die Trennungsregeln als prüfbare Bedingungen, prüfen sie gegen den Bestand und richten die Prüfung für den laufenden Betrieb ein. Für begründete Ausnahmen entsteht ein Verfahren mit Befristung und Verantwortlichem statt einer stillen Duldung.
- Ergebnis
- Verstöße fallen auf, wenn sie entstehen. Ausnahmen sind erfasst, begründet und befristet.
Nachweis und Berichte
- Ausgangslage
- Der Nachweis entsteht vor jeder Prüfung neu, aus Exporten mehrerer Systeme, von Hand zusammengeführt.
- Was wir tun
- Wir legen fest, welche Belege wiederkehrend gebraucht werden - Zuweisungen zum Stichtag, Entscheidungen der letzten Kampagne, offene Ausnahmen, Verstöße gegen Trennungsregeln - und richten ihre Erzeugung als festen Bestandteil des Betriebs ein.
- Ergebnis
- Der Nachweis liegt vor, wenn er gebraucht wird. Die Vorbereitung einer Prüfung ist kein Projekt mehr.
Steht die nächste Rezertifizierung an?
Je früher feststeht, wer entscheidet und woran, desto weniger wird pauschal bestätigt. Kurz vor dem Termin ist die Reihenfolge dieselbe - nur der Spielraum fehlt.
Leistungsumfang
Was wir übernehmen
Nicht jedes Vorhaben braucht alles davon. Der Zuschnitt entsteht nach der Bestandsaufnahme, nicht davor.
Verantwortung
- Rollenverantwortung je Rolle
- Zuständigkeit für Anwendungen und Berechtigungen
- Vertretungs- und Eskalationsregeln
- Abgrenzung von IT-Betrieb und Fachentscheidung
Prüfung
- Rezertifizierungskampagnen mit Kontext
- Risikoabhängiger Turnus
- Ereignisgetriebene Zwischenprüfungen
- Umgang mit Nichtreaktion
Zugriffsvergabe
- Antrags- und Genehmigungswege
- Regelbasierte gegenüber beantragter Vergabe
- Befristete Zugriffe
- Umgang mit erhöhten Rechten
Katalog
- Fachliche Beschreibung von Berechtigungen
- Kennzeichnung kritischer Rechte
- Zuordnung zu Rollen
- Aufdecken nicht zugeordneter Rechte
Regeln
- Trennungsregeln als prüfbare Bedingungen
- Prüfung gegen den Bestand
- Ausnahmen mit Frist und Verantwortlichem
- Laufende Prüfung im Betrieb
Nachweis
- Wiederkehrende Belege
- Entscheidungshistorie
- Offene Punkte und Ausnahmen
- Auswertung für Prüfungen
Was XINOO konkret übernimmt
- Bestandsaufnahme der heutigen Vergabe-, Prüf- und Genehmigungswege
- Zuordnung fachlicher Verantwortung je Rolle und Anwendung
- Gestaltung der Rezertifizierung inklusive Turnus, Umfang und Darstellung
- Definition der Antrags- und Genehmigungswege einschließlich Vertretung und Eskalation
- Katalog fachlich beschriebener Berechtigungen mit Kennzeichnung kritischer Rechte
- Trennungsregeln als prüfbare Bedingungen samt Ausnahmeverfahren
- Festlegung der wiederkehrenden Nachweise und ihrer Erzeugung
- Übergabe an die Organisation mit Dokumentation und Ablaufbeschreibung
Was am Ende vorliegt
- Ein Rezertifizierungsablauf, der ohne uns funktioniert
- Benannte Verantwortliche statt einer Zuständigkeit bei der IT
- Zugriffsentscheidungen mit erkennbarer Begründung
- Ein Berechtigungskatalog, in dem kritische Rechte als solche markiert sind
- Erfasste, befristete und begründete Ausnahmen
- Nachweise, die vorliegen statt vorbereitet zu werden
Passt besonders für
- Organisationen, deren Rollenmodell steht, aber im Betrieb auseinanderläuft
- Häuser vor einer Prüfung nach ISO 27001, NIS2 oder branchenspezifischen Vorgaben
- Unternehmen, in denen die Rezertifizierung als Sammelbestätigung endet
- Organisationen mit vielen externen Beteiligten und befristeten Zugriffen
- Häuser, die eine IGA-Plattform lizenziert, aber nur teilweise in Betrieb haben
Vorgehen
Wie wir arbeiten
Die Reihenfolge ist die Aussage: Erst das fachliche Modell, dann das Werkzeug.
Bestandsaufnahme
Wie werden Zugriffe heute beantragt, genehmigt, geprüft und entzogen? Wir nehmen den tatsächlichen Weg auf, nicht den beschriebenen.
Verantwortung klären
Je Rolle und Anwendung wird benannt, wer fachlich entscheidet - einschließlich Vertretung und Eskalation.
Katalog und Regeln
Berechtigungen werden fachlich beschrieben, kritische gekennzeichnet, Trennungsregeln als prüfbare Bedingungen formuliert.
Verfahren gestalten
Antrag, Genehmigung und Rezertifizierung werden als Abläufe festgelegt - mit Turnus, Darstellung und Umgang mit Nichtreaktion.
Einführen
Umsetzung im vorhandenen Werkzeug, beginnend mit einem überschaubaren Bereich statt mit der gesamten Organisation.
Übergeben
Dokumentation, Ablaufbeschreibung und ein Durchlauf, den die Organisation selbst fährt.
Häufige Fragen
Was uns dazu gefragt wird
Was ist der Unterschied zwischen IAM und IGA?
IAM ist der Oberbegriff für die Verwaltung von Identitäten und Zugriffen. Identity Governance and Administration ist der Teil davon, der die Vergabe steuerbar und nachweisbar macht: Wer verantwortet eine Rolle, wie wird beantragt und genehmigt, wann wird geprüft, was liegt danach als Beleg vor. Anmeldung und einmalige Anmeldung gehören nicht dazu - die stehen bei uns auf einer eigenen Seite.
Brauchen wir dafür eine IGA-Plattform?
Nicht zwingend am Anfang. Verantwortung, Katalog und Trennungsregeln lassen sich klären, bevor ein Werkzeug ausgewählt ist - und ohne diese Klärung bildet auch die beste Plattform nur den bisherigen Zustand ab. Umgekehrt gilt: Ab einer gewissen Zahl von Anwendungen und Beteiligten ist ein Werkzeug notwendig, weil Tabellen den Turnus nicht durchhalten.
Wie oft sollte rezertifiziert werden?
Nach Risiko, nicht nach Kalender. Für kritische Rechte - erhöhte Berechtigungen, Zugriff auf personenbezogene oder finanzielle Daten, externe Zugänge - ist ein kurzer Turnus sinnvoll; für breite, unkritische Rechte reicht ein langer. Zusätzlich sind ereignisgetriebene Prüfungen wirksam: bei Rollenwechsel oder Ende einer Befristung.
Wir haben bereits ein Rollenmodell. Reicht das nicht?
Ein Rollenmodell beschreibt den Sollzustand. Governance stellt fest, ob der Istzustand noch damit übereinstimmt, und hält das Ergebnis fest. Ohne diesen zweiten Teil ist ein Modell nach zwei Jahren eine Dokumentation der Vergangenheit.
Ersetzt das eine Zertifizierung?
Nein. Wir arbeiten im Beratungsprojekt - Bestandsaufnahme, Gestaltung, Umsetzung, Nachweisfähigkeit. Eine unabhängige Zertifizierung erfolgt durch die dafür zuständige akkreditierte Zertifizierungsstelle.
Weitere Themen
Gehört meistens dazu
Wer bestätigt bei Ihnen die Berechtigungen?
Wenn die Antwort "die IT" lautet oder "einmal im Jahr per Liste", ist die Reihenfolge klar. Wir sehen uns die heutigen Wege an und sagen, was zuerst dran ist.