Role-based access control

In computer systems security, role-based access control (RBAC)^[1][2] or role-based security^[3] is an approach to restricting system access to authorized users, and to implementing mandatory access control (MAC) or discretionary access control (DAC).

Role-based access control is a policy-neutral access control mechanism defined around roles and privileges. The components of RBAC such as role-permissions, user-role and role-role relationships make it simple to perform user assignments. A study by NIST has demonstrated that RBAC addresses many needs of commercial and government organizations.^[4] RBAC can be used to facilitate administration of security in large organizations with hundreds of users and thousands of permissions. Although RBAC is different from MAC and DAC access control frameworks, it can enforce these policies without any complication.

Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user's account; this simplifies common operations, such as adding a user, or changing a user's department.

Three primary rules are defined for RBAC:

1. Role assignment: A subject can exercise a permission only if the subject has selected or been assigned a role.
2. Role authorization: A subject's active role must be authorized for the subject. With rule 1 above, this rule ensures that users can take on only roles for which they are authorized.
3. Permission authorization: A subject can exercise a permission only if the permission is authorized for the subject's active role. With rules 1 and 2, this rule ensures that users can exercise only permissions for which they are authorized.

Additional constraints may be applied as well, and roles can be combined in a hierarchy where higher-level roles subsume permissions owned by sub-roles.

Mithilfe der Konzepte von Rollenhierarchie und -beschränkungen lässt sich rollenbasierte Zugriffskontrolle (RBAC) steuern, um gitterbasierte Zugriffskontrolle (LBAC) zu erstellen oder zu simulieren. RBAC kann daher als Obermenge von LBAC betrachtet werden.

Bei der Definition eines RBAC-Modells sind folgende Konventionen hilfreich:

• S = Subjekt = Eine Person oder ein automatisierter Agent
• R = Rolle = Berufsfunktion oder -titel, der eine Autoritätsebene definiert
• P = Berechtigungen = Die Genehmigung einer Zugriffsmethode auf eine Ressource
• SE = Sitzung = Eine Zuordnung von S, R und/oder P
• SA = Fachzuweisung
• PA = Genehmigungszuweisung
• RH = Teilweise geordnete Rollenhierarchie. RH kann auch so geschrieben werden: ≥ (Die Notation x ≥ y bedeutet, dass x die Berechtigungen von y erbt.)
  • Eine Person kann mehrere Rollen haben.
  • Eine Rolle kann mehrere Themenbereiche umfassen.
  • Eine Rolle kann über viele Berechtigungen verfügen.
  • Eine Berechtigung kann mehreren Rollen zugewiesen werden.
  • Eine Operation kann mehreren Berechtigungen zugewiesen werden.
  • Eine Berechtigung kann mehreren Operationen zugewiesen werden.

Eine Einschränkung begrenzt die mögliche Vererbung von Berechtigungen zwischen gegensätzlichen Rollen. Dadurch kann eine angemessene Funktionstrennung erreicht werden . Beispielsweise sollte es derselben Person nicht gestattet sein, sowohl ein Benutzerkonto zu erstellen als auch die Kontoerstellung zu autorisieren.

Unter Verwendung der Notation der Mengenlehre :

• ${\displaystyle PA\subseteq P\times R}$und ist eine Viele-zu-Viele-Berechtigungs-zu-Rollenzuweisungsbeziehung.
• ${\displaystyle SA\subseteq S\times R}$und ist eine Viele-zu-Viele-Beziehung, die der Rollenzuweisung unterliegt.
• ${\displaystyle RH\subseteq R\times R}$

Eine Versuchsperson kann mehrere gleichzeitige Sitzungen mit/in verschiedenen Rollen haben.

Der NIST/ANSI/ INCITS RBAC-Standard (2004) erkennt drei RBAC-Ebenen an: ^{[ 5 ]}

1. Core RBAC
2. hierarchisches RBAC, das die Vererbung zwischen Rollen unterstützt.
3. eingeschränkte RBAC, die eine Trennung der Aufgaben mit sich bringt

RBAC ist eine flexible Zugriffskontrolltechnologie, deren Flexibilität die Implementierung von DAC ^{[ 6 ]} oder MAC ^{[ 7 ]} ermöglicht . DAC mit Gruppen (z. B. wie in POSIX-Dateisystemen implementiert) kann RBAC emulieren. ^{[ 8 ]} MAC kann RBAC simulieren, wenn der Rollengraph auf einen Baum anstatt auf eine partiell geordnete Menge beschränkt ist . ^{[ 9 ]}

