Rollenbasierte Zugriffskontrolle (RBAC)

Rollenbasierte Zugriffskontrolle (RBAC) ist ein Modell der Zugriffssteuerung, bei dem Berechtigungen nicht einzelnen Personen, sondern Rollen zugewiesen werden; Personen erhalten Zugriff, indem sie einer Rolle zugeordnet werden. Rollenbasierte Zugriffskontrolle setzt damit das Prinzip der minimalen Rechtevergabe um und ist in ANSI/INCITS 359 standardisiert. Die Trennung von Person und Berechtigung senkt den Verwaltungsaufwand und macht Zugriffsrechte prüfbar.

Was ist rollenbasierte Zugriffskontrolle (RBAC)?

Rollenbasierte Zugriffskontrolle ist ein Verfahren, das eine Zwischenebene zwischen Personen und Berechtigungen einzieht. Statt jeder Person einzeln Rechte auf Systeme, Verzeichnisse oder Funktionen zu erteilen, werden Rechte zu Rollen gebündelt, und Personen werden diesen Rollen zugeordnet. Wer die Rolle „Sachbearbeitung Rechnungswesen“ erhält, bekommt automatisch alle darin hinterlegten Berechtigungen – und verliert sie ebenso automatisch, wenn die Zuordnung endet.

Der konzeptionelle Ursprung liegt in einer Arbeit des US-amerikanischen NIST aus dem Jahr 1992; standardisiert wurde das Modell später als ANSI/INCITS 359. Rollenbasierte Zugriffskontrolle ist heute das verbreitetste Berechtigungsmodell in Unternehmen und Behörden und in praktisch jedem Betriebssystem, Verzeichnisdienst, ERP-System und Fachverfahren in irgendeiner Form vorhanden.

Ein Missverständnis prägt dabei viele Projekte: Eine Rolle ist keine Stellenbezeichnung. Die Stellenbezeichnung beschreibt, was jemand im Organigramm ist; eine Rolle im Sinne der rollenbasierten Zugriffskontrolle beschreibt, was jemand in einem System tun darf. Beides fällt selten deckungsgleich zusammen. Eine Person kann mehrere Rollen gleichzeitig innehaben – etwa eine fachliche Rolle, eine Vertretungsrolle und eine Rolle für ein zeitlich begrenztes Projekt. Wer Rollen eins zu eins aus dem Stellenplan ableitet, erzeugt ein Modell, das die Realität der Arbeitsteilung nicht abbildet und deshalb ständig durch Einzelfallausnahmen unterlaufen wird.

Wie funktioniert RBAC?

Rollenbasierte Zugriffskontrolle funktioniert über zwei Zuordnungen: Personen werden Rollen zugewiesen, Rollen werden Berechtigungen zugewiesen. Der Zugriff einer Person ergibt sich rechnerisch aus der Verkettung beider Zuordnungen; eine direkte Verbindung zwischen Person und Berechtigung existiert im Modell nicht.

Das Standardmodell kennt dafür vier Grundelemente. Benutzer sind die handelnden Identitäten, in der Regel Personen, zunehmend auch technische Konten und Dienste. Rollen bündeln Berechtigungen entlang einer fachlichen Aufgabe. Berechtigungen bestehen jeweils aus einer Operation und einem Objekt – „lesen“ auf „Personalakte“, „freigeben“ auf „Zahlungslauf“. Sitzungen bilden ab, welche der zugeordneten Rollen eine Person zu einem bestimmten Zeitpunkt tatsächlich aktiviert hat. Dieses Sitzungskonzept ist der Grund, warum Administratoren in gut gebauten Umgebungen nicht dauerhaft mit erhöhten Rechten arbeiten, sondern diese gezielt aktivieren.

Ein Beispiel: In einem Krankenhausinformationssystem erhält die Rolle „Pflegekraft Station 3″ Leserechte auf die Behandlungsdokumentation der Patienten dieser Station und Schreibrechte auf die Pflegedokumentation, aber keinen Zugriff auf Abrechnungsdaten. Wechselt eine Pflegekraft die Station, wird lediglich die Rollenzuordnung getauscht – an den hinterlegten Berechtigungen ändert sich nichts. Genau darin liegt der Verwaltungsvorteil: Änderungen an Rechten erfolgen einmal an der Rolle statt hundertfach an einzelnen Konten.

Technisch umgesetzt wird rollenbasierte Zugriffskontrolle meist über Gruppen im Verzeichnisdienst, etwa in Active Directory oder über LDAP angebundene Systeme. Die Rollenzuordnung selbst wird zunehmend aus führenden Personalsystemen abgeleitet und über Provisionierungsschnittstellen automatisiert an die Zielsysteme verteilt.

