Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Humboldt University Computer Science Department Systems Architecture Group IT-Sicherheit Grundlagen Sicherheitsmodelle.

Ähnliche Präsentationen


Präsentation zum Thema: "Humboldt University Computer Science Department Systems Architecture Group IT-Sicherheit Grundlagen Sicherheitsmodelle."—  Präsentation transkript:

1 Humboldt University Computer Science Department Systems Architecture Group IT-Sicherheit Grundlagen Sicherheitsmodelle Klassifikation, Bewertung, Access Control

2 IT-Sicherheit Grundlagen Dr. Wolf Müller 2 Modell-Klassifikation Modell ist Abbild (Karikatur) des realen Systems. (Beinhaltet alle wesentlichen Eigenschaften) Beurteilung der Modelle nach Fähigkeit, –flexibel anwendungsspezifische Anforderungen zu erfüllen, –Datenintegritäts- und Vertraulichkeitsanforderungen zu erfassen. Dimensionen des Klassifikationsschemas: –Festlegung der zu schützenden und der agierenden Einheiten (Objekte / Subjekte). –Festlegung der zu verwaltenden Zugriffsrechte.

3 IT-Sicherheit Grundlagen Modell: Objekte & Subjekte Grobkörnige Modellierung Grobe Objekte –Zugriffskontrollen nur für zu schützende Einheiten (Objekte) Z.B. Dateien –Komponenten, die nicht als zu schützende Objekte modelliert sind, unterliegen keiner Zugriffs/Informationsflusskontrolle –Need-to-Know schwer realisierbar. –Aber gut mit OS verträglich Grobe Subjekte –Aktivitäten einzelner Benutzer nicht differenziert kontrollierbar. –Zusammenfassung in große Benutzergruppen Anwendungsspezifische Körnung Gestattet Need-to-Know Beliebige Granularität für Objekte, Subjekt nur benötigte Rechte Capability basierte Systeme / ACLs Dr. Wolf Müller 3

4 IT-Sicherheit Grundlagen Modell: Zugriffsrechte, Zugriffsbeschränkungen Zugriffsrechte Universelles Zugriffsrecht: Wenn durch allgemeine nicht objektspezifische Operationen bezeichnet. -read, write, execute -Bedrohung für Datenintegrität, aber durch OS unterstützt Objektspezifisches Recht: Zugriffsmöglichkeiten auf festgelegten funktionalen Kontext (zugeschnitten auf jeweiliges Objekt) beschränkt. Zugriffsbeschränkungen Einfach: Subjekt muss für Zugriff nur entsprechendes Zugriffsrecht besitzen. Komplex: Zulässigkeit des Zugriffs abhängig von entsprechendem Zugriffsrecht + weiteren Bedingungen. –Globale Variable (nur von 7:00 – 18:00) –Objektlokale Variable (innerhalb von 24h nur 3x Geld abholen) Dr. Wolf Müller 4

5 IT-Sicherheit Grundlagen Dr. Wolf Müller 5 Sicherheitsstrategien Unterscheidung in zwei Klassen: Zugriffskontrollstrategien: –Benutzerbestimmbar –Systembestimmt Informationsfluss-Strategien

6 IT-Sicherheit Grundlagen Dr. Wolf Müller 6 Zugriffskontrollstrategie Benutzerbestimmbare (discretionary access control DAC) –Basieren auf Eigentümer-Prinzip (owner) –Eigentümer ist für Schutz eines Objekts verantwortlich. –Zugriffsrechte werden auf Basis einzelner Objekte vergeben / zurückgenommen –Benutzerbestimmbare Strategien, objektbezogene Sicherheitseigenschaften –Gefahr: Modellierung inkonsistenter Strategien (Abhängigkeiten der Objekte untereinander wird nicht beachtet.) Systembestimmte (MAC) –Spezifizierung systemglobaler Eigenschaften –Dominieren über benutzerbestimmte Rechtevergaben; Zugriff verweigert, wenn es systembestimmte Festlegung gibt. –Können aber durch benutzerbestimmbare Berechtigungsverbote weiter eingeschränkt werden. RBAC-Strategie –Rollenbasiert –Verteilte Systeme Gruppenkonzept

