5. Zugriffsschutz - Fachbereich Mathematik und Informatik · –das System mono-operational ist, d.h. Kommandos bestehen aus genau einer Elementaroperation (jedoch NP-vollständig)

1

5. Zugriffsschutz

2

5. Zugriffsschutz

Kontrolliert Zugriffe von Subjekten auf Objekte

Beispiele:Prozessor überschreibt Speicherzelle: CLEAR 0Benutzer erweitert Paßwortdatei: append /etc/passwdProzess sucht in einem Verzeichnis: ls documentsBenutzer will auf Farbdrucker drucken: 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, wasein Subjekt in einem System (für dass der Zugriffsschutz definiert wurde) tun darf, bzw. wasmit den Objekten getan werden kann.

3

5.1. Zugriffsschutzstrategie(access control policy)

Aussagen über erwünschte/unerwünschteÄnderungen des Sicherheitszustandes

Sollte präzise formuliert sein, möglichst mitgeeigneter (formaler) Sprache (policy language)

Klassen von Zugriffsschutzstrategien– benutzerbestimmbare Strategien– systembestimmte Strategien– rollenbasierte Strategien

Eine Zugriffsschutzstrategie (access control policy) beschreibt die erlaubten und verbotenenZugriffe, z.B. wie Benutzer auf Dokumente oder andere Informationen zugreifen können undwie sich durch diese Zugriffe der Sicherheitszustand des Systems ändert. EineZugriffsschutzstrategie besteht aus einer Menge von Regeln, auf denen dieZugriffsschutzentscheidung des Systems basiert. Eine Sicherheitsstrategie sollte möglichstpräzise formuliert werden, um einen hohen Qualitätsstandard für die Sicherheit des Systems zuerreichen. Politiksprachen (policy languages) ermöglichen zum einen,Sicherheitsanforderungen zu dokumentieren und so zu formulieren, dass sie bei derSystementwicklung geeignet umgesetzt werden können. Bei besonders sicherheitskritischenSystemen werden formale Sprachen eingesetzt, mit denen sich die Sicherheit des Systemsverifizieren lässt. Wir unterscheiden drei Klassen von Zugriffsschutzstrategien:benutzerbestimmbare, systembestimmte und rollenbasierte Strategien.

4

Benutzerbestimmbare Zugriffskontrolle (discretionary accesscontrol, DAC):

– Eigentümer-Prinzip: Jedes Objekt hat ein Subjekt als Eigner

– Eigentümer ist für Schutz zuständig, d.h. Zugriffsschutzstrategievom Benutzer bestimmt.

– Benutzer können Berechtigungen auf ihre Objekte an andereweitergeben.

– Keine systemglobalen Sicherheitseigenschaften


Die benutzerbestimmbare Zugriffskontrolle (discretionary access control, DAC) basiert aufdem Eigentümer-Prinzip. Das bedeutet, dass der Eigentümer eines Objektes für dessen Schutzverantwortlich ist, so dass eine Sicherheitsstrategie (evtl. auch ad hoc) vom Benutzer bestimmtwird. Die Benutzer (d.h. die Subjekte) können ihre Zugriffsberechtigungen oder einen Teil derBerechtigungen an ihren Objekten (evtl. indirekt) einem anderen Benutzer (bzw. Subjekt)übertragen. Mit DAC werden keine systemglobalen Sicherheitseigenschaften festgelegt.

5


Systembestimmte Zugriffskontrolle (mandatory access control, MAC):

– Beschreibt systemglobale Sicherheitseigenschaften, d.h. nicht derBenutzer legt die Strategie fest.

– Zugriffsberechtigungen festgelegt über Geheimhaltungsgrad vonSubjekten und Objekten.

– Rechte-Änderungen sind somit stärkeren Beschränkungenunterworfen (z.B. Sicherheitsbeauftragter statt Eigner) und/oderzusätzliche systemweite Zugriffs-Restriktionen kommen zumEinsatz

Die systembestimmte Zugriffskontrolle (mandatory access control, MAC) spezifiziertsystemglobale Eigenschaften, d.h. der Zugriff auf Objekte eines Systems wird gemäß einer fürdas System festgelegten Sicherheitspolitik bestimmt (nicht durch die eines Benutzers wie beiDAC) und schützt gegen die unberechtigte Weitergabe von Rechten auf Objekten durch zumZugriff berechtigte Subjekte. In MAC sind Zugriffsberechtigungen durch denGeheimhaltungsgrad und die Kategorie des Objekts (Einstufung, die in einem Label am Objektzum Ausdruck kommt) und durch die formale Ermächtigung des zugreifenden Subjektsfestgelegt. Innerhalb des MAC kann DAC eingesetzt werden, wobei die MAC-Regeln dieDAC-Regeln dominieren, d.h. ein Zugriff wird verweigert, wenn es eine MAC-Regel gibt, diediesen Zugriff verbietet, selbst wenn eine DAC-Regel den Zugriff erlaubt.

6


Rollenbasierte Zugriffskontrolle (role-based accesscontrol, RBAC):

– Fokus auf auszuführende Aufgabenzusammengefasst in Rollen

