Rollenmodell entwickeln: Von der Analyse zum RBAC

Berechtigungen wachsen in den meisten Unternehmen organisch: Ein neuer Mitarbeiter bekommt „die gleichen Rechte wie die Kollegin", ein Projekt braucht „schnell mal Zugriff", eine Abteilung erbt die Altlasten ihrer Vorgänger. Nach ein paar Jahren weiß niemand mehr genau, wer warum worauf zugreifen darf. Genau hier setzt ein Rollenmodell RBAC an: Es ersetzt die individuelle Vergabe einzelner Berechtigungen durch Rollen, die Sie zentral definieren, kontrollieren und nachvollziehen können.

In diesem How-To zeigen wir Ihnen, wie Sie ein tragfähiges Rollenmodell entwickeln – von der Analyse des Ist-Zustands über die Wahl zwischen Top-down und Bottom-up bis zum fertigen Rollenkatalog mit sauberer Funktionstrennung. Geschrieben aus der Praxis von IAM-Projekten im Mittelstand, mit besonderem Augenmerk auf den häufigsten Fehler: die Rollenexplosion, die ein Rollenmodell am Ende komplizierter macht als der Wildwuchs, den es ersetzen sollte.

Was ein Rollenmodell leistet – und was RBAC eigentlich ist

RBAC steht für Role-Based Access Control, also rollenbasierte Zugriffskontrolle. Die Idee ist simpel: Statt jedem Benutzer einzelne Berechtigungen zuzuweisen, ordnen Sie ihn einer oder mehreren Rollen zu. Jede Rolle bündelt die Berechtigungen, die für eine bestimmte Aufgabe oder Funktion nötig sind. Der Sachbearbeiter im Einkauf erhält die Rolle „Einkauf Sachbearbeitung" – und mit ihr automatisch genau die Rechte, die diese Funktion braucht.

Der Gewinn liegt auf der Hand:

• Nachvollziehbarkeit: Sie sehen auf einen Blick, welche Rechte eine Funktion mit sich bringt – nicht 200 einzelne Berechtigungen pro Person.
• Effizienz: Beim Eintritt, Abteilungswechsel oder Austritt verwalten Sie Rollen statt Hunderter Einzelrechte. Das macht Joiner-Mover-Leaver-Prozesse erst beherrschbar.
• Compliance: Rezertifizierungen, Audits und der Nachweis des Need-to-know-Prinzips werden überhaupt erst praktikabel.
• Sicherheit: Sie erzwingen das Prinzip der geringsten Rechte (Least Privilege) strukturell, nicht durch Einzelfallprüfung.

Merksatz
Ein Rollenmodell ist kein technisches Projekt, sondern ein fachliches. Die schwierigste Frage ist nicht „Wie weise ich Rechte zu?", sondern „Welche Funktionen gibt es in unserem Unternehmen wirklich – und welche Rechte brauchen sie?"

RBAC vs. ABAC – kurz eingeordnet

Neben RBAC begegnet Ihnen oft ABAC (Attribute-Based Access Control). Statt fester Rollen entscheidet ABAC anhand von Attributen – etwa Abteilung, Standort, Gerätestatus oder Tageszeit – dynamisch über Zugriff. ABAC ist flexibler und feingranularer, aber auch deutlich komplexer in der Pflege und im Verständnis.

Für den Mittelstand gilt in den allermeisten Fällen: RBAC ist das Fundament, ABAC die gezielte Ergänzung. Sie bauen ein stabiles Rollenmodell auf und reichern es punktuell mit attributbasierten Regeln an, wo statische Rollen an ihre Grenzen stoßen – etwa bei kontextabhängigem Zugriff über Conditional Access. Wer dagegen versucht, von Anfang an alles über Attribute zu lösen, baut sich ein System, das niemand mehr durchschaut. Starten Sie mit RBAC.

Die zwei Wege zum Rollenmodell: Top-down und Bottom-up

Es gibt zwei grundsätzliche Herangehensweisen, ein Rollenmodell zu entwickeln. In der Praxis kombinieren Sie beide – aber Sie sollten verstehen, was jede für sich leistet.

Top-down: vom Organigramm zur Rolle

