Was ist RBAC?
RBAC (Role-Based Access Control, rollenbasierte Zugriffskontrolle) ist ein Berechtigungsmodell, das Zugriffsrechte an Rollen statt an einzelne Personen bindet. Eine Rolle bündelt die Rechte, die für eine Aufgabe nötig sind, etwa First-Level-Support oder Security-Analyst; Nutzer erhalten ihre Rechte ausschließlich über die Zuweisung solcher Rollen. Das macht Berechtigungen konsistent, nachvollziehbar und pflegbar: Wer die Aufgabe wechselt, wechselt die Rolle, statt Einzelrechte anzusammeln. RBAC ist damit das praktischste Werkzeug, um Least Privilege durchzusetzen, also jeder Person und jedem Dienst nur die minimal nötigen Rechte zu geben.
RBAC im Detail
Ein RBAC-Modell besteht aus drei Bausteinen: Nutzer, Rollen und Berechtigungen. Berechtigungen hängen an Rollen, Nutzer an Rollenzuweisungen; direkte Einzelrechte an Personen sind tabu. Ergänzend hat sich Domänen-Scoping etabliert: Es begrenzt zusätzlich, auf welchen Ausschnitt der Daten eine Rolle wirkt, etwa nur auf einen Standort, eine Abteilung oder einen Mandanten. Rechte beantworten dann zwei Fragen: Was darf die Rolle, und wo gilt das?
Abzugrenzen ist RBAC von ABAC (Attribute-Based Access Control), das Zugriffe über Attribute und Bedingungen wie Gerätezustand oder Standort entscheidet. In der Praxis ergänzen sich beide: RBAC liefert die stabile Grundordnung, attributbasierte Bedingungen verfeinern sie situativ. Formal beschrieben ist das Rollenmodell unter anderem in den RBAC-Arbeiten des NIST.
Warum ist RBAC im Zscaler-Betrieb wichtig?
Zscaler-Admin-Konsolen sind mächtig: Wer dort Zugriff hat, kann Richtlinien für das gesamte Unternehmen ändern. In vielen Organisationen erhalten Helpdesk-Teams deshalb entweder gar keinen Einblick, dann eskaliert jedes Ticket, oder zu weitreichende Rechte, dann wächst das Risiko. RBAC löst dieses Dilemma: Lesende Einsicht für die Fallbearbeitung ist eine eigene Rolle, administrativer Eingriff eine andere. So sieht der First-Level, was er für den Fall braucht, ohne etwas ändern zu können.
Auch für den Nachweis zählt das Modell: NIS2 verlangt Konzepte für die Zugriffskontrolle, DORA beherrschte Rechtevergabe im Finanzsektor. Ein sauberes Rollenmodell mit Domänen-Scoping beantwortet die Prüferfrage, wer worauf zugreifen kann und warum, direkt aus der Struktur heraus, statt aus gewachsenen Einzelrechten rekonstruiert werden zu müssen.
Typische Fehlerquellen
- Rollen-Wildwuchs: Entsteht faktisch eine Rolle pro Person, ist das Modell nur eine umbenannte Einzelrechtevergabe.
- Dauerrechte für Ausnahmefälle: Breite Rollen, die für eine einmalige Aufgabe vergeben wurden, bleiben oft dauerhaft bestehen.
- Sammel-Accounts: Geteilte Zugänge zerstören die Zuordnung von Aktionen zu Personen und damit jeden Audit-Trail.
- Keine Rezertifizierung: Rollenzuweisungen müssen regelmäßig überprüft werden, sonst sammeln langjährige Mitarbeitende stille Rechte an.
RBAC in der Praxis: so hilft CentaurNexus
CentaurNexus setzt RBAC mit Domain-Scoping konsequent für den Zscaler-Betrieb um: Helpdesk-Rollen erhalten über User Support Center eine lesende 360-Grad-Sicht auf Nutzer über ZIA, ZPA und ZDX hinweg, ohne Zscaler-Admin-Rechte zu benötigen, und sehen dabei nur den Bereich, für den sie zuständig sind. Schreibende Aktionen bleiben eigenen Rollen vorbehalten, lassen sich per Vier-Augen-Prinzip freigeben und landen im append-only geführten Audit-Trail. Für MSPs kommt Cross-Tenant-Scoping hinzu: viele Kundenmandanten in einer Oberfläche, strikt getrennt. Wie Support ohne Admin-Rechte konkret funktioniert, zeigt der Leitfaden Zscaler-Support ohne Admin-Rechte.
Verwandte Begriffe
Häufige Fragen zu RBAC
RBAC steht für Role-Based Access Control, auf Deutsch rollenbasierte Zugriffskontrolle. Zugriffsrechte werden nicht einzelnen Personen zugeteilt, sondern an Rollen wie Helpdesk oder Administrator gebunden; Nutzer erhalten ihre Rechte über die Zuweisung dieser Rollen. Das hält Berechtigungen konsistent und prüfbar und erleichtert Eintritt, Wechsel und Austritt von Mitarbeitenden erheblich.
RBAC entscheidet über Rollen: Wer die Rolle hat, hat die zugehörigen Rechte. ABAC entscheidet über Attribute und Bedingungen, etwa Gerätezustand, Standort oder Tageszeit, und kann dadurch feiner, aber auch komplexer steuern. In der Praxis bewährt sich die Kombination: RBAC als stabile Grundordnung, attributbasierte Bedingungen als situative Verfeinerung.
Weil Zscaler-Richtlinien das ganze Unternehmen betreffen, sollten möglichst wenige Personen volle Admin-Rechte halten. RBAC erlaubt die Trennung von lesender Einsicht und administrativem Eingriff: Der Helpdesk bekommt eine Sicht auf Nutzer- und Richtlinienstatus für die Fallbearbeitung, während Änderungen wenigen Berechtigten vorbehalten bleiben. Das senkt Risiko und Eskalationen zugleich.
So wenige wie möglich, so viele wie nötig. Bewährt hat sich ein kleiner Satz von Standardrollen entlang der Aufgaben, etwa First-Level, Second-Level, Administration und Audit, ergänzt um wenige begründete Sonderrollen. Entsteht faktisch eine Rolle pro Person, ist das Modell gescheitert und sollte konsolidiert werden.
NIS2 schreibt kein bestimmtes Modell vor, verlangt aber Konzepte für Zugriffskontrolle und beherrschtes Risikomanagement; maßgeblich ist die jeweilige nationale Umsetzung. RBAC ist der etablierte Weg, diese Anforderungen umzusetzen und zu belegen, weil sich aus Rollen und Zuweisungen jederzeit ableiten lässt, wer warum worauf zugreifen kann.
- NIST Computer Security Resource Center: Role Based Access Control (Projektseite) - csrc.nist.gov
- Richtlinie (EU) 2022/2555 (NIS2), Anforderungen an Zugriffskontrolle und Risikomanagement - eur-lex.europa.eu
- Zscaler Help Portal: offizielle Dokumentation zur rollenbasierten Administration - help.zscaler.com
Hinweis: CentaurNexus ist ein unabhängiges Produkt der SourcingBlox GmbH und kein Angebot von Zscaler, Inc. Produkt- und Markennamen gehören ihren jeweiligen Inhabern.