Zugriffskontrollstrategien / Access Control Models

/by

Tags: access control, mandatory access control, mac, discretionary access control, dac, role-based access control, rbac
Last update: Nov 2020

Dieser Artikel vermittelt einen Überblick über die verschiedenen geläufigen Zugriffskontrollstrategien:

  • Discretionary Access Control (DAC)
  • Mandatory Access Control (MAC)
  • Role Based Access Control (RBAC)
  • Rule Based Access Control (RuBAC)
  • Attribute Based Access Control (ABAC)

Discretionary Access Control (DAC)

Auch bekannt als: benutzerbestimmbare Zugriffskontrolle.

Für jedes Objekt O, welches von Benutzer A erstellt wird, ist automatisch Benutzer A der Eigentümer dieses Objekts. Benutzer A darf nun als Eigentümer des Objekts allein entscheiden, welche Zugriffsrechte (z. B. Lesen/Schreiben) andere Benutzer X auf sein Objekt O erhalten. DAC ist also eine Zugriffskontrolle, bei welcher die Zugriffsrechte pro Benutzer festgelegt werden. Ob ein Benutzer X Zugriff auf das Objekt O erhält, wird nur auf der Basis der Identität des Benutzers X entschieden.

Beispiele für DAC

  • Ich erstelle eine Tabelle lokal auf meinem Computer und darf allein entscheiden wer sie bekommt, also wer sie sehen und verändern darf. Ich kann für jeden Benutzer auf meinem Computer einzeln nach meinem Ermessen entscheiden, ob er/sie die Tabelle z. B. nur sehen, gar nicht sehen, oder aber auch verändern darf.

Mandatory Access Control (MAC)

Auch bekannt als: zwingend erforderliche Zugangskontrolle.

Zunächst wird vom Systemadministrator für jedes Objekt O eine Einstufung festgelegt (auch genannt: classification, label). Typische Sicherheitsstufen sind z. B. nicht klassifiziert, vertraulich, geheim oder streng geheim. Zusätzlich dazu wird für jeden Benutzer X eine Ermächtigung festgelegt (auch genannt: clearance). Kein Benutzer X kann selbst Änderungen an seiner eigenen Ermächtigung bewerkstelligen. Wie man erkennen kann wird hier nicht nur wie beim DAC rein auf Basis der Identität des Zugreifenden entschieden, sondern auch aufgrund der Eigenschaften (Einstufung/Ermächtigung). Dieses bereits 1973 von David Bell und Len LaPula entwickelte Sicherheitsmodell (daher der Name Bell-LaPadula) ist in den heutigen sog. Multi-Level-Sicherheitssystemen implementiert und ist vor allem im Militärbereich in Anwendung.

Die Umkehrung des Bell-LaPadula-Modells ist das sog. Biba-Modell, welches auch unter der Bezeichnung Low Watermark Mandatory Access Controlbekannt ist.

Hinweis: In einigen Webquellen wird manchmal besonders hervorgehoben, dass die Durchsetzung des MAC-Prinzips in Abgrenzung zu anderen Zugriffskontrollen durch das Betriebssystem erzwungen wird. Hierbei sollte man wissen, dass damit lediglich gemeint ist, dass die Zugriffe durch das System kontrolliert werden und eben nicht nur wie beim DAC nur durch den Eigentümer. Natürlich kontrollieren auch bei allen anderen Zugriffsstrategien die jeweiligen Betriebssysteme die Einhaltung der jeweiligen Prinzipien und Zugriffe. Die technische Ausgestaltung ist hier nicht gemeint. Man sollte sich also von Aussagen nicht irritieren lassen, die so klingen als würde beim MAC *nur* das Betriebssysteme die Grenzen bestimmen, welcher Zugriff gestattet werden darf.