Vor der Entwicklung von RBAC war das Bell-LaPadula -Modell (BLP) gleichbedeutend mit MAC und Dateisystemberechtigungen gleichbedeutend mit DAC. Diese galten als die einzigen bekannten Modelle für die Zugriffskontrolle: Entweder ein Modell entsprach nicht dem BLP-Modell oder dem DAC-Modell, oder umgekehrt. Untersuchungen Ende der 1990er-Jahre zeigten jedoch, dass RBAC keiner dieser Kategorien zuzuordnen ist. ^{[ 10 ] [ 11 ]} Im Gegensatz zur kontextbasierten Zugriffskontrolle (CBAC) berücksichtigt RBAC nicht den Nachrichtenkontext (z. B. die Quelle einer Verbindung). RBAC wurde zudem wegen der damit einhergehenden Rollenexplosion kritisiert ^{[ 12 ]} , einem Problem in großen Unternehmenssystemen, die eine feinere Zugriffskontrolle erfordern, als RBAC bieten kann, da Rollen Operationen und Datentypen inhärent zugewiesen werden. Ähnlich wie CBAC kann ein System für entitätsrelationale Zugriffskontrolle (ERB) Dateninstanzen sichern, indem es deren Zuordnung zum ausführenden Subjekt berücksichtigt. ^{[ 13 ]}

Zugriffskontrolllisten (ACLs) werden in traditionellen Systemen mit diskretionärer Zugriffskontrolle (DAC) verwendet, um Datenobjekte auf niedriger Ebene zu beeinflussen. RBAC unterscheidet sich von ACLs dadurch, dass Berechtigungen für Operationen zugewiesen werden, die die direkten Beziehungen zwischen mehreren Entitäten verändern (siehe: ACLg unten). Beispielsweise kann eine ACL verwendet werden, um Schreibzugriff auf eine bestimmte Systemdatei zu gewähren oder zu verweigern, ohne jedoch festzulegen, wie diese Datei geändert werden darf. In einem RBAC-basierten System könnte eine Operation beispielsweise das Erstellen einer Kreditkonto-Transaktion in einer Finanzanwendung oder das Speichern eines Blutzuckermessdatensatzes in einer medizinischen Anwendung sein. Eine Rolle ist somit eine Abfolge von Operationen innerhalb einer größeren Aktivität. RBAC hat sich als besonders geeignet für die Anforderungen der Funktionstrennung (SoD) erwiesen, die sicherstellen, dass mindestens zwei Personen an der Autorisierung kritischer Operationen beteiligt sein müssen. Notwendige und hinreichende Bedingungen für die Sicherheit der Funktionstrennung in RBAC wurden analysiert. Ein grundlegendes Prinzip der Funktionstrennung ist, dass niemand durch doppelte Berechtigungen einen Sicherheitsverstoß begehen können sollte. Folglich darf niemand eine Funktion innehaben, die Prüfungs-, Kontroll- oder Überprüfungsbefugnisse über eine andere, gleichzeitig innegehabte Funktion ausübt. ^{[ 14 ] [ 15 ]}

Andererseits kann ein „minimales RBAC-Modell“, RBACm , mit einem ACL-Mechanismus, ACLg , verglichen werden, bei dem nur Gruppen als Einträge in der ACL zulässig sind. Barkley (1997) ^{[ 16 ]} zeigte, dass RBACm und ACLg äquivalent sind.

Zum Datenaustausch und für „Vergleiche auf hoher Ebene“ können ACL-Daten in XACML übersetzt werden .

Attributbasierte Zugriffskontrolle ( ABAC) ist ein Modell, das aus der rollenbasierten Zugriffskontrolle (RBAC) weiterentwickelt wurde und neben Rollen und Gruppen zusätzliche Attribute berücksichtigt. In ABAC können folgende Attribute verwendet werden:

• der Benutzer z.B. Staatsbürgerschaft, Sicherheitsüberprüfung,
• die Ressource, z. B. Klassifizierung, Abteilung, Eigentümer,
• die Handlung und
• der Kontext, z. B. Zeit, Ort, IP-Adresse.

ABAC ist richtlinienbasiert, da es Richtlinien anstelle statischer Berechtigungen verwendet, um zu definieren, was erlaubt ist und was nicht.

Beziehungsbasierte Zugriffskontrolle ( ReBAC) ist ein Modell, das aus RBAC weiterentwickelt wurde. Bei ReBAC wird die Zugriffsberechtigung eines Subjekts auf eine Ressource durch das Vorhandensein von Beziehungen zwischen diesem Subjekt und der Ressource definiert.

Der Vorteil dieses Modells besteht darin, dass es fein abgestufte Berechtigungen ermöglicht; beispielsweise in einem sozialen Netzwerk , in dem Benutzer Beiträge mit anderen bestimmten Benutzern teilen können. ^{[ 17 ]}

