Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Sicherheitsmodelle Klassifikation, Bewertung, Access Control

Ähnliche Präsentationen


Präsentation zum Thema: "Sicherheitsmodelle Klassifikation, Bewertung, Access Control"—  Präsentation transkript:

1 Sicherheitsmodelle Klassifikation, Bewertung, Access Control
Grundlagen Sicherheitsmodelle Klassifikation, Bewertung, Access Control

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. Dr. Wolf Müller

3 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

4 Modell: Zugriffsrechte, Zugriffsbeschränkungen
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

5 Sicherheitsstrategien
Unterscheidung in zwei Klassen: Zugriffskontrollstrategien: Benutzerbestimmbar Systembestimmt Informationsfluss-Strategien 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 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. Dr. Wolf Müller

8 Zugriffskontrollmodelle
Zugriffsmatrix-Modell Rollenbasierte Modelle Chinese-Wall Modell Bell-LaPadua Modell 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. Dr. Wolf Müller

10 Zugriffsmatrix Schutzzustand eines Systems zum Zeitpunkt t wird durch eine |St|£|Ot|-Matrix Mt modelliert, wobei gilt: Die Spalten der Matrix werden durch die Menge Ot der Objekte Die Zeilen der Matrix werden durch die Menge der St Subjekte zum Zeitpunkt t definiert. Es gilt: Mt: St £ Ot ! 2R , wobei R die Menge der Zugriffsrechte festlegt. Ein Eintrag Mt (s,o)={r1,…,rn} 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 Mt ,die in dem betreffenden Zustand gültigen Zugriffsrechte der Subjekte an den Objekten des Systems. Der Schutzzustand des Systems (Mt) 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. Dr. Wolf Müller

11 Zugriffsmatrix: Beispiel
Rechte: Senden, Empfangen (Ports, Sockets), wait, signal (Ausführung von Synchronisationsoperationen) control (Eigentümer-Recht) Datei 1 Datei 2 Prozess 1 Prozess 2 Prozess 3 Prozess 4 c,send c wait,signal read,write write,ownwer receive send read,execute 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. Dr. Wolf Müller

12 Statische Matrix Statisch: Port 21 Port 25 Port 53 Port 514 1023
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 FTP-Server receive send Mail-Rechner Externer Rechner 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] Dr. Wolf Müller

14 Dynamische Matrix: Struktur der Kommandos zur Veränderung des Schutzzustandes
Erläuterung COMMAND (X1,…,Xk) IF r1 IN (XS1,XO1) AND Rm IN (XSm,XOm) THEN op1, … , opn END;  ist ein Regel-Name Xi Ot St formale Parameter ri R Rechte opi Elementaroperation Dr. Wolf Müller

15 Dynamische Matrix: Elementaroperationen enter und delete
Bedingung Wirkung enter r into (s,o) si St , oi Ot Mt‘(s,o) = Mt(s,o)  {r} delete r into (s,o) Mt‘(s,o) = Mt(s,o) \ {r} 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. Kommando Erläuterung COMMAND END; create (user,file) create file; enter owner into (user file) Aufruf durch Subjekt user Ot‘ = Ot  {file} neue Spalte in der Matrix Eigentümer-Recht an Subjekt user vergeben Dr. Wolf Müller

17 Dynamische Matrix: Beispiel Kommandos (2)
revoke_r Rechterücknahme, die nur für Berechtigte zulässig ist. Kommando Erläuterung COMMAND END; revoke_r (S1,S2,X) IF owner  Mt(S1,X) AND r  Mt(S2,X) THEN delete r from (S2,X) Aufruf durch Subjekt S1 Rechterücknahme Dr. Wolf Müller

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

19 Zugriffsmatrix: Sicherheitseigenschaften Safty-Problem (2)
Systemkonfiguration: Kt zum Zeitpunkt t ist durch Schutzzustand Mt und die in diesem Zustand existierenden Mengen von Objekten und Subjekten festgelegt. Kt =(Mt ,Ot,St) Konfigurationsübergang durch Kommando op: Safty-Problem: Sei K0 Anfangskonfiguration und für Kt gelte r  Mt(s,o). Dann reduziert sich das Safty-Problem darauf, ob von der Konfiguration Kt ausgehend durch Ausführung der Kommandos op1, … ,opn eine Konfiguration Kt+n erreicht werden kann mit r  Mt+n(s,o). 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. Dr. Wolf Müller