7 IT-Sicherheit Grundlagen Dr. Wolf Müller 7 Informationsfluss-Strategie –Zugriffskontrollstrategien beschränkt auf Zugriffe auf Objekte –Kontrollieren kaum oder gar nicht, in welcher Weise Subjekte durch Objektzugriffe erhaltene Informationen weiterverarbeiten dürfen. –Mit systembestimmten Strategien nur sehr restriktive und einfache Informationsflussbeschränkungen möglich. –Festlegung gültiger und verbotener Informationskanäle zwischen Subjekten bzw. Subjektklassen.

8 IT-Sicherheit Grundlagen Dr. Wolf Müller 8 Zugriffskontrollmodelle Zugriffsmatrix-Modell Rollenbasierte Modelle Chinese-Wall Modell Bell-LaPadua Modell

9 IT-Sicherheit Grundlagen Dr. Wolf Müller 9 Zugriffsmatrix-Modell (access matrix model) Auch bekannt als Referenzmonitor-Modell Einfachstes und ältestes Sicherheitsmodell Möglichkeit: –Objekte und Subjekte zugeschnitten auf die Anforderungen der zu konstruierenden Anwendung festzulegen –sowie Zugriffrechte universell oder objektspezifisch zu modellieren.

10 IT-Sicherheit Grundlagen Dr. Wolf Müller 10 Schutzzustand eines Systems zum Zeitpunkt t wird durch eine |S t | £ |O t |-Matrix M t modelliert, wobei gilt: –Die Spalten der Matrix werden durch die Menge O t der Objekte –Die Zeilen der Matrix werden durch die Menge der S t Subjekte zum Zeitpunkt t definiert. –Es gilt: M t : S t £ O t ! 2 R, wobei R die Menge der Zugriffsrechte festlegt. Ein Eintrag M t (s,o)={r 1,…,r n } beschreibt die Menge der Rechte, die das Subjekt s zum Zeitpunkt t an dem Objekt o besitzt. Für jeden Zeitpunkt t modelliert die Zugriffsmatrix M t,die in dem betreffenden Zustand gültigen Zugriffsrechte der Subjekte an den Objekten des Systems. Der Schutzzustand des Systems (M t ) kann durch Ausführung von Kommandos zum Erzeugen, Löschen von Subjekten / Objekten oder zur Weitergabe und Rücknahme von Zugriffsrechten verändert werden. Matrix ist selbst zu schützendes Objekt, für sie müssen ebenfalls Rechte modelliert werden. Zugriffsmatrix

11 IT-Sicherheit Grundlagen Dr. Wolf Müller 11 Zugriffsmatrix: Beispiel Rechte: –Senden, Empfangen (Ports, Sockets), –wait, signal (Ausführung von Synchronisationsoperationen) –control (Eigentümer-Recht) Datei 1Datei 2Prozess 1Prozess 2Prozess 3Prozess 4 Prozess 1 c,sendc Prozess 2 wait,signalc Prozess 3 read,writewrite,ownwerreceivesend Prozess 4 read,executesend Prozess 3 von Nutzer Carl, Prozess 4 von Nutzer Daniel gestartet. Subjekt Carl bzw. der für für ihn tätige Prozess 3 hat owner-Recht an Datei 2. Prozess 3 darf Rechte am Objekt Datei 2 an andere Subjekte weitergeben und wieder zurückziehen. Subjekt Daniel / Prozess 4 hat kein Recht auf das Objekt Datei 1 zuzugreifen, besitzt Lese-/Ausführungsrechecht für Datei 2 und das Recht, Nachrichten an Prozess 3 zu senden.

12 IT-Sicherheit Grundlagen Dr. Wolf Müller 12 Statische Matrix Statisch: –Modellierung von Anwendungsproblemen, bei denen Rechtezustand a priori über lange Zeiträume bekannt ist Einfache Router, die als Paketfilter / Firewalls arbeiten Port 21 (ftp) Port 25 (smtp) Port 53 (DNS- query) Port 514 (rshell) 1023 (smtp) FTP- Server receivesend Mail- Rechner receivesend Externer Rechner send

