Sicherheitsaspekte. Szenarien. Angriffsarten. Discretionary Access Control. Sicherheit im DBMS. Identifikation und Authentisierung

Transkript

1 Sicherheitsaspekte Sicherheit im DBMS Identifikation und Authentisierun Autorisierun und Zuriffskontrolle Auditin Szenarien Literaturdatenbank in der Hochschule: erines Sicherheitsbedürfnis ERP-Datenbank in einem Betrieb: Vertrauliche Daten Enthüllun kann zu finanziellen Verlusten führen Datenbank einer Bank Enthüllun von Daten kann zum Bankrott der Bank führen Datenbank in einer militärischen Anlae Anriffsarten Missbrauch von Autorität Inferenz ( Volkszählun ) und Areation ( Verkäufe ) Maskierun Umehun der Zuriffskontrolle ( Reviewin von Papern ) Browsin Trojanische Pferde Versteckte Kanäle Discretionary Access Control Zuriffsreeln (o, s, t, p, f) mit o O, der Mene der Objekte (z.b. Relationen, Tupel, Attribute), s S, der Mene der Subjekte (z.b. Benutzer, Prozesse), t T, der Mene der Zuriffsrechte (z.b. T = {lesen, schreiben, löschen}), p ein Prädikat (z.b. Ran = C4 für die Relation Professoren), und f ein Boolescher Wert, der anibt, ob s das Recht (o, t, p) an ein anderes Subjekt s weitereben darf.

2 Discretionary Access Control Zuriffskontrolle in SQL Realisierun: Zuriffsmatrix Sichten Query Modification Nachteile: Erzeuer der Daten = Verantwortlicher für deren Sicherheit Beispiel: rant select on Professoren to eickler; rant update (MatrNr, VorlNr, PersNr) on prüfen to eickler; Weitere Rechte: Zuriffskontrolle in SQL delete insert references Weiterabe von Rechten: with rant option Entzu von Rechten: revoke update (MatrNr, VorlNr, PersNr) on prüfen from eickler cascade; Sichten Realisierun des Zuriffsprädikats: create view ErstSemestler as select * from Studenten where Semester = 1; rant select on ErstSemestler to tutor; Schutz von Individualdaten durch Areation: create view VorlesunsHärte (VorlNr, Härte) as select VorlNr, av(note) from prüfen roup by VorlNr;

3 Auditin Beispiele: audit session by system whenever not successful; audit insert, delete, update on Professoren; Verfeinerunen des Autorisierunsmodells explizite / implizite Autorisierun positive / neative Autorisierun starke / schwache Autorisierun Autorisierunsalorithmus: wenn es eine explizite oder implizite starke Autorisierun (o, s, t) ibt, dann erlaube die Operation wenn es eine explizite oder implizite starke neative Autorisierun (o, s, t) ibt, dann verbiete die Operation ansonsten wenn es eine explizite oder implizite schwache Autorisierun [o, s, t] ibt, dann erlaube die Operation wenn es eine explizite oder implizite schwache Autorisierun [o, s, t] ibt, dann verbiete die Operation Implizite Autorisierun von Subjekten Dekane Professoren wissenschaftliche Anestellte Rektor / in Anestellte Referatsleiter explizite positive Autorisierun implizite positive Autorisierun auf allen höheren Stufen explizite neative Autorisierun implizite neative Autorisierun auf allen niedrieren Stufen Starke und schwache Autorisierun am Beispiel der Autorisierun von Subjekten Dekane Professoren wissenschaftliche Anestellte Rektor / in Aushilfen Leserecht: /Raum aller Anestellten Anestellte Referatsleiter Verwaltunsanestellte Verwaltunsanestellte Leserecht: /Raum aller Anestellten starke pos. Autorisierun starke ne. Autorisierun schwache pos. Autorisierun schwache ne. Autorisierun

4 Implizite Autorisierun von Operationen schreiben Implizite Autorisierun von Objekten Datenbank lesen explizite positive Autorisierun implizite positive Autorisierun auf allen niedrieren Stufen explizite neative Autorisierun implizite neative Autorisierun auf allen höheren Stufen Schema Relation Tupel Attribut Implikationen abhäni von Operation Implizite Autorisierun entlan einer Typhierarchie PersNr Anestellte GebDatum PersNr Benutzerruppen: Implizite Autorisierun entlan einer Typhierarchie Verwaltunsanestellte dürfen die n aller Anestellten lesen PersNr GebDatum Assistenten is-a Professoren GebDatum Ran wissenschaftliche Anestellte dürfen n und Ran aller Professoren lesen Anfraen: lese die n aller Anestellten Fachebiet Raum lese n und Ran aller Professoren