Warum ist rollenbasierte Zugriffskontrolle wichtig?

Rollenbasierte Zugriffskontrolle ist wichtig, weil unkontrolliert gewachsene Einzelberechtigungen zu den verlässlichsten Schwachstellen jeder IT-Landschaft gehören. Ohne Rollenmodell entstehen Rechte anlassbezogen: Jemand braucht kurzfristig Zugriff, bekommt ihn, und niemand entzieht ihn wieder. Nach wenigen Jahren verfügt ein erheblicher Teil der Belegschaft über Berechtigungen, die mit der aktuellen Aufgabe nichts mehr zu tun haben.

Diese Rechteanhäufung wirkt auf drei Ebenen. Sicherheitsseitig vergrößert sie die Angriffsfläche: Ein kompromittiertes Konto ist genau so gefährlich wie die Summe seiner Rechte, und übermäßig berechtigte Konten sind das bevorzugte Ziel bei Ransomware- und Innentäterangriffen. Organisatorisch erschwert sie jede Prüfung, weil sich ohne Rollenmodell kaum beantworten lässt, wer eigentlich worauf zugreifen kann. Rechtlich schließlich fehlt der Nachweis, dass der Zugriff auf personenbezogene Daten auf das Erforderliche begrenzt ist.

Hinzu kommt die Funktionstrennung als eigenständiger Grund. In vielen Prozessen darf dieselbe Person nicht beide Seiten eines Vorgangs kontrollieren: Wer eine Zahlung anlegt, soll sie nicht freigeben; wer Benutzerkonten verwaltet, soll keine Protokolldaten löschen können. Rollenbasierte Zugriffskontrolle macht solche Trennungen als Regel abbildbar, statt sie der Disziplin Einzelner zu überlassen.

Welche Ausbaustufen des RBAC-Modells gibt es?

Das RBAC-Modell kennt vier aufeinander aufbauende Komponenten, die sich schrittweise einführen lassen. Diese Abstufung ist praktisch bedeutsam, weil Organisationen selten alle Stufen gleichzeitig umsetzen können.

Core RBAC bildet die Grundlage: Benutzer, Rollen, Berechtigungen und Sitzungen mit den beiden Zuordnungen. Schon diese Stufe erfüllt den wesentlichen Zweck, nämlich die Entkopplung von Person und Recht.

Hierarchisches RBAC ergänzt Rollenhierarchien mit Vererbung. Eine übergeordnete Rolle erbt die Berechtigungen der untergeordneten – die Rolle „Teamleitung Buchhaltung“ enthält damit automatisch alles, was die Rolle „Buchhaltung“ enthält, plus zusätzliche Rechte. Hierarchien reduzieren Redundanz erheblich, machen das Modell aber auch schwerer durchschaubar: Bei tiefen Hierarchien ist oft nicht mehr unmittelbar erkennbar, welche Rechte am Ende tatsächlich wirken.

RBAC mit Beschränkungen führt die Funktionstrennung als technische Regel ein. Unterschieden wird zwischen statischer Trennung, bei der zwei unvereinbare Rollen derselben Person gar nicht erst zugeordnet werden dürfen, und dynamischer Trennung, bei der die Zuordnung zulässig ist, beide Rollen aber nicht in derselben Sitzung aktiviert werden können. Die dynamische Variante ist flexibler, etwa für Vertretungsfälle, verlangt aber eine saubere Sitzungsverwaltung.

Symmetrisches RBAC ergänzt die Überprüfbarkeit in die Gegenrichtung: Es muss sich nicht nur ermitteln lassen, welche Rechte eine Rolle hat, sondern auch, welche Rollen eine bestimmte Berechtigung enthalten. Erst diese Sicht macht Rezertifizierungen und Rechteabbau praktisch durchführbar.

Wie unterscheidet sich RBAC von DAC, MAC und ABAC?

RBAC, DAC, MAC und ABAC unterscheiden sich darin, wer über den Zugriff entscheidet und woraus sich die Entscheidung ableitet. Die Modelle schließen einander nicht aus – in realen Umgebungen laufen sie meist nebeneinander.

Die wichtigste Grenze der rollenbasierten Zugriffskontrolle ist ihre Statik: Eine Rolle gilt unabhängig davon, von welchem Gerät, zu welcher Zeit oder aus welchem Netz zugegriffen wird. Genau diese Kontextfaktoren adressiert ABAC, beschrieben unter anderem in NIST SP 800-162. In der Praxis hat sich eine Kombination durchgesetzt: Rollen legen die grundsätzliche Berechtigung fest, Attribute schränken sie situativ ein. Dieses Zusammenspiel ist auch die technische Grundlage von Zero Trust-Architekturen, in denen jede Zugriffsentscheidung neu bewertet wird, statt sich auf eine einmalige Anmeldung zu stützen.

