Welches Modell der Zugriffskontrolle (RBAC, ABAC, PBAC) passt zu Ihrer Organisation?

Der Unterschied zwischen RBAC, ABAC und PBAC

Bei RBAC, ABAC und PBAC handelt es sich um drei verschiedene Methoden für die Zugriffskontrolle, die sich innerhalb des Identity & Access Management als Nachfolger voneinander betrachten lassen. RBAC, ABAC und PBAC sind drei unterschiedliche Ansätze für die automatisierte Vergabe von Zugriffsrechten von Mitarbeitern. Für Organisationen ist ein solches automatisiertes Identitäts- und Zugangsmanagement essentiell, um nicht alle Zugriffsrechte manuell verwalten zu müssen. Stattdessen ist ein struktureller Ansatz wünschenswert, und dazu dienen RBAC, ABAC und PBAC.

Wir erklären, wie diese Verfahren funktionieren, worin sie sich unterscheiden und welche Vorteile sie jeweils bieten. Jedes Verfahren wird mit konkreten Beispielen illustriert, und es wird dargelegt, wie sie in einer modernen IAM-Umgebung wie HelloID laufen. Zunächst werfen wir aber einen Blick auf die historische Entwicklung dieser Zugangsverfahren.

So sind RBAC, ABAC und PBAC entstanden

Um die Unterschiede zwischen den Methoden zu verstehen, ist es sinnvoll, zunächst auf ihre Ursprünge zu schauen.

Der Anfang: IBAC

Die einfachste Art der Zugangsverwaltung ist die identitätsbasierte Zugriffskontrolle (Identity-Based- Access Control, IBAC). Dabei wird jedem Benutzer eine Liste von Zugriffsrechten zugeordnet. Diese Methode datiert in die Zeit der Mainframe-Rechner zurück, als mehrere Anwender Zugang zu einem einzigen Computer hatten und die Administratoren Konflikte bei der Nutzung verhindern wollten. Bei einer begrenzten Anzahl Nutzer und wen-igen gemeinsam verwendeten Ressourcen war eine solche einfache Liste von Identitäten und Zugriffsrechten ausreichend.

Der Übergang zur RBAC

Angesichts steigender Nutzerzahlen im Netzwerk und immer mehr Anwendungen wurde es zu kompliziert, die Rechte weiterhin individuell zu vergeben. Deshalb kam ungefähr im Jahr 1992 das Konzept der rollen-basierten Zugriffskontrolle (Role-Based Access Control, RBAC) auf. Hierbei wird der Zugriff auf IT-Ressourcen auf Basis von Rollen in einer Organisation gewährt. Mit einer Rolle sind automatisch bestimmte Rechte verbunden, sodass die Administration einfacher wurde. Die Zugriffsrechte werden nun nicht mehr pro Benutzer, sondern pro Rolle verwaltet.

Das Aufkommen der ABAC

RBAC funktionierte hervorragend für Organisationen mit klarer Eins-zu-Eins-Beziehung zwischen Rollen und Berechtigungen. Es gab aber auch Organisationen, die mehr Flexibilität benötigten. Deshalb wurde Ende der 1990er Jahre die attributbasierte Zugriffskontrolle (Attribute-Based Access Control, ABAC) entwickelt. Hierbei werden Zugriffsrechte anhand bestimmter Merkmale (Attribute) vergeben. Dabei kann es sich immer noch um Rollen handeln, aber beispielsweise auch um die Abteilung oder die Qualifikationen eines Mitarbeitenden. So gesehen ist die RBAC eine Untermenge der ABAC, denn Letztere ist universeller, flexibler und leistungsfähiger.

Weiterentwicklung zur PBAC

Zwar ermöglicht die ABAC mehr Flexibilität, aber sie macht die Verwaltung von Zugriffsrechten durch Abhängigkeiten zwischen Attributen und Berechtigungen auch schnell kompliziert. Aus diesem Grund wurde die richtlinienbasierte Zugriffskontrolle (Policy-Based Access Control, PBAC) entwickelt, bei der die Zugangsverwaltung über verständliche, natürliche Sprache statt über komplexe Strukturen oder Programmiercode erfolgt. Das Erstellen und Abändern von Zugriffsrechten wird für Organisationen damit viel einfacher und schneller. Die Berechtigungen werden weiterhin über Attribute erteilt, aber die Pflege wird dank Geschäftsregeln viel einfacher, und es lassen sich auf einfache Weise Prozessregeln oder Workflows hinzufügen.[1]

