Rollenbasierte Zugriffskontrolle (RBAC)

Was ist rollenbasierte Zugriffskontrolle (RBAC)?

Rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) ist ein Zugriffsmodell, bei dem Berechtigungen an Rollen wie Admin, Editor oder Betrachter hängen und Personen ihren Zugriff durch die Zuweisung einer Rolle erhalten. Was eine ganze Gruppe darf, ändern Sie an einer Rolle statt an Hunderten Konten. Laut NIST geht das formale Modell auf Ferraiolo und Kuhn (1992) zurück und wurde als ANSI/INCITS 359-2004 genormt.

RBAC beantwortet die Autorisierungsfrage, was diese Identität tun darf, nachdem die Authentifizierung geklärt hat, wer sie ist. Es ist eines der Modelle im Identity and Access Management (IAM). Single Sign-on (SSO) entscheidet, wer sich anmeldet, RBAC danach, was die Person tun darf.

Die Kernbegriffe

Beispiel: eine SaaS-App

# Rollen
admin: [users.create, users.delete, billing.view, billing.edit, settings.edit]
editor: [content.create, content.edit, content.publish]
viewer: [content.view]
billing-manager: [billing.view, billing.edit]

# Rollenzuweisungen
alice@example.com: [admin]
bob@example.com: [editor, billing-manager]
carol@example.com: [viewer]

Bob darf Inhalte bearbeiten und die Abrechnung verwalten, weil er zwei Rollen hat. Kommt ein neuer Editor dazu, weisen Sie eine Rolle zu, und die Berechtigungen folgen.

Beispiel: Kubernetes

Kubernetes liefert RBAC als API-Gruppe. Eine Role listet auf, welche Verben auf welchen Ressourcen erlaubt sind, und ein RoleBinding erteilt diese Role Nutzern, Gruppen oder Service-Accounts. Diese Role aus der Kubernetes-Dokumentation erlaubt das Lesen von Pods im Namespace default:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Zwei Details aus der Doku sind in der Praxis wichtig. Eine Role gilt immer für genau einen Namespace, eine ClusterRole nicht. Und Berechtigungen sind rein additiv: Es gibt keine Deny-Regeln, der Zugriff eines Nutzers ist also die Summe aller seiner Rollen.

RBAC, ABAC und ACL im Vergleich

RBAC genügt, solange Berechtigungen davon abhängen, was jemand tut, und nicht von den Daten, die vor ihm liegen. Hängen Regeln von Abteilung, Region oder Tageszeit ab, ergänzen Sie attributbasierte Prüfungen. Eine Access Control List (ACL) hängt Berechtigungen an jede einzelne Ressource, das ist flexibel, aber im großen Maßstab schwer zu prüfen.

Best Practices für RBAC

• Least Privilege. Geben Sie jeder Rolle nur, was die Funktion braucht.
• Funktionstrennung. Sensible Aktionen sollten zwei Rollen erfordern, etwa Antragsteller und Genehmiger.
• Über Gruppen zuweisen. Hängen Sie Rollen an Gruppen statt an einzelne Nutzer, dann ist das Offboarding eine einzige Änderung.
• Rollen nach Funktion benennen. Jobtitel ändern sich, Funktionen halten länger.
• Jede Rolle dokumentieren. Halten Sie fest, wofür sie da ist, wer sie bekommen soll und wer sie prüft.
• Vollzugriffskonten begrenzen. Viele Personen mit Vollzugriff sind für sich schon ein Risiko.
• Erhöhte Rechte nur befristet vergeben. Entziehen Sie sie automatisch, wenn die Aufgabe erledigt ist.
• Prüfen und protokollieren. Kontrollieren Sie Zuweisungen regelmäßig und halten Sie fest, wer wann welche Rolle vergeben hat.

Häufige Fehler

• Rollenexplosion. Mit der Organisation wachsen die Rollen, bis niemand mehr weiß, wofür sie alle da sind. Räumen Sie regelmäßig auf.
• Berechtigungswildwuchs. Rollen sammeln mit der Zeit Rechte an. Entfernen Sie Ungenutztes.
• Zu wenige Rollen. Eine einzige Nutzerrolle macht alle zu mächtig oder zu eingeschränkt.
• Vergessene Zuweisungen. Ein ehemaliger Mitarbeiter mit Admin-Rolle bedeutet, dass das Offboarding nicht funktioniert.
• Fest verdrahtete Rollenprüfungen. if user.role == 'admin' quer durch den Code ist mühsam zu ändern. Prüfen Sie Berechtigungen, nicht Rollennamen.
• Rollen mit Einzel-ACLs mischen. Halbes RBAC ist schwer zu auditieren. Wählen Sie ein Modell pro Ressource.

RBAC in LoadFocus-Teams und beim API-Testen

LoadFocus-Teams nutzen eine kleine Variante von RBAC. Beim Einladen wählen Sie zwischen Admin, der Tests ausführen, bearbeiten und ansehen darf, und View-only, der Tests nur ansehen darf. Außerdem können Sie eine Einladung auf bestimmte Produkte wie Load Testing, JMeter oder API Monitoring beschränken. Das deckt die übliche Aufteilung ab: Ingenieure führen Tests aus, Stakeholder lesen die Ergebnisse. Die Schritte stehen im Teams-Leitfaden.

Wenn Sie eine API mit rollenbasierten Berechtigungen testen, nutzen Sie für jede Rolle ein eigenes Credential. Ein Admin-Token und ein Betrachter-Token können unter Last andere Codepfade und andere Latenzen zeigen, und eine fehlgeschlagene Berechtigungsprüfung sollte sauber 403 liefern, nicht 500. Maschinenzugriff läuft meist über einen API-Schlüssel. Mehr dazu unter API-Sicherheit und im Leitfaden API-Performance-Tests mit OAuth2 (auf Englisch) für authentifizierte Läufe. Mit API Monitoring prüfen Sie geschützte Endpunkte nach dem Release weiter.

Häufige Fragen

RBAC oder ABAC: was soll ich nutzen?

Nutzen Sie RBAC, wenn Berechtigungen stabilen Funktionen folgen, das trifft auf die meisten Anwendungen zu. Nutzen Sie ABAC, wenn der Zugriff von Attributen wie Abteilung, Region oder Uhrzeit abhängt. Viele Systeme kombinieren beides: Rollen für das Grobe, Attribute für die Ausnahmen.

Kann ein Nutzer mehrere Rollen haben?

Ja. In den meisten RBAC-Systemen kann ein Nutzer mehrere Rollen halten. In Kubernetes sind Berechtigungen additiv, der Nutzer erhält also die Summe aller Rollen, ohne dass sich etwas abziehen lässt.

Was ist Rollenexplosion?

So nennt man es, wenn für jede Ausnahme eine neue Rolle entsteht, bis es zu viele sind, um sie zu verstehen oder zu prüfen. Meist ist das ein Zeichen, dass Sie für die Ausnahmen attributbasierte Regeln brauchen oder sich überlappende Rollen bereinigen sollten.

Ersetzt RBAC die Authentifizierung?

Nein. Die Authentifizierung belegt, wer jemand ist, RBAC entscheidet, was diese Identität darf. Sie brauchen beides.

Welche Rollen gibt es in LoadFocus-Teams?

Teammitglieder werden als Admin eingeladen, der Tests ausführen, bearbeiten und ansehen darf, oder als View-only, der Tests nur ansehen darf. Zusätzlich lässt sich ein Mitglied auf bestimmte LoadFocus-Produkte beschränken.