13 IT-Sicherheit Grundlagen Dr. Wolf Müller 13 Dynamische Matrix Zustandsübergänge (Veränderungen der Zugriffsmatrix) werden durch Ausführung von Kommandos modelliert. Definition von sechs Elementaroperationen zum Erzeugen (create) oder Löschen (destroy) von Objekten und Subjekten sowie Rechteweitergabe (enter) bzw. Rechterücknahme (delete) [M.A. Harrison, W.L. Ruzzo and J. Ullmann, Protection in Operating Systems. Communications of ACM, 19(8): ,1976]

14 IT-Sicherheit Grundlagen Dr. Wolf Müller 14 Dynamische Matrix: Struktur der Kommandos zur Veränderung des Schutzzustandes KommandoErläuterung COMMAND (X 1,…,X k ) IF r 1 IN (X S1,X O1 ) AND … R m IN (X Sm,X Om ) THEN op 1, …, op n END; ist ein Regel-Name X i O t S t formale Parameter r i R Rechte op i Elementaroperation

15 IT-Sicherheit Grundlagen Dr. Wolf Müller 15 Dynamische Matrix: Elementaroperationen enter und delete ElementaroperationBedingungWirkung enter r into (s,o) s i S t, o i O t M t (s,o) = M t (s,o) {r} delete r into (s,o) s i S t, o i O t M t (s,o) = M t (s,o) \ {r}

16 IT-Sicherheit Grundlagen Dr. Wolf Müller 16 Dynamische Matrix: Beispiel Kommandos (1) create definiert Rechtevergabe bei der Erzeugung neuer Objekte Gemäß Festlegung: Erzeuger Eigentümer des Objekts + Berechtigung Nutzungsrechte für dieses Objekt an andere Subjekte weiterzugeben. KommandoErläuterung COMMAND END; create (user,file) create file; enter owner into (user file) Aufruf durch Subjekt user O t = O t {file} neue Spalte in der Matrix Eigentümer-Recht an Subjekt user vergeben

17 IT-Sicherheit Grundlagen Dr. Wolf Müller 17 Dynamische Matrix: Beispiel Kommandos (2) revoke_r Rechterücknahme, die nur für Berechtigte zulässig ist. KommandoErläuterung COMMAND END; revoke_r (S 1,S 2,X) IF owner M t (S 1,X) AND r M t (S 2,X) THEN delete r from (S 2,X) Aufruf durch Subjekt S 1 Rechterücknahme

18 IT-Sicherheit Grundlagen Dr. Wolf Müller 18 Zugriffsmatrix: Sicherheitseigenschaften Safty-Problem Formalisierte Modellierung von Schutzzuständen gestattet Untersuchung der Sicherheitseigenschaften Safty-Problem: Kann ausgehend von Schutzzustand M t ein Subjekt s das Recht r an einem Objekt o erhalten, wenn es dies im Zustand M t noch nicht besitzt? –D.h., es ist zu zeigen, dass ausgehend von M t mit r M t (s,o), ein Zustand M t mit t > t erreichbar ist mit r M t (s,o).

19 IT-Sicherheit Grundlagen Dr. Wolf Müller 19 Zugriffsmatrix: Sicherheitseigenschaften Safty-Problem (2) Systemkonfiguration: K t zum Zeitpunkt t ist durch Schutzzustand M t und die in diesem Zustand existierenden Mengen von Objekten und Subjekten festgelegt. K t =(M t,O t,S t ) –Konfigurationsübergang durch Kommando op: Safty-Problem: Sei K 0 Anfangskonfiguration und für K t gelte r M t (s,o). Dann reduziert sich das Safty-Problem darauf, ob von der Konfiguration K t ausgehend durch Ausführung der Kommandos op 1, …,op n eine Konfiguration K t+n erreicht werden kann mit r M t+n (s,o).