Attribute für die Zugriffskontrolle

Attribute sind Eigenschaften von Benutzern und deren Anmeldesitzungen. Dabei werden meist drei unterschiedliche Arten von Attributen unterschieden:

Benutzerattribute: Diese Attribute beziehen sich auf den Benutzer selbst. Dazu zählen Benutzername, Abteilung, üblicher Arbeitsplatz, bestimmte Kenntnisse usw.

Objektattribute: Hierbei handelt es sich um Eigenschaften bzw. Merkmale von Anwendungen, Webservices oder Daten, auf die ein Benutzer zugreifen möchte. Zu den Objekt- bzw. Ressourcenattributen zählt z.B. das Geheimhaltungsniveau (öffentlich, vertraulich, geheim), über welches festgelegt ist, welche spezifischen Ressourcen ein Benutzer verwenden darf.

Kontextattribute: Diese Attributkategorie bezieht sich auf den betrieblichen, technischen und ggf. auch situationsabhängigen Kontext, in dem ein Zugriff erfolgt. Dazu zählen Datum und Uhrzeit eines Zugriffsversuchs, aber auch Standort, Netzwerk, System oder verwendetes Endgerät.[2]

Beispiele für RBAC, ABAC und PBAC

Beispiel für RBAC (Role-Based Access Control)

RBAC gewährt Zugriff basierend auf Rollen von Benutzern in einer Organisation. Jeder Benutzer hat eine oder mehrere Rollen, denen jeweils unterschiedliche Zugriffsrechte zugeordnet sind. Beispiel:

• Definition und Struktur: Im RBAC sind unter anderem die Rollen „Financial Manager“, „HR-Mitarbeiter“, „IT-Administrator“ und „Pflegekraft“ definiert. Die Benutzer Jan, Sara, Mike und Lisa werden diesen Rollen und den entsprechenden Zugriffsrechten zugeordnet.
• Beispiel:

Jan ist Financial Manager und darf Finanzberichte bearbeiten und Personalakten anzeigen.
Sara ist HR-Mitarbeiterin und darf Personalakten anzeigen, aber nicht bearbeiten.
Mike ist IT-Administrator und hat Zugriff auf IT-Systeme, aber nicht auf Finanzberichte oder Personalakten.
Lisa ist Pflegekraft und darf Patientenakten anzeigen und lebensnotwendige Daten bearbeiten.

Vorteile: Dieses Modell ist leicht verständlich und umsetzbar, vor allem in Organisationen mit festen Strukturen. Es ist klar geregelt, wer welche Zugriffsrechte hat.

Nachteile: RBAC ist weniger flexibel, wenn sich die Anforderungen an Zugriffsrechte ändern oder die Rechte komplexer werden. Dann müssen ggf. bestehende Rollen angepasst oder neue Rollen erstellt werden, wodurch die Gefahr besteht, dass übermäßig viele Rollen entstehen bzw. das Management zu kompliziert wird.[3]

Beispiel für ABAC (Attribute-Based Access Control)

ABAC gewährt Zugriff basierend auf verschiedenen Attributen bzw. Merkmalen von Benutzern, Datenquellen oder Aktionen. Diese Attribute werden geprüft, um zu ermitteln, ob der Zugriff erteilt werden darf. Beispiel:

• Definition und Struktur: Attribute können sich auf die Funktion, die Abteilung oder den Standort eines Benutzers beziehen (Benutzerattribute), Dateitypen oder das Sensibilitätsniveau (Ressourcenattribute) oder den Zeitpunkt und den Ort eines Zugriffsversuchs (Kontextattribute). In Geschäftsregeln werden die Attribute kombiniert, um eine detaillierte Zugangskontrolle zu ermöglichen.
• Beispiel:

Jan darf vertrauliche Finanzberichte bearbeiten, wenn er in der Abteilung Finanzen arbeitet, die Funktion Manager hat und dies innerhalb der Geschäftszeiten tut.
HR-Mitarbeiterin wie Sara dürfen Personalakten anzeigen, aber nicht bearbeiten, egal zu welcher Uhrzeit.
Lisa als Pflegekraft darf die Akte eines Patienten anzeigen, sofern sie die behandelnde Pflegemitarbeiterin ist und dies innerhalb ihrer Arbeitszeit und vom Netzwerk des Kranken-hauses aus erfolgt.

