SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R Vorlesung #10 Datensicherheit

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit2 Fahrplan Einführung und Motivation Schutzbedürfnisse Angriffsarten Schutzmechanismen in DBMS Identifikation und Authentisierung Autorisierung und Zugriffskontrolle Auditing Discretionary Access Control (DAC) Zugriffskontrolle in SQL Mandatory Access Control Multilevel-Datenbanken Kryptographie Zusammenfassung

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit3 Einführung Die Daten stellen einen immensen Wert für Unternehmen oder Organisationen dar. Bisher – Maßnahmen gegen unabsichtliche Beschädigung der Daten wie Integritätsprüfungen Mehrbenutzersynchronisation Recovery (wird noch eingeführt) Jetzt – Schutz gegen absichtliche Enthüllung, Beschädigung, Zerstörung oder Verfälschung von wertvollen (meist sensiblen oder persönlichen) Daten

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit4 Schutzbedürfnisse Das Schutzbedürfnis des eingesetzten System muss richtig eingeschätzt werden, denn Sicherheit ist vor allem ein Kostenfaktor. Beispiele für verschiedene Schutzbedürfnisse: Datenbank an einer Hochschule Datenbank in einem Betrieb Datenbank in einer militärischen Anlage Das Schutzbedürfnis soll bei der Planung, d.h. vor dem Einsatz der Datenbank(Anwendung) als wichtige Anforderung dokumentiert und auf die Verträglichkeit mit geltenden Gesetzen und internen Sicherheitsrichtlinien überprüft werden (siehe Zusammenfassung)

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit5 Angriffsarten Missbrauch von Autorität Inferenz und Aggregation Maskierung Umgehung der Zugriffskontrolle Browsing Trojanische Pferde Versteckte Kanäle

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit6 Sicherheitsmechanismen in einem DBMS Identifikation und Authentisierung Passwörter Vorgeschaltete Zugangssysteme mit Fingerabdruck, Magnet- oder ID-Karten, usw. Autorisierung und Zugriffskontrolle Sicherheitsobjekte – z.B. Tabellen, Prozeduren Sicherheitssubjekte – z.B. Benutzer, Benutzergruppen, Betriebsystem-Prozesse Autorisierung – Menge von Regeln, die die erlaubten Arten des Zugriffs auf Sicherheitsobjekte durch Sicherheitssubjekte regeln Auditing - Protokollierung aller sicherheitsrelevanten Datenbankoperationen

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit7 Discretionary Access Control (DAC) Zugriffsregeln (o, s, t, p, f) mit o O, der Menge der Objekte (z.B. Relationen, Tupel, Attribute), s S, der Menge der Subjekte (z.B. Benutzer, Prozesse), t T, der Menge der Zugriffsrechte (z.B. T = {lesen, schreiben, löschen}), p ein Prädikat (z.B. Rang = C4 für die Relation Professoren), und f ein Boolescher Wert, der angibt, ob s das Recht (o, t, p) an ein anderes Subjekt s weitergeben darf.

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit8 DAC (2) Realisierung: Zugriffsmatrix (kann sehr groß werden) Sichten (Views) Query Modification (dynamische Veränderung der Abfrage) zusätzliche WHERE Bedingung wird angehängt oder es wird nur auf erlaubte Attribute (Spalten) projiziert Nachteile: Erzeuger der Daten = Verantwortlicher für deren Sicherheit Bespiel: Die Sekretärin stellt einen Bericht ihres Vorgesetzten ins Intranet.

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit9 Zugriffskontrolle in SQL Kein weitgehender SQL 92 Standard (nur GRANT und REVOKE) Weitergabe von Rechten (GRANT) grant select on Professoren to eickler; grant update (MatrNr, VorlNr, PersNr) on prüfen to eickler; Das Recht für weitere Weitergaben (GRANT Option) grant select on Professoren to eickler with grant option; Entzug von Rechten (REVOKE) revoke update (MatrNr, VorlNr, PersNr) on prüfen from eickler cascade;

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit10 Zugriffskontrolle in SQL (2) REVOKE CASCADE ist das Gegenstück zu GRANT WITH GRANT OPTION Privilegien kann man grob unterscheiden in Objektprivilegien: SELECT, UPDATE, DELETE, INSERT, REFERENCE Systemprivilegien (DBMS spezifisch – hier ORACLE): CREATE ANY INDEX, CREATE PUBLIC SYNONYM, CREATE SESSION, DROP ANY TABLE, usw. Man kann die Administration der Zugriffsrechte durch Einführung und Verwaltung von Rollen vereinfachen CREATE ROLE Pruefer; GRANT TO Pruefer; GRANT Pruefer TO eickler, kossmann;

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit11 Zugriffskontrolle in SQL (3) Da man bei der vorgestellten Granularität sehr viele unterschiedlichen Rechte vergeben und wieder zurücknehmen kann, ist die resultierende Zugriffsmatrix sehr groß Die Zugriffsmatrix kann durch das Betrachten des DBMS Data Dictionary angesehen werden (Oracle Beispiel): SELECT * FROM dba_role_privs; SELECT * FROM dba_table_privs; Mit Hilfe des Datenwörterbuchs kann dann gezielt nach Objekten, Subjekten, Zugriffsrechten und Weitergaberechten gesucht werden

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit12 Views DAC-Modell sieht vor, dass Rechte abhängig von Bedingungen weitergegeben können In SQL kann dies mit Views abgebildet werden: CREATE VIEW ErstSemestler AS SELECT * FROM Studenten WHERE Semester = 1; GRANT SELECT ON ErstSemestler TO Tutor;

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit13 Views (2) Views können auch für die Aggregation verwendet werden. Schützenswerte Individualdaten bleiben durch anonymisierte Statistiken verborgen. CREATE VIEW VorlesungsHaerte(VorlNr, Haerte) AS SELECT VorlNr, avg(Note) FROM pruefen GROUP BY VorlNr Man muss aufpassen, dass genug Werte aggregiert werden, sonst kann man aus der Statistik auf die Individualwerte zurückschließen.

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit14 Auditing Protokollierung der einzelnen Operationen. Es entsteht eine u.U, sehr grosse Protokoll-DateiAuditfolge. Alle fehlgeschlagenen Zugriffsversuche von der Systemkennung SYSTEM aus: AUDIT SESSION BY SYSTEM WHENEVER NOT SUCCESSFUL; DML Operationen auf Professoren AUDIT INSERT, DELETE, UPDATE ON Professoren; -- rückgängig mit NOAUDIT NOAUDIT SELECT ON Professoren;

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit15 Query Modification dynamische Veränderung der Abfrage zusätzliche WHERE Bedingung wird angehängt oder es wird nur auf erlaubte Attribute (Spalten) projiziert Beispiel – Virtual Private Database von Oracle Es gibt eine zusätzliche Funktion SYS_CONTEXT(namespace,attribute), die aus der Umgebung namespace, den Wert für attribute zur Laufzeit liest. Einige Werte für namespace = USERENV sind HOST, IP_ADDRESS, CURRENT_USER usw. Die einzelnen Werte pro namespace werden beim Initialisieren der Datenbank-Anwendung gesetzt und können dann mit SYS_CONTEXT in die Abfragen eingebaut werden Beispiel: auf Projekte darf gemäß Abteilungszugehörigkeit zugegriffen werden...

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit16 Query Modification Beispiel - Oracle VPD Query VPD function Modified Query SELECT * FROM Projekte; SELECT * FROM Projekte WHERE Abteilung = `5` Initalisieren durch DB Applikation dbms_session.set_context (...); dbms_session.set_identifier(); Einsatz von sys_context VPD function SELECT * FROM Projekte WHERE Abteilung = sys_context(`projekt_app´,`abteilung´)

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit17 Verfeinerung des Autorisierungsmodells Zugriffsverwaltung kann sehr aufwendig werden. Verbesserungen sind möglich durch: Explizite/Implizite Autorisierung Explizite Autorisierung impliziert eine Vielzahl von impliziten Autorisierungen Positive/negative Autorisierung Oft einfacher die Regel durch die Negation auszudrücken (o, s, t) statt (o, s, t) Schwache/starke Autorisierung Beispiel: Alle Uni-Angestellten bekommen schwaches Leserecht, studentische Aushilfen bekommen starkes Leseverbot zum Lesen von Noten. Man kann sie miteinander kombinieren...

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit18 Verfeinerung des Autorisierungsmodells (2) Autorisierungsalgorithmus: wenn es eine explizite oder implizite starke Autorisierung (o, s, t) gibt, dann erlaube die Operation wenn es eine explizite oder implizite starke negative Autorisierung (o, s, t) gibt, dann verbiete die Operation ansonsten wenn es eine explizite oder implizite schwache Autorisierung [o, s, t] gibt, dann erlaube die Operation wenn es eine explizite oder implizite schwache Autorisierung [o, s, t] gibt, dann verbiete die Operation

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit19 Verfeinerung des Autorisierungsmodells (3) Man definiert eine Hierarchie Wenn es eine (explizite) Autorisierung auf einer Ebene der Hierarchie gibt, dann gilt sie automatisch (implizit) auf allen Ebenen tiefer. Es bestehen insgesamt folgende Möglichkeiten implizite/explizite, schwache/starke, positive/negative Autorisierung von Subjekten, Objekten und Operationen

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit20

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit21

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit22

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit23

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit24 Mandatory Access Control (MAC) Idee: S sicherheitsrelevante Dokumente entsprechend markiert werden: öffentlich, vertraulich, geheim, streng geheim usw. Diese Praxis wird in MAC übernommen: 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 geringere Sicherheitseinstufung besitzt (class(o) clear(s)). Ein Objekt o muss mit mindestens der Einstufung des Subjektes s geschrieben werden (clear(s) class(o)). Hauptproblem: unterschiedliche Stufen können kaum kommunizieren (Bsp. General und einfacher Soldat).

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit25 Multileveldatenbanken

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit26 Multileveldatenbanken (2) Lösung Polyinstanzinierung, sowohl geheimer als auch nicht geheimer 008 werden hinzugefügt. 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 Komplexe Integritätsbedingungen (s. Kemper, Kapitel 12.5)

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit27 Vergleich DAC und MAC MAC bietet bessere Sicherheit als DAC, aber schränkt die Kommunikationsfähigkeit und die Systemperformance. Das beschriebene DAC Modell wird weitgehend unterstützt und in Standard SQL implementiert. Einige kommerziellen DBMS unterstützen auch MAC Modell und Multilevel- Datenbanken.

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit28 Kryptographie (Verschlüsselung) Die Gefahr des Abhörens von Kommunikationskanälen ist in heutigen Datenbankarchitekturen und Anwendungen sehr groß. Die meisten Datenbankanwendungen werden in einer verteilten Umgebung betrieben (Client-Server Systeme, Internet-Datenbanken, verteilte Datenbanken), d.h. in Netzwerken LAN (local area network, z.B. Ethernet) WAN (wide area network, z.B. Internet) Sowohl in LAN als auch in WAN ist die Gefahr des Abhörens gegeben und kann technisch nicht ausgeschlossen werden Verschlüsselung

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit29 Kryptographie (2) Es werden gesendete Informationen verschlüsselt. Hierfür werden in der Praxis zusätzliche Server bzw. Dienste eingesetzt, die dann sowohl am Datenbank- Server als auch am Datenbank-Client (oft nur Web- Browser) installiert und betrieben werden müssen Es können aber auch innerhalb der Datenbank Daten (z.B. Inhalte von Tabellen) verschlüsselt, d.h. für den DBA unlesbar gemacht werden. Der Administrator muss bzw. darf nicht alles sehen können!. Beispiel - Gehaltsdatenbank in einem Unternehmen: DBA soll nicht den Gehalt des IT Managers sehen.

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit30 Kryptographie (3) Bei der Verschlüsselung kommt es auf die Geheimheit von Schlüsseln und nicht von Verschlüsselungsalgorithmen an. Knacken - nur durch Ausprobieren aller möglichen Schlüssel. Bei den meisten Verschlüsselungsverfahren wird mit Modulo und Primzahl-Funktionen gearbeitet. Je größer die Anzahl der möglichen Kombinationen, d.h. je länger der Schlüssel (z.B. 32-, 64-, 128-Bit Schlüssel) umso sicherer ist die Verschlüsselung. 100% Garantie gibt es aber bei keinem Verschlüsselungsverfahren deshalb sind legislative und organisatorische Maßnahmen auch sehr wichtig.

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit31 Kryptographie (4) Public-Key Kryptographie RSA Verfahren (Rivest, Shamir und Adleman) Mitte der 70er entstanden Idee- Schnappschlösser Benutzer teilt mehrere Schnappschlösser aus Jeder, der einen Schnappschloss bekommen hat, kann mit ihm Dinge verschließen Nur Benutzer hat aber den Schlüssel und kann die Schlösser öffnen Motivation und Bedeutung von Public-Key Verfahren liegt darin, dass eine Verschlüsselung ohne vorherigen (unsicheren bzw. unverschlüsselten) Austausch von geheimen Informationen möglich ist.

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R © Bojan Milijaš, Datensicherheit32 Zusammenfassung Datenbank Kryptographie Zugriffskontrolle Authentisierung Organisatorische Maßnahmen Legislative Maßnahmen

SS 2013 – IBB4C Datenmanagement Fr 17:00 – 18:30 R Vorlesung #10 Ende