RBAC und ABAC: Die Zugriffskontrollmodelle, die du kennen solltest

Einführung#

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?

Rollenbasierte Zugriffskontrolle (RBAC)#

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.

Schlüsselfaktoren von RBAC#

• 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.

RBAC-Varianten#

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.

Weitere Informationen zu diesen Varianten findest du unter RBAC-Modelle und ihre Evolution.

Vorteile von RBAC#

• 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.

Nachteile von RBAC#

• 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.

Attributbasierte Zugriffskontrolle (ABAC)#

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.

Schlüsselfaktoren von ABAC#

• 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.

Vorteile von ABAC#

• 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.

Nachteile von ABAC#

• 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.

Vergleichstabelle#

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.

Beispiele#

Szenario: Ein Krankenhaussystem, das den Zugriff auf Patientenakten für verschiedene Mitarbeiter verwalten muss.

• Personal: Ärzte, Krankenschwestern, Administratoren
• Ressourcen: Patientenakten
• Berechtigungen: Lesen, Schreiben, Löschen

Fall 1#

Die Zugriffskontrollrichtlinien sind relativ einfach:

1. Ärzte können Patientenakten lesen und schreiben.
2. Krankenschwestern können Patientenakten lesen.
3. Administratoren können Patientenakten lesen, schreiben und löschen.

RBAC-Modell#

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')
• DELETE /patient-records: user.permission.includes('löschen')

ABAC-Modell#

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.

Vergleich#

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.

Fall 2#

Dasselbe Krankenhaussystem nun, jetzt führen wir eine neue Rolle patient und ein neues Attribut patienten-id ein.

Die Zugriffskontrollrichtlinien sind:

1. Ärzte können Patientenakten lesen und schreiben.
2. Krankenschwestern können Patientenakten lesen.
3. Administratoren können Patientenakten lesen, schreiben und löschen.
4. Patienten können ihre eigenen Akten lesen.

RBAC-Modell#

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')
• DELETE /patient-records: user.permission.includes('löschen')
• GET /patient-records/:patient-id: user.permission.includes('selbst lesen') && user.id === patient-id || user.permission.includes('lesen')

ABAC-Modell#

Aktualisieren wir nun die Attribute und Richtlinien im ABAC-Modell, um die neuen Anforderungen zu erfüllen.

Attribute:

• user.role: doktor, krankenschwester, admin, patient
• user.id: patient-id
• resource.name: patienten-akte
• resource.patient-id: patient-id
• action: lesen, schreiben, löschen

Richtlinien:

• Richtlinie 1: Erlaube Lesezugriff auf alle Patientenakten
  • 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 das gesamte Personal und der Patient selbst"
• Richtlinie 2: Erlaube Schreibzugriff auf alle Patientenakten 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: Erlaube Löschzugriff auf alle Patientenakten 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"
• Richtlinie 4: Erlaube Lesezugriff auf eigene Patientenakten
  • subjekt: Benutzer mit Rolle patient
  • ressource: Ressource mit Namen patienten-akte
  • aktion: lesen
  • bedingung: user.id === resource.patient-id
  • effekt: erlauben
  • begründung: "Erlaube Lesezugriff auf eigene Patientenakten"

Vergleich#

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.

Fazit#

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.