Vorteile: Die ABAC bietet eine hohe Flexibilität und granulare Einstellungsmöglichkeiten. Der Zugriff kann dynamisch anhand aktueller Attribute angepasst werden, so dass sich diese Methode für Organisationen mit komplexen, häufig wechselnden Anforderungen an die Zugangsverwaltung eignet.

Nachteile: Das System ist schwieriger zu implementieren und zu verwalten. Das umfassende Management der Attribute und die sorgfältige Erstellung von Geschäftsregeln per Programmiercode, wie z.B. XACML, erfordern mehr Zeit und technische Expertise.

Beispiel für PBAC (Policy-Based Access Control)

Bei der PBAC erfolgt die Zugriffsverwaltung auf der Grundlage von zentral verwalteten Geschäftsregeln, in denen Attribute und Geschäftslogik kombiniert werden. Diese Regeln werden in verständlicher natürlicher Sprache geschrieben, sodass sie relativ einfach zu verstehen und zu verwalten sind. Beispiel:

• Definition und Struktur: Anhand von Geschäftsregeln wird eindeutig definiert, wer worauf unter welchen Umständen Zugriff hat. Diese Regeln setzen sich aus Attributen und bestimmten Bedingungen zusammen und werden zentral verwaltet.
• Beispiel:

Geschäftsregel 1: Finanzmanager dürfen während der Bürozeiten vertrauliche Finanzberichte bearbeiten.
Geschäftsregel 2: HR-Mitarbeiter dürfen Personalakten an-zeigen, aber nicht bearbeiten.
Geschäftsregel 3: Behandelnde Pflegemitarbeiter dürfen während ihrer Arbeitszeiten medizinische Akten ihnen zugewiesener Patienten anzeigen und bearbeiten.
Geschäftsregel 4: Der Zugriff auf Patientenakten darf ausschließlich vom Netzwerk des Krankenhauses aus erfolgen.

Diese Geschäftsregeln werden in natürlicher Sprache formuliert und zentral verwaltet, sodass sie relativ einfach zu verstehen und anzuwenden sind.

Vorteile: PBAC kombiniert die Flexibilität von ABAC mit einer einfachen Administration. Dank der Verwendung natürlicher Sprache können die Regeln schneller erstellt und geändert werden, und das auch von Personen ohne technischen Hintergrund. Die zentrale Verwaltung der Geschäftsregeln sorgt für Konsistenz und macht es einfacher, zeitnah auf Änderungen zu reagieren.

Nachteile: Die Methode erfordert ein korrekt eingerichtetes und verwaltetes Regelsystem. Bei übermäßig vielen Geschäftsregeln oder einer mangelhaften Administration kann das System komplex und unübersichtlich werden.

RBAC vs. ABAC

Worin unterscheiden sich RBAC und ABAC?

Der wichtigste Unterschied zwischen RBAC und ABAC ist die Art und Weise, wie Zugriffsberechtigungen erteilt werden. Bei der rollenbasierten Zugriffskontrolle geschieht dies durch die Zuweisung von Rollen an Benutzer. Bei der attributbasierten Zugriffskontrolle kann der Zugriff dynamisch über Benutzerattribute, Objektattribute und Kontextattribute erteilt werden.

ABAC vs. PBAC

Worin unterscheiden sich ABAC und PBAC?

Die attributbasierte Zugriffskontrolle unterscheidet sich von der richtlinienbasierten Zugriffskontrolle darin, wie das Berechtigungsmodell konfiguriert werden kann. Bei der ABAC werden die Rollenattribute über eine spezielle Markup-Sprache wie z.B. XACML eingerichtet. Bei der PBAC kommen hingegen einfache Geschäftsregeln in natürlicher Sprache zum Einsatz. Die PBAC ist also nicht per se leistungsstärker als die ABAC, aber viel einfacher anzuwenden.

Fazit

Kurz gesagt sind dies die Unterschiede:

• RBAC ist für einfache, stabile Umgebungen geeignet, aber nicht besonders flexibel.
• ABAC bietet viel Flexibilität und eine feinkörnige Kontrolle, aber ist komplexer zu verwalten.
• PBAC ist ähnlich flexibel wie ABAC, aber einfacher zu verwalten dank zentraler Geschäftsregeln in verständlicher Sprache.