– Rollen als Vermittler zwischen Subjekt und Objekt

– Subjekte erhalten über RollenmitgliedschaftBerechtigungen zum Ausführen von Aufgaben

Rollenbasierte Zugriffskontrolle (role-based access control, RBAC) stellt diedurchzuführenden Aufgaben im System in den Vordergrund des Rechtemanagements.Subjekte erhalten über Rollenmitgliedschaften Berechtigungen zum Ausführen von Aufgaben.

7

5.2. Zugriffsschutzmodell

• modelliert Zugriffsschutzstrategien durch Abstraktionvon 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 einerZugriffsschutzstrategie. In den Modellen wird von konkreten Subjekten, Objekten und Rechtenabstrahiert und nur die Regeln aufgestellt, wie ein System sich verhalten soll. FürHochsicherheitssysteme werden formale Zugriffsschutzmodelle benutzt, in denenSicherheitseigenschaften verifiziert werden können.

Es gibt eine ganze Reihe von Zugriffsschutzmodellen. Das Access Matrix Modell ist eingrundlegendes Modell, in dem der Sicherheitszustand eines Systems durch eine Matrixmodelliert wird, welche für jedes Objekt eine Spalte und jedes Subjekt eine Zeile besitzt. EinEintrag in einer Matrix spezifiziert die Zugriffsrechte, die ein Subjekt auf ein Objekt besitzt.Rollen-basierte Modelle setzen das Konzept des rollen-basierten Zugriffschutzes um undBeispiele für systembestimmte Zugriffsschutzmodelle sind das Chinese-Wall-Modell und dasBell-LaPadula-Modell.

8

5.2. Zugriffsschutzmodell

Gegeben seien Mengen

Objekte sollen geschützt werdenSubjekte wollen aktiv auf Objekte zugreifenRechte notwendig für eine Aktion

Die Mengen der Objekte und Subjekte sind nichtnotwendig disjunkt

Das Zugriffmatrix-Modell (access matrix model) ist das einfachste und ältesteZugriffsschutzmodell. Es bietet die Möglichkeit, Objekte und Subjekte zugeschnitten auf diezu konstruierende Anwendung festzulegen sowie Zugriffsrechte universell oder objekt-spezifisch zu modellieren. Es basiert auf drei Mengen: Den Objekten, welche geschützt werdensollen, den Subjekten, die aktiv auf die Objekte zugreifen wollen und die Rechte, dienotwendig 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.

9

5.2.1. Zugriffsmatrix-Modell(access matrix model)

writewrite,append

Benutzer 2

writeblock,wakeup

writeread,delete

Prozess 1

read,write

Benutzer 1

DruckerProzess 1Datei 2Datei 1Subjekte

Objekte

Zugriffsschutzmatrix beschreibt Schutzzustand eines Systems zum Zeitpunkt t

Der Schutzzustand eines Systems (zu einem bestimmten Zeitpunkt t) wird durch eineZugriffsschutzmatrix (access control matrix) modelliert. Die Spalten der Matrix werdendurch die Objekte (zum Zeitpunkt t) definiert, die Zeilen der Matrix durch die Subjekte desSystems (zum Zeitpunkt t). Ein Eintrag M(s,o) in der Zeile s und der Spalte o beschreibt dieMenge der Rechte, die das Subjekt s an dem Objekt o besitzt. Im obigen Beispiel hat Benutzer1 die Rechte read und write auf die Datei 1, Benutzer 2 besitzt hingegen keine Rechte aufDatei 1.

10

Varianten der Zugriffsschutzmatrix

Getypte Objekte und damit typgebundene Rechte

Hinzunahme von Spalten für Gruppen vonObjekten, z.B. alle Objekte eines bestimmten Typs

Hinzunahme von Zeilen für Gruppen vonSubjekten

und weitere


Basierend auf dem klassischen Modell der Zugriffsschutzmatrix wurden weitere Variantenentwickelt. So kann man die zu schützenden Objekte typisieren und typgebundene Rechtebetrachten bzw. Objekte in Gruppen eines Typs zusammenfassen und Rechte dem Typzuordnen. Dann haben alle Instanzen dieses Objekttyps die Rechte. Genauso kann manSubjekte (bzw. Objekte) in Gruppen zusammenfassen, um so Rechte an die gesamte Gruppe zuverteilen. Dann hat jedes Subjekt (bzw. Objekt) der Gruppe diese Rechte.

11


Schutzmatrix kann statisch oder dynamisch sein

statische Matrix:Rechtevergabe wird nicht geändertKann benutzt werden, wenn die Rechte von Anfang an

bekannt sind und über längere Zeit konstant bleiben.

dynamische Matrix:Rechtevergabe ändert sichZustandsänderungen werden durch Kommandos

beschrieben.Beispiel: Modell von Harrison, Ruzzo und Ullman

Die Zugriffsschutzmatrix kann statisch bzw. dynamisch sein. Bei einer statischen Matrix istkeine Änderung der Rechtevergabe, d.h. der Matrixeinträge möglich. Statische Matrizen sindzur Modellierung von Anwendungsproblemen geeignet, in denen der Rechtezustand vorherbekannt ist und über eine längere Zeit konstant bleibt. Im Gegensatz dazu verändert sich beieiner dynamischen Matrix die Rechtevergabe, wobei Kommandos die möglichen Änderungenmodellieren. Harrison, Ruzzo und Ullman haben ein solches Modell für die dynamischeModifikation der Zugriffsschutzmatrix im Artikel [HRU76] vorgestellt.