Beim Top-down-Ansatz leiten Sie Rollen aus der fachlichen Organisation ab. Sie analysieren Geschäftsprozesse, Funktionen und Verantwortlichkeiten und fragen: Welche Tätigkeiten gibt es, und welche Berechtigungen erfordern sie? Aus „Buchhaltung Kreditoren", „Vertrieb Innendienst" oder „IT-Administration Clients" werden Rollen, die sich an der gelebten Aufgabenstruktur orientieren.

Stärke: Die Rollen sind verständlich, fachlich begründet und langlebig. Ein Fachverantwortlicher kann nachvollziehen, was „seine" Rolle bedeutet.

Schwäche: Top-down ist aufwendig und übersieht leicht die historisch gewachsene Realität. Was im Organigramm sauber aussieht, weicht in der Praxis oft erheblich ab.

Bottom-up: Role Mining aus den Ist-Daten

Beim Bottom-up-Ansatz – auch Role Mining genannt – analysieren Sie die tatsächlich vergebenen Berechtigungen. Sie exportieren, wer heute welche Rechte hat, und suchen mit Cluster-Analysen nach Mustern: Welche Gruppen von Benutzern haben auffällig ähnliche Berechtigungen? Daraus lassen sich Kandidaten für Rollen ableiten.

Stärke: Sie arbeiten mit der Realität, nicht mit einem Idealbild. Role Mining deckt auf, was wirklich genutzt wird, und findet Rollen, die im Organigramm nicht sichtbar sind.

Schwäche: Wer Bottom-up pur betreibt, zementiert den Wildwuchs. Wenn 80 Menschen über die Jahre 80 leicht unterschiedliche Rechtebündel angesammelt haben, finden Sie 80 „Rollen" – und haben nichts gewonnen.

Praxis-Tipp
Kombinieren Sie beide Wege. Nutzen Sie Top-down, um die fachliche Soll-Struktur zu definieren, und Role Mining, um sie mit der Realität abzugleichen. Die spannendsten Erkenntnisse liegen in den Abweichungen: Wo weicht das, was Menschen tatsächlich an Rechten haben, von dem ab, was ihre Funktion eigentlich braucht? Genau dort sitzen entweder vergessene Altrechte oder ungedeckte Bedarfe.

Business-Rollen und technische Rollen trennen

Ein häufiger Konstruktionsfehler ist, alles in eine einzige Rollenebene zu pressen. Tragfähige Rollenmodelle arbeiten mit mindestens zwei Ebenen.

Business-Rollen (auch fachliche oder Geschäftsrollen) orientieren sich an Funktionen im Unternehmen: „Personalreferent", „Einkäufer", „Standortleiter". Sie sind das, was Fachverantwortliche verstehen und verantworten können. Eine Business-Rolle beantwortet die Frage: Wer ist diese Person im Unternehmen?

Technische Rollen (auch Berechtigungs- oder Systemrollen) bündeln konkrete Rechte in einem Zielsystem: „SAP FI Anzeige", „Fileshare Marketing Schreibzugriff", „Entra-ID-Gruppe Vertrieb". Eine technische Rolle beantwortet: Was darf man in System X konkret tun?

Die Verbindung entsteht durch Zuordnung: Eine Business-Rolle „Einkäufer" enthält mehrere technische Rollen aus verschiedenen Systemen. Dieser zweistufige Aufbau hat einen großen Vorteil – wenn sich ein Zielsystem ändert, passen Sie die technische Rolle an, ohne die Business-Rolle anzufassen. Fachseite und IT arbeiten an dem, was sie jeweils verantworten können.

Aus der Praxis
Bei einem mittelständischen Industrieunternehmen reduzierte sich die Zahl der direkt an Personen vergebenen Berechtigungen um über 80 Prozent, nachdem wir konsequent zwischen rund 40 Business-Rollen und einer überschaubaren Zahl technischer Rollen getrennt hatten. Entscheidend war nicht die Technik, sondern dass jede Business-Rolle einen klaren fachlichen Eigentümer bekam.

Der Rollenkatalog: Struktur und Inhalt

Das Ergebnis Ihrer Arbeit ist der Rollenkatalog – das zentrale Verzeichnis aller Rollen mit ihren Eigenschaften. Ein guter Rollenkatalog dokumentiert pro Rolle mindestens:

