SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
Vorlesung #10
Datensicherheit
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 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
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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 (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 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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)
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 5
Angriffsarten
Missbrauch von Autorität
Inferenz und Aggregation
Maskierung
Umgehung der Zugriffskontrolle
Browsing
Trojanische Pferde
Versteckte Kanäle
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 6
Sicherheitsmechanismenin 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 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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.
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 8
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 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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üfenfrom eickler cascade;
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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;
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 12
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 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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.
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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 ProfessorenAUDIT INSERT, DELETE, UPDATE ON Professoren;
-- rückgängig mit NOAUDIT
NOAUDIT SELECT ON Professoren;
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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 ...“
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 16
„Query Modification“ Beispiel - Oracle VPD
Query
VPD function
Modified Query
SELECT * FROM Projekte;
SELECT * FROM Projekte
WHERE Abteilung = `5`
-- 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´)
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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 ...
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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
ansonstenwenn 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 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 20
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 21
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 22
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 23
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 24
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 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 25
Multileveldatenbanken
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 26
Multileveldatenbanken (2)
Lösung Polyinstanzinierung, sowohl geheimer als auch nicht geheimer „008“ werden hinzugefügt.
Multilevel-Relation R mit SchemaR = {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)
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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.
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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.
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 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.
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 31
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 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
© Bojan Milijaš, 11.04.23 Datensicherheit 32
Zusammenfassung
Datenbank
Kryptographie
Zugriffskontrolle
Authentisierung
Organisatorische Maßnahmen
Legislative Maßnahmen
SS 2013 – IBB4CDatenmanagement
Fr 17:00 – 18:30R 0.012
Vorlesung #10
Ende