[HRU76] Harrison, Ruzzo, Ullman. Protection in Operating Systems. Communications of theACM, 19(8):461-471,1976

12


Harrison-Ruzzo-Ullman (HRU) ModellModifikation der Zugriffsschutzmatrix mit folgendenElementaroperationen

Eintragen eines Rechtes: enter r into M(s,o)Entfernen eines Rechtes: delete r from M(s,o)Erzeugen eines Subjekts: create subject sLöschen eines Subjekts: delete subject sErzeugen eines Objekts: create object oLöschen eines Objekts: delete object o

Im HRU-Modell kann der Schutzzustand des Systems (d.h. die Zugriffsschutzmatrix) durchdie 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 zumErzeugen (create) bzw. Löschen (destroy) von Objekten und Subjekten sowie zurRechteweitergabe (enter) und –rücknahme (delete).

13

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,..,opaEND

mit s1,...,sN, o1,...,oK formale Parameter, op1,..,opa Elementaroperationen


Mit diesen sechs Elementaroperationen können Kommandos gebildet werden, die dieZugriffsschutzmatrix in einen neuen Zustand transformieren. Die Folie zeigt die Struktur einessolchen Kommandos. Ein Kommando hat einen Namen und eine Parameterliste von Subjektenund Objekten, die von der Schutzmatrixtransformation betroffen sind. In einem Kommandokönnen mehrere Elementaroperation aufgelistet werden, die beim Aufruf des Kommandosausgeführt werden. Die Ausführung der Elementaroperationen kann zusätzlich anBedingungen geknüpft sein, die in einem if-then-Ausdruck spezifiziert sind. Die Bedingungenfordern bestimmte Einträge in der Matrix.

14


Der Erzeuger einer Datei erhält das Eigentümerrechtfü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 dasEigentümerrecht. Das Kommando besteht aus den zwei Elementaroperationen create objectund 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 desKommandos.

15

Rücknahme eines Rechtes, jedoch nur zulässig fürden 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 desObjekts tun, wie die Bedingung spezifiziert. Außerdem wird in der Bedingung gefordert, dassdas zu löschende Recht einen entsprechenden Eintrag in der Matrix besitzt. Das Kommandoenthält nur eine Elementaroperation zum Löschen des Rechts aus der entsprechenden Zelle derMatrix.

16

SafetyEin Schutzsystem mit Anfangsmatrix M heißt sicherbzgl. eines Rechtes r, wenn kein Zustandsübergangmöglich ist, bei dem eine Zelle von M um das Recht rerweitert wird.

Satz (Harrison, Ruzzo, Ullman 1976)Es ist unentscheidbar, ob ein Schutzsystem M sicherbzgl. eines Rechtes r ist.


Wenn man nun eine Menge solcher Kommandos hat, ist die Frage interessant, ob dieAusführung dieser Kommandos den Initialzustand des Systems in einen unerwünschtenZustand transformieren kann, d.h. in einen Zustand, in dem ein Subjekt ein bestimmtes Rechterlangt, welches eigentlich gar nicht gewährt werden sollte. Harrison, Ruzzo und Ullmanhaben in [HRU76] gezeigt, dass dieses als Saftey-Problem bezeichnete Problemunentscheidbar ist, indem sie es auf das Halteproblem von Turing-Maschinen zurückführten.Es gibt also keinen Entscheidungsalgorithmus, der für beliebige Kommandomengenentscheiden könnte, ob ein Recht in einem Eintrag der Matrix erscheinen wird oder ncht.

17


Durch Einschränkung des Zugriffsschutzmatrixmodells kann manEntscheidbarkeit 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 sehreinfache Systeme leicht möglich – und im allgemeinen schwierig bis unmöglich.

Durch Einschränkung des Zugriffsschutzmatrixmodells lässt sich das Safety-Problem in diesenrestriktiveren Modellen jedoch entscheiden. Mögliche Einschränkungen sind mono-operationale Kommandos bzw. endliche Subjekt- oder Objektmengen. Ein Kommando heißtmono-operational, wenn es genau aus einer Elementaroperation besteht. Mit beidenEinschrä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 wenigrelevant. Es ist also festzustellen, dass man zwar Sicherheitsgarantien für sehr einfacheSysteme geben kann, dies aber für allgemeine (und praxisrelevante) Systeme sehr schwierigbzw. unmöglich ist.

18

Implementierungen der Zugriffsschutzmatrix

Zweidimensionale Implementierung ist ineffizient, da Matrixin 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 einezweidimensionale Implementierung ineffizient. In heutigen IT-Systemen werden in der Regelzwei Konzepte zur Implementierung einer Zugriffsmatrix verwendet: Zugriffskontrolllisten(access control list) und Zugriffsausweise (capability). Mit Access Control Lists (ACL) wirdeine objektbezogene Sicht auf die Zugriffsmatrix realisiert, während bei Capabilities einesubjektbezogene Sicht eingenommen wird.

