Role-Based Access Control (RBAC): Definition, Beispiele, Best Practices
RBAC granted Permissions an Roles, dann assigniert User zu Roles. Skaliert besser als per-User Permissions; fundamental für moderne IAM.
Was ist Role-Based Access Control (RBAC)?
Role-Based Access Control (RBAC) ist ein Access-Control-Modell, bei dem Permissions an Roles (z.B. "Admin", "Editor", "Viewer") granted werden und User Roles assigniert werden. Statt Permissions an jeden User individuell zu granten, granted man sie an Roles, dann packt man User in Roles.
RBAC ist das Fundament von moderner IAM.
RBAC-Core-Konzepte
| Konzept | Beschreibung |
|---|---|
| User | Eine Identity |
| Role | Eine benannte Sammlung von Permissions |
| Permission | Eine Action allowed auf einer Resource |
| Role-Assignment | User mit Role verlinken |
| Role-Hierarchy | Roles können von anderen inheritan |
| Constraints | Rules limiting Role-Assignment |
Beispiel: SaaS-App-RBAC
# Roles
admin: [users.create, users.delete, billing.view, billing.edit]
editor: [content.create, content.edit, content.publish]
viewer: [content.view]
# User-Assignments
alice@example.com: [admin]
bob@example.com: [editor]RBAC vs ABAC vs ACL
| Modell | Decision basiert auf | Am besten für |
|---|---|---|
| RBAC | User's Role(n) | Die meisten Apps |
| ABAC | Attributes | Fine-grained dynamic Policies |
| ACL | Per-Resource User-Permissions | Wenige Resources |
| PBAC | Zentralisierter Policy-Engine | Modern, decoupled |
RBAC in Major-Systemen
| System | RBAC-Implementation |
|---|---|
| AWS IAM | Roles + managed Policies |
| Kubernetes | Roles, ClusterRoles, RoleBindings |
| Azure RBAC | Built-in + Custom-Roles |
| Google Cloud IAM | Predefined + Custom-Roles |
| GitHub | Org/Repo-Roles + Teams |
| Slack | Workspace-Roles + Channel-Roles |
| Salesforce | Profiles + Permission-Sets |
Kubernetes-RBAC-Beispiel
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]RBAC Best Practices
- Least Privilege.
- Separation of Duties.
- Role-Count limitieren.
- Role-Hierarchy careful nutzen.
- Role-Assignments quartalsweise auditen.
- Jede Role dokumentieren.
- "Super Admin"-Sprawl vermeiden.
- Groups für Assignment nutzen.
- Just-in-Time-Elevation.
- Role-Changes loggen.
Häufige RBAC-Fallstricke
- Role-Explosion.
- Permission-Creep.
- Zu wenige Roles.
- Roles an Job-Titles gebunden.
- Vergessene Role-Assignments.
- Role-based, aber ACLs underneath.
- Kein Audit-Trail.
- Hardcoded Role-Checks.
RBAC vs andere Authorization-Patterns
Wann RBAC genug ist
- Predictable Roles
- Permissions hängen nicht von Resource-Attributes ab
- 10-50 Roles passen zu Ihrer Org
Wann ABAC stattdessen
- Permissions hängen von Attributes ab
- Multi-Tenant-SaaS
- Fine-grained
- Conditional-Access nötig
FAQ: RBAC
RBAC vs ABAC: was nutzen?
RBAC für klare stable Roles. ABAC für fine-grained.
Wie viele Roles sind zu viele?
10-30 ist Sweet-Spot.
Sollte ich Kubernetes RBAC oder Service-Mesh nutzen?
Beide.
Was ist Role-Hierarchy?
Roles können von anderen Roles inheritan.
Wie migriere ich von ACLs zu RBAC?
Common Access-Patterns identifizieren, in Roles gruppieren.
Sind Roles dasselbe wie Groups?
Manchmal synonym genutzt. Strict: Groups = Sammlungen von Usern; Roles = Sammlungen von Permissions.
Wie related RBAC zu SSO?
SSO authentifiziert. RBAC authorisiert.
RBAC-protected APIs mit LoadFocus testen
LoadFocus läuft JMeter- und k6-Scripts, die User mit verschiedenen Roles simulieren. Registrieren bei loadfocus.com/signup.
Verwandte LoadFocus-Tools
Setze dieses Konzept mit LoadFocus in die Praxis um — derselben Plattform, die alles antreibt, was du gerade gelesen hast.