RBAC und ABAC: Die Zugriffskontrollmodelle, die du kennen solltest
Rollenbasierte Zugriffskontrolle (RBAC) und attributbasierte Zugriffskontrolle (ABAC) sind zwei der beliebtesten Zugriffskontrollmodelle. In diesem Beitrag geben wir einen kurzen Überblick über beide Modelle und diskutieren ihre Unterschiede.
SimengDeveloper
Verschwenden Sie keine Wochen mit Benutzerauthentifizierung
Bringen Sie sichere Apps schneller mit Logto auf den Markt. Integrieren Sie Benutzerauthentifizierung in Minuten und konzentrieren Sie sich auf Ihr Kernprodukt.
Zugriffskontrolle ist ein kritischer Aspekt der Sicherheit in jedem System. Sie stellt sicher, dass nur autorisierte Benutzer auf Ressourcen zugreifen und Aktionen durchführen können. Rollenbasierte Zugriffskontrolle (RBAC) und attributbasierte Zugriffskontrolle (ABAC) sind zwei der beliebtesten Zugriffskontrollmodelle, die in modernen Systemen verwendet werden. Beide Modelle sind weit verbreitet und können effektiv verwendet werden, um Zugriffskontrollrichtlinien durchzusetzen. Doch was sind sie und wie unterscheiden sie sich?
Die rollenbasierte Zugriffskontrolle (RBAC) wurde erstmals in den frühen 1990er Jahren eingeführt. Die Formalisierung des Modells wird David Ferraiolo und Rick Kuhn in einem Papier zugeschrieben, das 1992 veröffentlicht wurde. Seitdem ist RBAC eines der am weitesten verbreiteten Zugriffskontrollmodelle in der Industrie geworden.
In RBAC basieren die Zugriffskontrollrichtlinien auf Rollen, bei denen es sich um Sammlungen von Berechtigungen handelt. Benutzern werden Rollen zugewiesen (z. B. Administrator, Redakteur, Betrachter), und ihre Zugriffsrechte werden durch die Berechtigungen (z. B. Erstellen, Bearbeiten, Löschen) für bestimmte Ressourcen (z. B. Dateien, Datenbanken, Anwendungen) bestimmt. Dies vereinfacht die Verwaltung von Zugriffskontrollrichtlinien, indem Benutzer basierend auf ihren Rollen gruppiert und Berechtigungen Rollen zugewiesen werden. Es ist einfach, Benutzer zu Rollen hinzuzufügen oder aus ihnen zu entfernen, und die Änderungen werden automatisch in den Zugriffskontrollrichtlinien widerspiegelt.
Ressource: Eine Ressource ist eine Entität, auf die ein Benutzer zugreifen kann. Ressourcen können alles von Dateien, Datenbanken, APIs oder anderen Systementitäten sein, die geschützt werden müssen.
Berechtigung: Eine Berechtigung ist eine spezifische Aktion, die ein Benutzer auf einer Ressource ausführen kann. Zum Beispiel Erstellen, Bearbeiten, Löschen, Anzeigen. Die Definition von Berechtigungen kann je nach System variieren. In den meisten Fällen werden Berechtigungen auf der Ebene der Ressource mit einer minimalen Granularität definiert.
Rolle: Eine Rolle ist eine Sammlung von Berechtigungen, die eine Reihe von Aktionen definieren, die ein Benutzer ausführen kann. Zum Beispiel kann eine Administratorrolle Berechtigungen zum Erstellen, Bearbeiten und Löschen von Ressourcen haben, während eine Betrachterrolle die Berechtigung zum Anzeigen von Ressourcen haben kann.
Benutzer: Ein Benutzer ist eine Entität, der eine oder mehrere Rollen zugewiesen werden können. Benutzer erhalten basierend auf den Berechtigungen, die den ihnen zugewiesenen Rollen zugeordnet sind, Zugriff auf Ressourcen.
Es gibt mehrere Varianten von RBAC, die das Basismodell erweitern, um komplexere Anforderungen an die Zugriffskontrolle zu berücksichtigen:
RBAC0: Das Basismodell, bei dem Benutzern Rollen und Rollen Berechtigungen zugewiesen werden.
RBAC1: Fügt das Konzept der Rollenhierarchien hinzu. Rollen können Berechtigungen von anderen Rollen erben. Es ist auch als hierarchisches RBAC bekannt.
RBAC2: Fügt Rollenbeschränkungen hinzu. Beschränkungen können verwendet werden, um zusätzliche Bedingungen zu definieren, die erfüllt sein müssen, damit einem Benutzer eine Rolle zugewiesen wird. Es ist auch als beschränkungsbasiertes RBAC bekannt.
RBAC3: Kombiniert die Funktionen von RBAC1 und RBAC2. Es unterstützt sowohl Rollenhierarchien als auch Beschränkungen.
Einfachheit: RBAC ist leicht zu verstehen und umzusetzen. Berechtigungen Rollen zuzuweisen und Rollen Benutzern zuzuweisen ist unkompliziert.
Effizienz: Es vereinfacht die Verwaltung von Zugriffskontrollrichtlinien, indem Benutzer basierend auf ihren Rollen gruppiert werden. Es ist einfach, Benutzer zu Rollen hinzuzufügen oder aus ihnen zu entfernen, ohne die Zugriffskontrollrichtlinien zu ändern. Besonders in großen Organisationen mit gut definierten Berechtigungsstrukturen kann RBAC sehr effizient sein.
Transparenz: RBAC bietet eine klare Zuordnung zwischen Rollen, Berechtigungen und Benutzern. Es ist einfach, Zugriffskontrollrichtlinien zu prüfen und zu überprüfen.
Starrheit: RBAC kann starr sein, wenn es darum geht, komplexe Zugriffskontrollrichtlinien zu definieren. Es ist möglicherweise nicht geeignet für Systeme, in denen Zugriffskontrollrichtlinien dynamischer und kontextbewusster sein müssen.
Granularität: RBAC kann die notwendige Granularität für eine feinkörnige Zugriffskontrolle fehlen. Die Zugriffskontrollrichtlinien sind an klar definierte Rollen gebunden, und es kann zusätzlichen Aufwand erfordern, Berechtigungen auf einem granulareren Niveau zu definieren.
Rollenexplosion: In großen Organisationen mit komplexen Berechtigungsstrukturen kann die Anzahl der Rollen exponentiell wachsen, was zu einer sogenannten Rollenexplosion führt. Die Verwaltung einer großen Anzahl von Rollen kann herausfordernd sein.
In den späten 2000er Jahren, als Systeme komplexer und dynamischer wurden, begannen immer mehr Organisationen, die attributbasierte Zugriffskontrolle (ABAC) als Alternative zu RBAC zu übernehmen. Ein bemerkenswerter Meilenstein in der Formalisierung von ABAC ist die Veröffentlichung der NIST Special Publication 800-162 im Jahr 2014.
ABAC ist ein flexibleres Zugriffskontrollmodell im Vergleich zu RBAC. Es ist ein Autorisierungsmodell, das Zugriffskontrollrichtlinien basierend auf den Attributen des Benutzers, der Ressource, der Aktion und der Umgebung definiert. Es ermöglicht Organisationen, feinkörnige Zugriffskontrollrichtlinien zu definieren, die sich an unterschiedliche Kontexte und Bedingungen anpassen können.
Subjekt: Ein Subjekt ist eine Entität, die Zugriff auf eine Ressource anfordert. Es kann ein Benutzer, ein Gerät, eine Anwendung oder eine andere Entität sein, die Zugriff auf Ressourcen benötigt.
Ressource: Genau wie bei RBAC ist eine Ressource eine Entität, auf das ein Subjekt zugreifen kann. Ressourcen können Dateien, Datenbanken, APIs oder andere Systementitäten sein.
Aktion: Eine Aktion ist eine spezifische Operation, die ein Subjekt auf einer Ressource ausführen kann. Es kann sich um Erstellen, Lesen, Aktualisieren, Löschen oder eine andere operationale Handlung handeln, die kontrolliert werden muss.
Umgebung: Die Umgebung ist der Kontext, in dem der Zugriffsantrag gemacht wird. Sie kann Attribute wie Tageszeit, Standort, Netzwerk, Gerät usw. enthalten.
Attribut: Ein Attribut ist ein Merkmal eines Subjekts, einer Ressource, einer Aktion oder der Umgebung. Attribute können alles sein, von Benutzerrollen, Abteilung, Standort, IP-Adresse, Gerätetyp usw.
Richtlinie: Eine Richtlinie ist eine Regel, die die Bedingungen definiert, unter denen der Zugriff gewährt oder verweigert wird. Richtlinien werden basierend auf den Attributen definiert.
Flexibilität: ABAC kann komplexe Zugriffskontrollrichtlinien berücksichtigen, die auf mehreren Attributen basieren. Es ermöglicht Organisationen, feinkörnige Richtlinien zu definieren, die sich an unterschiedliche Kontexte und Bedingungen anpassen können.
Dynamik: ABAC-Richtlinien können dynamisch und kontextbewusst sein. Zugriffskontrollentscheidungen können auf Basis von Echtzeit-Attributen wie Standort, Tageszeit, Gerätetyp usw. getroffen werden.
Granularität: ABAC bietet eine feinkörnige Zugriffskontrolle, indem Organisationen Richtlinien basierend auf mehreren Attributen definieren können. Im Gegensatz zum Definieren von Rollen und Berechtigungen können attributbasierte Richtlinien granularer sein.
Komplexität: ABAC kann im Vergleich zu RBAC komplexer zu implementieren und zu verwalten sein. Das Definieren von Attributen und Richtlinien kann mehr Aufwand und Fachwissen erfordern. Im Gegensatz zu RBAC, wo Rollen und Berechtigungen gut strukturiert sind, können Attribute dynamischer sein und daher auch die Richtlinien. Die Verwaltung einer großen Anzahl von Attributen und Richtlinien in einem komplexen System kann herausfordernd sein. Oftmals ist eine zentrale Richtlinienbewertungseinheit erforderlich, um die Richtlinien auszuwerten.
Leistung: Die Attributbewertung kann die Leistung beeinträchtigen, insbesondere in Echtzeitumgebungen. Richtlinien basieren auf mehreren Attributen und Echtzeitbedingungen, die zu Verzögerungen bei den Zugriffskontrollentscheidungen führen können.
Aus der Vergleichstabelle geht hervor, dass RBAC am besten für Systeme mit gut definierten Berechtigungsstrukturen und relativ statischen Zugriffskontrollrichtlinien geeignet ist. ABAC hingegen ist besser für Systeme geeignet, in denen Zugriffskontrollrichtlinien dynamisch, kontextbewusst und feinkörnig sein müssen.
In diesem Fall ist RBAC einfach und effektiv. Wir können Rollen für Ärzte, Krankenschwestern und Administratoren definieren und die entsprechenden Berechtigungen jeder Rolle zuweisen.
Die Zugriffskontrollbewertung ist unkompliziert:
GET /patient-records: user.permission.includes('lesen')
POST /patient-records: user.permission.includes('schreiben')
In diesem Fall mag ABAC übertrieben erscheinen, aber es kann dennoch verwendet werden, um feinkörnige Richtlinien basierend auf Attributen wie Abteilung, Rolle usw. zu definieren.
Attribute:
user.role: doktor, krankenschwester, admin
resource.name: patienten-akte
action: lesen, schreiben, löschen
Richtlinien:
Richtlinie 1: Lesezugriff basierend auf user.role und resource.name erlauben
subjekt: Benutzer mit Rolle doktor, krankenschwester, admin
ressource: Ressource mit Namen patienten-akte
aktion: lesen
effekt: erlauben
begründung: "Erlaube Lesezugriff auf Patientenakten für alle Rollen"
Richtlinie 2: Schreibzugriff für Ärzte und Administratoren
subjekt: Benutzer mit Rolle doktor, admin
ressource: Ressource mit Namen patienten-akte
aktion: schreiben
effekt: erlauben
begründung: "Erlaube Schreibzugriff auf Patientenakten für Ärzte und Administratoren"
Richtlinie 3: Löschzugriff für Administratoren
subjekt: Benutzer mit Rolle admin
ressource: Ressource mit Namen patienten-akte
aktion: löschen
effekt: erlauben
begründung: "Erlaube Löschzugriff auf Patientenakten für Administratoren"
Für jede Lese-/Schreib-/Löschanforderung bewertet die Richtlinien-Engine alle relevanten Richtlinien basierend auf den Attributen und trifft eine Zugriffskontrollentscheidung.
In diesem Fall sind die Zugriffskontrollrichtlinien einfach und gut strukturiert. Es erfordert nur eine Einstufen-Berechtigungsprüfung, um festzustellen, ob ein Benutzer Zugriff auf eine Ressource hat. Stellen Sie sich vor, das Krankenhaussystem hat eine komplexere Struktur mit mehreren Abteilungen, Rollen und Berechtigungen:
In einem RBAC-Modell bleibt der Prozess der Zugriffskontrollbewertung der Ressource Patientenakten einfach und unkompliziert, ob der Benutzer die Erlaubnis hat, lesen, schreiben oder löschen zu dürfen.
ABAC hingegen muss zusätzliche Attribute wie abteilungs-id und arzt-id einbeziehen. Was ist, wenn ein IoT-Gerät Zugriff auf die Patientenakten benötigt? Es wird ein neues Attribut gerät-id eingeführt, um die Richtlinienauswertung zu unterstützen. Wie wäre es, einem praktizierenden Arzt vorübergehend die Erlaubnis zum Lesen zu erteilen?
Zusammengefasst ist RBAC besser geeignet. RBAC ist einfach und effizient für Systeme mit gut definierten Berechtigungsstrukturen und wo Zugriffskontrollrichtlinien statisch sind.
In diesem Fall müssen wir neben der alten Lesen-Berechtigung eine neue Berechtigung Selbst lesen einführen. Wir können Rollen für Ärzte, Krankenschwestern, Administratoren und Patienten definieren und die entsprechenden Berechtigungen jeder Rolle zuweisen.
Nun ist die Zugriffskontrollbewertung etwas komplexer, insbesondere für die Lesen-Patientenakten-Aktion:
GET /patient-records: user.permission.includes('lesen')
POST /patient-records: user.permission.includes('schreiben')
In diesem Fall sind die Zugriffskontrollrichtlinien komplexer und kontextbewusster. Der Prozess der Zugriffskontrollbewertung der Ressource Patientenakten erfordert mehrere Stufen der Berechtigungsprüfung, um festzustellen, ob ein Benutzer Zugriff auf eine Ressource hat.
In einem RBAC-Modell erfordert der Prozess der Zugriffskontrollbewertung der Ressource Patientenakten mehrere Stufen der Berechtigungsprüfung, um festzustellen, ob ein Benutzer Zugriff auf eine Ressource hat. Beispielsweise muss das System, um festzustellen, ob ein Patient Zugriff auf seine eigenen Aufzeichnungen hat, überprüfen, ob der Benutzer die Berechtigung selbst lesen hat und ob die Benutzer-ID mit der Patienten-ID übereinstimmt.
In einem ABAC-Modell kann der Prozess der Zugriffskontrollbewertung einfacher sein. Die Richtlinien können basierend auf den Attributen des Benutzers, der Ressource und der Aktion definiert werden. Um beispielsweise festzustellen, ob ein Patient Zugriff auf seine eigenen Aufzeichnungen hat, kann die Richtlinien-Engine die Richtlinie basierend auf der Benutzer-ID und der Patienten-ID bewerten.
In diesem Fall könnte ABAC besser geeignet sein. ABAC ist besser geeignet für Systeme, in denen Zugriffskontrollrichtlinien dynamisch, kontextbewusst und feinkörnig sein müssen.
Die Wahl zwischen RBAC und ABAC hängt von den spezifischen Anforderungen des Systems ab. RBAC eignet sich am besten für Systeme mit gut definierten Berechtigungsstrukturen und statischen Zugriffskontrollrichtlinien. ABAC ist besser geeignet für Systeme, in denen Zugriffskontrollrichtlinien dynamisch, kontextbewusst und feinkörnig sein müssen. In der Praxis können Organisationen sich dafür entscheiden, eine Kombination beider Modelle zu verwenden, um das gewünschte Maß an Zugriffskontrolle zu erreichen.