20 IT-Sicherheit Grundlagen Dr. Wolf Müller 20 Zugriffsmatrix: Sicherheitseigenschaften Safty-Problem (3) Harrison, Ruzzo, Ullmann haben Unentscheidbarkeit des Safty-Problems bewiesen. –Rückführung auf das unentscheidbare Halteproblem von Turing- Maschinen. –Es gibt keinen Algorithmus, der bei gegebener Ausgangskonfiguration eines Systems mit einer beliebig festgelegten Menge von Kommandos entscheiden kann, ob ein Recht r in den Besitz eines Subjekts s kommen kann. –Das bedeutet in der Praxis jedoch nicht, das diese Frage für ein konkretes System mit konkreter Kommandomenge diese Frage nicht zu beantworten ist. –Es sind von Fall zu Fall dezidierte Entscheidungsverfahren zu konstruieren. –Es gibt Entscheidungsverfahren für ganze Systemklassen, welche mit Take-Grant-Modellen beschrieben werden.

21 IT-Sicherheit Grundlagen Dr. Wolf Müller 21 Zugriffsmatrix: Sicherheitseigenschaften Soll-Ist-Vergleiche Soll-Ist-Vergleiche –Gegeben konkretes Systemmodell mit festgelegter Kommandomenge und Schutzzustand M t. –Die gewünschten Sicherheitszustände seien informell (oder formal gegeben) –Frage: Stimmen modellierte System- (Ist-) Eigenschaften mit gestellten (Soll-) Eigenschaften überein? Z.B. Kann Subjekt Rechte erhalten, welche im Widerspruch zu festgelegten Sicherheitsanforderungen stehen? –Matrixorientierte Erfassung der direkten Berechtigungen ermöglicht durch Bildung der transitiven Hülle der Berechtigungs- abhängigkeiten die indirekten Berechtigungen direkt zu bestimmen. Ermittlung der impliziten Rechte aller Subjekte, um Widersprüche zu festgelegten Anforderungen zu entdecken.

22 IT-Sicherheit Grundlagen Dr. Wolf Müller 22 Zugriffsmatrix: Sicherheitseigenschaften Beispiel: Soll-Ist-Vergleiche Soll-Eigenschaften: –Subjekt Joe darf weder explizit noch implizit das Recht lese_Kontostand an Objekt Konto_Bill erhalten. –Modellierung erfasst Prozeduren als Objekte bzw. Subjekte Ist-Eigenschaften: –Auszug des Schutzzustands des modellierten Systems Problem: Vergabe von execute-Recht an Joe für Prozedur Drucke_Auszug und gleichzeitiges lese_Kontostand-Recht an Prozedur Drucke_Auszug gibt Joe implizit das Recht lese_Kontostand an Konto_Bill. Modellierung oder Rechtevergabe muss verändert werden! …Konto_BillDrucke_Auszug Joeexecute Drucke_Auszuglese_Kontostand …

23 IT-Sicherheit Grundlagen Dr. Wolf Müller 23 Zugriffsmatrix: Sicherheitseigenschaften Modellierung von Zugriffsrechten / Beispiel Modellierung von Zugriffsrechten hat großen Einfluss auf Sicherheitseigenschaften des modellierten Systems –Werden Rechte grobgranular vergeben (Zusammenfassung unterschiedlicher Zugriffsmöglichkeiten auf ein Objekt unter einer Sammelberechtigung), so können Sicherheitslücken im Vergleich zu gestellten Sicherheitsanforderungen entstehen. Beispiel: –Sicherheitsanforderungen: 1.Verzeichnis D ist Objekt (tmp-Datei) für das alle Benutzer des Systems Schreibrecht an diesem Verzeichnis erhalten, also Dateien darin ablegen dürfen. 2.Datei f ist ein Element von D und wird von Nutzer Joe (owner) verwaltet. Es soll sichergestellt sein, dass nur der Eigentümer von f die Datei f modifizieren darf.