Beachten Sie, dass sich ABAC und PBAC nicht darin unterscheiden, dass Attribute verwendet werden. Auch bei der PBAC werden Attribute verwendet, wobei jedoch die Zugriffsrechte auf benutzerfreundlichere Weise verwaltet werden.[4] Dies zeigen wir am Beispiel der HelloID-Plattform.

RBAC, ABAC und PBAC in Ihrer IAM-Plattform

Viele Identity & Access Management-Plattformen unterstützen RBAC. Bei dieser Methode gibt es allerdings einige Einschränkungen, wie wir gesehen haben. Deshalb verfügt HelloID über einen fortschrittlicheren Mechanismus, der die Vorteile von RBAC, ABAC und PBAC kombiniert. Dabei werden alle verfügbaren Informationen zu Benutzern, Kontext und Zugriffsanfragen herangezogen. Um diese Informationen handhabbar zu machen, werden Benutzerattribute in HelloID anders als Kontext- und Ressourcenattribute verwendet:

• Die Werte von Benutzerattributen sind eher statisch, denn die Funktion oder Abteilung eines Mitarbeiters ändert sich selten. Deshalb wird hiermit im HelloID-Provisioning-Modul automatisch bestimmt, welche Benutzerkonten und Zugriffsrechte ein Mitarbeiter benötigt. Ein- bis zweimal täglich aktualisiert das System die Benutzerkonten und Zugriffsrechte und gibt mögliche Änderungen an Zielsysteme wie Active Directory, TOPdesk oder Unternehmensanwendungen weiter.
• Kontextattribute und Ressourcenattribute beziehen sich nicht auf den Benutzer selbst, sondern auf dessen Anmeldesitzung, und können je nach Sitzung unterschiedliche Werte haben. Daher eignen sie sich nicht für die Bereitstellung von Benutzerkonten und -berechtigungen. Stattdessen kommen diese Kontext- und Ressourceneinschränkungen zum Einsatz, um die Zugriffsrechte weiter zu verfeinern. Beispiel: Für eine Zugangsberechtigung wird die Bedingung hinzugefügt, dass der Zugriff nur während der Bürozeiten erlaubt ist. Auf diese Weise kann der Zugang kontext- und ressourcen-abhängig erlaubt werden.

Zusammengefasst:
Die automatisierte Bereitstellung von Benutzerkonten und entsprechenden Berechtigungen für Zielsysteme erfolgt über Benutzerattribute.
Die detailliertere Einstellung von Zugangsberechtigungen geschieht über Kontextattribute und Ressourcenattribute. So unter-stützen wir eine vollständige ABAC und PBAC. Dies wird im Folgenden noch genauer erklärt.

Provisioning anhand von Benutzerattributen

Bei der Bereitstellung von Benutzerkonten liegt der größte Unterschied zwischen RBAC und ABAC in den verfügbaren Benutzerattributen. Eine einfache RBAC nutzt ausschließlich Rollen, während die ABAC viel mehr Attribute bietet, wie z.B. Abteilung, Arbeitsplatz oder Qualifikationen, die sich zudem noch kombinieren lassen. Mit diesen Funktionen lässt sich die Berechtigungsverwaltung viel präziser und zugleich einfacher organisieren, zum Beispiel als smarte „Rechtepyramide“.

• Manche Berechtigungen brauchen alle Mitarbeiter. In vielen Organisationen bekommt jeder Nutzer beispielsweise eine E-Mail-Adresse sowie eine Microsoft-365-Lizenz. Diese werden daher automatisch per ABAC an alle Benutzer in der Organisation vergeben. Diese Berechtigungen müssen also nicht, wie bei der RBAC, mit sämtlichen bestehenden Rollen verknüpft werden.
• Andere Berechtigungen können abhängig von einer Abteilung oder einem Team vergeben werden. Dazu kann beispielsweise eine SharePoint-Freigabe für eine bestimmte Abteilung zählen. Diese Berechtigung wird auf Grundlage der Abteilung eines Mitarbeiters erteilt. Auch hier sind individuelle Rollen nicht relevant.
• So bleibt häufig nur eine begrenzte Anzahl von Rechten übrig, die tatsächlich spezifisch mit einer Rolle verknüpft werden müssen, zum Beispiel für Pflegemitarbeiter, die bestimmte Berechtigungen im Pflegesystem benötigen. Ausschließlich diese Berechtigungen werden noch über individuelle Rollen erteilt.