19


writewrite,append

Benutzer 2

writeblock,wakeup

writeread,delete

Prozess 1

read,write

Benutzer 1

DruckerProzess 1Datei 2Datei 1

Subjekte

Objekte

Objekt-Sicht (ACL)

Subjekt-Sicht

(Capability)

Die Folie spiegelt die beiden Sichten auf die Zugriffsmatrix wieder. Aus der Sicht von Datei 1ergibt 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 dasObjekt (in diesem Beispiel Datei 1) auflistet. Aus der Subjektsicht für Benutzer 2 ergibt sichbeispielsweise eine Liste (Datei2, {write,append}), (Drucker, {write})) mit Einträgen (Objekt,Rechtemenge), die die Objekte mit den möglichen Zugriffen des Subjekts auflistet.

20

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:

- r w x r w x r w x 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 ACList eine listenartige Struktur, die einem Objekt zugeordnet ist. Jeder Listeneintrag identifiziertein Subjekt, sowie die Rechte, die dem Subjekt an dem Objekt eingeräumt werden. EinBeispiel ist die ACL zum Dateischutz in UNIX-Betriebssystemen. Einer Datei wird eine Listezugeordnet, die die Rechte für den Eigner der Datei, einer Gruppe und allen anderen Benutzernbeschreibt. In UNIX gibt es die drei Rechte read, write und execute, die dem Subjekten Eigner,Gruppe und Rest der Welt zugeordnet werden können.

21

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 Rechtebesitzen können.

Die Vorteile der ACL liegen in der einfachen Verwaltung, insbesondere in der einfachen undeffizienten Realisierung der Rechterücknahme. Dazu müssen nur die entsprechenden Einträgein 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ürein Subjekt (z.B. für einen Benutzer) die Menge seiner aktuellen Rechte zu ermitteln. Beilangen ACLs wird die Zugriffskontrolle aufwendig und ineffizient, da bei jedem Zugriff aufdas Objekt die gesamte ACL zu durchsuchen ist. Dies hat zur Folge, dass viele Systeme nursehr einfache Listenstrukturen zulassen (z.B. UNIX). In Systemen mit einer Vielzahl vonSubjekten, die unterschiedliche Rechte auf Objekten besitzen können, ist das ACL-Konzeptaufgrund seiner schlechten Skalierbarkeit eher ungeeignet. Ein Beispiel sind CORBA-basierteverteilte Systeme, bei denen es wünschenswert ist, differenzierte Berechtigungen auf dieOperationen von CORBA-Objekten für unterschiedliche Subjekte zu verteilen.

22

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. beigenerischen Rechten R,W:

Objekt R W

0

1

2

3

Capability List

Capabilities implementieren die Zugriffsmatrix zeilenweise (im Gegensatz zur spaltenweisenImplementierung von ACLs). Eine Capability besteht aus einer Objektreferenz und denBerechtigungen, die durch die Capability an dem Objekt eingeräumt werden. Jedem Subjektwird dann eine Liste, die Capability List, von Paaren (Objektreferenz, Zugriffsrechte)zugeordnet. Diese Liste spiegelt die Einträge in der dem Subjekt zugeordneten Zeile derMatrix wider.

23


Capabilities erfüllen ihre Schutzfunktion nur, wenn sienicht 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 unautorisierteBenutzer gegeben werden, gibt es mehrere Schutzmechanismen für Capabilities: das Arbeitenmit Tags, Verwenden von geschütztem Speicher und Kryptographie . Bei getaggtenArchitekturen ist jedem Speicherwort ein Tag-Bit zugeordnet. Über das Tag-Bit wird für jedesSpeicherwort festgelegt, ob es sich um eine Capability oder um ein normales Datenworthandelt. Wenn das Tag-Bit gesetzt ist, kann das Speicherwort von jedem Prozess gelesen abernicht modifiziert werden. Das Tag-Bit kann nur von einem Prozess im privilegierten Modusgeändert werden.

24


Capability-Segmente

Capabilities werden in eigenem Segment verwaltet.

Zugriff auf dieses Segment erfordert speziellePrivilegien.

Kann mit vorhandenem Speicherschutz realisiertwerden.

Ein weiterer Ansatz zum Schutz der Capabilities sind Capability-Segmente. Ein Capability-Segment enthält ausschließlich Capabilities. Dieses Segment kann von Prozessen gelesen, abernicht geändert werden. Der Zugriff auf Capability-Segmente erfordert spezielle Privilegien, diedem Betriebssystem erteilt werden. Capability-Segmente können mit den vorhandenenMechanismen des Speichermanagements realisiert werden und erfordern keine spezielleHardware.

25


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 Capabilitywird ein verschlüsselter Hash-Wert zugeordnet. Wenn ein Prozess eine solche Capability demBetriebssystem präsentiert, berechnet das Betriebssystem dessen Hash-Wert und entschlüsseltdann die empfangene Capability. Sind beide Werte gleich, ist die Capability unmodifiziert.Andernfalls wird die Capability abgelehnt.

26


Vorteile von Capabilities