• Eindeutiger Name und ID nach einer klaren Namenskonvention (z. B. BR_Einkauf_Sachbearbeitung für Business-Rollen, TR_SAP_FI_Anzeige für technische).
• Beschreibung und Zweck in einem Satz, den ein Fachverantwortlicher versteht.
• Enthaltene Berechtigungen bzw. untergeordnete Rollen.
• Rolleneigentümer (Role Owner) – die Person, die fachlich für Inhalt und Vergabe verantwortlich ist.
• Risikoeinstufung – besonders für Rollen mit kritischen oder weitreichenden Rechten.
• Geltungsbereich – für welche Organisationseinheiten, Standorte oder Mandanten die Rolle gilt.

Halten Sie die Zahl der Rollen bewusst klein. Eine gute Faustregel: Lieber wenige Rollen, die mehrere Menschen teilen, als viele Rollen für Einzelfälle. Sonderfälle lösen Sie über zusätzliche, klar befristete Einzelberechtigungen – nicht über eine eigene Rolle pro Person.

Funktionstrennung (SoD): Konflikte von Anfang an mitdenken

Ein Rollenmodell ist die Gelegenheit, Funktionstrennung – Segregation of Duties, kurz SoD – strukturell zu verankern. SoD bedeutet, dass kritische Vorgänge nicht von einer einzigen Person allein abgewickelt werden dürfen. Das klassische Beispiel: Wer eine Rechnung anlegen darf, sollte sie nicht auch freigeben und auszahlen können. Sonst entsteht ein Einfallstor für Betrug und Fehler.

In einem Rollenmodell definieren Sie SoD-Regeln als Konfliktpaare: Rolle A und Rolle B dürfen nicht gleichzeitig an dieselbe Person vergeben werden. Typische Konfliktfelder:

• Anlegen vs. Freigeben von Zahlungen oder Bestellungen.
• Administration eines Systems vs. fachliche Nutzung mit weitreichenden Rechten.
• Vergabe von Berechtigungen vs. Empfang besonders kritischer Berechtigungen.

Diese Regeln gehören in den Rollenkatalog und in den Vergabeprozess. Ein gutes IAM-System prüft bei jeder Zuweisung automatisch gegen die SoD-Matrix und blockiert oder eskaliert Konflikte. Wer SoD erst nach einem Audit-Befund nachrüstet, zahlt drauf – planen Sie die Konfliktmatrix von Beginn an ein, auch wenn Sie zunächst nur die offensichtlichsten Paare abdecken.

Compliance-Hinweis
Funktionstrennung ist nicht nur „nice to have". Sie ist Bestandteil vieler Prüfungsstandards und Erwartung interner wie externer Auditoren. Ein dokumentiertes SoD-Regelwerk ist oft der Unterschied zwischen einem bestandenen Audit und einer Abweichung.

Pflege und Governance: Das Modell lebt

Der größte Irrtum bei Rollenmodellen ist die Annahme, sie seien mit dem Go-live fertig. Tatsächlich beginnt die eigentliche Arbeit danach. Organisationen ändern sich, neue Systeme kommen hinzu, Aufgaben verschieben sich. Ohne kontinuierliche Pflege verfällt ein Rollenmodell innerhalb von ein bis zwei Jahren wieder zu Wildwuchs – nur dass dieser jetzt hinter scheinbar sauberen Rollennamen versteckt ist.

Etablieren Sie deshalb feste Governance-Strukturen:

1. Klare Verantwortlichkeiten: Jede Rolle hat einen Eigentümer, der Änderungen verantwortet. Es gibt eine zentrale Stelle (oft ein Role-Management-Board oder der IAM-Verantwortliche), die Konsistenz über alle Rollen wahrt.
2. Definierter Änderungsprozess: Neue Rollen oder Rechteänderungen durchlaufen einen Antrags- und Freigabeprozess – nicht den Zuruf.
3. Regelmäßige Rezertifizierung: In festen Abständen bestätigen Rolleneigentümer und Vorgesetzte, dass Rollen und Zuweisungen noch korrekt sind. Wie das praktisch funktioniert, lesen Sie in unserem Beitrag zur Berechtigungsrezertifizierung.
4. Aufräum-Disziplin: Verwaiste Rollen, ungenutzte Berechtigungen und veraltete Zuordnungen werden konsequent entfernt – nicht „für alle Fälle" behalten.

Die Governance entscheidet darüber, ob Ihr Rollenmodell ein dauerhaftes Asset oder ein einmaliges Projekt mit Verfallsdatum ist.

Typische Fehler – allen voran die Rollenexplosion

Aus zahlreichen IAM-Projekten lassen sich die wiederkehrenden Fehler klar benennen. Der gravierendste:

