Wer Zugriffsrechte einzeln pro Person vergibt, verliert schon in mittelgroßen Umgebungen den Überblick. Rechte sammeln sich über Jahre an, und Abteilungswechsel hinterlassen Altlasten. Spätestens beim Austritt weiß niemand mehr genau, welche Konten und Freigaben zu entziehen sind. Role-Based Access Control (RBAC) löst dieses Problem strukturell: Berechtigungen hängen an Rollen, und Personen erhalten Rollen. Wer eine Rolle abgibt, verliert automatisch die damit verbundenen Rechte. Das Modell ist als ANSI-Standard formalisiert und prägt heute die Zugriffskontrolle vom Verzeichnisdienst bis zur Cloud-Plattform.
Was ist Role-Based Access Control?
RBAC ist ein Autorisierungsmodell, das Berechtigungen an Rollen bindet statt an einzelne Identitäten. Eine Rolle beschreibt eine Funktion im Unternehmen, etwa „Buchhaltung“ oder „Service-Desk“. Jede Rolle bündelt die Zugriffsrechte, die für diese Funktion erforderlich sind. Die Zuweisung verbindet schließlich eine Person oder ein technisches Konto mit einer oder mehreren Rollen.
Das Modell besteht damit aus drei Bausteinen: der Rolle als fachlichem Container, der Berechtigung als konkretem Zugriffsrecht auf eine Ressource und der Zuweisung als Verknüpfung zwischen Identität und Rolle. Diese Struktur macht Zugriffe nachvollziehbar. Statt zehntausende Einzelrechte zu prüfen, prüfen Sie einige Dutzend Rollen.
RBAC ist zugleich das praktikabelste Werkzeug für Least Privilege, das Prinzip minimaler Rechtevergabe. Eine sauber geschnittene Rolle enthält genau die Rechte, die eine Funktion benötigt, und nichts darüber hinaus.
Wie funktioniert RBAC?
Ein tragfähiges Rollenmodell entsteht in wiederkehrenden Schritten:
- Rollen modellieren: Fachbereiche und IT definieren gemeinsam, welche Funktionen es gibt und welche Zugriffe sie benötigen. Grundlage sind Stellenprofile und tatsächlich genutzte Berechtigungen.
- Berechtigungen bündeln: Einzelrechte auf Anwendungen oder Netzwerksegmente werden Rollen zugeordnet. Die technischen Details bleiben in der Rolle gekapselt.
- Identitäten zuweisen: Mitarbeitende und technische Konten erhalten Rollen, idealerweise automatisiert über das Identity-Management entlang des gesamten Identitäts-Lebenszyklus.
- Hierarchien nutzen: Übergeordnete Rollen erben die Rechte untergeordneter Rollen. Das reduziert Redundanz, verlangt aber Disziplin beim Rollenschnitt.
- Funktionstrennung erzwingen: Kritische Kombinationen, etwa Zahlungen anlegen und Zahlungen freigeben, schließen sich über getrennte Rollen gegenseitig aus.
- Regelmäßig rezertifizieren: Verantwortliche bestätigen periodisch, dass Zuweisungen weiterhin berechtigt sind. Ungenutzte Rollen und verwaiste Rechte werden entfernt.
Das größte Praxisproblem ist die Rollenexplosion. Wenn jede Sonderanforderung eine neue Rolle erzeugt, existieren irgendwann mehr Rollen als Mitarbeitende, und das Modell wird genauso unübersichtlich wie die Einzelrechtevergabe zuvor. Wirksam dagegen sind ein Rollenschnitt entlang stabiler Funktionen und ein fester Genehmigungsprozess für jede neue Rolle.
Warum RBAC wichtig ist
- Least Privilege wird praktisch durchsetzbar, weil Rechte gebündelt und begründet vergeben werden.
- On- und Offboarding beschleunigen sich, da eine Rollenzuweisung viele Einzelanträge ersetzt und beim Austritt ein einziger Entzug genügt.
- Audits nach ISO 27001 oder DORA werden einfacher, weil jederzeit nachvollziehbar ist, wer warum Zugriff hat.
- Die Angriffsfläche sinkt, weil kompromittierte Konten nur die Rechte ihrer Rollen mitbringen.
- Fehler durch manuelle Einzelvergabe und kopierte Berechtigungsprofile entfallen weitgehend.
- Verwaiste Konten und ungenutzte Rechte fallen bei Rezertifizierungen systematisch auf.
Typische Szenarien
- Ein Mittelständler führt Abteilungsrollen im Verzeichnisdienst ein. Neue Mitarbeitende erhalten am ersten Tag automatisch ihre Basisrolle, Sonderrechte laufen über einen Genehmigungsworkflow.
- In Kubernetes regeln Roles und RoleBindings, welches Team in welchem Namespace Deployments ändern darf. ClusterRoles mit weitreichenden Rechten bleiben wenigen Plattform-Verantwortlichen vorbehalten.
- In Cloud-Plattformen begrenzen Rollen auf Subscription- oder Projektebene, wer Ressourcen anlegt und wer Netzwerkregeln ändert.
- Ein über Jahre gewachsenes Rollenmodell mit tausenden Einträgen wird konsolidiert. Nutzungsdaten zeigen, welche Rollen faktisch deckungsgleich sind, und der Bestand schrumpft auf einen wartbaren Kern.
- Netzwerk-Policies folgen demselben Prinzip: Workloads erhalten Rollen wie „Datenbank Produktion“, und Kommunikationsregeln gelten pro Rolle statt pro IP-Adresse.
RBAC oder ABAC: Wo liegt der Unterschied?
RBAC entscheidet anhand vorab definierter Rollen. Attribute-Based Access Control (ABAC) bewertet dagegen zur Laufzeit Attribute von Identität, Ressource und Kontext, etwa den Gerätezustand oder die Datenklassifizierung. ABAC steuert feiner und beugt der Rollenexplosion vor, verlangt aber gepflegte Attributdaten und ist schwerer zu auditieren, weil Entscheidungen erst zur Laufzeit aus Regeln entstehen. In der Praxis kombinieren viele Unternehmen beides: RBAC als stabiles Grundgerüst, ergänzt um attributbasierte Bedingungen für besonders sensible Zugriffe. Moderne Zero-Trust-Architekturen arbeiten typischerweise mit genau dieser Kombination.
RBAC bei KAEMI
KAEMI überträgt Rollenmodelle auf die Netzwerkebene. Bei der Zero Trust Mikrosegmentierung erhalten Workloads Labels nach Funktion und Umgebung, und Kommunikationsregeln folgen diesen Rollen statt einzelnen IP-Adressen. So entsteht Least Privilege für den Ost-West-Verkehr zwischen Servern und Anwendungen. Für den Zugriff von Nutzern auf Anwendungen setzt KAEMI auf identitätsbasierte Policies im Rahmen von SASE/SSE : Auch hier entscheidet die Rolle darüber, welche Ziele erreichbar sind. Wenn Sie ein Rollenmodell für Zugriffe oder Netzwerk-Policies aufbauen oder sanieren möchten, sprechen Sie uns an .