Einfache Bestimmung der Subjekt-RechteEinfache Zugangskontrolle (kein Durchsuchen langer Listen)Einfache Weitergabe von Capabilities (sind nicht mit Subjektenidentifiziert)

Nachteile von Capabilities

Rechterücknahme sehr schwierigVerteilung der Capabilities ist nicht leicht zu kontrollierenObjekt-Sicht ist schwierig

Capabilities erlauben eine einfache Bestimmung der Subjekt-Rechte, da die Rechte direkt ansSubjekt gebunden sind. Zugriffskontrollen können außerdem einfach realisiert werden, da nurdie eine Capability des Subjekts geprüft werden muss. Das aufwendige Durchsuchen vonZugriffskontrolllisten ist nicht nötig. Capabilities sind nicht an Subjekte gebunden (sieenthalten keinen Subjekt-Identifikator) und können daher einfach an andere Subjekteweitergegeben werden.

Zu den Nachteilen von Capabilities gehört die dynamische Rechterücknahme. Dazu müssendie Capabilities entweder zurückgefordert oder ungültig gemacht werden. Die Rückforderungist jedoch nicht praktikabel, da Capabilities unbeschränkt kopiert werden können. Capabilitieskö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 danndie Gültigkeit überprüft werden.

27

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 eineMenge von Zugriffsrechten

Eine Kombination aus ACLs und Capabilities ist das Lock/Key-Verfahren. In diesemVerfahren 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 Kzugreifen will. Jedes Objekt o besitzt eine ACL, die Einträge der Form (L,a) enthält. Hierbeiist L ein Schloss und a sind die Rechte, die ein Besitzer eines zum Schloss L passendenSchlüssels K auf dem Objekt o hat.

28

5.2.1.3 Lock/Key

Zugriffsversuch: Subjekt s auf Objekt o mit Rechten b

1) Subjekt s sucht (o,K) aus seiner Key-Liste2) Zugriffskontrolle prüft:

Gibt es einen Eintrag (L,a) in der Lock-Liste vono 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 SchlossL passt, d.h. wenn es einen Eintrag (L,a) mit K=L für das Objekt o gibt. Zum anderen müssenauch die vom Subjekt gewünschten Rechte zulässig sein, also b muss eine Teilmenge von asein.

29

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 vereinfachteKombination aus ACL und Capabilities.

Eine Rechterücknahme im Lock/Key-Verfahren ist einfach und effizient zu realisieren, da inder ACL des Objekts (d.h. der Lock-Liste) nur das Schloss L verändert werden muss. ZurRücknahme der Rechte sind keine Kenntnisse über aktuelle Besitzer vergebener Capabilitiesnö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 vereinfachteKombinationen aus ACLs und Capabilities verwendet.

30

5.2.1.4 ACL und Capabilities in UNIX

Spaltenweise Implementierung der Matrix: einfacheACLs für Dateien

Nach dem Öffnen einer Datei:Ausstellen eines Datei-Deskriptors (entsprichtCapability)

Objekte sind Dateien und besitzen einen Datei-Deskriptor (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 Capabilityangesehen werden kann, und der für alle weiteren Zugriffe auf die Datei benutzt wird. InUNIX besitzen alle Dateien einen Datei-Deskriptor (genannt inode), in dem die Attribute derDatei (z.B. Datei-Eigner, ACL, etc.) enthalten sind.

31


Zum Zugriff auf eine Datei muss diese zunächst mit demSystemcall open geöffnet werden.

fildes = open(path,flags)

Aktionen des UNIX-Kerns1) Laden der inode der zu öffnenden Datei path2) Prüfen: Besitzt der Prozess die benötigten Rechte in

der ACL des inodes zum Öffnen der Datei und für diegewünschten Operationen in flags

3) Falls o.k. gibt es einen Datei-Deskriptor zurück,derzum Zugriff auf die Datei gemäß flags erlaubt.

Wenn ein Prozess auf eine Datei zugreifen möchte, muss er diese zunächst mit dem open-Systemcall ö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 wirddann vom System auf den inode der gewünschten Datei abgebildet. Der Kern überprüft dannanhand der im inode enthaltenen ACL, ob der Prozess die gewünschten Operationen ausführenkann. Ist der Zugriff zulässig, erzeugt der Kern für den Prozess einen Datei-Deskriptor undträgt diesen in eine prozesslokale Datei-Deskriptor-Tabelle ein (vergleichbar mit derCapability-Liste).

32


Der mit open generierte Datei-Deskriptor kommtin die Datei-Deskriptor-Tabelle des Prozesses.

Für jeden generierten Datei-Deskriptor gibt eseinen Eintrag in der globalen Open-File-Tabelle(enthält Zugriffsrechte).

Einträge in der Open-File-Tabelle zeigen auf deninode der Datei in der inode-Tabelle.