5 Reeln: Implizite Autorisierun entlan einer Typhierarchie Benutzer mit einem Zuriffsrecht auf einem Objekttypen haben auf die eerbten Attribute in den Untertypen ein leicharties Zuriffsrecht Ein Zuriffsrecht auf einen Objekttyp impliziert auch ein Zuriffsrecht auf alle von Obertypen eerbte Attribute in diesem Typ. Ein Attribut, das in einem Untertyp definiert wurde, ist nicht von einem Obertyp aus erreichbar. Mandatory Access Control hierarchische Klassifikation von Vertrauenswürdikeit und Sensitivität clear(s), mit s Subjekt (clearance) class(o), mit o Objekt (classification) Ein Subjekt s darf ein Objekt o nur lesen, wenn das Objekt eine erinere Sicherheitseinstufun besitzt (class(o) clear(s)). Ein Objekt o muss mit mindestens der Einstufun des Subjektes s eschrieben werden (clear(s) class(o)). Multilevel-Datenbanken Benutzer soll sich der Existenz unzuänlicher Daten nicht bewusst sein Beispiel (TC = Klassifizierun des esamten Tupels = Maximum der Attributklassifizierunen): TC s s Kennun KC s Aenten Blond, James Mata, Harry s meucheln spitzeln Sichtweise eines eheim einestuften Benutzers: TC Probleme: Kennun 007 KC Aenten Blond, James - s s eheimer Benutzer füt Tupel mit Schlüssel 008 ein eheimer Benutzer modifiziert von 007 Multilevel-Relationen Multilevel-Relation R mit Schema R = {A 1, C 1, A 2, C 2,..., A n, C n, TC} Relationeninstanzen R C mit Tupeln [a 1, c 1, a 2, c 2,..., a n, c n, tc] c c i a i ist sichtbar, wenn class (s) c i

6 Interitätsbedinunen Sei κ sichtbarer Schlüssel der Multilevel-Relation R Entity-Interität. R erfüllt die Entity-Interität enau dann, wenn für alle Instanzen R c und r R c die folende Bedinunen elten: 1. A i κ r.a i Null 2. A i,a j κ r.c i =r.c j 3. A i κ r.c i r.c κ (wobei C κ die Zuriffsklasse des Schlüssels ist) Interitätsbedinunen Sei κ sichtbarer Schlüssel der Multilevel-Relation R Null-Interität. R erfüllt die Null-Interität enau dann, wenn für jede Instanz R c von R ilt: 1. r R c, r.a i = Null r.c i = r.c κ 2. R c ist subsumierunsfrei, d.h. es existieren keine zwei Tupel r und s, bei denen für alle Attribute A i entweder r.a i = s.a i und r.c i = s.c i oder r.a i Null und s.a i = Null ilt. Subsumtionsfreiheit von Relationen a) R s Aenten TC Kennun KC 007 Blond, James - Interitätsbedinunen Interinstanz-Interität. R erfüllt die Interinstanz- Interität enau dann, wenn für alle Instanzen R c und R c von R mit c < c R c = f(r c, c ) ilt. Die Filterfunktion f arbeitet wie folt: a) Änderun von R s Aenten TC Kennun KC s 007 Blond, James a) Fehlende Subsumtionsfreiheit Aenten TC Kennun KC 007 Blond, James s 007 Blond, James meucheln - meucheln s s 1. Für jedes r R c mit r.c κ c muss ein Tupel s R c existieren, mit r. Ai wenn r. c' s. Ai = Null sonst r. wenn r. c' s. = r. Ck sonst 1. R c enthält außer diesen keine weiteren Tupel. 2. Subsumierte Tupel werden eliminiert.

7 Interitätsbedinunen Polyinstanziierunsinterität. R erfüllt die Polyinstanziierunsinterität enau dann, wenn für jede Instanz R c für alle a i die folende funktionale Abhänikeit ilt: {κ, C κ, C } i A i. Kryptoraphie Gerade die Gefahr des Abhörens von Kommunikationskanälen ist in heutien Datenbankarchitekturen und Anwendunen sehr roß. Die meisten Datenbankanwendunen werden in einer verteilten Umebun betrieben sei es als Client / Server-System oder als echte verteilte Datenbank. In beiden Fällen ist die Gefahr des unleitimierten Abhörens sowohl innerhalb eines LAN (local area network, z.b. Ethernet) als auch im WAN (wide area network, z.b. Internet) eeben und kann technisch fast nicht auseschlossen werden. Deshalb kann nur die Verschlüsselun der esendeten Information einen effektiven Datenschutz ewährleisten. Ebenen des Datenschutzes leislative Maßnahmen oranisatorische Maßnahmen Authentisierun Zuriffskontrolle Kryptoraphie Datenbank