Hier zeigt sich die Stärke der ABAC. Mit Attributen wie Rollen, Abteilungen, Teams, Standorten oder Kompetenzen lassen sich ganz einfach bestimmte, größere Gruppen in Ihrer Organisation selektieren, denen Sie dieselben Rechte zuweisen wollen. Dies wäre mit der RBAC nur schwierig oder gar nicht möglich.

Von ABAC zur PBAC mit Geschäftsregeln

Es ist eine Herausforderung, ein solches attributbasiertes Modell auf benutzerfreundliche Weise zu administrieren. Man möchte Scripting-Tools oder andere komplexe Methoden für die ABAC-Konfiguration vermeiden. In HelloID kommen Geschäftsregeln (auch als Business Rules bezeichnet) zum Einsatz, über die sich bestimmte Bedingungen und die entsprechenden Berechtigungen auf einfache Weise ausdrücken lassen. Für ein Pflegezentrum könnte eine Geschäftsregel beispielsweise so aussehen:

Hat ein Mitarbeiter die Funktion ‚Pflegeniveau 4‘ und arbeitet in der Abteilung ‚Pflege A‘ (die Bedingung), erhält er standardmäßig ein EntraID-Konto sowie ein Konto in der elektronischen Patientenakte mit Berechtigung für Patienten in der Abteilung Pflege A (die zugehörigen Berechtigungen).

Wie oben beschrieben, lassen sich diese Berechtigungen über Kontext- und Ressourcenattribute noch weiter verfeinern. In einem Pflegesystem könnten Sie beispielsweise einstellen, welche Patientengruppen zugänglich sind, ob Daten nur angezeigt oder auch bearbeitet werden dürfen und von welchem Netzwerk aus der Zugriff erfolgen darf. Je nach Anwendung gibt es unterschiedliche Konfigurationsmöglichkeiten, und über den umfangreichen HelloID Connector-Katalog lassen sich diverse Zielsysteme anbinden, um dort automatisch die richtigen Berechtigungen zu setzen.

Mit diesen Geschäftsregeln ist ein vollständiges PBAC-Modell (richtlinienbasierte Zugriffskontrolle) implementiert, das enorme Vorteile bietet. Das Denken in Geschäftsregeln ist einfach, und der Administrator braucht sich nicht um komplexe Strukturen mit Attributen und Berechtigungen zu kümmern. Es werden ganz einfach Regeln hinzugefügt, die entweder für alle Nutzer oder nur für bestimmte Abteilungen, Rollen oder sonstige Benutzerattribute gelten sollen. Außerdem lassen sich auch diverse Bedingungen mit den Rechten verbinden. Mögliche Überschneidungen zwischen Geschäftsregeln sind kein Problem, denn das System übersetzt alle Regeln in eine konsistente, zusammenhängende Berechtigungsstruktur.

Ein weiterer Vorteil ist die Möglichkeit, über Geschäftsregeln auch ergänzende Prozessregeln oder Workflows hinzuzufügen. Ein Beispiel hierfür ist eine Regel für Benutzerkonten, die erfordert, dass Konten für neue Mitarbeiter eine Woche vor dem Onboarding aktiviert werden müssen. Ein weiteres Beispiel ist eine Regel, die erfordert, dass Berechtigungen für eine Anwendung erst dann aktiv werden, nachdem online die entsprechenden Nutzungsbedingungen akzeptiert wurden.

Mehr Informationen zu RBAC, ABAC und PBAC

Wollen Sie noch mehr zur praktischen Anwendung dieser Methoden für die Zugriffskontrolle bei Ihrem Identity & Access Management erfahren? In einem persönlichen Beratungstermin erläutern wir Ihnen ausführlich den Aufbau einer Berechtigungsstruktur anhand von Rollen und weiteren Attributen. Außerdem zeigen wir Ihnen, wie Sie mittels Role Mining Ihre derzeitige Rechtestruktur analysieren und optimieren können.

Geschrieben von:

Jan Pieter Giele

Managing Director DACH, Nord- & Osteuropa

Jan Pieter Giele ist seit 2004 als Managing Director verantwortlich für die Aktivitäten der Tools4ever Informatik GmbH. Von Bergisch Gladbach aus kümmert er sich um die Weiterentwicklung und den Verkauf unserer IAM-Tools in Deutschland, Schweiz, Österreich und Nord- & Osteuropa und überwacht Beratung, Implementierung und Support.