Sobald ein SaaS-Produkt von mehreren Personen pro Kunde genutzt wird, stellt sich die Frage der Autorisierung: Wer darf was? Role-Based Access Control (RBAC) ist die Standardantwort — ein Modell, das Berechtigungen nicht einzelnen Nutzern, sondern Rollen zuordnet, denen Nutzer dann zugewiesen werden. Klingt einfach, ist aber eine der Stellen, an denen frühe Designentscheidungen langfristig teuer werden, wenn man sie falsch trifft. Dieser Leitfaden fasst zusammen, wie wir RBAC in Multi-Tenant-Produkten aufbauen.
Authentifizierung ist nicht Autorisierung
Eine grundlegende Trennung vorweg: Authentifizierung beantwortet «Wer bist du?», Autorisierung beantwortet «Was darfst du?». RBAC betrifft ausschliesslich die zweite Frage. Vermischt man beides — etwa indem man Berechtigungen im Login-Token hartcodiert, ohne ein sauberes Rechtemodell dahinter — entsteht ein System, das sich kaum mehr ändern lässt. Behandeln Sie Autorisierung als eigene, zentrale Schicht, die bei jeder geschützten Aktion konsultiert wird.
Die Bausteine: Berechtigung, Rolle, Zuweisung
Ein sauberes Modell trennt drei Ebenen. Berechtigungen (Permissions) sind die kleinste Einheit — atomare Rechte wie «Rechnung lesen», «Nutzer einladen», «Projekt löschen». Rollen bündeln Berechtigungen zu sinnvollen Paketen — etwa «Admin», «Mitglied», «Betrachter». Zuweisungen verbinden Nutzer mit Rollen, im Multi-Tenant-Kontext immer im Bezug auf einen bestimmten Mandanten. Der entscheidende Designgrundsatz: Prüfen Sie im Code immer gegen Berechtigungen, nie gegen Rollennamen. Eine Abfrage wie «hat dieser Nutzer die Berechtigung, Rechnungen zu lesen?» bleibt stabil, auch wenn Sie die Rollenstruktur später umbauen; eine Abfrage «ist dieser Nutzer Admin?» bricht, sobald eine neue Rolle dieselbe Berechtigung braucht.
Mandantenbezug ist Pflicht
Im Multi-Tenant-SaaS hat jede Berechtigungsprüfung einen Mandantenkontext. Ein Nutzer kann in Mandant A Administrator und in Mandant B nur Betrachter sein. Die Rollenzuweisung gehört also an die Verbindung von Nutzer und Mandant, nicht an den Nutzer global. Vergisst man das, entstehen die gefährlichsten Sicherheitslücken überhaupt: Ein Nutzer sieht oder ändert Daten eines fremden Mandanten. Die Autorisierungsschicht muss bei jeder Anfrage prüfen, ob der Nutzer die Berechtigung für genau diesen Mandanten und diese Ressource hat. Auf Datenbankebene ergänzen Mechanismen wie Row-Level Security diese Prüfung als zweite Verteidigungslinie.
Custom Roles: Fluch und Segen
Früher oder später fragen grössere Kunden nach eigenen, frei definierbaren Rollen. Das ist ein starkes Verkaufsargument, aber auch eine Komplexitätsfalle. Bevor Sie Custom Roles bauen, klären Sie: Brauchen die meisten Kunden das wirklich, oder genügen drei bis vier gut durchdachte Standardrollen? In der Praxis decken wenige durchdachte Standardrollen den überwiegenden Bedarf ab. Wenn Custom Roles nötig sind, bauen Sie sie auf demselben Permission-Fundament auf — eine Custom Role ist dann nur eine kundendefinierte Bündelung vorhandener Berechtigungen, keine neue Logik.
Häufige Fehler
Erstens: gegen Rollennamen statt Berechtigungen prüfen — der Klassiker, der jede spätere Änderung zur Bruchstelle macht. Zweitens: fehlender Mandantenbezug, mit dem Risiko mandantenübergreifender Zugriffe. Drittens: keine Default-Deny-Logik — wenn eine Berechtigung nicht explizit erteilt ist, muss die Antwort «nein» lauten, nicht «ja». Viertens: die Autorisierung nur im Frontend zu prüfen; das Frontend kann jeder umgehen, die verbindliche Prüfung gehört ins Backend. Fünftens: keine Berücksichtigung von Berechtigungsänderungen zur Laufzeit — entzieht man einem Nutzer eine Rolle, muss das unmittelbar wirken, nicht erst nach dem nächsten Login.
Audit und Nachvollziehbarkeit
Berechtigungen sind sicherheits- und oft auch compliance-relevant. Führen Sie ein Audit-Log darüber, wer wem wann welche Rolle erteilt oder entzogen hat. Das ist nicht nur für die Fehlersuche wertvoll, sondern auch für Sicherheitsaudits und für Kunden mit eigenen Compliance-Anforderungen, die nachweisen müssen, wer Zugriff auf welche Daten hatte. Ein nachvollziehbares Berechtigungssystem ist ein Verkaufsargument im Enterprise-Segment.
Fazit
Ein gutes RBAC-Modell ist unsichtbar, wenn es funktioniert, und katastrophal, wenn es fehlt. Trennen Sie Authentifizierung von Autorisierung, prüfen Sie immer gegen Berechtigungen statt gegen Rollennamen, verankern Sie den Mandantenbezug in jeder Prüfung, halten Sie die Standardrollen schlank und erzwingen Sie Default-Deny im Backend. Wer dieses Fundament früh richtig legt, kann es über Jahre erweitern — wer es falsch legt, baut es irgendwann unter Schmerzen neu. Investieren Sie die Sorgfalt am Anfang; sie zahlt sich bei jeder neuen Funktion aus.
ABAC als Ergänzung für feinere Fälle
RBAC stösst an Grenzen, wenn Berechtigungen von Attributen abhängen, die keine Rolle abbildet — etwa «darf nur eigene Datensätze bearbeiten» oder «Zugriff nur während der Geschäftszeiten». Hier ergänzt Attribute-Based Access Control (ABAC) das Rollenmodell: Entscheidungen berücksichtigen zusätzlich Eigenschaften des Nutzers, der Ressource und des Kontexts. In der Praxis bewährt sich eine Kombination — RBAC als grobes Gerüst für die Hauptfälle, ergänzt um wenige attributbasierte Regeln für die feinen. Überziehen Sie ABAC aber nicht; ein Regelwerk, das niemand mehr durchschaut, ist eine eigene Sicherheitslücke.
Planen Sie schliesslich von Anfang an für die Migration. Berechtigungsmodelle wachsen mit dem Produkt, und früher oder später müssen Sie Rollen umbenennen, aufteilen oder zusammenlegen. Wenn Ihr Code konsequent gegen Berechtigungen statt gegen Rollennamen prüft, sind solche Umbauten beherrschbar: Sie ändern die Bündelung der Berechtigungen in Rollen, ohne eine einzige Code-Prüfung anfassen zu müssen. Diese Entkopplung ist der eigentliche Wert eines sauberen RBAC-Designs — sie macht das System über Jahre wartbar, statt es mit jeder neuen Funktion brüchiger werden zu lassen.