5. Zugriffsschutz. Kontrolliert Zugriffe von Subjekten auf Objekte. Beispiele: Prozessor überschreibt Speicherzelle: CLEAR 0

Transkript

1 5. Zugriffsschutz 1

2 5. Zugriffsschutz Kontrolliert Zugriffe von Subjekten auf Objekte Beispiele: Prozessor überschreibt Speicherzelle: CLEAR 0 Benutzer erweitert Paßwortdatei: append /etc/passwd Prozess sucht in einem Verzeichnis: ls documents Benutzer 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, was ein Subjekt in einem System (für dass der Zugriffsschutz definiert wurde) tun darf, bzw. was mit den Objekten getan werden kann. 2

3 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

4 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 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

6 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

7 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

8 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

9 Zugriffsmatrix-Modell (access matrix model) Zugriffsschutzmatrix beschreibt Schutzzustand eines Systems zum Zeitpunkt t Objekte Datei 1 Datei 2 Prozess 1 Drucker Subjekte Benutzer 1 read, write Prozess 1 read, delete write block, wakeup write Benutzer 2 write, append 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

10 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

11 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): ,

12 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

13 Zugriffsmatrix-Modell (access matrix model) Kommandos zur Veränderung des Schutzzustandes COMMAND com(s 1,...,s N, o 1,...,o K ) IF r 1 IN M(s i1,o j1 )... r m IN M(s im,o jm ) THEN op 1,..,op a END mit s 1,...,s N, o 1,...,o K formale Parameter, op 1,..,op a 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

14 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

15 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

16 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

17 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

18 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

19 Zugriffsmatrix-Modell (access matrix model) Objekt-Sicht (ACL) Objekte Datei 1 Datei 2 Prozess 1 Drucker Subjekte Benutzer 1 read, write Prozess 1 read, delete write block, wakeup write Subjekt- Sicht (Capability) Benutzer 2 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

20 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 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

21 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

22 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: 0 Objekt R W Capability List 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

23 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

24 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 Capability- Segment 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

25 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

26 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

27 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

28 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

29 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

30 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 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 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

31 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 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 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

32 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

33 ACL und Capabilities in UNIX Datei-Deskriptor-Tabelle inode-tabelle Open-File-Table /etc/passwd Prozess A write 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

34 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 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ü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

35 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

36 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

37 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 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

38 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

39 5.2 Rollenbasierter Zugriffsschutz Reduzierung von Kosten und Komplexität der Sicherheitsadministration durch Rollen. Benutzer 1 Benutzer 2 Rolle A Drucker Dokument Benutzer 3 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

40 5.2.1 RBAC 0 Elementares RBAC-Modell RBAC 0 - 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 RBAC 0. 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

41 5.2.1 RBAC 0 User UR * * Rollen Rechte P PR * * Operat. * * Objekt user : S ÆU roles : S Æ 2 1 * * * Sessions R Rechteverteilung Rollenverteilung mit roles( s) = { r ( user( s), r) ŒUR} Sitzung s hat die Rechte rœroles U ( s) PR Õ P R UR Õ U R { p ( p, r) Œ PR} 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

42 5.2.1 RBAC 0 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

43 5.2.1 RBAC 0 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

44 5.2.2 RBAC 1 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 RBAC 0 -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

45 5.2.2 RBAC 1 Im RBAC 1 -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

46 5.2.2 RBAC 1 Otto Filialleiter a Recht b c Kundenbetreuer 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

47 5.2.3 RBAC 2 RBAC 2 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 RBAC 1 kann prinzipiell mit RBAC 2 formuliert werden. Im RBAC 2 -Modell können zusätzlich Einschränkungen (constraints) definiert werden. Die Folie zeigt einige Beispiele. Es ist zu bemerken, dass die Constraints des RBAC 2 -Modells auch zur Definition einer Rollenhierarchie gemäß RBAC 1 -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

48 Klassen von Constraints RBAC 2 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

49 5.2.3 RBAC 2 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

50 5.2.3 RBAC 2 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

51 5.2.3 RBAC 2 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

52 5.2.4 RBAC 3 RBAC 3 fasst RBAC 1 und RBAC 2 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 RBAC 3 -Modell fasst die Modelle RBAC 1 und RBAC 3 zusammen. Damit lassen sich zusätzliche Constraints bzgl. der Rollenhierarchie auftsellen. Beispiele solcher Constraints zeigt die Folie. 52