RBAC (Role-Based Access Control)

Standard in fast jeder Business-Software.

• Editor: Darf Artikel schreiben.
• Publisher: Darf Artikel veröffentlichen.
• Admin: Darf User löschen. Ein User kann mehrere Rollen haben.

1. Role Explosion

Der Nachteil. "Ich brauche einen Admin, der aber nicht User löschen darf, aber in Projekt A schreiben darf." -> Rolle: Admin_NoDelete_ProjectA. Irgendwann hast du 1000 Rollen für 500 Mitarbeiter. Niemand blickt mehr durch. Lösung: Hierarchische Rollen oder ABAC.

2. Separation of Duties (SoD)

Eine Regel: "Niemand darf die Rolle 'Einkäufer' UND 'Rechnungsprüfer' gleichzeitig haben." RBAC kann solche giftigen Kombinationen verbieten, um Betrug zu verhindern.

1. Role Explosion & The ReAC Alternative

In exponentiell skalierenden SaaS-Produkten scheitert RBAC gnadenlos. Wenn du eine B2B-Plattform baust, fängt es simpel an ("Admin", "Editor"). Dann fordert Kunde Siemens: "Unser Admin darf nur Rechnungen aus Deutschland sehen, nicht aber Projekt X löschen." Du erschaffst die Rolle Admin_DE_NoProjX. Nach 2 Jahren hat deine Datenbank $500$ User und $800$ maßgeschneiderte Rollen ("Role Explosion"). Da die Rollen starr sind (Static Assignment), ist der Audit-Trail eine Katastrophe. Moderne Systeme flüchten sich in ReBAC (Relationship-Based Access Control, wie in Google Zanzibar). In ReBAC existiert keine Rolle Admin_DE. Der User erbt Rechte durch Graphen-Beziehungen ("Bob $\rightarrow$ gehört zu Gruppe X $\rightarrow$ ist Viewer von Folder Y $\rightarrow$ beinhaltet Document Z"). Die Zugriffsprüfung ist ein O(1) Graph-Traversal, kein statischer DB Lookup.

2. Time-of-Check to Time-of-Use (Session Revocation)

Ein klassischer RBAC-Fehler ist Caching in verteilten Systemen. Beim Login lädt das Backend die Rollen des Users aus der Datenbank in den JWT (JSON Web Token), z. B. role: "admin". Der JWT ist 2 Stunden gültig. Der User macht 10 Minuten später etwas Illegales, der Superadmin entzieht ihm in der Datenbank die Admin-Mütze (!). Das Problem: Der JWT im Browser des gebannten Users lügt weiterhin role: "admin", und die Microservices vertrauen dem Token blind (da kryptografisch signiert)! Der User hat faktisch noch 1 Stunde und 50 Minuten Admin-Rechte (Time-of-Use verfehlt Time-of-Check). Die Architektur muss zwingend ein JWT-Blacklisting via API-Gateway/Redis aufbauen oder die TTL (Time to live) drastisch auf z.B. 5 Minuten shorten, um sichere Revocation zu gewährleisten.

3. Dual Control & Segregation of Duties (SoD)

Im Enterprise- und Fintech-Sektor reicht simples "Glaube dem Admin" nicht aus ("Wer überwacht die Wächter?"). Professionelles RBAC erzwingt die Segregation of Duties (Funktionstrennung). Die Business Rule verbietet auf Datenbank-Level, dass ein Account gleichzeitig die Rollen Invoice_Creator UND Invoice_Approver besitzt (Toxic Combinations). Um interne Fraud-Versuche durch Superadmins zu verhindern, nutzt man "Dual Control" (4-Augen-Prinzip): Ein Admin darf zwar die Datenbank resetten, der RBAC-Kernel triggert dabei aber ein "Pending-State-Approval" und verlangt mathematisch die kryptografische Freigabe eines zweiten Admin-Accounts, bevor das Commit in der Linux-Ebene durchgeführt wird.