Für jeden generierten Datei-Deskriptor erzeugt der Kern ebenfalls einen Eintrag in dersystemweiten Open-File Tabelle. In dieser wird vermerkt, für welche Operationen die Dateivom Prozess geöffnet wurde (z.B. zum Lesen oder zum Schreiben). Jeder Eintrag in derlokalen Datei-Deskriptor Tabelle eines Prozesses zeigt auf einen eindeutigen Eintrag in derglobalen Open-File-Tabelle des Kerns. Damit kann bei jedem Zugriff auf eine geöffnete Dateianhand des vom Prozess übergebenen Datei-Deskriptors entschieden werden, ob der Zugriffgemäß der beim open-Aufruf angegebenen Zugriffsoperationen zulässig ist.

33


Datei-Deskriptor-Tabelle

Prozess A

Prozess B

write

read

read/write

Open-File-Table/etc/passwd

file 1

file 2

inode-Tabelle

Den auf den vorigen Folien beschriebenen Zusammenhang zwischen den prozesslokalenDatei-Deskriptor-Tabellen und der globalen Open-File-Tabelle bzw. inode-Tabelle zeigtgraphisch die obige Folie.

34


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 denZugriff zu entscheiden. Beispielsweise wird beim Aufruf von read und write der Datei-Deskriptor der zu lesenden bzw. zu schreibenden Datei als Parameter übergeben. Dieser Datei-Deskriptor verweist auf einen Eintrag in der Open-File-Tabelle, in der gespeichert wurde, fürwelchen Zugriffsmodus die Datei geöffnet wurde. Dieser muss beispielsweise für read dasZugriffsrecht 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 erhaltenbleibt, bis die Datei geschlossen wird.

35

5.2.1.5 ACL und Capabilities inWindows

Spaltenweise Implementierung der Matrix: etwas komplexereACLs für DateienNach dem Öffnen einer Datei: Ausstellen eines Object-Handles(entspricht Capability)

Zugriffskontrolle beim Öffnen eines Objekts o1) 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 etwaskomplexer als im Falle von UNIX. In Windows-Systemen erfordert jeder Zugriff auf einObjekt die Vorlage eines Object Handles. Diese Object Handles sind von den Objektmanagernausgestellt 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. DerAufruf wird an den Security Reference Monitor weitergeleitet. Dieser überprüft anhand derACL 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ährtenBerechtigungen.

36

5.2.1.5 ACL und Capabilities inWindows

Bei Objektzugriffen wird nur noch das Object-Handlevorgezeigt, um den Zugriff zu entscheiden(d.h. ist der Zugriff bzgl. der Handle-Berechtigungenerlaubt?)

Problem: Keine direkte Aktualisierung von Zugriffsrechten(weniger Verwaltungsaufwand, höhere Performance)

Rechterücknahme wird erst mit dem Schließen unddem 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 ObjectHandles enthalten ist. Auch in Windows wird auf eine direkte Aktualisierung vonZugriffsrechten verzichtet, um den Verwaltungsaufwand zu reduzieren und die Performanz desSystems zu steigern. Eine Rechterücknahme wird für einen Prozess, der ein Objekt geöffnethat und ein Handle dafür besitzt erst dann wirksam, wenn der Prozess das Objekt wiederschließt und erneut öffnet.

37

5.2 Rollenbasierter Zugriffsschutz

NIST-Standard (NIST = National Institute of Standards andTechnology)

Berechtigungen werden direkt an Aufgaben, d.h. Rollen,geknüpft (z.B. Filialleiter, Kassierer, Wertpapierberater, ...)

Rolle beschreibt Funktion, Aufgabenkreis, Verantwortlichkeitenetc. in einer Organisation.

Berechtigungen beziehen sich auf eine oder mehrereObjekte/Ressourcen.

Reduzierung von Kosten und Komplexität der Sicherheits-administration.

Rollenbasierter Zugriffsschutz (role based access control, RBAC), von Ferraiolo und Kuhn1992 und von Sandhu 1996 präsentiert, reduziert die Komplexität und die Kosten derSicherheitsadministration in Anwendungen. Seit dem 19. Februar 2004 ist RBAC einAmerican National Standard - ANSI INCITS 359-2004. Bei einer rollenbasiertenModellierung werden die Berechtigungen zur Nutzung von Objekten an Rollen geknüpft, diebestimmte Aufgaben zu erfüllen haben. Beispiele von Rollen in einer Bankanwendung wärenFilialleiter, Kassierer, Kundenbetreuer, Wertpapierberater etc. Die durch Rollen modelliertenAufgaben 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 SecurityConference (1992)

38


Benutzer 1

Benutzer 2

Benutzer 3

Drucker

Dokument

Verzeichnis

Programm X

Reduzierung von Kosten und Komplexität der Sicherheits-administration durch Rollen.

Wie Rollenbasierter Zugriffsschutz die Komplexität der Verwaltung der Sicherheit in einemSystem reduzieren kann, sollen diese und die nächste Folie veranschaulichen. Auf dieser Foliesind die Rechte direkt den Benutzern zugeordnet. Benutzer 1 hat beispielsweise das Recht, denDrucker zu benutzen und auf das Dokument zuzugreifen, Benutzer 3 darf das Verzeichnis unddas Programm X nutzen. Benutzer 2 darf alles. Eine Rechteänderung (z.B. neuer Benutzer mitRechten für Dokument und Drucker, die Zurücknahme vom Verzeichnisrecht für Benutzer 2und Benutzer 3, neue Rechte für Drucker und Dokument für Benutzer 3,....) sind relativaufwendig zu verwalten, da eine ganze Reihe von Benutzer-Rechte-Verbindungen neu erstelltwerden müssen. Um diese Änderungen zu reduzieren, werden Rollen als Vermittler zwischenBenutzern und eingeführt.