Die Rollenexplosion. Wenn für jeden Sonderfall eine neue Rolle entsteht, wächst der Katalog ins Unermessliche. Am Ende gibt es fast so viele Rollen wie Mitarbeiter – und das Modell hat seinen Zweck verfehlt. Gegenmittel: konsequente Standardisierung, klare Regeln, wann eine neue Rolle gerechtfertigt ist, und Sonderfälle über befristete Einzelrechte statt über eigene Rollen lösen.

Weitere häufige Fehler:

• Bottom-up ohne Bereinigung: Role Mining liefert Kandidaten, keine fertigen Rollen. Wer die Cluster ungeprüft übernimmt, zementiert Altlasten.
• Keine Rolleneigentümer: Ohne fachliche Verantwortliche verwaist das Modell. Die IT kann Rechte technisch verwalten, aber nicht beurteilen, ob ein Einkäufer Zugriff auf Lieferantenkonditionen braucht.
• Zu granular gestartet: Wer von Tag eins jede Feinheit abbilden will, verliert sich in Komplexität. Beginnen Sie mit den 80 Prozent der Standardfälle.
• SoD vergessen: Funktionstrennung später nachzurüsten ist teuer und oft schmerzhaft.
• Modell ohne Governance: Ein gepflegtes Rollenmodell braucht Prozesse, sonst zerfällt es.

Praxis-Tipp
Starten Sie mit einem klar abgegrenzten Bereich – etwa einer Abteilung oder einem Leitsystem – und bauen Sie dort ein funktionierendes Rollenmodell auf. Die Erfahrungen aus diesem Piloten sparen im Roll-out auf das Gesamtunternehmen ein Vielfaches an Aufwand. Ein perfektes Gesamtmodell auf dem Reißbrett scheitert fast immer an der Realität.

Wie welabs Sie beim Rollenmodell unterstützt

Ein Rollenmodell zu entwickeln ist Konzern-Handwerk – und genau dieses Handwerk übersetzen wir in den Mittelstand. Wir bringen die Methodik großer IAM-Programme mit, ohne deren Overhead. Konkret unterstützen wir Sie im Rahmen unseres Identity- & Access-Management-Angebots bei:

• Ist-Analyse und Role Mining: strukturierte Auswertung Ihrer bestehenden Berechtigungen, um echte Muster und Altlasten sichtbar zu machen.
• Entwicklung des Rollenmodells: Top-down-Konzeption fachlicher Business-Rollen, sauber getrennt von technischen Rollen, mit pragmatischem Zuschnitt.
• SoD-Konzept: Definition der Funktionstrennungs-Konflikte und ihrer Verankerung im Vergabeprozess.
• Rollenkatalog und Governance: Aufbau eines pflegbaren Katalogs samt Verantwortlichkeiten, Änderungs- und Rezertifizierungsprozessen.
• Einbindung in Ihr IAM-Tooling: Überführung des Modells in Ihre bestehende oder geplante IAM-Landschaft, inklusive Anbindung an Entra ID.

Wenn Sie Ihr Berechtigungschaos in ein belastbares Rollenmodell überführen wollen, lassen Sie uns in einem unverbindlichen Erstgespräch über Ihren Ausgangspunkt sprechen. Wie ein IAM-Projekt im Mittelstand insgesamt aufgesetzt wird, lesen Sie zudem in unserem Leitfaden zum Berechtigungsmanagement im Mittelstand.

Fazit

Ein gutes Rollenmodell ist kein IT-Projekt, sondern eine fachliche Übersetzungsleistung: Es bildet ab, wer im Unternehmen welche Aufgabe hat – und leitet daraus ab, welche Rechte dazugehören. Der Weg dorthin führt über die Kombination aus Top-down-Konzeption und Bottom-up-Role-Mining, über die saubere Trennung von Business- und technischen Rollen und über eine von Anfang an mitgedachte Funktionstrennung.

Entscheidend ist die Disziplin, das Modell schlank zu halten und konsequent zu pflegen. Wer der Versuchung widersteht, für jeden Sonderfall eine eigene Rolle anzulegen, und wer klare Rolleneigentümer und Governance-Prozesse etabliert, schafft mehr als sauberere Berechtigungen: ein dauerhaftes Fundament für Sicherheit, Compliance und effiziente Identity-Prozesse. Starten Sie klein, denken Sie groß – und halten Sie das Modell am Leben.