24 IT-Sicherheit Grundlagen Dr. Wolf Müller 24 Zugriffsmatrix: Sicherheitseigenschaften Modellierung von Zugriffsrechten / Beispiel (2) –Zu modellieren zunächst ist Schreibrecht für Verzeichnisse In UNIX-Semantik: Berechtigung zum Schreibend auf D zugreifen zu dürfen, beinhaltet gleichzeitig Rechte zum Löschen einer beliebigen Datei f aus D und zum Hinzufügen einer Datei f. Schreibrecht fasst Berechtigungen einer vergröberten Berechtigung zusammen. –Modellierung: Menge aller Zugriffsrechte R={owner, all_write, write} –Erfüllung von Anforderung 2.: {owner,write} M t (Joe, f)

25 IT-Sicherheit Grundlagen Dr. Wolf Müller 25 Zugriffsmatrix: Sicherheitseigenschaften Modellierung von Zugriffsrechten / Beispiel (3) –Anforderung 1. im Zugriffmatrix-Modell erfordert, dass alle Benutzer, also auch alle zukünftigen Schreibrecht an D erhalten. Modellierungstechnisches Problem: Lösung durch Definition eines Kommandos Vergabe von all_write-Recht an Objekt D selbst: all_write M t (D,D) –COMMAND all_user_write_for_D(user) IF all_write M t (D,D) THEN enter write into M t (user,D); delete write from M t (user,D) Mit definierten Kommando erhält jedes ausführende Subjekt temporär das Schreibrecht für D (1. ist erfüllet). –Problem: Wegen gewählter Modellierung ist Sicherheitsanforderung 2. verletzt! sowner kann f aus D löschen, also modifizieren. –Lösung: Differenzierung des Schreibrechts an Verzeichnissen {Recht zum Löschen, Recht zum Hinzufügen einer Datei}

26 IT-Sicherheit Grundlagen Dr. Wolf Müller 26 Zugriffsmatrix: Fazit Sehr flexibel einsetzbar, da Objekte & Subjekte beliebig granular festlegbar und Zugriffsrechte universell oder objektspezifisch modellierbar sind. Sorgsame Modellierung wichtig! Probleme: –Zugriffsbeschränkungen sind objektbezogen festzulegen, Gefahr von inkonsistenten Schutzzuständen. Analyse zur der Eigenschaften des Modellsystems zur Erkennung / Beseitigung nötig. –Viele Freiheitsgrade des Modells ermöglicht Beschreibung sehr komplexer Sicherheitseigenschaften, deren Nachweis schwierig. Unter Benutzung von Eigentümerrechten sind benutzerbestimmbare Sicherheitsstrategien zu formulieren. Rollenbasierte Strategie höchstens rudimentär (Gruppenkonzept) beschreibbar. Beschränkung von Informationsflüssen mit Zugriffsmatrix-Ansatz nicht modellierbar.

27 IT-Sicherheit Grundlagen Dr. Wolf Müller 27 Rollenbasierte Modelle Role-based access control (RBAC) Berechtigungen zur Nutzung geschützter Komponenten direkt an Rollen und damit Aufgaben geknüpft. Durch Rollen modellierte Aufgaben werden von Subjekten durchgeführt. Sicherheitsmodell legt fest, welche Subjekte welche Aufgaben durchführen, d.h. in welchen Rollen sie agieren dürfen. –GOYA von R. Sandhu eingeführt. [R. S. Sandhu. Role Hierarchies and Constraints for Lattice-Based Access Controls. In Proceedings of the European Symposium on Research in Security and Privacy, 1996.]

28 IT-Sicherheit Grundlagen Dr. Wolf Müller 28 Rollenbasiertes Sicherheitsmodell Role-based access control (RBAC) Rollenbasiertes Sicherheitsmodell wird durch ein Tupel RBAC=(S,O,RL,P,sr,pr,session), definiert wobei 1.S die Menge der Benutzer des Systems, 2.O die Menge der zu schützenden Objekte und 3.RL die Menge von Rollen ist. Jede Rolle beschreibt eine Aufgabe und damit die Berechtigungen der Rollenmitglieder. 4.P ist die Menge der Zugriffsberechtigungen und 5.sr, pr und session beschreiben Relationen.

