Vorlesung9

WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
Vorlesung #9
Sicherheit
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
„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š, 08.12.2004
Vorlesung #9 - Sicherheit
2
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 08.12.2004
Vorlesung #9 - Sicherheit
3
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 08.12.2004
Vorlesung #9 - Sicherheit
4
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
Angriffsarten
 Missbrauch von Autorität
 Inferenz und Aggregation
 Maskierung
 Umgehung der Zugriffskontrolle
 Browsing
 Trojanische Pferde
 Versteckte Kanäle
© Bojan Milijaš, 08.12.2004
Vorlesung #9 - Sicherheit
5
Sicherheitsmechanismen
in einem DBMS
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 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š, 08.12.2004
Vorlesung #9 - Sicherheit
6
Discretionary Access Control
(DAC)
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 08.12.2004
Vorlesung #9 - Sicherheit
7
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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.“
© Bojan Milijaš, 08.12.2004
Vorlesung #9 - Sicherheit
8
Zugriffskontrolle in SQL
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 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š, 08.12.2004
Vorlesung #9 - Sicherheit
9
Zugriffskontrolle in SQL (2)
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 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š, 08.12.2004
Vorlesung #9 - Sicherheit
10
Zugriffskontrolle in SQL (3)
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 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š, 08.12.2004
Vorlesung #9 - Sicherheit
11
Views
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 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š, 08.12.2004
Vorlesung #9 - Sicherheit
12
Views (2)
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 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š, 08.12.2004
Vorlesung #9 - Sicherheit
13
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 08.12.2004
Vorlesung #9 - Sicherheit
14
„Query Modification“
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 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š, 08.12.2004
Vorlesung #9 - Sicherheit
15
„Query Modification“
Beispiel - Oracle VPD
Query
VPD function
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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´)
SELECT * FROM Projekte
Modified Query
© Bojan Milijaš, 08.12.2004
WHERE Abteilung = `5`
Vorlesung #9 - Sicherheit
16
WS 2004/2005
Verfeinerung des
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 08.12.2004
Vorlesung #9 - Sicherheit
17
Verfeinerung des
Autorisierungsmodells (2)
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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
© Bojan Milijaš, 08.12.2004
Vorlesung #9 - Sicherheit
18
WS 2004/2005
Verfeinerung des
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 08.12.2004
Vorlesung #9 - Sicherheit
19
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
© Bojan Milijaš, 08.12.2004
Vorlesung #9 - Sicherheit
20
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
© Bojan Milijaš, 08.12.2004
Vorlesung #9 - Sicherheit
21
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
© Bojan Milijaš, 08.12.2004
Vorlesung #9 - Sicherheit
22
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
© Bojan Milijaš, 08.12.2004
Vorlesung #9 - Sicherheit
23
Mandatory Access Control
(MAC)
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 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).
© Bojan Milijaš, 08.12.2004
Vorlesung #9 - Sicherheit
24
Multileveldatenbanken
© Bojan Milijaš, 08.12.2004
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
Vorlesung #9 - Sicherheit
25
Multileveldatenbanken (2)
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 08.12.2004
Vorlesung #9 - Sicherheit
26
Vergleich DAC und MAC
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 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 MultilevelDatenbanken.
© Bojan Milijaš, 08.12.2004
Vorlesung #9 - Sicherheit
27
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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š, 08.12.2004
Vorlesung #9 - Sicherheit
28
Kryptographie (2)
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 Es werden gesendete Informationen verschlüsselt.
Hierfür werden in der Praxis zusätzliche Server bzw.
Dienste eingesetzt, die dann sowohl am DatenbankServer als auch am Datenbank-Client (oft nur WebBrowser) 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š, 08.12.2004
Vorlesung #9 - Sicherheit
29
Kryptographie (3)
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
 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š, 08.12.2004
Vorlesung #9 - Sicherheit
30
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
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.
© Bojan Milijaš, 08.12.2004
Vorlesung #9 - Sicherheit
31
Zusammenfassung
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
Legislative Maßnahmen
Organisatorische Maßnahmen
Authentisierung
Zugriffskontrolle
Kryptographie
Datenbank
© Bojan Milijaš, 08.12.2004
Vorlesung #9 - Sicherheit
32
WS 2004/2005
Datenbanken II - 5W
Mi 17:00 – 18:30
G 3.18
Vorlesung #9
Ende