Der Einsatz von rollenbasierter Zugriffskontrolle (RBAC) zur Verwaltung von Benutzerrechten (Computerberechtigungen) innerhalb eines einzelnen Systems oder einer Anwendung gilt weithin als bewährte Methode . Ein 2010 vom Research Triangle Institute im Auftrag des NIST erstellter Bericht analysierte den wirtschaftlichen Nutzen von RBAC für Unternehmen und schätzte den Nutzen pro Mitarbeiter durch reduzierte Ausfallzeiten, effizientere Bereitstellung und effizientere Verwaltung von Zugriffskontrollrichtlinien. ^{[ 18 ]}

In Organisationen mit heterogener IT-Infrastruktur und Anforderungen, die Dutzende oder Hunderte von Systemen und Anwendungen umfassen, gestaltet sich die Verwaltung ausreichender Rollen und die Zuweisung adäquater Rollenzugehörigkeiten mittels rollenbasierter Zugriffskontrolle (RBAC) ohne hierarchische Erstellung von Rollen und Berechtigungszuweisungen äußerst komplex. ^{[ 19 ]} Neuere Systeme erweitern das ältere NIST-RBAC-Modell ^{[ 20 ]} , um die Einschränkungen von RBAC bei unternehmensweiten Implementierungen zu beheben. Das NIST-Modell wurde von INCITS als ANSI/INCITS 359-2004 als Standard übernommen. Eine Diskussion einiger Designentscheidungen für das NIST-Modell wurde ebenfalls veröffentlicht. ^{[ 21 ]}

Störungen durch rollenbasierte Zugriffskontrolle sind ein relativ neues Problem in Sicherheitsanwendungen. Mehrere Benutzerkonten mit dynamischen Zugriffsebenen können zu Instabilität der Verschlüsselungsschlüssel führen, wodurch ein externer Benutzer die Schwachstelle für unbefugten Zugriff ausnutzen kann. Anwendungen zur Schlüsselverteilung in dynamischen virtualisierten Umgebungen haben bei der Lösung dieses Problems einige Erfolge erzielt. ^{[ 22 ]}

Die rollenbasierte Zugriffskontrolle wird in mehreren regulatorischen Rahmenwerken erwähnt oder impliziert, die von Organisationen verlangen, den Zugriff auf sensible Informationen auf der Grundlage der jeweiligen Funktion einzuschränken.

Die Sicherheitsregel des Health Insurance Portability and Accountability Act (HIPAA) verpflichtet betroffene Einrichtungen zur Implementierung technischer Richtlinien und Verfahren, die den Zugriff auf elektronische geschützte Gesundheitsinformationen ausschließlich Personen oder Softwareprogrammen mit entsprechenden Zugriffsrechten ermöglichen (45 CFR 164.312(a)(1)). ^{[ 23 ]} Der HIPAA- Standard des minimalen Zugriffs verlangt zudem, dass der Zugriff auf die minimal erforderliche Menge an geschützten Gesundheitsinformationen beschränkt wird , um den beabsichtigten Zweck zu erfüllen. Dieses Prinzip deckt sich direkt mit der rollenbasierten Zugriffskontrolle. ^{[ 24 ]} Die im Dezember 2024 veröffentlichte Bekanntmachung über die vorgeschlagene Regelung (NPRM) zur Überarbeitung der HIPAA-Sicherheitsregel würde die Implementierung einer rollenbasierten Zugriffskontrolle für elektronische geschützte Gesundheitsinformationen (ePHI) vorschreiben, die betroffenen Mitarbeiter innerhalb von 24 Stunden über Änderungen der Zugriffsrechte informieren und die Klassifizierung von Zugriffskontrollen als lediglich „adressierbare“ Spezifikationen aufheben. ^{[ 25 ]}

Der Payment Card Industry Data Security Standard (PCI DSS) schreibt vor, dass der Zugriff auf Systemkomponenten und Karteninhaberdaten auf Personen beschränkt sein muss, deren Tätigkeit einen solchen Zugriff erfordert, und dass der Zugriff auf Grundlage der Stellenklassifizierung und Funktion zugewiesen wird (Anforderung 7). ^{[ 26 ]}

• David F. Ferraiolo, D. Richard Kuhn und Ramaswamy Chandramouli (2007). Rollenbasierte Zugriffskontrolle (2. Aufl.). Artech House. ISBN 978-1-59693-113-8Die

• Häufig gestellte Fragen zu RBAC-Modellen und -Standards
• Rollenbasierte Zugriffskontrollen beim NIST
• XACML-Kern und hierarchisches rollenbasiertes Zugriffskontrollprofil