29 IT-Sicherheit Grundlagen Dr. Wolf Müller 29 Rollenbasiertes Sicherheitsmodell (2)Role-based access control (RBAC) Rollenbasiertes Sicherheitsmodell wird durch ein Tupel … 5.sr, pr und session beschreiben Relationen. Abbildung sr modelliert Rollenmitgliedschaft eines Subjekts s sr : S 2 RL Falls sr (s) = {R 1, …, R n }, so ist s autorisiert für die Rollen R 1, …, R n. Berechtigungsabbildung weist jeder Rolle R RL die Menge der Zugriffsrechte zu, die die Mitglieder der Rolle während der Rollenaktivitäten wahrnehmen dürfen. pr : S 2 P Relation session S × 2 RL beschreibt Paare (s,rl ), die als Sitzungen bezeichnet werden. Es muss gelten, rl sr(s). Für Subjekt s S und für Sitzung (s,rl ) session gilt, dass s alle Berechtigungen der Rollen R rl besitzt. Sei (s,rl ) eine Sitzung, dann sagt man, s ist aktiv in den Rollen R rl.

30 IT-Sicherheit Grundlagen Dr. Wolf Müller 30 RBAC Beispiel Systemverwaltungsrollen Sun Solaris –Hier: Zu jedem Zeitpunkt höchstens eine Rolle für jeden Benutzer –Angelegt wie Benutzerkennungen (haben eigenes home, group, passwd) –Flache Rollenstruktur, zugeordnete Rechte (Rechte- Profile) hierarchisch strukurierbar –Vordefiniert: Primäradministrator Systemadministrator Operator –su benutzbar, um Rolle zu Wechseln. Sitzungen mit aktiven Rollen Benutzer Rollen Zugriffsrechte sr pr

31 IT-Sicherheit Grundlagen Dr. Wolf Müller 31 Hierarchische RBAC Entspricht Anwendungsumgebung in vielen Unternehmen Aufgaben sind hierarchisch geordnet Erweiterung des RBAC-Modells um partielle Ordnung auf den Rollen –Seien R 1 und R 2 Rollen mit R 1 R 2, so besitzen Mitglieder der Rolle R 2 mindestens auch alle Rechte der Rolle R 1 Rechtevererbung kann jedoch auch problematisch sein, Subjekt erhält unter Umständen mehr Rechte als zur Ausführung seiner Aufgaben nötig, widerspricht Prinzip der minimalen Rechte.

32 IT-Sicherheit Grundlagen Dr. Wolf Müller 32 Hierarchische RBAC Bankszenario Bankfiliale RL = {Filialleiter, Kassierer, Kundenbetreuer, Angestellter, Kassenprüfer, Kunde} Rollenhierarchie:Filialleiter Kassenprüfer, Kassenprüfer Kundenbetreuer, Kassenprüfer Kassierer, Kundenbetreuer Angestellter, Kassierer Angestellter Kundenbetreuer Kassenprüfer Filialleiter Kassierer Angestellter Kunde Problem: Mitglieder der Kassenprüfer-Rolle erben Rechte der Rolle Kassierer

33 IT-Sicherheit Grundlagen Dr. Wolf Müller 33 RBAC-Sicherheitseigenschaften Sicherheitseigenschaften werden in Form von Invarianten angegeben, diese sind durch Realisierung des Modell zu gewährleisten. Notation: –Schreiben R i session genau dann, wenn es ein Paar (s,R) session gibt, mit R i R. –Schreiben {(R i, R j )} session(s), wenn es Paare (s,R ), (s,R ) session gibt, mit R i R und R j R.

34 IT-Sicherheit Grundlagen Dr. Wolf Müller 34 RBAC-Invarianten 1.Subjekt darf nur in solchen Rollen aktiv sein, in denen Mitglied ist: s S muss gelten: R i session(s) R i sr(s) 2.Subjekt nimmt nur Rechte wahr, die der Rolle in der es aktiv ist zugeordnet sind. Gegeben Funktion exec mit: exec: S × K Boolean; exec(s,p)=true: s ist berechtigt, p auszuführen. Dann muss gelten: s S exec(s,p) R i RL: R i session(s) p pr (R i ) 3.In hierarchischen, rollenbasierten Modell gilt, dass ein Subjekt alle Rechte derjenigen Rollen erbt, die von seinen aktiven Rollen dominiert werden: Gegeben sei partielle Ordnung. s S gilt: s S exec(s,p) R i RL: R i session(s) ( p pr (R i ) R k R k R i p pr (R k ) ).