Beispiele für MAC

  • Ich erstelle in einem Multi-Level-System mit meiner Clearance von „streng geheim“ eine neues Objekt O, welches von mir das Label „geheim“ erhält. Alle Benutzer X, welche lediglich eine Clearance von „nicht klassifiziert“ oder „vertraulich“ besitzen, können mein Objekt O nicht sehen, geschweige denn öffnen.

Role Based Access Control (RBAC, RoBAC)

Auch bekannt als: rollenbasierte Zugriffskontrolle.

Bei einer steigenden Anzahl von Benutzern wird die Verwaltung ihrer jeweiligen expliziten Rechte schnell aufwändig und unübersichtlich; daher fehleranfällig. Um den entgegenzuwirken nutzt man die Zusammenfassung und Kategorisierung von Rechten und zwar auf der Basis von abstrahierten Arbeitsprozessen. Das bedeutet, dass einem Benutzer eine oder mehrere sog. Benutzerrollen zugewiesen werden, welche ihre Rechte dem einzelnen Benutzer „vererbt“. Es leuchtet ein, dass Mitarbeiter aus dem Bereich HR beispielsweise keine Rechte haben sollten Konfigurationen am Netzwerk oder Server vorzunehmen.

Beispiele für RBAC

  • Auf einem für alle Benutzer zugänglichen Netzlaufwerk gibt es einzelne Ordner für: Vorstand, IT Administration und Unternehmenswerbung. Während auf den Vorstandordner nur Personen des Managements zugreifen können (diese Personen haben die Rolle Management), können Werkstudenten nur auf den Ordner für die Unternehmenswerbung zugreifen (da sie in die Rolle Werkstudenten besitzen).

Wie man sieht ist die RBAC im obigen Beispiel eine Art erweitertes DAC: Die Zugriffsrechte werden weiterhin pro Benutzer vergeben, jedoch erspart man sich etwas Verwaltungsaufwand in dem man häufig vorkommende Kombinationen von Zugriffsrechten in Rollen definiert, um diese dann Benutzern zuzuweisen. Das heißt der Fokus liegt hier nicht mehr auf der Verwaltung der einzelnen Nutzer sondern eher schwerpunktmäßig auf der Verwaltung von Gruppen von Benutzern. Gerade in Abgrenzung zu DAC sind ebenfalls zwei weitere Dinge wichtig: Während bei DAC der Eigentümer über die Zugriffsrechte entscheidet (wer kann auf meine Daten zugreifen), werden beim RBAC die Zugriffsrechte vom IT Administrator global verwaltet (was darf ein Benutzer tun). Das heißt also insgesamt, dass die Entscheidung über den Zugriff auf Basis der Rolle des Akteurs getroffen wird.

Rule Based Access Control (RuBAC)

Zu deutsch: Regelbasierte Zugriffskontrolle.

Hinter diesem Prinzip verbirgt sich ein Zugriff bzw. eine Entscheidung auf der Basis von Eigenschaften. Regeln erlauben oder verweigern dann den Zugriff.

Beispiele für RuBAC

  • Das TCP-Paket wird an einer Firewall gemäß ihrer Regeln durchgelassen oder verworfen.
  • Studierende dürfen das Labor nur an bestimmten Tagen zu bestimmten Uhrzeiten für Experimente nutzen.

Attribute Based Access Control (ABAC)

Auch bekannt als: attributbasierte Zugriffskontrolle.

Hierbei wird über den Zugriff auf ein Objekt nicht nur mit Hilfe einer Rolle oder expliziten Rechtezuweisung entschieden, sondern vielmehr anhand mehrerer Attribute wie beispielsweise einer Kombination aus Benutzer, Client, einer weiteren Ressource und/oder einem Systemzustand. Der Akteur benötigt also mehrere Attribute/Elemente, um sich gegenüber dem System als berechtigt für den Zugriff auszuweisen.

Beispiele für ABAC

  • Ein Benutzer meldet sich an einem internen Unternehmenssystem mittels OAuth an.

Quellen