IT-Sicherheit: Übung 2: Zugriffskontrolle Das Biba-Modell Ken Biba, 1977 BLP kann nur Vertraulichkeit sichern, aber keine Integrität Ziel: ein formales und einfaches Modell zur Sicherung der Integrität. Wie könnte ein solches Modell aussehen? Wiederholung aus erster Vorlesung: Integrität (integrity) der Daten: Schutz vor unautorisierter und unbemerkter Veränderung von Daten. (vgl. Integritätsbegriff aus den Datenbanken) 12
Wiederholung: Regeln BLP M sei die Zugriffsmatrix. SC sei eine Menge von Sicherheitsmarkierungen. o O: SC(o) SC sei die Sicherheitsmarkierung von Objekt o (classification) s S: SC(s) SC sei die Sicherheitsmarkierung von Subjekt s (clearance) Simple Security-Property (no read-up) : s S. o O : read M(s,o) SC(o) SC(s) *-Property (no write-down) : s S. o O : write M(s, o) SC(s) SC(o) 13 Biba-Regeln Integrity *-Property (no write-up) : s S. o O : write M(s,o) SC(o) SC(s) Kein unautorisiertes Überschreiben von Daten. Simple Integrity-Property (no read-down) : s S. o O : read M(s,o) SC(s) SC(o) Verhindert das Einlesen von fehlerhaften (unklassifizierten) Daten ( Verseuchung ). 14
Biba-Modell: Einordnung duales Modell zum BLP-Modell Integrität als Sicherheitsziel Beispiele: Bahn: Daten eines Passagier-Informationssystems dürfen nicht die Bahnsteuerungssysteme unautorisiert beeinflussen. LOMAC, Linux-Erweiterung (Systemdaten hohe Klassifikation, Daten über das Netz niedrige Klassifikation) Fragen: Wie könnte ein Modell aussehen, das sowohl die Integrität als auch die Vertraulichkeit sicherstellt? Was lässt sich über den Nutzen eines solchen Modells aussagen? 15 Vertraulichkeit + Integrität Simple Security-Property (no read-up) : s S. o O : read M(s,o) SC(o) SC(s) *-Property (no write-down) : s S. o O : write M(s,o) SC(s) SC(o) Integrity *-Property (no write-up) : s S. o O : write M(s,o) SC(o) SC(s) Simple Integrity-Property (no read-down) : s S. o O : read M(s,o) SC(s) SC(o) Problem: völlige Trennung der Sicherheitsstufen (praktischer Nutzen?) 16
Chinese Wall-Modell (1) Brewer, Nash, 1989 Modell aus Finanzbereich Ausgangspunkt: Berater für verschiedene Unternehmen/Organisationen Insiderwissen darf nicht genutzt werden. Beispielszenario: Ölfirmen: OIL-A, OIL-B Banken: Bank-A, Bank-B Alice, Bob Berater für die Banken und die Ölfirmen 17 Chinese Wall-Modell (2) Vermeidung von Interessenkonflikten (conflict of interest, COI) : Ein Berater darf nicht mehrere Firmen/Organisation aus derselben Konfliktklasse beraten. Einführung von Konfliktklassen (COI classes): Banken, Ölfirmen Zugriffsrechte read, write auf Objekte Objekte sind Firmen/Organisationen zugeordnet (= Besitzer), und Firmen/Organisationen gehören zu Konfliktklassen. 18
Chinese Wall-Modell (3) Simple Security Property: Ein Berater darf auf ein Objekt o lesend zugreifen, falls eine der folgenden Bedingungen erfüllt ist: 1. Der Berater hat schon auf andere Objekte dieser Firma/Organisation zugegriffen oder 2. Das Objekt gehört zu einer Konfliktklasse, für die der Berater noch kein Objekt gelesen hat. Berücksichtigung der Zugriffshistorie; Aufbau einer Chinese Wall Beispiel: Bob berät Bank-B und hat noch nie eine Ölfirma beraten. Auf welche Objekte darf Bob dann noch lesend zugreifen: alle Objekte von Oil-A und Oil-B Alle Objekte von Bank-B (aber nicht von Bank-A,...) 19 Reicht diese Regel aus? Beispiel: Bob berät Bank-B und Oil-A; Alice berät Bank-A und Oil-A. Alice hat insbesondere auch Schreibrechte für Objekte aus Oil-A. Was ist, wenn Trojanische Pferde als Bedrohung zu berücksichtigen sind? Einführung einer neuen Regel 20
Chinese Wall-Modell (4) *-Property: Ein Berater darf ein Objekt O nur dann schreiben, wenn er lesenden Zugriff ausschließlich auf Objekte aus der Firma/Organisation hat, zu der Objekt O gehört. Für unser Beispiel bedeutet dies: Alice darf nicht Objekte in Oil-A schreiben, weil sie lesenden Zugriff auf Objekte aus Bank-A hat. Vergleich mit der Problematik Verdeckte Kanäle 21 Bewertung/Einordnung Chinese Wall-Modell zugeschnitten auf bestimmte Problematik aus dem Finanzbereich nur Vertraulichkeit, keine Integrität Umsetzung durch organisatorische Maßnahmen und weniger durch IT-Systeme 22
Rollenbasierte Zugriffskontrolle (2) Komponenten des RBAC96-Modelles gemäß Sandhu et al.: Eine Rolle (role) ist eine Sammlung von Zugriffsberechtigungen (permissions), die Benutzern (users) zugewiesen werden. Benutzer sind Personen (und keine Prozesse, vgl. Subjekt-Begriff) Zugriffsberechtigungen sind Paare (Operation, Objekt). Beispiele: read File1, read File2, debit account1, credit account2, drop table1 Mengen: Users (U), Roles (R), Permissions (P), Sessions (S) 24 Rollenbasierte Zugriffskontrolle (3) Rollen werden Zugriffsberechtigungen und Nutzern zugeordnet. Relationen: UA UxR (user assignment) Zuordnung von Benutzern zu Rollen PA PxR (permission assignment) Zuordnung von Zugriffsberechtigungen zu Rollen RBAC soll Organisationsstrukturen nachbilden, also Einführung von Rollenhierarchien: RH RxR (role hierarchy), RH ist eine partielle Ordnung auf RxR Rollen werden von Benutzern in Sessions (Sitzungen) aktiviert, wobei jede Session genau einen User hat. Andererseits kann ein User mehrere Sessions aktivieren. 25
Beispiel für RBAC-Relationen Die Benutzer Alice und Bob sollen der Rolle Bankangestellter zugewiesen werden. Die Rolle Bankangestellter hat die Berechtigungen Kontostand abfragen, Kontostand erhöhen, Kontostand verringern. Wie sehen UA und PA aus? UA= {(Bob, Bankangestellter), (Alice, Bankangestellter)} PA= {(Kontostand abfragen, Bankangestellter), (Kontostand erhöhen, Bankangestellter), (Kontostand verringern, Bankangestellter)} 26 Warum vereinfacht RBAC das Berechtigungsmanagement? P3 P1 P2 Alice R P4 P5 P6 Bob P8 P7 P9 27
Separation of Duty Aufgabentrennung Vorteil von RBAC: natürliche Abbildung von organisationsinternen Kontrollregeln Beispiel zur Motivation: Niedergang der Barings-Bank Aufgabentrennung (separation of duty) verletzt: In a fatal mistake, the bank allowed Leeson to remain Chief Trader while being responsible for settling his trades, a job that is usually split. This had made it much simpler for him to hide his losses. Beispiele für die Aufgabentrennung: Kassenprüfer und Kassierer dürfen nicht von ein und derselben Person angenommen werden. Kunde und Kreditberater 30 Statische Separation of Duty In RBAC-Formalismus: CR (Menge von Konfliktrollen) wie z.b. CR={Kassierer, Kassenprüfer} roles(u) = {r R (u,r) UA} Statisches Separation of Duty u U: roles(u) CR 1 User u darf jeweils höchstens eine Konfliktrolle annehmen. Was ist mit den Rollen Kreditberater und Kunde? 31
Dynamische Separation of Duty Trennung von Rollen nicht beim UA, sondern beim Aktivieren von Rollen in Sitzungen In RBAC-Formalismus: active_roles(u) = {r R (u,r) UA s S.(user(s)=u r session_roles(s))} Dynamic Separation of Duty: u U: active_roles(u) CR 1 User u darf höchstens eine Konfliktrolle aktiviert haben. 32 Informationssicherheit 1, 2 te Übung Aufgabe 1: etwas mit (Solaris-)ACLs fingerfertig werden Einstiegspunkt: Man-Pages zu getfacl(1), setfacl(1) einfache und komplexe Beispiele im Netz; daher hier keines dokumentieren, was Ihr gemacht und wie Ihr es getestet habt Veranstalter sind nicht in Gruppe stud ($HOME ggf. öffnen) Aufgabe 2: zuvor gesetzte ACLs unter Linux betrachten 36
Informationssicherheit 1, 2 te Übung Aufgabe 3: mit.htaccess/.htpasswd fingerfertig werden Dokumentation zu Mechanismen und Kommandos im Netz nachsehen, welche Verschlüsselungsverfahren brauchbar sind bar:$apr1$b74...$5gsbudputycamdkrboeef. bla:7zxy9iyvjp.di ich:{sha}/6zwb/isenszcwcnvvg8uy5d7qi= sie:bla prüfen, ob Rahmenbedingungen im Fachbereichsnetz okay sind 37