35 IT-Sicherheit Grundlagen Dr. Wolf Müller 35 Beschränkte Rollenmitgliedschaft, statische Aufgabentrennung Oft sinnvoll / notwendig Regeln zur Beschränkung der Rollenmitgliedschaft zu formulieren Regeln zur statischen Aufgabentrennung (static sepearation of duty) Relation SSD beschreibt die statische Aufgabentrennung SSD RL × RL, mit (R i, R k ) SSD die gleichzeitige Mitgliedschaft in de Rollen R i und R k ist ausgeschlossen. Invariante für RBAC-Modell mit der Relation SSD: R i, R k RL mit R i R k s S gilt: (s member (R i ) s member (R k ) ) (R i, R k ) SSD, wobei member (R i ) :={s | s S R i sr(s)} Subjekt darf nur dann Mitglied zweier unterschiedlicher Rollen sein, wenn sich die den Rollen assoziierten Aufgaben sich nicht wechselseitig ausschließen.

36 IT-Sicherheit Grundlagen Dr. Wolf Müller 36 Statische Aufgabentrennung (Bankingszenario) / Fazit Verfeinerung der Rollen des Kassenprüfers und des Kassierers (Bezug auf jeweilige Filiale) –R1 = Kassenprüfer_von_Filiale_A –R2 = Kassierer_in_Filiale_A Kassenprüfer soll Aktivitäten des Kassierers prüfen. Subjekt sollte folglich nicht Mitglied der Kassierer- und Prüferrolle in der selben Filiale sein dürfen. –(R1,R2) SSD Fazit: –Statische Aufgabentrennungen unabhängig von aktiven Sitzungen formuliert. –Oft zu starr. –Oft ausreichend, die gleichzeitige Aktivität von Subjekten in unterschiedlichen Rollen zu untersagen.

37 IT-Sicherheit Grundlagen Dr. Wolf Müller 37 Beschränkte Rollenmitgliedschaft, dynamische Aufgabentrennung Relation DSD beschreibt die dynamisch Aufgabentrennung DSD RL × RL, mit (R i, R k ) DSD die gleichzeitige Aktivität eines Subjekts in den Rollen R i und R k ist unzulässig. Invariante für RBAC-Modell mit der Relation DSD: R i, R k RL s S gilt: {(R i,R k )} session(s) (R i, R k ) DSD Subjekt s darf nicht gleichzeitig in solchen Sitzungen aktiv sein, deren assoziierte Aufgaben wechselseitig ausgeschlossen durchzuführen sind.

38 IT-Sicherheit Grundlagen Dr. Wolf Müller 38 Statische Aufgabentrennung (Bankingszenario) Betrachten wir Kundenbetreuer / Kunde –Bankangestellter der Kundenberater ist, hat oft Konto bei gleicher Bank (statische Trennung unzweckmäßig), trotzdem sollen Manipulation verhindert werden R3 = Kundenbetreuer R4 = Kunde –Forderung Angestellter dar nicht gleichzeitig als Kunde und Berater agieren (R3,R4) DSD

39 IT-Sicherheit Grundlagen Dr. Wolf Müller 39 RBAC-Modell Fazit Objekte anwendungsspezifisch modellierbar. Zugriff auf Objekte wird aufgabenorientiert vergeben. Nachteile klassischer, objektbezogener Sicherheitsstrategien überwunden, da sich Berechtigungsprofile von Rollen nur selten ändern. Reduzierung der Probleme mit Skalierbarkeit Gut geeignet für Einsatz in verteilten Systemen Definierte Invarianten + statische und dynamische Beschränkungen von Rollenaktivitäten ermöglichen Rechtevergabe gemäß des need to know Prinzips


Herunterladen ppt "Humboldt University Computer Science Department Systems Architecture Group IT-Sicherheit Grundlagen Sicherheitsmodelle."

Ähnliche Präsentationen


Google-Anzeigen