Wie wird ein Rollenmodell für RBAC entwickelt?

Ein Rollenmodell entsteht durch Role Engineering, für das sich zwei Vorgehensweisen etabliert haben. Der Top-down-Ansatz leitet Rollen aus den Geschäftsprozessen ab: Welche Aufgaben gibt es, welche Schritte gehören dazu, welche Zugriffe sind dafür nötig? Das Ergebnis ist fachlich sauber und gut begründbar, der Aufwand aber erheblich, weil jede Aufgabe mit den Fachbereichen erhoben werden muss.

Der Bottom-up-Ansatz, auch Role Mining genannt, geht vom Bestand aus: Vorhandene Berechtigungen werden analysiert und wiederkehrende Muster zu Rollenvorschlägen verdichtet. Das ist schnell und werkzeuggestützt möglich, zementiert aber genau jene historisch gewachsenen Überberechtigungen, die eigentlich abgebaut werden sollen. Erfahrungsgemäß liefert erst die Kombination brauchbare Ergebnisse: Role Mining für den Überblick und die Massendaten, Top-down für die kritischen Prozesse und die Funktionstrennung.

Unabhängig vom Ansatz braucht ein tragfähiges Rollenmodell vier weitere Bestandteile. Erstens klare Verantwortlichkeiten: Für jede Rolle sollte eine fachlich verantwortliche Person benannt sein, die Zuordnungen genehmigt und regelmäßig prüft – die IT verwaltet Rollen, sie verantwortet sie nicht. Zweitens ein definierter Prozess für Eintritt, Wechsel und Austritt. Der Wechselfall ist dabei der kritische: Neue Rechte werden zuverlässig erteilt, alte selten entzogen. Drittens die Rezertifizierung, also die turnusmäßige Bestätigung bestehender Zuordnungen durch die Verantwortlichen, für privilegierte Rollen in kürzeren Abständen als für Standardrollen. Viertens ein geregeltes Verfahren für Ausnahmen samt Befristung, weil dauerhafte Sonderrechte sonst am Modell vorbei entstehen.

Welche rechtlichen Anforderungen gelten für rollenbasierte Zugriffskontrolle?

Rollenbasierte Zugriffskontrolle ist rechtlich zwar nirgends namentlich vorgeschrieben, ergibt sich aber als praktische Konsequenz aus mehreren Anforderungen. Die DSGVO verlangt in Art. 32 Abs. 1 lit. b die dauerhafte Sicherstellung von Vertraulichkeit und Integrität und in Art. 32 Abs. 4, dass unterstellte Personen mit Zugang zu personenbezogenen Daten diese nur auf Anweisung verarbeiten. Art. 25 Abs. 2 fordert datenschutzfreundliche Voreinstellungen, ausdrücklich bezogen auf die Zugänglichkeit von Daten, und Art. 5 Abs. 1 lit. c die Beschränkung auf das notwendige Maß. Zusammengenommen ist das eine Beschreibung des Prinzips der minimalen Rechtevergabe; ein Rollenmodell ist der übliche Weg, es nachweisbar umzusetzen und damit die DSGVO-Konformität einer Verarbeitung zu belegen.

Die NIS2-Richtlinie (EU) 2022/2555 nennt in Art. 21 Konzepte für die Zugriffskontrolle ausdrücklich als geforderte Risikomanagementmaßnahme und ergänzt sie um Anforderungen an Multi-Faktor-Authentifizierung. Methodisch untersetzt wird dies durch ISO/IEC 27001 und ISO/IEC 27002 mit eigenen Maßnahmen zu Zugangssteuerung, Zugangsrechten und privilegierten Zugangsrechten sowie durch das IT-Grundschutz-Kompendium des BSI, das dem Identitäts- und Berechtigungsmanagement einen eigenen Baustein widmet.

Im Rechnungswesen und in der internen Revision kommt die Funktionstrennung als Anforderung an das interne Kontrollsystem hinzu. Prüfungen setzen dort regelmäßig genau an dieser Stelle an – die Frage lautet nicht, ob ein Rollenkonzept existiert, sondern ob die tatsächlich vergebenen Rechte ihm entsprechen.

Welche Rolle spielt RBAC in der sicheren Kommunikation?

