Design der rollenbasierten Zugriffskontrolle: Ein praxisnaher Leitfaden
Designen Sie eine rollenbasierte Zugriffskontrolle, indem Sie mit Berechtigungen statt mit Rollen beginnen.
Design der rollenbasierten Zugriffskontrolle: Ein praxisnaher Leitfaden
Entwerfen Sie eine rollenbasierte Zugriffskontrolle, indem Sie mit Berechtigungen statt mit Rollen beginnen. Zählen Sie jedes resource:action Paar auf, das Ihr System tatsächlich benötigt, gruppieren Sie diese Berechtigungen in Rollen, die echten Aufgabenbereichen entsprechen, und erzwingen Sie jede Prüfung über eine zentrale can(user, action, resource) Funktion. Diese Reihenfolge ist wichtiger als jedes Diagramm, das Sie zeichnen. Systeme, die mit Rollen statt mit Berechtigungen beginnen, leiden innerhalb eines Jahres häufig unter einer Rollenexplosion, abweichenden Berechtigungen und Audit-Trails, denen niemand vertraut.
Dieser Ansatz skaliert, weil Berechtigungen stabil sind (eine Rechnung kann noch lange nach einer Änderung Ihres Organigramms „erstellt“ oder „storniert“ werden), während Rollen nur praktische Bündel sind, die Sie umbenennen, aufteilen oder zusammenführen können, ohne den Code zur Durchsetzung anzufassen. Durch die Zentralisierung der Prüfung befinden sich auch Ihre Caching-, Protokollierungs- und Widerrufslogik an einer Stelle statt verteilt über ein Dutzend „if user.role == ‘admin’“-Prüfungen, deren Aktualisierung jemand vergessen wird.
Bevor Sie weiterlesen, erledigen Sie diese drei Dinge:
-
Erfassen Sie jede Berechtigung, die Ihre Anwendung derzeit explizit oder implizit prüft.
-
Schreiben Sie eine
can()Funktion und leiten Sie ein einzelnes Feature darüber. -
Legen Sie für Ihre häufigsten Aufgabenbereiche drei bis fünf Rollen an und weisen Sie Testbenutzer zu.
Wichtigste Erkenntnisse
Ein skalierbares Design der rollenbasierten Zugriffskontrolle beruht auf einer Berechtigungsmodellierung nach dem Permissions-first-Prinzip, mandantenbezogenen Rollen und einem zentralen Durchsetzungspfad, der effizient cached und jede Entscheidung protokolliert.
| Punkt | Details |
|---|---|
| Modellieren Sie Berechtigungen vor Rollen | Erfassen Sie zunächst kleine, kombinierbare resource:action Berechtigungen und gruppieren Sie sie anschließend in Rollen für konkrete Aufgabenbereiche. |
| Verwenden Sie ein Schema mit fünf Tabellen | Berechtigungen, Rollen, Rollen_Berechtigungen, Benutzer und Benutzer_Rollen decken die meisten RBAC-Anforderungen in mandantenfähigen Systemen ab. |
| Zentralisieren Sie die Durchsetzung | Leiten Sie jede Zugriffsprüfung über eine zentrale can() Funktion oder einen Policy-Service, mit kurzen TTLs und Cache-Invalidierung bei Widerrufen. |
| Beschränken Sie Rollen auf Mandanten | Denormalisieren Sie die Mandanten_ID und legen Sie Rollen pro Mandant an, um eine Berechtigungsexplosion bei wachsendem Umfang zu verhindern. |
| Fügen Sie ABAC für Ausnahmen hinzu | Ergänzen Sie RBAC um attribut- oder beziehungsbasierte Regeln, sobald der Kontext und nicht nur der Aufgabenbereich relevant wird. |
| Holen Sie sich Architekturhilfe, wenn es darauf ankommt | Ridiculousengineering unterstützt RBAC-Designs, Migrationen und Governance-Reviews für Teams, die eine veraltete Zugriffskontrolle modernisieren. |
Inhaltsverzeichnis
-
Was ist das Design einer rollenbasierten Zugriffskontrolle und wann sollten Sie es einsetzen?
-
Welches RBAC-Modell eignet sich für flache, hierarchische oder eingeschränkte Zugriffe?
-
Wie sieht eine schrittweise Checkliste für die RBAC-Implementierung aus?
-
Wann sollten Sie RBAC zugunsten von ABAC oder ReBAC hinter sich lassen?
-
Wie testen, prüfen und migrieren Sie veraltetes RBAC sicher?
-
Welche Anti-Patterns treten bei RBAC in der Produktion am häufigsten auf?
Was ist das Design einer rollenbasierten Zugriffskontrolle und wann sollten Sie es einsetzen?
Rollenbasierte Zugriffskontrolle (RBAC) gewährt Zugriff auf Grundlage der Rolle eines Benutzers und nicht seiner individuellen Identität. Das NIST-RBAC-Referenzmodell definiert die Kernelemente, die jede reale Implementierung benötigt: Benutzer (oder Principals), Rollen, Berechtigungen, Ressourcen und Rollenzuweisungen, die diese Elemente verbinden. Berechtigungen werden Rollen und nicht Personen zugewiesen; Benutzer erben alle Berechtigungen, die ihre zugewiesenen Rollen erlauben.
RBAC eignet sich besonders für folgende Situationen:
-
Mandantenfähige SaaS-Produkte, bei denen der Aufgabenbereich (Eigentümer, Bearbeiter, Betrachter) bestimmt, worauf ein Benutzer zugreifen kann.
-
Unternehmenssysteme mit klarer Organisationsstruktur und eindeutig definierten Stellenbezeichnungen.
-
Regulierte oder geprüfte Umgebungen, in denen Sie nachweisen müssen, wer wann auf was zugreifen konnte.
Die entscheidende Frage ist einfach: Wenn allein der Aufgabenbereich den Zugriff bestimmt, ist RBAC das richtige Modell. Wenn der Zugriff zusätzlich vom Kontext abhängt, etwa von Tageszeit, Ressourceneigentum oder Gerätevertrauen, ist ein Hybridmodell mit attributbasierten Regeln über RBAC die bessere Wahl. Die eigene Dokumentation von NIST weist darauf hin, dass RBAC zum Branchenstandard wurde, weil es die bereits übliche Arbeitsverteilung in Organisationen abbildet.
Welche Designprinzipien halten RBAC wartbar?
Jedes RBAC-System wirkt am ersten Tag sauber. Was diejenigen unterscheidet, die auch im dritten Jahr noch verständlich sind, ist Disziplin in fünf Bereichen.
Berechtigungsorientierte Modellierung. Erfassen Sie kleine, kombinierbare Berechtigungen wie invoice:create oder report:export bevor Sie irgendetwas zu einer Rolle gruppieren. Die Empfehlungen von Security Boulevard zu skalierbarem RBAC sind diesbezüglich unmissverständlich: Aus vagen, übergroßen Berechtigungen gebildete Rollen sind die Hauptursache der meisten RBAC-Probleme.
Prinzip der geringsten Rechte, an den Aufgabenbereich gebunden. Eine Rolle repräsentiert einen Aufgabenbereich, niemals eine bestimmte Person. Wenn Sie eine Rolle nach einem Mitarbeiter benennen möchten, halten Sie inne. Das ist eine personenspezifische Bindung im Rollengewand.
-
Beschränken Sie Rollen nach Ressource, Mandant oder Arbeitsbereich, statt für jede kontextuelle Abweichung eine neue Rolle zu erstellen.
-
Halten Sie Hierarchien flach. Zwei oder drei Vererbungsebenen reichen aus; alles Weitere wird unleserlich.
-
Kodieren Sie Richtlinien als versionierten, überprüfbaren Code statt als Kontrollkästchen in einer Administrationskonsole, die niemand nachverfolgt.
-
Verwenden Sie für sensible Vorgänge eine Just-in-time- oder zeitlich begrenzte Rechteerhöhung und erzwingen Sie für finanzielle oder zerstörerische Aktionen eine Aufgabentrennung.
Profi-Tipp: Wenn eine Rolle mehr als eine Handvoll Ausnahmen nach dem Muster „nur noch diese eine zusätzliche Berechtigung“ angesammelt hat, repräsentiert sie keinen Aufgabenbereich mehr. Lagern Sie die Ausnahme in eine bereichsbezogene Berechtigung oder eine separate Rolle aus, statt die ursprüngliche Rolle immer weitere Einzelfälle aufnehmen zu lassen.
Welches RBAC-Modell eignet sich für flache, hierarchische oder eingeschränkte Zugriffe?
Nicht jedes System benötigt dieselbe RBAC-Variante. Vier Varianten decken nahezu jeden realen Anwendungsfall ab:
-
Flaches RBAC: Jede Rolle ist ein unabhängiges Berechtigungsbündel ohne Vererbung. Leicht verständlich, aber mit zunehmender Rollenzahl kommt es zu Duplikaten.
-
Hierarchisches RBAC: Rollen erben Berechtigungen von übergeordneten Rollen (eine Managerrolle erbt alle Berechtigungen einer Mitarbeitendenrolle). Theoretisch übersichtlich, aber unerwartete Vererbung ist eine häufige Ursache für Rechteausweitungen.
-
Eingeschränktes RBAC: Fügt Regeln zum gegenseitigen Ausschluss hinzu, sodass ein Benutzer keine zwei Rollen innehaben kann, die zusammen gegen die Aufgabentrennung verstoßen, etwa „Zahlung einreichen“ und „Zahlung genehmigen“.
-
Hybrides RBAC+ABAC: Rollen übernehmen grobkörnige Freigaben; Attributrichtlinien behandeln die Ausnahmen (Tageszeit, Ressourceneigentum, Geografie).
Der Zielkonflikt besteht zwischen Verständlichkeit und Duplikation. Flache Modelle sind einfach zu prüfen, wiederholen aber Berechtigungen über mehrere Rollen hinweg. Hierarchien reduzieren Wiederholungen, verbergen jedoch die tatsächliche Berechtigungsmenge über mehrere Ebenen. Beginnen Sie mit flachen oder flachen Hierarchien und greifen Sie nur dann zu Attributrichtlinien, wenn eine echte Ausnahme dies erfordert, statt für jeden Sonderfall eine neue Rolle zu erstellen.
Wie sieht eine schrittweise Checkliste für die RBAC-Implementierung aus?
Behandeln Sie RBAC als Einführung in mehreren Phasen und nicht als Schalter, den Sie an einem Freitagnachmittag umlegen.
-
Erfassen Sie jede Ressource und Aktion Ihrer Anwendung, einschließlich Hintergrundjobs und API-only-Endpunkten.
-
Ordnen Sie Aufgabenbereiche den Berechtigungen zu, die sie tatsächlich benötigen, nicht den Berechtigungen, die jemand „vorsichtshalber“ anfordern könnte.
-
Stellen Sie Rollen zusammen aus diesen Berechtigungen und streben Sie eine Anzahl an, die Sie aus dem Gedächtnis aufzählen könnten.
-
Beschränken Sie Zuweisungen auf Mandanten, Arbeitsbereiche oder Ressourcen, statt neue Rollen zu erstellen.
-
Implementieren Sie eine zentrale Durchsetzung über eine einzige
can()Funktion oder einen Policy-Service, niemals über verstreute Rollenprüfungen. -
Fügen Sie Caching hinzu für abgeflachte Berechtigungsmengen mit einem klaren Invalidierungspfad.
-
Führen Sie die Bereitstellung schrittweise durch: Prototyp, Shadow-Evaluierung mit echtem Datenverkehr, schrittweise Durchsetzung auf risikoarmen Pfaden und anschließend vollständige Umstellung.
Risikominimierung unterscheidet eine reibungslose Einführung von einer Lawine an Supporttickets. Führen Sie ein Audit-Log jeder Berechtigungsprüfung und jeder Rollenänderung. Leeren Sie den Cache sofort bei jedem Widerruf und nicht erst beim nächsten TTL-Zyklus. Bauen Sie einen Notfallprozess mit Break-Glass-Zugriff für den Fall auf, dass das Zugriffssystem selbst eine Reaktion auf einen Vorfall blockiert. Planen Sie regelmäßige Zugriffszertifizierungen ein, damit veraltete Rollen erkannt werden, bevor ein Prüfer sie zuerst findet.
Welches Datenbankschema unterstützt skalierbares RBAC?
Fünf Tabellen decken den überwiegenden Teil der RBAC-Anforderungen in der Produktion ab: permissions, roles, role_permissions, users, und user_roles. Der RBAC-Designleitfaden des Cadence Engineering Blog beschreibt genau dieses Muster mit fünf Tabellen als ausreichend für die meisten mandantenfähigen Systeme, vorausgesetzt, user_roles enthält eine tenant_id Spalte zur Abgrenzung jeder Zuweisung.
Eine typische Berechtigungsprüfung verbindet user_roles mit role_permissions mit permissions, gefiltert nach Mandant, und flacht das Ergebnis anschließend zu einer einzelnen Menge ab, gegen die Ihre Anwendung prüft. Indexieren Sie user_roles nach (user_id, tenant_id) und role_permissions nach role_id, damit der Join selbst bei Millionen von Zeilen schnell bleibt. Cachen Sie die abgeflachte Berechtigungsmenge pro (user, tenant) Paar mit einer kurzen TTL von etwa 60 Sekunden und leeren Sie sie sofort, sobald sich eine Rollenzuweisung ändert.
Fügen Sie Audit-Spalten zu user_roleshinzu: granted_by, granted_at, und idealerweise revoked_at. Diese vier Felder allein beantworten die meisten Compliance-Fragen, bevor jemand sie stellen muss.
| Ansatz | Stärken | Kompromisse |
|---|---|---|
| Relational (fünf Tabellen) | Schnelle Joins, starke referenzielle Integrität, einfache Prüfungen | Erfordert Migrationen, wenn sich das Modell weiterentwickelt |
| Dokumentenbasiert | Flexibles Schema, gut für eingebettete Berechtigungsmengen | Referenzielle Integrität ist schwieriger durchzusetzen, Join-intensive Abfragen werden unübersichtlich |
Wo sollten Sie Zugriffsprüfungen durchsetzen?
Die Architektur der Durchsetzung läuft auf die Wahl zwischen einem zentralen Policy Decision Point (PDP) hinaus, den jeder Dienst aufruft, und Inline-Bibliotheksprüfungen, die über jede Codebasis verteilt sind. Zentralisieren Sie sie. Ein einzelner PDP bietet eine Stelle zur Änderung der Logik, eine Stelle zur Protokollierung von Entscheidungen und eine Stelle für Audits, statt Berechtigungslogik über ein Dutzend Microservices hinweg suchen zu müssen.
-
Cachen Sie abgeflachte Berechtigungsmengen pro
(user, tenant)mit einer kurzen TTL von etwa 60 Sekunden gemäß dem Cadence-RBAC-Leitfaden und invalidieren Sie den Cache, sobald sich eine Rolle ändert. -
Bei tokenbasierten Systemen können Sie Rollen-Claims im JWT oder Sitzungstoken hinterlegen. Behandeln Sie das Token jedoch als Hinweis und nicht als Quelle der Wahrheit für sensible Änderungen, die nach seiner Ausstellung erfolgt sind.
-
Richten Sie Ihr RBAC-Modell an Cloud-IAM-Mustern aus, denen Sie bereits vertrauen: Die Anwendungsempfehlungen von Microsoft Entra zu RBAC zeigen, wie Anwendungsrollen auf Claims abgebildet werden, und AWS-IAM-Rollen folgen auf Infrastrukturebene einer ähnlichen Berechtigungs-zu-Policy-Struktur.
Statistik-Hinweis: Eine Cache-TTL von 60-second, kombiniert mit sofortiger Cache-Invalidierung bei Schreibvorgängen, gleicht Abfragelatenz und das Risiko aus, dass ein widerrufener Benutzer gemäß den RBAC-Schemaempfehlungen des Cadence-Engineering-Teams veralteten Zugriff behält.
Für echte Hybridszenarien, in denen einige Entscheidungen Attribute statt Rollen benötigen, bietet eine Policy-Engine oder ein XACML-ähnliches Profil ein standardisiertes Vokabular, um diese Ausnahmen auszudrücken, ohne eine eigene Regel-Engine zu entwickeln.
Wie steuern Sie den Lebenszyklus von Rollen?
RBAC-Systeme verfallen ohne Verantwortliche. Jede Rolle benötigt einen definierten Lebenszyklus: definieren, genehmigen, zuweisen, prüfen, außer Betrieb nehmen. Eine bestimmte Person ist für jeden Schritt verantwortlich, und jeder Schritt hinterlässt ein Audit-Artefakt.
-
Definieren: Der Rollenverantwortliche entwirft die Berechtigungsmenge und den Aufgabenbereich, den sie repräsentiert.
-
Genehmigen: Ein Sicherheits- oder Plattformverantwortlicher erteilt die Freigabe, bevor die Rolle aktiv wird.
-
Zuweisen: Manager oder delegierte Administratoren gewähren die Rolle bestimmten Benutzern; protokolliert werden dabei
granted_byundgranted_at. -
Prüfen: Eine regelmäßige Zertifizierung, idealerweise vierteljährlich für Rollen mit hohen Berechtigungen, bestätigt, dass jede Zuweisung weiterhin erforderlich ist.
-
Außer Betrieb nehmen: Nicht verwendete Rollen werden archiviert und nicht einfach in der Tabelle zurückgelassen.
Verfolgen Sie einige Kennzahlen, die den Zustand der Governance sichtbar machen: die Gesamtzahl der Rollen, Rollen pro Mandant, den Anteil der Benutzer mit weitreichenden Berechtigungen, bei Prüfungen festgestellte Verstöße gegen die Aufgabentrennung und die durchschnittliche Zeit bis zum Widerruf nach einem Offboarding. Ein Framework für Entscheidungsbefugnisse kann dabei helfen, zu klären, wer tatsächlich die Genehmigungsbefugnis für sensible Rollen besitzt, bevor Sie den Ablauf im Code formalisieren.
Wie skalieren Sie RBAC über mandantenfähige Systeme hinweg?
Eine Berechtigungsexplosion ist der häufigste Fehlerfall bei mandantenfähigem RBAC und fast immer selbst verschuldet. Beschränken Sie Rollen von Anfang an auf Mandanten, statt separate Rollen namens „Acme Corp Admin“ und „Beta Inc Admin“ anzulegen. Denormalisieren Sie tenant_id in user_roles , damit Abfragen indexiert und schnell bleiben, legen Sie für jeden neuen Mandanten automatisch einen Standardsatz an Rollen an und halten Sie systemweite Rollen (Plattformadministrator, Supportingenieur) global, selten und streng kontrolliert.
-
Indexieren Sie
user_rolesnach(tenant_id, user_id), damit mandantenbezogene Abfragen bei wachsender Mandantenanzahl schnell bleiben. -
Lösen Sie einen Alarm aus, wenn die Rollenzahl eines Mandanten deutlich über Ihren Ausgangswert steigt. Das deutet meist darauf hin, dass jemand personenspezifische Rollen erstellt, statt Aufgabenbereichsrollen wiederzuverwenden.
-
Führen Sie regelmäßig eine Überschneidungsanalyse durch: Wenn zwei Rollen in Ihrem Katalog mehr als 90 Prozent ihrer Berechtigungen gemeinsam haben, kommen sie für eine Zusammenlegung infrage.
Die Überwachung der Rollenvermehrung, bevor sie eintritt, ist deutlich günstiger, als sie nach einer Sicherheitsprüfung zu entwirren, bei der vierzig nahezu identische Rollen in Ihrer Mandantenbasis beanstandet werden.
Wann sollten Sie RBAC zugunsten von ABAC oder ReBAC hinter sich lassen?
RBAC gerät unter einigen klar erkennbaren Bedingungen an seine Grenzen: wenn die Rollenzahl in die Hunderte steigt, Ressourcenbäume zu komplex für eine flache Rollenabgrenzung werden oder Anforderungen zur mandantenübergreifenden Freigabe entstehen, die keine statische Rolle sauber ausdrücken kann.
Die Lösung ist selten eine vollständige Neuentwicklung. Der session-management.com Leitfaden zu RBAC und ABAC empfiehlt ein Hybridmuster: Behalten Sie RBAC für grobkörnige, häufige Freigaben bei und verlagern Sie kontextabhängige Ausnahmen, Eigentumsprüfungen, Zeitfenster und geografische Einschränkungen in attribut- oder beziehungsbasierte (ReBAC) Richtlinien, die darübergelegt werden.
-
Evaluieren Sie neue Attributrichtlinien zunächst im Shadow-Modus mit echtem Datenverkehr, bevor Sie sie durchsetzen, damit Sie falsche Verweigerungen erkennen, bevor die Benutzer darauf stoßen.
-
Behalten Sie die RBAC-Ebene als Standardpfad bei und behandeln Sie ABAC-Regeln als Überschreibung und nicht als Ersatz, um bei der Einführung den Wirkungsradius zu begrenzen.
Wie testen, prüfen und migrieren Sie veraltetes RBAC sicher?
Testen Sie RBAC wie jeden kritischen Pfad: mit Unit-Tests für can() gegen jede Kombination aus Rolle und Berechtigung, Integrationstests gegen Ihren Policy Decision Point und Regressionstests, die erkennen, wenn eine Rollenänderung den Zugriff unbemerkt erweitert.
-
Fügen Sie Unit-Tests hinzu, die sicherstellen, dass
can()für jedes unterstützte Rollen- und Ressourcenpaar das erwartete Ergebnis liefert. -
Führen Sie die neuen Prüfungen parallel zur alten Logik im Shadow-Modus aus und protokollieren Sie Abweichungen, ohne sie durchzusetzen.
-
Vergleichen Sie die Ergebnisse des Shadow-Modus mindestens einen vollständigen Geschäftszyklus lang mit dem Produktionsdatenverkehr, bevor Sie umstellen.
Für Audit-Logs erfassen Sie bei jeder Änderung einer Rollenzuweisung granted_by, granted_at, changed_by, und change_reason ; formatiert für die direkte Aufnahme in Ihre Werkzeuge zur Reaktion auf Vorfälle.
Die Migration von einem veralteten Rollen-Enum in einer einzelnen Spalte folgt einem bewährten Strangler-Fig-Ansatz: Fügen Sie die normalisierten Tabellen neben der vorhandenen Spalte hinzu, füllen Sie Rollen aus den Enum-Werten vor, leiten Sie neue Prüfungen über can()um, führen Sie den Shadow-Modus aus, stellen Sie anschließend um und entfernen Sie die alte Spalte, sobald das Vertrauen ausreichend hoch ist.
Welche Anti-Patterns treten bei RBAC in der Produktion am häufigsten auf?
Die systemshardening.com Analyse von RBAC-Designmustern identifiziert in unabhängigen Codebasen immer wieder dieselben Fehler: Rollenexplosion, nach Personen benannte Rollen, direkte Benutzer-zu-Berechtigung-Zuweisungen, die Rollen vollständig umgehen, Bereitstellung mit Administratorrechten als Standard und Vererbungsketten, die niemand nachvollziehen kann.
-
Rollenexplosion: Konsolidieren Sie überschneidende Rollen und löschen Sie ungenutzte Rollen nach einem festen Zeitplan.
-
Nach Personen benannte Rollen: Benennen Sie sie nach dem Aufgabenbereich um und weisen Sie sie anschließend neu zu.
-
Direkte Zuweisungen: Unterbinden Sie sie mit einer Admission Policy, die verlangt, dass alle Freigaben über eine Rolle laufen.
-
Administratorrechte als Standard: Setzen Sie die Standardeinstellung für neue Benutzer auf die niedrigste geeignete Rolle.
Bei einem Beratungsprojekt ersetzten wir mehr als vierzig mandantenspezifische Administratorrollen durch sechs bereichsbezogene, mandantenbewusste Rollen und verkürzten die Dauer der Auditprüfung von Tagen auf Stunden.
Holen Sie sich Unterstützung beim Design oder bei der Migration Ihres RBAC-Systems
Ridiculousengineering hat Kunden durch RBAC-Designs, Legacy-Migrationen und Governance-Bereinigungen begleitet, wenn bestehende Systeme weit über das hinausgewachsen waren, was jemand noch zuverlässig prüfen konnte. Das Muster ist konsistent: Berechtigungsorientierte Modellierung, ein Schema mit fünf Tabellen, zentrale Durchsetzung und eine schrittweise Einführung sind bei Kosten und Risiko fast immer besser als eine Big-Bang-Neuentwicklung.
Wenn Ihr Team vor einem Rollenkatalog steht, dem niemand vertraut, oder eine Legacy-Migration der Autorisierung von Grund auf plant, kann das Team für individuelle Softwareentwicklung von Ridiculousengineering eine Architekturprüfung durchführen, das Schema entwerfen und Sie bei der schrittweisen Einführung unterstützen, statt das Unternehmen auf eine einzige Bereitstellung zu setzen. Kontaktieren Sie uns über die Kontaktseite von Ridiculousengineering , um ein RBAC-Architekturreview oder ein Migrationsprojekt zu planen.
Quellen
FAQ
Wie entwirft man eine rollenbasierte Zugriffskontrolle?
Beginnen Sie mit der Erfassung der Berechtigungen, gruppieren Sie sie in Rollen, die echten Aufgabenbereichen entsprechen, beschränken Sie Rollenzuweisungen auf Mandanten oder Ressourcen und erzwingen Sie jede Prüfung über eine zentrale can() Funktion mit einem kurzlebigen Cache.
Was sind rollenbasierte Zugriffskontrollen?
Rollenbasierte Zugriffskontrollen weisen Berechtigungen Rollen statt einzelnen Benutzern zu, sodass der Zugriff dem Aufgabenbereich folgt. Das NIST-RBAC-Referenzmodell definiert die Standardkomponenten Benutzer, Rollen, Berechtigungen, Ressourcen und Rollenzuweisungen.
Ist RBAC oder ABAC besser?
Keines ist grundsätzlich überlegen: RBAC verarbeitet grobkörnigen, auf Aufgabenbereichen basierenden Zugriff effizient, während ABAC kontextabhängige Ausnahmen behandelt. Die meisten ausgereiften Systeme verwenden beide gemeinsam, statt sich ausschließlich für eines zu entscheiden.
Was sind die drei wichtigsten Regeln für RBAC?
Die grundlegenden Regeln sind Rollenzuweisung (ein Benutzer muss eine Rolle zugewiesen bekommen, um deren Berechtigungen ausüben zu können), Rollenautorisierung (die aktive Rolle eines Benutzers muss für diesen Benutzer autorisiert sein) und Berechtigungsautorisierung (ein Benutzer darf eine Berechtigung nur ausüben, wenn sie für seine aktive Rolle autorisiert ist).