Grundlagen

1. 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 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

5. Sicherheitsstrategien Unterscheidung in zwei Klassen: • Zugriffskontrollstrategien: • Benutzerbestimmbar • Systembestimmt • Informationsfluss-Strategien Dr. Wolf Müller

6. Zugriffskontrollstrategie • Benutzerbestimmbare (discretionaryaccess 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 • 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|-MatrixMtmodelliert, wobei gilt: • Die Spalten der Matrix werden durch die Menge Otder Objekte • Die Zeilen der Matrix werden durch die Menge der St Subjekte zum Zeitpunktt 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 tmodelliert 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) • 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: • Modellierung von Anwendungsproblemen, bei denen Rechtezustand a priori über lange Zeiträume bekannt ist • Einfache Router, die als Paketfilter / Firewalls arbeiten 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):461-471,1976] Dr. Wolf Müller

14. Dynamische Matrix: Struktur der Kommandos zur Veränderung des Schutzzustandes Dr. Wolf Müller

15. Dynamische Matrix: Elementaroperationen enter und delete 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. Dr. Wolf Müller

17. Dynamische Matrix: Beispiel Kommandos (2) • revoke_r Rechterücknahme, die nur für Berechtigte zulässig ist. Dr. Wolf Müller

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

19. Zugriffsmatrix: SicherheitseigenschaftenSafty-Problem (2) • Systemkonfiguration:Ktzum Zeitpunkt t ist durch Schutzzustand Mtund 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 Ktgelte r Mt(s,o). Dann reduziert sich das Safty-Problem darauf, ob von der Konfiguration Ktausgehend durch Ausführung der Kommandos op1, … ,opn eine Konfiguration Kt+nerreicht werden kann mitr Mt+n(s,o). Dr. Wolf Müller

20. Zugriffsmatrix: SicherheitseigenschaftenSafty-Problem (3) • Harrison, Ruzzo, Ullmann haben Unentscheidbarkeitdes 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 • 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! Dr. Wolf Müller

23. Zugriffsmatrix: SicherheitseigenschaftenModellierung 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 fist 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: SicherheitseigenschaftenModellierung 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: SicherheitseigenschaftenModellierung 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 writeintoMt (user,D); delete writefromMt (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≠ownerkann 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-basedaccess 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. RoleHierarchies 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 SicherheitsmodellRole-based access control (RBAC) • Rollenbasiertes Sicherheitsmodell wird durch ein Tupel RBAC=(S,O,RL,P,sr,pr,session) , definiert wobei • Sdie Menge der Benutzer des Systems, • Odie Menge der zu schützenden Objekte und • RLdie 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) Role-based access control (RBAC) • Rollenbasiertes Sicherheitsmodell wird durch ein Tupel … • sr, pr und session beschreiben Relationen. • Abbildung srmodelliert 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 Rollen • 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‘)  sessiongibt,mit Ri R‘. • Schreiben {(Ri, Rj)}  session(s), wenn es Paare (s,R ‘), (s,R ‘‘)  sessiongibt,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  Smuss gelten: Risession(s)  Risr(s) • Subjekt nimmt nur Rechte wahr, die der Rolle in der es aktiv ist zugeordnet sind. Gegeben Funktionexec 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  Sgilt: 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 AufgabentrennungSSD 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 AufgabentrennungDSD 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