5. Zugriffsschutz

5. Zugriffsschutz
1
5. Zugriffsschutz
Kontrolliert Zugriffe von Subjekten auf Objekte
Beispiele:
Prozessor überschreibt Speicherzelle:
Benutzer erweitert Paßwortdatei:
Prozess sucht in einem Verzeichnis:
Benutzer will auf Farbdrucker drucken:
CLEAR 0
append /etc/passwd
ls documents
lpr –Pcdu picture.pdf
Bestimmt
– was ein Subjekt tun darf
– was mit einem Objekt getan werden kann
Zugriffsschutz regelt, in welcher Weise welche Subjekte auf welche Objekte zugreifen können.
Subjekte sind in der Regel Benutzer bzw. Prozesse die im Auftrag von Benutzern laufen.
Objekte können Dateien, Speicherzellen, Drucker etc. sein. Der Zugriffsschutz bestimmt, was
ein Subjekt in einem System (für dass der Zugriffsschutz definiert wurde) tun darf, bzw. was
mit den Objekten getan werden kann.
2
5.1. Zugriffsschutzstrategie
(access control policy)
Aussagen über erwünschte/unerwünschte
Änderungen des Sicherheitszustandes
Sollte präzise formuliert sein, möglichst mit
geeigneter (formaler) Sprache (policy language)
Klassen von Zugriffsschutzstrategien
– benutzerbestimmbare Strategien
– systembestimmte Strategien
– rollenbasierte Strategien
Eine Zugriffsschutzstrategie (access control policy) beschreibt die erlaubten und verbotenen
Zugriffe, z.B. wie Benutzer auf Dokumente oder andere Informationen zugreifen können und
wie sich durch diese Zugriffe der Sicherheitszustand des Systems ändert. Eine
Zugriffsschutzstrategie besteht aus einer Menge von Regeln, auf denen die
Zugriffsschutzentscheidung des Systems basiert. Eine Sicherheitsstrategie sollte möglichst
präzise formuliert werden, um einen hohen Qualitätsstandard für die Sicherheit des Systems zu
erreichen.
Politiksprachen
(policy
languages)
ermöglichen
zum
einen,
Sicherheitsanforderungen zu dokumentieren und so zu formulieren, dass sie bei der
Systementwicklung geeignet umgesetzt werden können. Bei besonders sicherheitskritischen
Systemen werden formale Sprachen eingesetzt, mit denen sich die Sicherheit des Systems
verifizieren lässt. Wir unterscheiden drei Klassen von Zugriffsschutzstrategien:
benutzerbestimmbare, systembestimmte und rollenbasierte Strategien.
3
5.1. Zugriffsschutzstrategie
(access control policy)
Benutzerbestimmbare Zugriffskontrolle (discretionary access
control, DAC):
– Eigentümer-Prinzip: Jedes Objekt hat ein Subjekt als Eigner
– Eigentümer ist für Schutz zuständig, d.h. Zugriffsschutzstrategie
vom Benutzer bestimmt.
– Benutzer können Berechtigungen auf ihre Objekte an andere
weitergeben.
– Keine systemglobalen Sicherheitseigenschaften
Die benutzerbestimmbare Zugriffskontrolle (discretionary access control, DAC) basiert auf
dem Eigentümer-Prinzip. Das bedeutet, dass der Eigentümer eines Objektes für dessen Schutz
verantwortlich ist, so dass eine Sicherheitsstrategie (evtl. auch ad hoc) vom Benutzer bestimmt
wird. Die Benutzer (d.h. die Subjekte) können ihre Zugriffsberechtigungen oder einen Teil der
Berechtigungen an ihren Objekten (evtl. indirekt) einem anderen Benutzer (bzw. Subjekt)
übertragen. Mit DAC werden keine systemglobalen Sicherheitseigenschaften festgelegt.
4
5.1. Zugriffsschutzstrategie
(access control policy)
Systembestimmte Zugriffskontrolle (mandatory access control, MAC):
– Beschreibt systemglobale Sicherheitseigenschaften, d.h. nicht der
Benutzer legt die Strategie fest.
– Zugriffsberechtigungen festgelegt über Geheimhaltungsgrad von
Subjekten und Objekten.
– Rechte-Änderungen sind somit stärkeren Beschränkungen
unterworfen (z.B. Sicherheitsbeauftragter statt Eigner) und/oder
zusätzliche systemweite Zugriffs-Restriktionen kommen zum
Einsatz
Die systembestimmte Zugriffskontrolle (mandatory access control, MAC) spezifiziert
systemglobale Eigenschaften, d.h. der Zugriff auf Objekte eines Systems wird gemäß einer für
das System festgelegten Sicherheitspolitik bestimmt (nicht durch die eines Benutzers wie bei
DAC) und schützt gegen die unberechtigte Weitergabe von Rechten auf Objekten durch zum
Zugriff berechtigte Subjekte. In MAC sind Zugriffsberechtigungen durch den
Geheimhaltungsgrad und die Kategorie des Objekts (Einstufung, die in einem Label am Objekt
zum Ausdruck kommt) und durch die formale Ermächtigung des zugreifenden Subjekts
festgelegt. Innerhalb des MAC kann DAC eingesetzt werden, wobei die MAC-Regeln die
DAC-Regeln dominieren, d.h. ein Zugriff wird verweigert, wenn es eine MAC-Regel gibt, die
diesen Zugriff verbietet, selbst wenn eine DAC-Regel den Zugriff erlaubt.
5
5.1. Zugriffsschutzstrategie
(access control policy)
Rollenbasierte Zugriffskontrolle (role-based access
control, RBAC):
– Fokus auf auszuführende Aufgaben
zusammengefasst in Rollen
– Rollen als Vermittler zwischen Subjekt und Objekt
– Subjekte erhalten über Rollenmitgliedschaft
Berechtigungen zum Ausführen von Aufgaben
Rollenbasierte Zugriffskontrolle (role-based access control, RBAC) stellt die
durchzuführenden Aufgaben im System in den Vordergrund des Rechtemanagements.
Subjekte erhalten über Rollenmitgliedschaften Berechtigungen zum Ausführen von Aufgaben.
6
5.2. Zugriffsschutzmodell
• modelliert Zugriffsschutzstrategien durch Abstraktion
von konkreten
– Subjekten (z.B. Menschen, Prozessen, Rollen...)
– Objekten (z.B. Segmenten, Geräten, Dateien, Tabellen,...)
– Rechten (z.B. Leserecht, Erwerbsrecht,...)
• Beispiele
–
–
–
–
Zugriffsmatrix-Modell (DAC)
RBAC-Modelle (RBAC)
Chinese Wall (MAC)
Bell-LaPadula Modell (MAC)
Ein Zugriffsschutzmodell ist eine abstrakte und präzise Repräsentation einer
Zugriffsschutzstrategie. In den Modellen wird von konkreten Subjekten, Objekten und Rechten
abstrahiert und nur die Regeln aufgestellt, wie ein System sich verhalten soll. Für
Hochsicherheitssysteme werden formale Zugriffsschutzmodelle benutzt, in denen
Sicherheitseigenschaften verifiziert werden können.
Es gibt eine ganze Reihe von Zugriffsschutzmodellen. Das Access Matrix Modell ist ein
grundlegendes Modell, in dem der Sicherheitszustand eines Systems durch eine Matrix
modelliert wird, welche für jedes Objekt eine Spalte und jedes Subjekt eine Zeile besitzt. Ein
Eintrag in einer Matrix spezifiziert die Zugriffsrechte, die ein Subjekt auf ein Objekt besitzt.
Rollen-basierte Modelle setzen das Konzept des rollen-basierten Zugriffschutzes um und
Beispiele für systembestimmte Zugriffsschutzmodelle sind das Chinese-Wall-Modell und das
Bell-LaPadula-Modell.
7
5.2. Zugriffsschutzmodell
Gegeben seien Mengen
Objekte
Subjekte
Rechte
sollen geschützt werden
wollen aktiv auf Objekte zugreifen
notwendig für eine Aktion
Die Mengen der Objekte und Subjekte sind nicht
notwendig disjunkt
Das Zugriffmatrix-Modell (access matrix model) ist das einfachste und älteste
Zugriffsschutzmodell. Es bietet die Möglichkeit, Objekte und Subjekte zugeschnitten auf die
zu konstruierende Anwendung festzulegen sowie Zugriffsrechte universell oder objektspezifisch zu modellieren. Es basiert auf drei Mengen: Den Objekten, welche geschützt werden
sollen, den Subjekten, die aktiv auf die Objekte zugreifen wollen und die Rechte, die
notwendig für den Zugriff der Subjekte auf die Objekte sind, um Aktionen auszuführen.
Hierbei müssen die Subjekt- und Objektmengen nicht notwendigerweise disjunkt sein.
8
5.2.1. Zugriffsmatrix-Modell
(access matrix model)
Zugriffsschutzmatrix beschreibt Schutzzustand eines Systems zum
Zeitpunkt t
Objekte
Datei 1 Datei 2 Prozess 1
Drucker
Subjekte
Benutzer 1
Prozess 1
Benutzer 2
read,
write
read,
delete
write
write,
append
block,
wakeup
write
write
Der Schutzzustand eines Systems (zu einem bestimmten Zeitpunkt t) wird durch eine
Zugriffsschutzmatrix (access control matrix) modelliert. Die Spalten der Matrix werden
durch die Objekte (zum Zeitpunkt t) definiert, die Zeilen der Matrix durch die Subjekte des
Systems (zum Zeitpunkt t). Ein Eintrag M(s,o) in der Zeile s und der Spalte o beschreibt die
Menge der Rechte, die das Subjekt s an dem Objekt o besitzt. Im obigen Beispiel hat Benutzer
1 die Rechte read und write auf die Datei 1, Benutzer 2 besitzt hingegen keine Rechte auf
Datei 1.
9
5.2.1. Zugriffsmatrix-Modell
(access matrix model)
Varianten der Zugriffsschutzmatrix
Getypte Objekte und damit typgebundene Rechte
Hinzunahme von Spalten für Gruppen von
Objekten, z.B. alle Objekte eines bestimmten Typs
Hinzunahme von Zeilen für Gruppen von
Subjekten
und weitere
Basierend auf dem klassischen Modell der Zugriffsschutzmatrix wurden weitere Varianten
entwickelt. So kann man die zu schützenden Objekte typisieren und typgebundene Rechte
betrachten bzw. Objekte in Gruppen eines Typs zusammenfassen und Rechte dem Typ
zuordnen. Dann haben alle Instanzen dieses Objekttyps die Rechte. Genauso kann man
Subjekte (bzw. Objekte) in Gruppen zusammenfassen, um so Rechte an die gesamte Gruppe zu
verteilen. Dann hat jedes Subjekt (bzw. Objekt) der Gruppe diese Rechte.
10
5.2.1. Zugriffsmatrix-Modell
(access matrix model)
Schutzmatrix kann statisch oder dynamisch sein
statische Matrix:
Rechtevergabe wird nicht geändert
Kann benutzt werden, wenn die Rechte von Anfang an
bekannt sind und über längere Zeit konstant bleiben.
dynamische Matrix:
Rechtevergabe ändert sich
Zustandsänderungen werden durch Kommandos
beschrieben.
Beispiel: Modell von Harrison, Ruzzo und Ullman
Die Zugriffsschutzmatrix kann statisch bzw. dynamisch sein. Bei einer statischen Matrix ist
keine Änderung der Rechtevergabe, d.h. der Matrixeinträge möglich. Statische Matrizen sind
zur Modellierung von Anwendungsproblemen geeignet, in denen der Rechtezustand vorher
bekannt ist und über eine längere Zeit konstant bleibt. Im Gegensatz dazu verändert sich bei
einer dynamischen Matrix die Rechtevergabe, wobei Kommandos die möglichen Änderungen
modellieren. Harrison, Ruzzo und Ullman haben ein solches Modell für die dynamische
Modifikation der Zugriffsschutzmatrix im Artikel [HRU76] vorgestellt.
[HRU76] Harrison, Ruzzo, Ullman. Protection in Operating Systems. Communications of the
ACM, 19(8):461-471,1976
11
5.2.1. Zugriffsmatrix-Modell
(access matrix model)
Harrison-Ruzzo-Ullman (HRU) Modell
Modifikation der Zugriffsschutzmatrix mit folgenden
Elementaroperationen
Eintragen eines Rechtes:
Entfernen eines Rechtes:
Erzeugen eines Subjekts:
Löschen eines Subjekts:
Erzeugen eines Objekts:
Löschen eines Objekts:
enter r into M(s,o)
delete r from M(s,o)
create subject s
delete subject s
create object o
delete object o
Im HRU-Modell kann der Schutzzustand des Systems (d.h. die Zugriffsschutzmatrix) durch
die Ausführung von Kommandos zur Erzeugung und zum Löschen von Subjekten bzw.
Objekten oder zur Weitergabe und Rücknahme von Zugriffsrechten verändert werden.
Harrisson, Ruzzo und Ullman definieren in [HRU76] sechs Elementaroperationen zum
Erzeugen (create) bzw. Löschen (destroy) von Objekten und Subjekten sowie zur
Rechteweitergabe (enter) und –rücknahme (delete).
12
5.2.1. Zugriffsmatrix-Modell
(access matrix model)
Kommandos zur Veränderung des Schutzzustandes
COMMAND com(s1,...,sN, o1,...,oK)
IF r1 IN M(si1,oj1)
...
rm IN M(sim,ojm)
THEN op1,..,opa
END
mit s1,...,sN, o1,...,oK formale Parameter,
op1,..,opa Elementaroperationen
Mit diesen sechs Elementaroperationen können Kommandos gebildet werden, die die
Zugriffsschutzmatrix in einen neuen Zustand transformieren. Die Folie zeigt die Struktur eines
solchen Kommandos. Ein Kommando hat einen Namen und eine Parameterliste von Subjekten
und Objekten, die von der Schutzmatrixtransformation betroffen sind. In einem Kommando
können mehrere Elementaroperation aufgelistet werden, die beim Aufruf des Kommandos
ausgeführt werden. Die Ausführung der Elementaroperationen kann zusätzlich an
Bedingungen geknüpft sein, die in einem if-then-Ausdruck spezifiziert sind. Die Bedingungen
fordern bestimmte Einträge in der Matrix.
13
5.2.1. Zugriffsmatrix-Modell
(access matrix model)
Der Erzeuger einer Datei erhält das Eigentümerrecht
für das neu erzeugte Objekt.
COMMAND create_file( user, file)
create object file;
enter owner into M( user, file);
END
Ein Beispiel-Kommando zeigt die Folie: Das Kommando gibt dem Erzeuger einer Datei das
Eigentümerrecht. Das Kommando besteht aus den zwei Elementaroperationen create object
und enter. Parameter sind der user, welcher die Datei erzeugt und der Name der neuen Datei.
Es gibt keine Bedingungen an die Ausführung der Elementaroperationen innerhalb des
Kommandos.
14
5.2.1. Zugriffsmatrix-Modell
(access matrix model)
Rücknahme eines Rechtes, jedoch nur zulässig für
den Eigner des Objekts
COMMAND revoke_right ( user1, user2, file )
IF owner IN M(user1, file)
right IN M(user2, file)
THEN delete right from (user2, file)
END
In diesem Beispiel wird ein Recht zurückgenommen. Dies darf jedoch nur der Eigner des
Objekts tun, wie die Bedingung spezifiziert. Außerdem wird in der Bedingung gefordert, dass
das zu löschende Recht einen entsprechenden Eintrag in der Matrix besitzt. Das Kommando
enthält nur eine Elementaroperation zum Löschen des Rechts aus der entsprechenden Zelle der
Matrix.
15
5.2.1. Zugriffsmatrix-Modell
(access matrix model)
Safety
Ein Schutzsystem mit Anfangsmatrix M heißt sicher
bzgl. eines Rechtes r, wenn kein Zustandsübergang
möglich ist, bei dem eine Zelle von M um das Recht r
erweitert wird.
Satz (Harrison, Ruzzo, Ullman 1976)
Es ist unentscheidbar, ob ein Schutzsystem M sicher
bzgl. eines Rechtes r ist.
Wenn man nun eine Menge solcher Kommandos hat, ist die Frage interessant, ob die
Ausführung dieser Kommandos den Initialzustand des Systems in einen unerwünschten
Zustand transformieren kann, d.h. in einen Zustand, in dem ein Subjekt ein bestimmtes Recht
erlangt, welches eigentlich gar nicht gewährt werden sollte. Harrison, Ruzzo und Ullman
haben in [HRU76] gezeigt, dass dieses als Saftey-Problem bezeichnete Problem
unentscheidbar ist, indem sie es auf das Halteproblem von Turing-Maschinen zurückführten.
Es gibt also keinen Entscheidungsalgorithmus, der für beliebige Kommandomengen
entscheiden könnte, ob ein Recht in einem Eintrag der Matrix erscheinen wird oder ncht.
16
5.2.1. Zugriffsmatrix-Modell
(access matrix model)
Durch Einschränkung des Zugriffsschutzmatrixmodells kann man
Entscheidbarkeit erhalten
Safety ist entscheidbar, wenn
– das System mono-operational ist, d.h. Kommandos bestehen
aus genau einer Elementaroperation (jedoch NP-vollständig)
– Subjekt- und Objektmengen endlich sind
Feststellung:
Sicherheitsgarantien zu geben ist nur für sehr
einfache Systeme leicht möglich – und im allgemeinen
schwierig bis unmöglich.
Durch Einschränkung des Zugriffsschutzmatrixmodells lässt sich das Safety-Problem in diesen
restriktiveren Modellen jedoch entscheiden.
Mögliche Einschränkungen sind monooperationale Kommandos bzw. endliche Subjekt- oder Objektmengen. Ein Kommando heißt
mono-operational, wenn es genau aus einer Elementaroperation besteht. Mit beiden
Einschränkungen kann gezeigt werden, dass das Sicherheitsproblem dann entscheidbar ist.
Da diese Einschränkungen jedoch sehr stark sind, sind diese Modelle für die Praxis wenig
relevant. Es ist also festzustellen, dass man zwar Sicherheitsgarantien für sehr einfache
Systeme geben kann, dies aber für allgemeine (und praxisrelevante) Systeme sehr schwierig
bzw. unmöglich ist.
17
5.2.1. Zugriffsmatrix-Modell
(access matrix model)
Implementierungen der Zugriffsschutzmatrix
Zweidimensionale Implementierung ist ineffizient, da Matrix
in der Regel dünn besetzt.
Zugriffkontrolllisten (Access Control List, ACL)
objektbezogene Sicht der Matrix
Zugriffsausweise (Capabilities)
subjektbezogene Sicht der Matrix
Da eine Zugriffschutzmatrix in der Regel nicht sehr dicht besetzt ist, wäre eine
zweidimensionale Implementierung ineffizient. In heutigen IT-Systemen werden in der Regel
zwei Konzepte zur Implementierung einer Zugriffsmatrix verwendet: Zugriffskontrolllisten
(access control list) und Zugriffsausweise (capability). Mit Access Control Lists (ACL) wird
eine objektbezogene Sicht auf die Zugriffsmatrix realisiert, während bei Capabilities eine
subjektbezogene Sicht eingenommen wird.
18
5.2.1. Zugriffsmatrix-Modell
(access matrix model)
Objekt-Sicht (ACL)
Objekte Datei 1
Datei 2
Prozess 1
Drucker
write
block,
wakeup
write
Subjekte
Benutzer 1
read,
write
Prozess 1
read,
delete
Benutzer 2
SubjektSicht
(Capability)
write,
append
write
Die Folie spiegelt die beiden Sichten auf die Zugriffsmatrix wieder. Aus der Sicht von Datei 1
ergibt sich beispielsweise eine Liste {(Benutzer 1, {read,write}), (Prozess 1, {read, delete}) }
mit Einträgen (Subjekt, Rechtemenge), die die Subjekte mit ihren erlaubten Zugriffen auf das
Objekt (in diesem Beispiel Datei 1) auflistet. Aus der Subjektsicht für Benutzer 2 ergibt sich
beispielsweise eine Liste (Datei2, {write,append}), (Drucker, {write})) mit Einträgen (Objekt,
Rechtemenge), die die Objekte mit den möglichen Zugriffen des Subjekts auflistet.
19
5.2.1.1 Access Control List
ACL implementiert Zugriffsmatrix spaltenweise
ACL ist listenartige Struktur, die Objekten zugeordnet wird.
Listeneintrag identifiziert Subjekt sowie seine Rechte auf das Objekt.
Beispiel Unix:
-rwxrwxrwx
mkoch inst 12345 Feb 2 12:34 DATEI
Subjekte sind Eigner, Gruppe und alle anderen.
Rechte sind read (r), write (w) und execute (x).
Wie gesehen, implementieren Access Control Lists eine Zugriffsmatrix spaltenweise. Die ACL
ist eine listenartige Struktur, die einem Objekt zugeordnet ist. Jeder Listeneintrag identifiziert
ein Subjekt, sowie die Rechte, die dem Subjekt an dem Objekt eingeräumt werden. Ein
Beispiel ist die ACL zum Dateischutz in UNIX-Betriebssystemen. Einer Datei wird eine Liste
zugeordnet, die die Rechte für den Eigner der Datei, einer Gruppe und allen anderen Benutzern
beschreibt. In UNIX gibt es die drei Rechte read, write und execute, die dem Subjekten Eigner,
Gruppe und Rest der Welt zugeordnet werden können.
20
5.2.1.1 Access Control List
Vorteile der ACL
einfache Verwaltung, insbesondere effiziente Rechterücknahme
Einfach zu bestimmen, welche Subjekte Zugriff auf ein Objekt haben.
Nachteile der ACL
Schwierig, die aktuellen Rechte eines Subjektes zu bestimmen.
Bei langen ACLs ist Zugangskontrolle aufwendig und ineffizient.
Schlechte Skalierbarkeit, wenn viele Subjekte unterschiedliche Rechte
besitzen können.
Die Vorteile der ACL liegen in der einfachen Verwaltung, insbesondere in der einfachen und
effizienten Realisierung der Rechterücknahme. Dazu müssen nur die entsprechenden Einträge
in der ACL aktualisiert werden. Außerdem ist es sehr einfach für ein Objekt zu bestimmen,
welche Subjekte welche Zugriffsrechte auf dem Objekt haben. Hingegen ist es schwierig für
ein Subjekt (z.B. für einen Benutzer) die Menge seiner aktuellen Rechte zu ermitteln. Bei
langen ACLs wird die Zugriffskontrolle aufwendig und ineffizient, da bei jedem Zugriff auf
das Objekt die gesamte ACL zu durchsuchen ist. Dies hat zur Folge, dass viele Systeme nur
sehr einfache Listenstrukturen zulassen (z.B. UNIX). In Systemen mit einer Vielzahl von
Subjekten, die unterschiedliche Rechte auf Objekten besitzen können, ist das ACL-Konzept
aufgrund seiner schlechten Skalierbarkeit eher ungeeignet. Ein Beispiel sind CORBA-basierte
verteilte Systeme, bei denen es wünschenswert ist, differenzierte Berechtigungen auf die
Operationen von CORBA-Objekten für unterschiedliche Subjekte zu verteilen.
21
5.2.1.2 Capabilities
Capabilities implementieren die Zugriffsmatrix zeilenweise.
Capability besteht aus Objektreferenz und Berechtigungen.
Jedem Subjekt ist eine Capability List (CL) zugeordnet, z.B. bei
generischen Rechten R,W:
Objekt
R
W
0
Capability List
1
2
3
Capabilities implementieren die Zugriffsmatrix zeilenweise (im Gegensatz zur spaltenweisen
Implementierung von ACLs). Eine Capability besteht aus einer Objektreferenz und den
Berechtigungen, die durch die Capability an dem Objekt eingeräumt werden. Jedem Subjekt
wird dann eine Liste, die Capability List, von Paaren (Objektreferenz, Zugriffsrechte)
zugeordnet. Diese Liste spiegelt die Einträge in der dem Subjekt zugeordneten Zeile der
Matrix wider.
22
5.2.1.2 Capabilities
Capabilities erfüllen ihre Schutzfunktion nur, wenn sie
nicht gefälscht werden können.
Schutz von Capabilities
getaggte Architekturen
Jedes Speicherwort hat Tag-Bit, das sagt
ob es
sich um eine Capability oder ein
normales Datenwort handelt.
Tag-Bit gesetzt: keine Modifikation möglich
Damit Capabilities nicht einfach kopiert bzw. modifiziert werden und an unautorisierte
Benutzer gegeben werden, gibt es mehrere Schutzmechanismen für Capabilities: das Arbeiten
mit Tags, Verwenden von geschütztem Speicher und Kryptographie . Bei getaggten
Architekturen ist jedem Speicherwort ein Tag-Bit zugeordnet. Über das Tag-Bit wird für jedes
Speicherwort festgelegt, ob es sich um eine Capability oder um ein normales Datenwort
handelt. Wenn das Tag-Bit gesetzt ist, kann das Speicherwort von jedem Prozess gelesen aber
nicht modifiziert werden. Das Tag-Bit kann nur von einem Prozess im privilegierten Modus
geändert werden.
23
5.2.1.2 Capabilities
Capability-Segmente
Capabilities werden in eigenem Segment
verwaltet.
Zugriff auf dieses Segment erfordert
Privilegien.
spezielle
Kann mit vorhandenem Speicherschutz realisiert
werden.
Ein weiterer Ansatz zum Schutz der Capabilities sind Capability-Segmente. Ein CapabilitySegment enthält ausschließlich Capabilities. Dieses Segment kann von Prozessen gelesen, aber
nicht geändert werden. Der Zugriff auf Capability-Segmente erfordert spezielle Privilegien, die
dem Betriebssystem erteilt werden. Capability-Segmente können mit den vorhandenen
Mechanismen des Speichermanagements realisiert werden und erfordern keine spezielle
Hardware.
24
5.2.1.2 Capabilities
Verschlüsselung von Capabilities
Zur Erkennnung von Capability-Modifikationen
(z.B. zusätzliche Rechte)
Capabilities wird verschlüsselter Hash-Wert
zugeordnet.
Betriebssystem prüft die Integrität der
präsentierten Capability bzgl. des Hash-Wertes.
Ein dritte Möglichkeit zum Schutz der Capabilities bietet die Kryptographie. Jeder Capability
wird ein verschlüsselter Hash-Wert zugeordnet. Wenn ein Prozess eine solche Capability dem
Betriebssystem präsentiert, berechnet das Betriebssystem dessen Hash-Wert und entschlüsselt
dann die empfangene Capability. Sind beide Werte gleich, ist die Capability unmodifiziert.
Andernfalls wird die Capability abgelehnt.
25
5.2.1.2 Capabilities
Vorteile von Capabilities
Einfache Bestimmung der Subjekt-Rechte
Einfache Zugangskontrolle (kein Durchsuchen langer Listen)
Einfache Weitergabe von Capabilities (sind nicht mit Subjekten
identifiziert)
Nachteile von Capabilities
Rechterücknahme sehr schwierig
Verteilung der Capabilities ist nicht leicht zu kontrollieren
Objekt-Sicht ist schwierig
Capabilities erlauben eine einfache Bestimmung der Subjekt-Rechte, da die Rechte direkt ans
Subjekt gebunden sind. Zugriffskontrollen können außerdem einfach realisiert werden, da nur
die eine Capability des Subjekts geprüft werden muss. Das aufwendige Durchsuchen von
Zugriffskontrolllisten ist nicht nötig. Capabilities sind nicht an Subjekte gebunden (sie
enthalten keinen Subjekt-Identifikator) und können daher einfach an andere Subjekte
weitergegeben werden.
Zu den Nachteilen von Capabilities gehört die dynamische Rechterücknahme. Dazu müssen
die Capabilities entweder zurückgefordert oder ungültig gemacht werden. Die Rückforderung
ist jedoch nicht praktikabel, da Capabilities unbeschränkt kopiert werden können. Capabilities
können ungültig gemacht werden, indem diejenige Instanz, welche eine Capability ausstellt,
eine Tabelle mit gültigen Capabilities verwaltet. Bei der Vorlage einer Capability kann dann
die Gültigkeit überprüft werden.
26
5.2.1.3 Lock/Key
Lock/Key-Verfahren:
Kombination aus ACL und Capabilities
Jedes Subjekt s besitzt eine Key-Liste: (...,(o,K),...)
Jedes Objekt o besitzt eine Lock-Liste: (...,(L,a),...)
K ist ein Schlüssel, L ist ein Schloss und a eine
Menge von Zugriffsrechten
Eine Kombination aus ACLs und Capabilities ist das Lock/Key-Verfahren. In diesem
Verfahren wird jedem Subjekt s eine Capability-Liste zugeordnet, die Paare der Form (o,K)
enthält. Dabei bezeichnet o ein Objekt, auf das Subjekt s unter Anwendung des Schlüssels K
zugreifen will. Jedes Objekt o besitzt eine ACL, die Einträge der Form (L,a) enthält. Hierbei
ist L ein Schloss und a sind die Rechte, die ein Besitzer eines zum Schloss L passenden
Schlüssels K auf dem Objekt o hat.
27
5.2.1.3 Lock/Key
Zugriffsversuch: Subjekt s auf Objekt o mit Rechten b
1) Subjekt s sucht (o,K) aus seiner Key-Liste
2) Zugriffskontrolle prüft:
Gibt es einen Eintrag (L,a) in der Lock-Liste von
o mit L=K?
Gilt für dieses (L,a), dass b Teilmenge der
Rechtemenge a ist?
Möchte ein Subjekt s gemäß der Rechte b auf ein Objekt o zugreifen, so legt s seine Capability
(o,K) dem Objekt o vor. Ein Zugriff ist möglich, wenn zum einen der Schlüssel K zum Schloss
L passt, d.h. wenn es einen Eintrag (L,a) mit K=L für das Objekt o gibt. Zum anderen müssen
auch die vom Subjekt gewünschten Rechte zulässig sein, also b muss eine Teilmenge von a
sein.
28
5.2.1.3 Lock/Key
Einfache und effiziente Rücknahme von Rechten:
Verändern des Schlosses in der Lock-Liste (ACL)
‡ Schlüssel passen nicht mehr.
Neue aktuelle Capabilities können bei einer
Abweisung neu beantragt werden.
In der Praxis selten in dieser Form, vielmehr stark vereinfachte
Kombination aus ACL und Capabilities.
Eine Rechterücknahme im Lock/Key-Verfahren ist einfach und effizient zu realisieren, da in
der ACL des Objekts (d.h. der Lock-Liste) nur das Schloss L verändert werden muss. Zur
Rücknahme der Rechte sind keine Kenntnisse über aktuelle Besitzer vergebener Capabilities
nötig. Wird der Zugriffsversuch eines Subjektes aufgrund einer Schlossänderung abgewiesen,
kann das Subjekt von der zuständigen Objektverwaltung die Ausstellung einer neuen,
aktuellen Capability beantragen. In der Praxis werden jedoch vielmehr stark vereinfachte
Kombinationen aus ACLs und Capabilities verwendet.
29
5.2.1.4 ACL und Capabilities in UNIX
Spaltenweise Implementierung der Matrix: einfache
ACLs für Dateien
Nach dem Öffnen einer Datei:
Ausstellen eines Datei-Deskriptors (entspricht
Capability)
Objekte sind Dateien und besitzen einen DateiDeskriptor (genannt inode)
Der inode enthält die Attribute der Datei (z.B.
physikalische Adresse auf der Platte, Datei-Eigner,
Dateigröße, ACL,..)
In UNIX-Betriebssystemen werden ACLs in sehr einfacher Form den Dateien zugeordnet.
Dabei werden nur drei Subjekttypen (Eigner, Gruppe, Welt) und drei Rechte (read, write,
execute) unterschieden. Das Konzept der Capabilities benutzt UNIX beim Öffnen einer Datei.
Das Öffnen einer Datei gibt nämlich einen Datei-Deskriptor zurück, der als Capability
angesehen werden kann, und der für alle weiteren Zugriffe auf die Datei benutzt wird. In
UNIX besitzen alle Dateien einen Datei-Deskriptor (genannt inode), in dem die Attribute der
Datei (z.B. Datei-Eigner, ACL, etc.) enthalten sind.
30
5.2.1.4 ACL und Capabilities in UNIX
Zum Zugriff auf eine Datei muss diese zunächst mit dem
Systemcall open geöffnet werden.
fildes = open(path,flags)
Aktionen des UNIX-Kerns
1) Laden der inode der zu öffnenden Datei path
2) Prüfen: Besitzt der Prozess die benötigten Rechte in
der ACL des inodes zum Öffnen der Datei und für die
gewünschten Operationen in flags
3) Falls o.k. gibt es einen Datei-Deskriptor zurück,der
zum Zugriff auf die Datei gemäß flags erlaubt.
Wenn ein Prozess auf eine Datei zugreifen möchte, muss er diese zunächst mit dem openSystemcall öffnen. Dabei werden als Parameter der Pfadname der Datei und die Operationen,
die der Prozess ausführen will, angegeben (z.B. Lesen oder Schreiben). Der Pfadname wird
dann vom System auf den inode der gewünschten Datei abgebildet. Der Kern überprüft dann
anhand der im inode enthaltenen ACL, ob der Prozess die gewünschten Operationen ausführen
kann. Ist der Zugriff zulässig, erzeugt der Kern für den Prozess einen Datei-Deskriptor und
trägt diesen in eine prozesslokale Datei-Deskriptor-Tabelle ein (vergleichbar mit der
Capability-Liste).
31
5.2.1.4 ACL und Capabilities in UNIX
Der mit open generierte Datei-Deskriptor kommt
in die Datei-Deskriptor-Tabelle des Prozesses.
Für jeden generierten Datei-Deskriptor gibt es
einen Eintrag in der globalen Open-File-Tabelle
(enthält Zugriffsrechte).
Einträge in der Open-File-Tabelle zeigen auf den
inode der Datei in der inode-Tabelle.
Für jeden generierten Datei-Deskriptor erzeugt der Kern ebenfalls einen Eintrag in der
systemweiten Open-File Tabelle. In dieser wird vermerkt, für welche Operationen die Datei
vom Prozess geöffnet wurde (z.B. zum Lesen oder zum Schreiben). Jeder Eintrag in der
lokalen Datei-Deskriptor Tabelle eines Prozesses zeigt auf einen eindeutigen Eintrag in der
globalen Open-File-Tabelle des Kerns. Damit kann bei jedem Zugriff auf eine geöffnete Datei
anhand des vom Prozess übergebenen Datei-Deskriptors entschieden werden, ob der Zugriff
gemäß der beim open-Aufruf angegebenen Zugriffsoperationen zulässig ist.
32
5.2.1.4 ACL und Capabilities in UNIX
inode-Tabelle
Datei-Deskriptor-Tabelle
Open-File-Table
/etc/passwd
write
Prozess A
read
read/write
file 1
file 2
Prozess B
Den auf den vorigen Folien beschriebenen Zusammenhang zwischen den prozesslokalen
Datei-Deskriptor-Tabellen und der globalen Open-File-Tabelle bzw. inode-Tabelle zeigt
graphisch die obige Folie.
33
5.2.1.4 ACL und Capabilities in UNIX
Zugriffskontrolle beim read und write Aufruf.
Zugriffe unter Angabe des Datei-Deskriptors.
read( fildes, &buffer, bufsize)
Vor.: read-Recht gesetzt für fildes
write( fildes, &buffer, bufsize)
Vor.: write-Recht gesetzt für fildes
Rechterücknahmen erst bei neuem open-Call!
Beim Zugriff auf geöffnete Dateien werden dann die Datei-Deskriptoren benutzt, um den
Zugriff zu entscheiden. Beispielsweise wird beim Aufruf von read und write der DateiDeskriptor der zu lesenden bzw. zu schreibenden Datei als Parameter übergeben. Dieser DateiDeskriptor verweist auf einen Eintrag in der Open-File-Tabelle, in der gespeichert wurde, für
welchen Zugriffsmodus die Datei geöffnet wurde. Dieser muss beispielsweise für read das
Zugriffsrecht zum Lesen haben, für write das Recht zum Schreiben.
Es ist zu beachten, dass Rechterücknahmen erst nach einen neuem open-Aufruf gültig werden.
Das heißt zum Beispiel, dass ein entzogenes Schreibrecht auf einer Datei solange erhalten
bleibt, bis die Datei geschlossen wird.
34
5.2.1.5 ACL und Capabilities in
Windows
Spaltenweise Implementierung der Matrix: etwas komplexere
ACLs für Dateien
Nach dem Öffnen einer Datei: Ausstellen eines Object-Handles
(entspricht Capability)
Zugriffskontrolle beim Öffnen eines Objekts o
1) Aufruf wird an Security Reference Monitor (SRM)
weitergeleitet.
2) Der SRM entscheidet auf Basis der ACL von o und
der ID des Prozesses, ob der Zugriff erlaubt ist.
3) Falls ja, wird dem Prozess ein Object-Handle mit den
gewünschten Berechtigungen zurückgeliefert,
Auch in Windows-Systemen sind Dateien mt ACLs ausgestattet. Diese sind jedoch etwas
komplexer als im Falle von UNIX. In Windows-Systemen erfordert jeder Zugriff auf ein
Objekt die Vorlage eines Object Handles. Diese Object Handles sind von den Objektmanagern
ausgestellt und sind den Prozessen eindeutig zugeordnet. Möchte ein Prozess ein Objekt öffnen,
so führt er einen Open-Ausruf aus und gibt dabei die gewünschten Zugriffsrechte an. Der
Aufruf wird an den Security Reference Monitor weitergeleitet. Dieser überprüft anhand der
ACL des Objektes, ob der Prozess zur Durchführung der gewünschten Zugriffe berechtigt ist.
Ist dies der Fall, so bekommt der Prozess ein Object Handle mit den gewährten
Berechtigungen.
35
5.2.1.5 ACL und Capabilities in
Windows
Bei Objektzugriffen wird nur noch das Object-Handle
vorgezeigt, um den Zugriff zu entscheiden
(d.h. ist der Zugriff bzgl. der Handle-Berechtigungen
erlaubt?)
Problem:
Keine direkte Aktualisierung von Zugriffsrechten
(weniger Verwaltungsaufwand, höhere Performance)
Rechterücknahme wird erst mit dem Schließen und
dem neu Öffnen einer Datei wirksam.
Bei einem Objektzugriff weist der Prozess nur noch sein Object Handle vor und es wird
überprüft, ob der gewünschte Zugriff des Prozesses in der Berechtigungsliste des Object
Handles enthalten ist. Auch in Windows wird auf eine direkte Aktualisierung von
Zugriffsrechten verzichtet, um den Verwaltungsaufwand zu reduzieren und die Performanz des
Systems zu steigern. Eine Rechterücknahme wird für einen Prozess, der ein Objekt geöffnet
hat und ein Handle dafür besitzt erst dann wirksam, wenn der Prozess das Objekt wieder
schließt und erneut öffnet.
36
5.2 Rollenbasierter Zugriffsschutz
NIST-Standard (NIST = National Institute of Standards and
Technology)
Berechtigungen werden direkt an Aufgaben, d.h. Rollen,
geknüpft (z.B. Filialleiter, Kassierer, Wertpapierberater, ...)
Rolle beschreibt Funktion, Aufgabenkreis, Verantwortlichkeiten
etc. in einer Organisation.
Berechtigungen beziehen sich auf eine oder mehrere
Objekte/Ressourcen.
Reduzierung von Kosten und Komplexität der Sicherheitsadministration.
Rollenbasierter Zugriffsschutz (role based access control, RBAC), von Ferraiolo und Kuhn
1992 und von Sandhu 1996 präsentiert, reduziert die Komplexität und die Kosten der
Sicherheitsadministration in Anwendungen. Seit dem 19. Februar 2004 ist RBAC ein
American National Standard - ANSI INCITS 359-2004. Bei einer rollenbasierten
Modellierung werden die Berechtigungen zur Nutzung von Objekten an Rollen geknüpft, die
bestimmte Aufgaben zu erfüllen haben. Beispiele von Rollen in einer Bankanwendung wären
Filialleiter, Kassierer, Kundenbetreuer, Wertpapierberater etc. Die durch Rollen modellierten
Aufgaben werden von Subjekten ausgeführt, die den Rollen zugeordnet sind.
Original-Artikel:
D.F. Ferraiolo and D.R. Kuhn "Role Based Access Control" 15th National Computer Security
Conference (1992)
37
5.2 Rollenbasierter Zugriffsschutz
Reduzierung von Kosten und Komplexität der Sicherheitsadministration durch Rollen.
Benutzer 1
Drucker
Benutzer 2
Dokument
Benutzer 3
Verzeichnis
Programm X
Wie Rollenbasierter Zugriffsschutz die Komplexität der Verwaltung der Sicherheit in einem
System reduzieren kann, sollen diese und die nächste Folie veranschaulichen. Auf dieser Folie
sind die Rechte direkt den Benutzern zugeordnet. Benutzer 1 hat beispielsweise das Recht, den
Drucker zu benutzen und auf das Dokument zuzugreifen, Benutzer 3 darf das Verzeichnis und
das Programm X nutzen. Benutzer 2 darf alles. Eine Rechteänderung (z.B. neuer Benutzer mit
Rechten für Dokument und Drucker, die Zurücknahme vom Verzeichnisrecht für Benutzer 2
und Benutzer 3, neue Rechte für Drucker und Dokument für Benutzer 3,....) sind relativ
aufwendig zu verwalten, da eine ganze Reihe von Benutzer-Rechte-Verbindungen neu erstellt
werden müssen. Um diese Änderungen zu reduzieren, werden Rollen als Vermittler zwischen
Benutzern und eingeführt.
38
5.2 Rollenbasierter Zugriffsschutz
Reduzierung von Kosten und Komplexität der Sicherheitsadministration durch Rollen.
Drucker
Benutzer 1
Rolle A
Benutzer 2
Benutzer 3
Dokument
Rolle B
Verzeichnis
Programm X
Rollen werden dann mit den Rechten verbunden. Zum Beispiel hat Rolle A das Zugriffsrecht
auf den Drucker und das Dokument, Rolle B das Recht für das Verzeichnis und das Programm
X. Benutzer können dann bestimmte Rollen spielen und bekommen damit die Rechte der Rolle.
So ist Benutzer 1 in Rolle A und hat damit Zugriffsrechte auf den Drucker und das Dokument.
Durch Hinzufügen oder Entfernen eines Rechtes zu bzw. von einer Rolle bekommen alle
Benutzer, die diese Rolle spielen, die Rechteänderung sofort mit. Genauso einfach kann man
einem Benutzer einfach eine Rolle entziehen, um ihm alle Rechte dieser Rolle zu entziehen.
Genauso kann man einen Benutzer zu einer Rolle zufügen, um ihm alle Rechte der Rolle zu
geben.
39
5.2.1 RBAC0
Elementares RBAC-Modell RBAC0
- U (user) ist die Menge der Benutzer im System
- O (objects) ist die Menge der zu schützenden
Objekte im System
- OP (operations) ist die Menge von Operationen, die
auf Objekten ausgeführt werden können
- R (roles) ist die Menge der Rollen
- P = OP x O (permissions) ist die Menge der Rechte
- S (session) ist die Menge der Sitzungen, in denen
Benutzer ihre Rollen aktivieren können.
Das grundlegende Modell des rollenbasierten Zugriffsschutzes nennt sich RBAC0. Dieses
definiert die grundlegenden Mengen und Relationen, auf denen das Modell operiert. Dies ist
die Menge der Benutzer, die am System beteiligt sind, die Menge O der zu schützenden
Objekte, die Menge OP der möglichen Zugriffsoperationen auf diesen Objekte und die Menge
R der Rollen. Die Menge P der Permissions besteht aus Paaren (op,o) einer Operation op und
eines Objekts o. Dieses Permissionpaar gibt dann die Erlaubnis, auf dem Objekt o die
Zugriffsoperation op auszuführen. Ein Benutzer kann seine Rollen in einer Sitzung (session)
aktivieren. Hierbei kann ein Benutzer mehrere Sitzungen besitzen in denen er unterschiedliche
Rollen aktiviert.
40
5.2.1 RBAC0
UR
* * Rollen *
User
PR
*
Rechte P
Operat. * * Objekt
*
1
*
*
Sessions
Rechteverteilung PR Õ P ¥ R
Rollenverteilung UR Õ U ¥ R
user : S Æ U
roles : S Æ 2 R mit roles( s ) = {r | (user ( s ), r ) Œ UR}
‡ Sitzung s hat die Rechte
U{ p | ( p, r ) ΠPR}
rŒroles ( s )
Benutzer können Rollen zugeordnet werden, wobei ein Benutzer mehrere Rollen haben kann
und eine Rolle mehreren Benutzern zugeordnet sein kann. Permissions (bzw. Rechte) werden
Rollen zugeordnet. Eine Rolle kann mehrere Rechte besitzen und ein Recht kann mehreren
Rollen zugeordnet werden. Benutzer können Sessions starten, wobei jede Session eindeutig zu
einem Benutzer zugeordnet sein muss. Die Funktion user weist jeder Session ihren Benutzer
zu. In einer Session können mehrere Rollen des Benutzers aktiviert werden und eine Rolle
kann in mehreren Sessions aktiviert sein. Die Funktion roles weist jeder Session die Menge
der in der Session aktivierten Rollen zu. Damit besitzt der Benutzer in einer Session alle
Rechte der in der Sitzung aktivierten Rollen.
41
5.2.1 RBAC0
Unterschied Rollen und Benutzergruppen
– Rechte einer Rolle leicht änderbar (wie
Capabilities)
– Rechte einer Gruppe nicht leicht änderbar (wie
ACL)
Rollen und Benutzergruppen unterscheiden sich: Rollen sind eine Zusammenfassung von
Aufgaben, während Gruppen eine Zusammenfassung von Benutzern sind. Außerdem können
die Rechte einer Rolle einfach geändert werden (durch Zufügen oder Entfernen eines Rechtes),
womit eine Rolle einer Capability ähnelt. Die Rechte einer Benutzergruppe lassen sich nicht
einfach ändern, da man alle Objekte betrachten muss, auf die die Gruppe Berechtigungen hat.
Damit ähneln Gruppen eher ACLs.
42
5.2.1 RBAC0
Rollenverwaltung und Schutzstrategien:
Rechteverteilung (d.h. Rechte der Rollen) :
anwendungsspezifisch, selten geändert,
vorzugsweise
durch Systementwickler und/oder
zentralem
Sicherheitsverwalter
Rollenverteilung (d.h. Rollen der Benutzer):
gemäß Personalverwaltung, öfter geändert, vorzugsweise
von Sicherheitsverwalter und/oder Personalchef
Typische Schutzstrategien bei rollenbasiertem Zugriffsschutz
sind weitgehend systembestimmt durch die Rechte- und
Rollenverteilung.
RBAC ist weitgehend eine systembestimmte Zugriffsschutzstrategie, da die Rechteverteilung
und die Rollenverteilung vom Systemadministrator, Personalverwaltung etc. vorgenommen
wird. Der Benutzer kann nur aus dem ihm zugeordneten Rollen auswählen, aber nicht selbst
neue Rollenmitgliedschaften aufstellen. Die Rechteverteilung ist anwendungsspezifisch und
wird eher selten geändert, da die Aufgaben in einer Organisation als relativ konstant angesehen
werden. Wer diese Aufgaben ausführt, wird allerdings öfter geändert, so dass auch die
Rollenverteilung öfters geändert wird.
43
5.2.2 RBAC1
Aufgaben sind häufig hierarchisch geordnet.
Filialleiter
Kundenbetreuer
Kassierer
Angestellter
z.B. hat ein Filialleiter alle Rechte des Kundenbetreuers und Kassierers
In praktischen Anwendungen werden die Aufgaben und Zuständigkeiten häufig hierarchisch
geordnet. Deshalb wird das RBAC0-Modell um eine Rollenhierarchie erweitert, mit der sich
auch hierarchische Berechtigungsstrukturen ausdrücken lassen. Ein Beispiel einer Hierarchie
in einer Bank zeigt das Beispiel der Folie.
44
5.2.2 RBAC1
Im RBAC1-Modell sind die Rollen zusätzlich partiell
geordnet.
£Õ R ¥ R
y £ x bedeutet: Rolle x erbt alle Rechte von Rolle y,
d.h. „x darf alles was y darf (und mehr)“
Präzisierung:
roles( s ) = {r | r £ t , (user ( s ), t ) Œ UR}
Die Rollenhierarchie ist formal durch eine partielle Ordnung (reflexiv, antisymmetrisch,
transitiv) auf der Menge der Rollen definiert. Wenn y <= x in dieser partiellen Ordnung stehen,
so bedeutet dies, dass die Rolle x alle Rechte besitzt, die auch die Rolle y besitzt. Damit
ergeben sich dann die Rechte in einer Sitzung s aus den Rechten aller in s aktivierten Rollen
und aller Rollen, die von den aktivierten Rollen dominiert werden, d.h. von Rollen, die tiefer
in der Rollenhierarchie stehen.
45
5.2.2 RBAC1
Otto
b
c
a
Filialleiter
Kundenbetreuer
Recht
Kassierer
d
e
Fritz
Angestellter
f
Rechte für Fillialleiter Otto in Session s, d.h. user(s)= Otto:
roles(s) = {Filialleiter, Kundenbetreuer,Kassierer,Angestellter}
daraus ergeben sich die Rechte {a,b,c,d,e,f}
Rechte für Angestellten Fritz in Session s‘, d.h. user(s‘)= Fritz:
roles(s) = {Kundenbetreuer,Angestellter}
daraus ergeben sich die Rechte {b,c,f}
Betrachten wir beispielsweise eine Session des Benutzers Otto, der der Rolle Filialleiter
zugeordnet ist. Dann hat Otto das Recht a, da die Rolle Filialleiter dieses Recht hat. Otto
besitzt aber auch die Rechte b,c,d,e und f, da die Rolle Filialleiter die Rollen Kundenbetreuer,
Kassierer und Angestellter dominiert und damit deren Rechte erbt. Der Benutzer Fritz in der
Rolle Kundenbetreuer besitzt die Rechte der ihm zugeordneten Rolle Kundenbetreuer und der
Rolle Angestellter (somit hat Fritz die Rechte b,c und f).
46
5.2.3 RBAC2
RBAC2 definiert zusätzlich Einschränkungen
(constraints), z.B.
„Kassierer kann nicht Kassenprüfer sein“
„Es gibt nur einen Filialleiter“
„Nur wer Angestellter ist, darf Kundenbetreuer
werden“
RBAC1 kann prinzipiell mit RBAC2 formuliert werden.
Im RBAC2-Modell können zusätzlich Einschränkungen (constraints) definiert werden. Die
Folie zeigt einige Beispiele. Es ist zu bemerken, dass die Constraints des RBAC2-Modells auch
zur Definition einer Rollenhierarchie gemäß RBAC1-Modell genutzt werden können. Wenn y
<= x, so könnte ein Constraint fordern, dass ein Benutzer die Rolle x nur haben darf, wenn er
auch Rolle y hat. Damit hätte der Benutzer in der Rolle x sowohl die Rechte von x als auch die
von y.
47
5.2.3 RBAC2
Klassen von Constraints
Anzahl (Kardinalität) von Rolleninhabern:
Eine Rolle kann nur einer bestimmten Anzahl von Benutzern
zugeordnet werden.
Beispiel:
„Es gibt genau einen Inhaber der Rolle Bundespräsident.“
Rollen-Voraussetzungen:
Eine Rollenmitgliedschaft setzt weitere Rollen voraus.
Beispiel:
„Die Rolle Chefarzt kann nur demjenigen zugeteilt werden, der
schon die Rolle Arzt hat.“
Bei den Constraints gibt es mehrere Klassen, die in Anwendungen häufig auftreten.
Kardinalitäts-Constraints beschränken die Anzahl der Benutzer, die einer Rolle zugeordnet
werden können bzw. fordern eine bestimmte Anzahl von Benutzern in der Rolle. Bei der
Klasse der Rollen-Voraussetzungen handelt es sich um Constraints, die für die Zuordnung
eines Benutzers zu einer Rolle eine (oder mehrere) Rollen für den Benutzer als Voraussetzung
fordern.
48
5.2.3 RBAC2
Ausschluss:
Constraints zum Ausschluss von Rollenmitgliedschaften.
Benutzer-Konflikt:
Ein Paar von Benutzern darf nicht Mitglied derselben Rolle sein.
Beispiel: „Anna Schultze und Fritz Schultze dürfen nicht
gleichzeitig in der Rolle Jury sein“
Rechte-Konflikt:
Ein Paar von Rechten darf nicht derselben Rolle zugeordnet
werden.
Beispiel: „Das Recht zum Genehmigen und Ausstellen eines
Schecks darf nicht in der Verantwortung derselben Rolle liegen“
Eine der häufigsten Constraints sind Constraints zum wechselseitigen Ausschluss von
Rollenmitgliedshaften. Hierbei können Konflikte zwischen Benutzern, Rechten und Rollen
auftreten. Bei einem Benutzer-Konflikt dürfen die im Konflikt stehenden Benutzer nicht
derselben Rolle zugeordnet werden. Bei einem Rechte-Konflikt dürfen die im Konflikt
stehenden Rechte nicht derselben Rolle zugeordnet werden.
49
5.2.3 RBAC2
Benutzer-Rechte-Ausschluss:
Ein Benutzer darf niemals einer Rolle zugeordnet werden.
Beispiel: „Fritz darf niemals die Rolle Bundespräsident haben“
Statische Aufgabentrennung (static separation of duty, SoD):
Zwei bestimmte Rollen dürfen niemals demselben Benutzer
zugeordnet werden.
Beispiel: „Keine Person darf gleichzeitig die Rollen Kassierer und
Kassenprüfer haben“.
Beim Benutzer-Rechte-Ausschluss darf der Benutzer mit der im Konflikt stehenden Rolle
niemals dieser Rolle zugeordnet werden. Bei der statischen Aufgabentrennung (static
separation of duty, SoD) stehen Rollen im Konflikt, d.h. ein Benutzer darf entweder die eine
Rolle haben oder die andere, aber niemals beide. Statisch bedeutet hierbei, dass dies
beispielsweise auch session-übergreifend ist, d.h. er darf auch nicht die eine Rolle in einer
Session, die andere in einer anderen Session aktivieren.
50
5.2.3 RBAC2
Dynamisches SoD:
Zwei bestimmte Rollen dürfen nicht gleichzeitig in einer Sitzung
desselben Benutzers aktiviert werden.
Beispiel: „Die Rollen Schiedsrichter und Spieler dürfen nicht
gleichzeitig ausgeübt werden.“
Das dynamische SoD beschränkt sich auf die aktive Session eines Benutzers. Nur bezüglich
einer Session stehen die Rollen in Konflikt, d.h. in einer Session dürfen die Rollen nicht
gleichzeitig aktiviert werden. Es ist jedoch für einen Benutzer erlaubt, in einer Session die eine
Rolle, in einer anderen Session die andere Rolle zu aktivieren.
51
5.2.4 RBAC3
RBAC3 fasst RBAC1 und RBAC2 zusammen.
Damit ergeben sich zusätzliche Möglichkeiten wie
z.B.
– Keine Mehrfachvererbung
– Mehrfachvererbung nur dann, wenn die
Unterrollen sich nicht ausschließen
– Es gibt höchstens eine Rolle, die mächtiger als
Rolle r ist
– etc.
Das RBAC3-Modell fasst die Modelle RBAC1 und RBAC3 zusammen. Damit lassen sich
zusätzliche Constraints bzgl. der Rollenhierarchie auftsellen. Beispiele solcher Constraints
zeigt die Folie.
52