21 Zugriffsmatrix: Sicherheitseigenschaften Soll-Ist-Vergleiche
Gegeben konkretes Systemmodell mit festgelegter Kommandomenge und Schutzzustand Mt. 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. 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_Bill Drucke_Auszug Joe execute lese_Kontostand 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: Verzeichnis D ist Objekt (tmp-Datei) für das alle Benutzer des Systems Schreibrecht an diesem Verzeichnis erhalten, also Dateien darin ablegen dürfen. 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. 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}  Mt(Joe, f) 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  Mt (D,D) COMMAND all_user_write_for_D(user) IF all_write  Mt (D,D) THEN enter write into Mt (user,D); delete write from Mt (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! s≠owner 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} 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. 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. GOYA3 1996 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.] 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 S die Menge der Benutzer des Systems, O die Menge der zu schützenden Objekte und RL die Menge von Rollen ist. Jede Rolle beschreibt eine Aufgabe und damit die Berechtigungen der Rollenmitglieder. P ist die Menge der Zugriffsberechtigungen und sr, pr und session beschreiben Relationen. Dr. Wolf Müller

29 Rollenbasiertes Sicherheitsmodell (2)
Rollenbasiertes Sicherheitsmodell (2) Role-based access control (RBAC) Rollenbasiertes Sicherheitsmodell wird durch ein Tupel … sr, pr und session beschreiben Relationen. Abbildung sr modelliert Rollenmitgliedschaft eines Subjekts s sr : S  2RL Falls sr (s) = {R1, … , Rn}, so ist s autorisiert für die Rollen R1, … , Rn. 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  2P Relation session  S × 2RL 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. 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. Zugriffsrechte Benutzer pr sr Sitzungen mit aktiven Rollen 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 R1 und R2 Rollen mit R1 ≤ R2, so besitzen Mitglieder der Rolle R2 mindestens auch alle Rechte der Rolle R1 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. 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 Angestellter Kunde Problem: Mitglieder der Kassenprüfer-Rolle erben Rechte der Rolle Kassierer Kassierer Kundenbetreuer Kassenprüfer Filialleiter 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 Ri  session genau dann, wenn es ein Paar (s,R‘)  session gibt, mit Ri  R‘. Schreiben {(Ri, Rj)}  session(s), wenn es Paare (s,R ‘), (s,R ‘‘)  session gibt, mit Ri  R‘ und Rj  R‘‘. Dr. Wolf Müller

34 RBAC-Invarianten Subjekt darf nur in solchen Rollen aktiv sein, in denen Mitglied ist: s  S muss gelten: Ri  session(s)  Ri  sr(s) 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)   Ri  RL: Ri  session(s)  p  pr (Ri) 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)   Ri  RL: Ri  session(s)  ( p  pr (Ri)   Rk  Rk ≤ Ri  p  pr (Rk) ). 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 (Ri, Rk)  SSD  die gleichzeitige Mitgliedschaft in de Rollen Ri und Rk ist ausgeschlossen. Invariante für RBAC-Modell mit der Relation SSD:  Ri, Rk  RL mit Ri  Rk  s  S gilt: (s  member (Ri)  s  member (Rk) )  (Ri, Rk)  SSD, wobei member (Ri) :={s | s  S  Ri  sr(s)} Subjekt darf nur dann Mitglied zweier unterschiedlicher Rollen sein, wenn sich die den Rollen assoziierten Aufgaben sich nicht wechselseitig ausschließen. 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. Dr. Wolf Müller

37 Beschränkte Rollenmitgliedschaft, dynamische Aufgabentrennung
Relation DSD beschreibt die dynamisch Aufgabentrennung DSD  RL × RL, mit (Ri, Rk)  DSD  die gleichzeitige Aktivität eines Subjekts in den Rollen Ri und Rk ist unzulässig. Invariante für RBAC-Modell mit der Relation DSD:  Ri, Rk  RL  s  S gilt: {(Ri,Rk)}  session(s)  (Ri, Rk)  DSD Subjekt s darf nicht gleichzeitig in solchen Sitzungen aktiv sein, deren assoziierte Aufgaben wechselseitig ausgeschlossen durchzuführen sind. 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 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 Dr. Wolf Müller


Herunterladen ppt "Sicherheitsmodelle Klassifikation, Bewertung, Access Control"

Ähnliche Präsentationen


Google-Anzeigen