Rollen & Berechtigungen
Ein Rollenmodell, das im Audit standhält
Berechtigungen wachsen mit der Organisation – und werden selten wieder entzogen. Wir bringen sie in ein Modell, das fachlich verständlich bleibt, technisch umsetzbar ist und den Nachweis liefert, den Prüfer verlangen.
Worum es geht
Ein Berechtigungskonzept beantwortet drei Fragen dauerhaft und nachvollziehbar: Wer darf was? Warum darf er es? Und wer hat das entschieden?
In gewachsenen Umgebungen liegt die Antwort meist verteilt – in Verzeichnisgruppen, Anwendungsrechten, Tabellen und im Kopf einzelner Kolleginnen und Kollegen. Das funktioniert, solange niemand fragt. Bei einer Prüfung, einem Rollenwechsel oder einem Vorfall funktioniert es nicht mehr.
Wir arbeiten dabei bewusst zuerst fachlich und erst danach technisch: Ein Rollenmodell, das nur im Werkzeug existiert, aber nicht der Aufbauorganisation entspricht, wird umgangen – und ein umgangenes Modell schützt nichts.
Ausgangslage
Kommt Ihnen das bekannt vor?
Keiner dieser Punkte entsteht durch Nachlässigkeit. Sie entstehen, weil Systeme mitwachsen und niemandem allein gehören.
Rechte sammeln sich an
Bei jedem Wechsel kommt etwas dazu, entzogen wird selten. Nach Jahren hat kaum jemand noch genau die Rechte, die zur Aufgabe passen.
Gruppen statt Rollen
Verzeichnisgruppen sind historisch gewachsen, heißen nach Abteilungen von gestern und enthalten Ausnahmen, die niemand mehr begründen kann.
Funktionstrennung nur auf dem Papier
Dass niemand gleichzeitig anlegen und freigeben darf, steht in der Richtlinie – geprüft wird es nirgends automatisch.
Rezertifizierung als Sammelaktion
Einmal im Jahr gehen Listen durch die Fachbereiche, die mangels Kontext pauschal bestätigt werden – abgehakt ist damit die Pflicht, nicht das Risiko.
Im Einzelnen
Die Themen, um die es geht
Je Bereich: worin das Problem besteht, was wir übernehmen und was danach anders ist.
RBAC – rollenbasierte Vergabe
- Ausgangslage
- Rechte hängen an einzelnen Personen. Wer neu anfängt, bekommt sie „wie die Kollegin“ kopiert – samt allem, was die Kollegin über Jahre angesammelt hat.
- Was wir tun
- Wir führen die Vergabe auf Rollen zurück: Eine Rolle bündelt die Rechte einer Aufgabe, Personen erhalten Rollen statt Einzelrechte. Wo Rollen zu grob greifen, ergänzen wir attributbasierte Regeln – etwa Standort oder Kostenstelle.
- Ergebnis
- Neue Mitarbeitende bekommen eine Rolle statt einer Kopie. Was jemand darf, lässt sich in einem Satz begründen.
Role Mining – das Modell aus den Daten
- Ausgangslage
- Niemand kann aus dem Kopf sagen, welche Rollen es geben müsste. Ein Modell am Reißbrett trifft die Praxis selten.
- Was wir tun
- Wir werten die bestehenden Zuweisungen aus und suchen Muster: Welche Rechtebündel treten wiederholt gemeinsam auf, welche sind Einzelfälle? Das Ergebnis ist ein Rollenvorschlag, der aus dem tatsächlichen Betrieb stammt.
- Ergebnis
- Ein Entwurf, über den die Fachbereiche diskutieren können – statt eines leeren Blattes.
Role Engineering – vom Vorschlag zum Modell
- Ausgangslage
- Aus der Auswertung entstehen zu viele Rollen. Ein Modell mit hunderten Rollen ist so unbrauchbar wie gar keines.
- Was wir tun
- Wir verdichten den Vorschlag gemeinsam mit den Fachbereichen: Geschäftsrollen entlang der Aufgaben, IT-Rollen entlang der Systeme, Anwendungsrollen für das, was nur innerhalb einer Anwendung gilt. Vererbung reduziert Doppelungen.
- Ergebnis
- Ein Modell in drei Ebenen, dessen oberste Ebene ein Fachbereichsleiter ohne IT-Kenntnisse versteht.
Funktionstrennung und minimale Rechte
- Ausgangslage
- Kritische Kombinationen – anlegen und freigeben, bestellen und bezahlen – lassen sich technisch vergeben, ohne dass jemand es merkt.
- Was wir tun
- Wir definieren die unvereinbaren Kombinationen als prüfbare Regeln und legen fest, was bei einem Verstoß passiert: Blockade, Genehmigung mit Vier-Augen-Prinzip oder dokumentierte Ausnahme mit Ablaufdatum.
- Ergebnis
- Verstöße werden bei der Vergabe sichtbar, nicht erst im Prüfbericht.
Rollenverantwortung und Rezertifizierung
- Ausgangslage
- Rollen haben keinen Eigentümer. Bei der jährlichen Prüfung bestätigt jemand Rechte, deren Zweck er nicht kennt.
- Was wir tun
- Jede Rolle bekommt eine benannte verantwortliche Person aus dem Fachbereich. Die Rezertifizierung fragt danach nicht mehr „darf Person X das?“, sondern zeigt Aufgabe, Rolle und Abweichung im Zusammenhang.
- Ergebnis
- Bestätigungen mit Sachkenntnis statt Sammelfreigaben – und ein Nachweis, der etwas wert ist.
Unsicher, ob Ihr Modell trägt?
Eine Sichtung der bestehenden Rechtevergabe zeigt, wo sie bei einer Prüfung auffallen würde – bevor sie es tut.
Leistungsumfang
Was wir übernehmen
Nicht jedes Vorhaben braucht alles davon. Der Zuschnitt entsteht nach der Bestandsaufnahme, nicht davor.
Analyse
- Bestandsaufnahme der Verzeichnisse und Anwendungen
- Auswertung vorhandener Gruppen und Rechte
- Abgleich mit der Aufbauorganisation
- Risikobetrachtung kritischer Berechtigungen
Modell
- Fachliche und technische Rollen
- Rollenhierarchie und Vererbung
- Regelbasierte Zuweisung (RBAC/ABAC)
- Ausnahmen und ihre Befristung
Kontrolle
- Funktionstrennung (Segregation of Duties)
- Least Privilege als Vergaberegel
- Rezertifizierung mit Kontext
- Genehmigungswege und Vertretung
Nachweis
- Dokumentation für interne Revision
- Auswertbare Berechtigungsberichte
- Historie der Vergabeentscheidungen
- Vorbereitung auf Prüfungen
Was XINOO konkret übernimmt
- Auswertung der bestehenden Gruppen, Rechte und Zuweisungen
- Rollenmodell in drei Ebenen (Geschäfts-, IT- und Anwendungsrollen)
- Regelwerk für Funktionstrennung mit benannten kritischen Kombinationen
- Vergabe- und Genehmigungsregeln einschließlich Vertretung
- Zuordnung der Rollenverantwortung zu benannten Personen
- Rezertifizierungsablauf mit Turnus und Zuständigkeit
- Abbildung im vorhandenen Verzeichnis oder Identity-System
- Einweisung der Personen, die das Modell künftig pflegen
Was am Ende vorliegt
- Ein Rollenkatalog, der Aufgabe, Rechte und Verantwortung je Rolle benennt
- Eine Liste kritischer Rechtekombinationen mit Behandlungsregel
- Ein Vergabekonzept, das ohne Rückfrage anwendbar ist
- Ein Prüfbericht zum Ist-Zustand samt Abweichungen
- Ein Rezertifizierungsablauf, der ohne uns läuft
Passt besonders für
- Organisationen vor einer Prüfung nach ISO 27001, NIS2 oder branchenspezifischen Vorgaben
- Häuser, in denen Berechtigungen über Jahre gewachsen sind
- Vorhaben, die ein IAM-System einführen wollen und das fachliche Modell noch brauchen
Vorgehen
Wie wir arbeiten
Die Reihenfolge ist die Aussage: Erst das fachliche Modell, dann das Werkzeug.
Ist-Aufnahme
Welche Verzeichnisse, Anwendungen und Gruppen gibt es, wer vergibt heute Rechte und nach welcher Regel? Am Ende steht eine Karte des tatsächlichen Zustands – nicht des dokumentierten.
Rollenschnitt
Aus Aufgaben werden Rollen. Wir schneiden entlang dessen, was Menschen tun, nicht entlang dessen, was Systeme anbieten – sonst entsteht ein Modell, das nur die IT versteht.
Regeln und Ausnahmen
Funktionstrennung, Genehmigungswege und der Umgang mit Sonderrechten werden festgelegt. Ausnahmen bekommen von Anfang an ein Ablaufdatum.
Umsetzung im Werkzeug
Erst jetzt die Abbildung im vorhandenen System – Verzeichnisdienst, Identity-Lösung oder Anwendung. Zuerst ein Pilotbereich, dann die Fläche.
Übergabe und Rezertifizierung
Das Modell gehört danach der Organisation, nicht uns. Wir übergeben Dokumentation, Regeln und einen Rezertifizierungsablauf, der ohne uns funktioniert.
Häufige Fragen
Was uns dazu gefragt wird
Brauchen wir dafür erst ein IAM-Werkzeug?
Nein. Das Rollenmodell ist eine fachliche Arbeit und entsteht unabhängig vom Werkzeug. Es ist im Gegenteil sinnvoll, es vorher zu haben: Wer ein System einführt, ohne zu wissen, welche Rollen es abbilden soll, bildet den Ist-Zustand ab – samt seiner Fehler.
Wie viele Rollen sind richtig?
So wenige wie möglich, so viele wie nötig. Zu wenige Rollen führen zu Sammelrechten, zu viele zu einem Modell, das niemand pflegt. Die Zahl ergibt sich aus der Organisation, nicht aus einer Faustregel.
Was passiert mit den bestehenden Gruppen?
Sie werden nicht gelöscht, sondern zugeordnet. Ein harter Schnitt legt den Betrieb lahm. Üblich ist ein paralleler Betrieb, in dem neue Vergaben bereits dem Modell folgen, während der Bestand schrittweise überführt wird.
Wie lange dauert so etwas?
Das hängt an der Zahl der Anwendungen und daran, wie klar die Aufbauorganisation ist. Belastbar wird die Antwort erst nach der Ist-Aufnahme – vorher ist jede Zahl geraten.
Weitere Themen
Gehört meistens dazu
Wissen Sie, wer bei Ihnen worauf Zugriff hat?
Wenn die Antwort länger als einen Satz braucht, lohnt sich ein Gespräch. Nennen Sie uns Ihre Systeme – wir sagen Ihnen, wo wir anfangen würden.