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