Wie moderne Anwendungen Rollen und Berechtigungen verwalten
Ihr Benutzer kann ein Dokument einsehen. Aber kann er es auch teilen? Kann er es mit jedem teilen oder nur innerhalb seiner Organisation? Kann er erteilte Zugriffsrechte widerrufen? Diese Fragen zeigen, warum traditionelle rollenbasierte Zugriffskontrolle in modernen Anwendungen an ihre Grenzen stößt.
Statische Rollen wie „Admin”, „Editor” und „Viewer” funktionierten, als Anwendungen noch einfacher waren. Heutige kollaborative, mandantenfähige SaaS-Produkte benötigen etwas Flexibleres. Dieser Artikel erklärt, wie moderne Autorisierungsmuster diese Herausforderungen lösen und warum die Branche über das reine Rollen-Denken hinaus zu feingranularer Autorisierung übergegangen ist.
Wichtigste Erkenntnisse
- Traditionelles RBAC hat Schwierigkeiten mit dynamischen, beziehungsbasierten Berechtigungen und führt in komplexen Anwendungen zu einer Rollenexplosion
- ReBAC bestimmt den Zugriff über Beziehungen zwischen Entitäten und macht Teilen und Zusammenarbeit zu Konzepten erster Klasse
- ABAC bewertet den Zugriff basierend auf Benutzer-, Ressourcen- und Kontextattributen für kontextabhängige Regeln
- Die meisten Produktivsysteme kombinieren RBAC für übergeordnete Kategorien mit ReBAC für Berechtigungen auf Ressourcenebene
- Policy-as-Code-Ansätze machen Autorisierungslogik testbar, auditierbar und versionskontrolliert
Warum traditionelles RBAC nicht ausreicht
Role-Based Access Control (RBAC) weist Berechtigungen über Rollen zu. Ein Benutzer erhält die Rolle „Editor”, die ihm einen vordefinierten Satz von Berechtigungen gewährt. Einfach und intuitiv.
Das Problem entsteht, wenn Anwendungen wachsen. Betrachten Sie ein Projektmanagement-Tool, bei dem Benutzer unterschiedliche Zugriffsebenen pro Projekt, pro Workspace und pro Dokumenttyp benötigen. Sie beginnen, Rollen wie „Projekt-A-Editor” und „Workspace-B-Admin” zu erstellen. Diese Rollenexplosion macht das System unüberschaubar.
RBAC hat auch Schwierigkeiten mit beziehungsbasierten Fragen. „Kann dieser Benutzer dieses Dokument bearbeiten?” hängt davon ab, ob er es besitzt, ob jemand es mit ihm geteilt hat oder ob er zu einem Team gehört, das Zugriff hat. Statische Rollen können diese Bedingungen nicht elegant ausdrücken.
Moderne Autorisierungsmuster
Relationship-Based Access Control (ReBAC)
ReBAC bestimmt den Zugriff über Beziehungen zwischen Entitäten. Anstatt zu fragen „hat dieser Benutzer die Editor-Rolle?”, fragen Sie „hat dieser Benutzer eine Editor-Beziehung zu diesem Dokument?”
Googles Zanzibar-System war Pionier für diesen Ansatz im großen Maßstab. Wenn Sie ein Google Doc teilen, erstellen Sie eine Beziehung. Das System durchläuft dann diese Beziehungen, um Berechtigungsfragen zu beantworten. Tools wie OpenFGA, SpiceDB und Permify implementieren Zanzibar-inspirierte Modelle für Anwendungen jeder Größe.
ReBAC behandelt kollaborative Szenarien auf natürliche Weise. Teilen, Teammitgliedschaft und Organisationshierarchien werden zu Konzepten erster Klasse statt zu umständlichen Rollen-Workarounds.
Attribute-Based Access Control (ABAC)
ABAC bewertet den Zugriff basierend auf Attributen von Benutzern, Ressourcen und Kontext. Eine Richtlinie könnte besagen: „Benutzer können auf Dokumente zugreifen, wenn ihre Abteilung mit der Abteilung des Dokuments übereinstimmt und die Anfrage während der Geschäftszeiten erfolgt.”
Dieses Modell eignet sich hervorragend für kontextabhängige Regeln. Gesundheitsanwendungen verwenden ABAC zur Durchsetzung von HIPAA-Anforderungen – der Zugriff hängt von der Patienten-Anbieter-Beziehung, der Datensensibilität und dem Zugriffskontext ab.
RBAC vs. ReBAC: Wann welches verwenden?
RBAC bleibt für Anwendungen mit klaren, statischen Berechtigungsgrenzen geeignet. Interne Tools mit klar definierten Benutzertypen profitieren von seiner Einfachheit.
ReBAC passt besser, wenn Berechtigungen von Ressourcenbesitz, Teilen oder Organisationsstruktur abhängen. Jede Anwendung mit „Teilen”-Funktionalität oder Mandantenfähigkeit sollte ReBAC in Betracht ziehen.
Die meisten Produktivsysteme kombinieren beides. RBAC behandelt übergeordnete Kategorien (Admin vs. normaler Benutzer), während ReBAC Berechtigungen auf Ressourcenebene verwaltet.
Discover how at OpenReplay.com.
Architekturmuster für Zugriffskontrolle in Webanwendungen
Trennung von Authentifizierung und Autorisierung
Authentifizierung beantwortet „wer ist dieser Benutzer?” Autorisierung beantwortet „was darf er tun?” Moderne Architekturen behandeln diese als separate Anliegen mit dedizierten Services für jedes.
Ihr Identity Provider übernimmt die Authentifizierung. Ein separater Autorisierungsservice – ob selbst entwickelt oder verwaltet – übernimmt Berechtigungsentscheidungen. Diese Trennung ermöglicht es jedem System, sich unabhängig weiterzuentwickeln.
Policy-as-Code
Moderne Autorisierungsmuster bevorzugen es, Regeln als Code statt als Datenbankkonfigurationen auszudrücken. Policy-as-Code bedeutet, dass Ihre Autorisierungslogik in der Versionskontrolle lebt, in Pull Requests überprüft wird und über Ihre Standard-Pipeline bereitgestellt wird.
Open Policy Agent (OPA) verwendet Rego für Richtliniendefinitionen. Cedar, entwickelt von AWS, bietet eine weitere Policy-Sprache. Diese Tools machen Autorisierungslogik testbar und auditierbar.
Zentralisierte Richtlinien, verteilte Durchsetzung
Das Muster, das skaliert: Definieren Sie Richtlinien zentral, setzen Sie sie bei jedem Service durch. Ihre Policy Engine verwaltet die Regeln. Jeder Microservice fragt die Engine nach Berechtigungsentscheidungen ab und cached oft Ergebnisse für bessere Performance.
Diese Architektur hält die Autorisierung über Services hinweg konsistent und vermeidet gleichzeitig einen Single Point of Failure.
Frontend-Implikationen
Das Backend bleibt die einzige Quelle der Wahrheit für alle Berechtigungsentscheidungen. Vertrauen Sie niemals dem Frontend für Sicherheit.
Dennoch benötigen Frontends Berechtigungsinformationen für gute UX. Feature Gating – das Ausblenden von Schaltflächen, die Benutzer nicht klicken können, das Deaktivieren von Formularen, die sie nicht absenden können – erfordert clientseitige Kenntnis von Berechtigungen. Das Muster ist einfach: Verwenden Sie Berechtigungsprüfungen (z. B. „kann dieser Benutzer diese Aktion ausführen?”) für UI-Entscheidungen, validieren Sie aber immer auf dem Server.
Bibliotheken wie CASL helfen bei der Verwaltung clientseitiger Berechtigungslogik, während die eigentliche Durchsetzung serverseitig bleibt.
Fazit
Feingranulare Autorisierung ist nicht experimentell – so funktionieren moderne Anwendungen. Google, GitHub und Notion verwenden alle beziehungsbasierte Modelle. Policy Engines treiben die Autorisierung in Unternehmen jeder Größe an.
Beginnen Sie damit, zu identifizieren, wo Ihr aktuelles RBAC an Grenzen stößt. Wenn Sie für jede Berechtigungskombination Rollen erstellen oder wenn sich Teilen und Zusammenarbeit nachträglich angebaut anfühlen, werden moderne Autorisierungsmuster Ihr System vereinfachen und gleichzeitig leistungsfähiger machen.
Der Wechsel von „welche Rolle hat dieser Benutzer?” zu „welche Beziehung hat dieser Benutzer zu dieser Ressource?” verändert, wie Sie über Berechtigungen denken. Es ist ein besseres mentales Modell dafür, wie Benutzer tatsächlich mit modernen Anwendungen interagieren.
Häufig gestellte Fragen
RBAC weist Berechtigungen über statische Rollen wie Admin oder Editor zu. ReBAC bestimmt den Zugriff über Beziehungen zwischen Benutzern und Ressourcen. Während RBAC fragt hat dieser Benutzer die Editor-Rolle, fragt ReBAC hat dieser Benutzer eine Editor-Beziehung zu diesem spezifischen Dokument. ReBAC behandelt dynamisches Teilen und Zusammenarbeit natürlicher.
Ja, die meisten Produktivsysteme kombinieren beide Ansätze. RBAC behandelt typischerweise übergeordnete Berechtigungskategorien wie die Unterscheidung zwischen Admins und normalen Benutzern. ReBAC verwaltet Berechtigungen auf Ressourcenebene wie Dokumentenfreigabe und Teamzugriff. Dieser Hybridansatz bietet Ihnen Einfachheit für globale Berechtigungen und Flexibilität für ressourcenspezifische Zugriffskontrolle.
Authentifizierung identifiziert, wer der Benutzer ist, während Autorisierung bestimmt, was er tun darf. Die Trennung dieser Anliegen ermöglicht es jedem System, sich unabhängig weiterzuentwickeln. Ihr Identity Provider übernimmt Login und Identitätsverifizierung. Ein dedizierter Autorisierungsservice verwaltet Berechtigungsentscheidungen. Diese Trennung verbessert die Wartbarkeit und ermöglicht es Ihnen, jede Komponente auszutauschen oder zu aktualisieren, ohne die andere zu beeinflussen.
Setzen Sie Berechtigungen immer im Backend durch. Der Server ist die einzige Quelle der Wahrheit für alle Zugriffskontrollentscheidungen. Frontends benötigen jedoch Berechtigungsdaten für gute Benutzererfahrung, wie das Ausblenden nicht verfügbarer Schaltflächen oder das Deaktivieren eingeschränkter Formulare. Laden Sie effektive Berechtigungen beim Seitenaufruf für UI-Entscheidungen, validieren Sie aber jede Aktion serverseitig.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
