Vorlesung #8 Datensicherheit (Autorisierung / SQL)

Präsentation zum Thema: "Vorlesung #8 Datensicherheit (Autorisierung / SQL)"—  Präsentation transkript:

1 Vorlesung #8 Datensicherheit (Autorisierung / SQL)

2 „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š, Datensicherheit

3 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š, Datensicherheit

4 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š, Datensicherheit

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

6 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š, Datensicherheit

7 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š, Datensicherheit

8 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š, Datensicherheit

9 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š, Datensicherheit

10 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š, Datensicherheit

11 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š, Datensicherheit

12 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š, Datensicherheit

13 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š, Datensicherheit

14 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š, Datensicherheit

15 „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š, Datensicherheit

16 „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š, Datensicherheit

17 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š, Datensicherheit

18 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š, Datensicherheit

19 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š, Datensicherheit

20 © Bojan Milijaš, Datensicherheit

21 © Bojan Milijaš, Datensicherheit

22 © Bojan Milijaš, Datensicherheit

23 © Bojan Milijaš, Datensicherheit

24 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š, Datensicherheit

25 Multileveldatenbanken
© Bojan Milijaš, Datensicherheit

26 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š, Datensicherheit

27 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š, Datensicherheit

28 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š, Datensicherheit

29 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š, Datensicherheit

30 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š, Datensicherheit

31 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š, Datensicherheit

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

33 Vorlesung #8 Ende