39


Benutzer 1

Benutzer 2

Benutzer 3

Drucker

Dokument

Verzeichnis

Programm X

Rolle A

Rolle B

Reduzierung von Kosten und Komplexität der Sicherheits-administration durch Rollen.

Rollen werden dann mit den Rechten verbunden. Zum Beispiel hat Rolle A das Zugriffsrechtauf den Drucker und das Dokument, Rolle B das Recht für das Verzeichnis und das ProgrammX. 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 alleBenutzer, die diese Rolle spielen, die Rechteänderung sofort mit. Genauso einfach kann maneinem 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 zugeben.

40

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. Diesesdefiniert die grundlegenden Mengen und Relationen, auf denen das Modell operiert. Dies istdie Menge der Benutzer, die am System beteiligt sind, die Menge O der zu schützendenObjekte, die Menge OP der möglichen Zugriffsoperationen auf diesen Objekte und die MengeR der Rollen. Die Menge P der Permissions besteht aus Paaren (op,o) einer Operation op undeines Objekts o. Dieses Permissionpaar gibt dann die Erlaubnis, auf dem Objekt o dieZugriffsoperation op auszuführen. Ein Benutzer kann seine Rollen in einer Sitzung (session)aktivieren. Hierbei kann ein Benutzer mehrere Sitzungen besitzen in denen er unterschiedlicheRollen aktiviert.

41

5.2.1 RBAC0

RPPR ¥Õ

RUUR ¥Õ

RSroles

USuser

2:

:

Æ

Æ

User Rollen

Sessions

ObjektOperat.

Rechte PPRUR

* * * ** *

*1

RechteverteilungRollenverteilung