In Kommunikationsplattformen steuert rollenbasierte Zugriffskontrolle, wer welche Inhalte sieht und wer administrativ eingreifen darf – zwei Ebenen, die sauber getrennt gehören. Auf der Inhaltsebene entscheidet sie darüber, welche Personengruppen an welchen Kommunikationskreisen teilnehmen. In einer Lage müssen Stab, Fachbereiche und Gesamtorganisation getrennt kommunizieren können, ohne dass jede Nachricht jeden erreicht; gleichzeitig muss die Zuordnung schnell änderbar sein, wenn sich Zuständigkeiten verschieben.

Auf der administrativen Ebene geht es um abgestufte Verwaltungsrechte. Wer Benutzer anlegen darf, muss nicht zugleich Konfigurationen serverweit ändern oder Verläufe exportieren können. Diese Abstufung ist besonders in Umgebungen mit mehreren Organisationseinheiten relevant, in denen jede Einheit ihre eigenen Nutzer verwaltet, ohne Einblick in die Daten der anderen zu erhalten. Ergänzend gehört zu einem belastbaren Berechtigungsmodell die Protokollierung administrativer Handlungen – ohne sie lässt sich weder die Einhaltung der Funktionstrennung nachweisen noch ein Vorfall aufklären.

Organisationen lösen das über Kommunikationslösungen, die administrative Berechtigungen mehrstufig abbilden, Nutzergruppen zentral verwaltbar machen und alle administrativen Eingriffe nachvollziehbar protokollieren.

Wie sich abgestufte Administrationsrechte, zentral verwaltete Nutzergruppen und protokollierte Eingriffe abbilden lassen, zeigt Teamwire in einer Demo oder im kostenlosen Test.

Welche Fehler treten bei rollenbasierter Zugriffskontrolle häufig auf?

Der häufigste Fehler ist die Rollenexplosion: Um jeden Sonderfall abzubilden, werden immer neue Rollen geschnitten, bis ihre Zahl der Zahl der Nutzer nahekommt. Das Modell verliert damit genau den Vorteil, für den es eingeführt wurde, und wird unpflegbar. Weitere typische Schwachstellen:

• Rechteakkumulation bei Stellenwechseln, weil neue Rollen ergänzt, alte aber nicht entzogen werden
• Rollen werden aus dem Stellenplan statt aus den tatsächlichen Aufgaben abgeleitet
• keine oder nur formale Rezertifizierung, bei der Verantwortliche pauschal bestätigen
• befristete Sonderrechte und Notfallzugänge bleiben dauerhaft aktiv
• Administratoren arbeiten dauerhaft mit erhöhten Rechten statt sie gezielt zu aktivieren
• technische Konten und Dienste bleiben außerhalb des Rollenmodells
• Rollenhierarchien werden so tief geschachtelt, dass die effektiven Rechte nicht mehr erkennbar sind
• Austritte werden im Personalsystem gepflegt, aber nicht in alle Zielsysteme übertragen

Zusammenfassung: Wichtige Punkte zu rollenbasierter Zugriffskontrolle (RBAC)

• Rollenbasierte Zugriffskontrolle (RBAC) weist Berechtigungen nicht Personen, sondern Rollen zu; Personen erhalten Zugriff über ihre Rollenzuordnung.
• Das Modell geht auf eine NIST-Arbeit von 1992 zurück und ist als ANSI/INCITS 359 standardisiert.
• Eine Rolle ist keine Stellenbezeichnung: Sie beschreibt, was jemand in einem System tun darf, nicht seine Position im Organigramm; eine Person kann mehrere Rollen halten.
• Das Standardmodell umfasst Benutzer, Rollen, Berechtigungen und Sitzungen sowie die Zuordnungen zwischen ihnen.
• Die Ausbaustufen reichen von Core RBAC über hierarchisches RBAC mit Vererbung bis zu RBAC mit Funktionstrennung in statischer und dynamischer Ausprägung.
• Funktionstrennung (Separation of Duties) ist der wesentliche Compliance-Nutzen: Unvereinbare Aufgaben lassen sich als Regel statt als Absichtserklärung abbilden.
• RBAC ist statisch und berücksichtigt keinen Kontext wie Gerät, Zeit oder Netz – dafür wird es mit ABAC kombiniert, was die Grundlage von Zero-Trust-Architekturen bildet.
• Ein Rollenmodell entsteht durch Top-down-Analyse der Prozesse und Bottom-up-Role-Mining; erst die Kombination liefert belastbare Ergebnisse.
• Ohne Rezertifizierung und einen geregelten Wechselprozess verfällt jedes Rollenmodell, weil Rechte ergänzt, aber nicht entzogen werden.
• Rechtliche Bezugspunkte sind Art. 5, 25 und 32 DSGVO, die NIS2-Richtlinie (EU) 2022/2555, ISO/IEC 27001 sowie der IT-Grundschutz des BSI.