Vorlesung #8 Datensicherheit (Autorisierung / SQL)

„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 © Bojan Milijaš, 16.06.2017 Datensicherheit

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 Jetzt – Schutz gegen absichtliche Enthüllung, Beschädigung, Zerstörung oder Verfälschung von wertvollen (meist sensiblen oder persönlichen) Daten © Bojan Milijaš, 16.06.2017 Datensicherheit

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) © Bojan Milijaš, 16.06.2017 Datensicherheit

Angriffsarten Missbrauch von Autorität Inferenz und Aggregation Maskierung Umgehung der Zugriffskontrolle Browsing Trojanische Pferde Versteckte Kanäle © Bojan Milijaš, 16.06.2017 Datensicherheit

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 © Bojan Milijaš, 16.06.2017 Datensicherheit

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. © Bojan Milijaš, 16.06.2017 Datensicherheit

DAC (2) Realisierung: Nachteile: 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.“ © Bojan Milijaš, 16.06.2017 Datensicherheit

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; © Bojan Milijaš, 16.06.2017 Datensicherheit

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 <Privileges> TO Pruefer; GRANT Pruefer TO eickler, kossmann; © Bojan Milijaš, 16.06.2017 Datensicherheit

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 © Bojan Milijaš, 16.06.2017 Datensicherheit

In SQL kann dies mit Views abgebildet werden: 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; © Bojan Milijaš, 16.06.2017 Datensicherheit

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. © Bojan Milijaš, 16.06.2017 Datensicherheit

Auditing Protokollierung der einzelnen Operationen. Es entsteht eine u.U, sehr grosse Protokoll-Datei „Auditfolge“. 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; © Bojan Milijaš, 16.06.2017 Datensicherheit

„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 ...“ © Bojan Milijaš, 16.06.2017 Datensicherheit

„Query Modification“ Beispiel - Oracle VPD SELECT * FROM Projekte; -- 1. Initalisieren durch DB Applikation dbms_session.set_context (...); dbms_session.set_identifier(); -- 2. Einsatz von sys_context VPD function SELECT * FROM Projekte WHERE Abteilung = sys_context(`projekt_app´,`abteilung´) VPD function SELECT * FROM Projekte WHERE Abteilung = `5` Modified Query © Bojan Milijaš, 16.06.2017 Datensicherheit

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 ... © Bojan Milijaš, 16.06.2017 Datensicherheit

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, wenn es eine explizite oder implizite schwache Autorisierung [o, s, t] gibt, © Bojan Milijaš, 16.06.2017 Datensicherheit

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 © Bojan Milijaš, 16.06.2017 Datensicherheit

© Bojan Milijaš, 16.06.2017 Datensicherheit

© Bojan Milijaš, 16.06.2017 Datensicherheit

© Bojan Milijaš, 16.06.2017 Datensicherheit

© Bojan Milijaš, 16.06.2017 Datensicherheit

Mandatory Access Control (MAC) Idee: sicherheitsrelevante Dokumente entsprechend markieren: „ö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). © Bojan Milijaš, 16.06.2017 Datensicherheit

Multileveldatenbanken © Bojan Milijaš, 16.06.2017 Datensicherheit

Multileveldatenbanken (2) Lösung  Polyinstanzinierung, sowohl geheimer als auch nicht geheimer „008“ werden hinzugefügt. Multilevel-Relation R mit Schema R = {A1, C1, A2, C2, . . ., An, Cn, TC} Relationeninstanzen RC mit Tupeln [a1, c1, a2, c2, . . . , an, cn, tc] c  ci ai ist sichtbar, wenn class (s)  ci  Komplexe Integritätsbedingungen (s. Kemper, Kapitel 12.5) © Bojan Milijaš, 16.06.2017 Datensicherheit

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. © Bojan Milijaš, 16.06.2017 Datensicherheit

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 © Bojan Milijaš, 16.06.2017 Datensicherheit

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. © Bojan Milijaš, 16.06.2017 Datensicherheit

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. © Bojan Milijaš, 16.06.2017 Datensicherheit

Kryptographie (4) Public-Key Kryptographie Idee- „Schnappschlösser“ 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. © Bojan Milijaš, 16.06.2017 Datensicherheit

Zusammenfassung Legislative Maßnahmen Organisatorische Maßnahmen Datenbank Kryptographie Zugriffskontrolle Authentisierung Organisatorische Maßnahmen Legislative Maßnahmen © Bojan Milijaš, 16.06.2017 Datensicherheit

Vorlesung #8 Ende