mit })),((|{)( URrsuserrsroles Œ=

‡ Sitzung s hat die Rechte U)(

}),(|{srolesr

PRrppŒ

Œ

**

Benutzer können Rollen zugeordnet werden, wobei ein Benutzer mehrere Rollen haben kannund eine Rolle mehreren Benutzern zugeordnet sein kann. Permissions (bzw. Rechte) werdenRollen zugeordnet. Eine Rolle kann mehrere Rechte besitzen und ein Recht kann mehrerenRollen zugeordnet werden. Benutzer können Sessions starten, wobei jede Session eindeutig zueinem Benutzer zugeordnet sein muss. Die Funktion user weist jeder Session ihren Benutzerzu. In einer Session können mehrere Rollen des Benutzers aktiviert werden und eine Rollekann in mehreren Sessions aktiviert sein. Die Funktion roles weist jeder Session die Mengeder in der Session aktivierten Rollen zu. Damit besitzt der Benutzer in einer Session alleRechte der in der Sitzung aktivierten Rollen.

42

Unterschied Rollen und Benutzergruppen

– Rechte einer Rolle leicht änderbar (wieCapabilities)

– Rechte einer Gruppe nicht leicht änderbar (wieACL)

5.2.1 RBAC0

Rollen und Benutzergruppen unterscheiden sich: Rollen sind eine Zusammenfassung vonAufgaben, während Gruppen eine Zusammenfassung von Benutzern sind. Außerdem könnendie 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 nichteinfach ändern, da man alle Objekte betrachten muss, auf die die Gruppe Berechtigungen hat.Damit ähneln Gruppen eher ACLs.

43

5.2.1 RBAC0

Rollenverwaltung und Schutzstrategien:

Rechteverteilung (d.h. Rechte der Rollen) : anwendungsspezifisch, selten geändert, vorzugsweisedurch Systementwickler und/oder zentralem Sicherheitsverwalter

Rollenverteilung (d.h. Rollen der Benutzer):gemäß Personalverwaltung, öfter geändert, vorzugsweisevon Sicherheitsverwalter und/oder Personalchef

Typische Schutzstrategien bei rollenbasiertem Zugriffsschutzsind weitgehend systembestimmt durch die Rechte- undRollenverteilung.

RBAC ist weitgehend eine systembestimmte Zugriffsschutzstrategie, da die Rechteverteilungund die Rollenverteilung vom Systemadministrator, Personalverwaltung etc. vorgenommenwird. Der Benutzer kann nur aus dem ihm zugeordneten Rollen auswählen, aber nicht selbstneue Rollenmitgliedschaften aufstellen. Die Rechteverteilung ist anwendungsspezifisch undwird eher selten geändert, da die Aufgaben in einer Organisation als relativ konstant angesehenwerden. Wer diese Aufgaben ausführt, wird allerdings öfter geändert, so dass auch dieRollenverteilung öfters geändert wird.

44

5.2.2 RBAC1

Aufgaben sind häufig hierarchisch geordnet.

Filialleiter

KassiererKundenbetreuer

Angestellter

z.B. hat ein Filialleiter alle Rechte des Kundenbetreuers und Kassierers

In praktischen Anwendungen werden die Aufgaben und Zuständigkeiten häufig hierarchischgeordnet. Deshalb wird das RBAC0-Modell um eine Rollenhierarchie erweitert, mit der sichauch hierarchische Berechtigungsstrukturen ausdrücken lassen. Ein Beispiel einer Hierarchiein einer Bank zeigt das Beispiel der Folie.

45

5.2.2 RBAC1

Im RBAC1-Modell sind die Rollen zusätzlich partiellgeordnet.

RR¥£Õ

bedeutet: Rolle x erbt alle Rechte von Rolle y,d.h. „x darf alles was y darf (und mehr)“

xy £

Präzisierung:

})),((,|{)( URtsusertrrsroles Œ£=

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. Damitergeben sich dann die Rechte in einer Sitzung s aus den Rechten aller in s aktivierten Rollenund aller Rollen, die von den aktivierten Rollen dominiert werden, d.h. von Rollen, die tieferin der Rollenhierarchie stehen.

46

5.2.2 RBAC1

Filialleiter

KassiererKundenbetreuer

Angestellter

a Recht

bc

de

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}

Otto

Fritz

Betrachten wir beispielsweise eine Session des Benutzers Otto, der der Rolle Filialleiterzugeordnet ist. Dann hat Otto das Recht a, da die Rolle Filialleiter dieses Recht hat. Ottobesitzt 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 derRolle Kundenbetreuer besitzt die Rechte der ihm zugeordneten Rolle Kundenbetreuer und derRolle Angestellter (somit hat Fritz die Rechte b,c und f).

47

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. DieFolie zeigt einige Beispiele. Es ist zu bemerken, dass die Constraints des RBAC2-Modells auchzur 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 erauch Rolle y hat. Damit hätte der Benutzer in der Rolle x sowohl die Rechte von x als auch dievon y.

48

5.2.3 RBAC2

Klassen von Constraints

Anzahl (Kardinalität) von Rolleninhabern:Eine Rolle kann nur einer bestimmten Anzahl von Benutzernzugeordnet 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, derschon 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 zugeordnetwerden können bzw. fordern eine bestimmte Anzahl von Benutzern in der Rolle. Bei derKlasse der Rollen-Voraussetzungen handelt es sich um Constraints, die für die Zuordnungeines Benutzers zu einer Rolle eine (oder mehrere) Rollen für den Benutzer als Voraussetzungfordern.

49

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 nichtgleichzeitig in der Rolle Jury sein“

Rechte-Konflikt:Ein Paar von Rechten darf nicht derselben Rolle zugeordnetwerden.

Beispiel: „Das Recht zum Genehmigen und Ausstellen einesSchecks darf nicht in der Verantwortung derselben Rolle liegen“

Eine der häufigsten Constraints sind Constraints zum wechselseitigen Ausschluss vonRollenmitgliedshaften. Hierbei können Konflikte zwischen Benutzern, Rechten und Rollenauftreten. Bei einem Benutzer-Konflikt dürfen die im Konflikt stehenden Benutzer nichtderselben Rolle zugeordnet werden. Bei einem Rechte-Konflikt dürfen die im Konfliktstehenden Rechte nicht derselben Rolle zugeordnet werden.

50

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 Benutzerzugeordnet werden.

Beispiel: „Keine Person darf gleichzeitig die Rollen Kassierer undKassenprüfer haben“.

Beim Benutzer-Rechte-Ausschluss darf der Benutzer mit der im Konflikt stehenden Rolleniemals dieser Rolle zugeordnet werden. Bei der statischen Aufgabentrennung (staticseparation of duty, SoD) stehen Rollen im Konflikt, d.h. ein Benutzer darf entweder die eineRolle haben oder die andere, aber niemals beide. Statisch bedeutet hierbei, dass diesbeispielsweise auch session-übergreifend ist, d.h. er darf auch nicht die eine Rolle in einerSession, die andere in einer anderen Session aktivieren.

51

5.2.3 RBAC2

Dynamisches SoD:Zwei bestimmte Rollen dürfen nicht gleichzeitig in einer Sitzungdesselben Benutzers aktiviert werden.

Beispiel: „Die Rollen Schiedsrichter und Spieler dürfen nichtgleichzeitig ausgeübt werden.“

Das dynamische SoD beschränkt sich auf die aktive Session eines Benutzers. Nur bezüglicheiner Session stehen die Rollen in Konflikt, d.h. in einer Session dürfen die Rollen nichtgleichzeitig aktiviert werden. Es ist jedoch für einen Benutzer erlaubt, in einer Session die eineRolle, in einer anderen Session die andere Rolle zu aktivieren.

52

5.2.4 RBAC3

RBAC3 fasst RBAC1 und RBAC2 zusammen.

Damit ergeben sich zusätzliche Möglichkeiten wiez.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 sichzusätzliche Constraints bzgl. der Rollenhierarchie auftsellen. Beispiele solcher Constraintszeigt die Folie.

Documents

5. Zugriffsschutz - Fachbereich Mathematik und Informatik · –das System mono-operational ist, d.h. Kommandos bestehen aus genau einer Elementaroperation (jedoch NP-vollständig)