SS 2011 – IBB4C Datenmanagement Fr 15:15 – 16:45 R 1.007 Vorlesung #10 Datensicherheit.

SS 2011 – IBB4CDatenmanagement

Fr 15:15 – 16:45R 1.007

Vorlesung #10

Datensicherheit


Fr 15:15 – 16:45R 1.007

© 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


Fr 15:15 – 16:45R 1.007


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


Fr 15:15 – 16:45R 1.007


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)


Fr 15:15 – 16:45R 1.007


Angriffsarten

Missbrauch von Autorität

Inferenz und Aggregation

Maskierung

Umgehung der Zugriffskontrolle

Browsing

Trojanische Pferde

Versteckte Kanäle


Fr 15:15 – 16:45R 1.007


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


Fr 15:15 – 16:45R 1.007


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.


Fr 15:15 – 16:45R 1.007


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.“


Fr 15:15 – 16:45R 1.007


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;


Fr 15:15 – 16:45R 1.007


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;


Fr 15:15 – 16:45R 1.007


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


Fr 15:15 – 16:45R 1.007


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;


Fr 15:15 – 16:45R 1.007


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.


Fr 15:15 – 16:45R 1.007


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;


Fr 15:15 – 16:45R 1.007


„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 ...“


Fr 15:15 – 16:45R 1.007


„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´)


Fr 15:15 – 16:45R 1.007


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 ...


Fr 15:15 – 16:45R 1.007


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


Fr 15:15 – 16:45R 1.007


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


Fr 15:15 – 16:45R 1.007



Fr 15:15 – 16:45R 1.007


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).


Fr 15:15 – 16:45R 1.007


Multileveldatenbanken


Fr 15:15 – 16:45R 1.007


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)


Fr 15:15 – 16:45R 1.007


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.


Fr 15:15 – 16:45R 1.007


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


Fr 15:15 – 16:45R 1.007


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.


Fr 15:15 – 16:45R 1.007


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.


Fr 15:15 – 16:45R 1.007


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.


Fr 15:15 – 16:45R 1.007


Zusammenfassung

Datenbank

Kryptographie

Zugriffskontrolle

Authentisierung

Organisatorische Maßnahmen

Legislative Maßnahmen


Fr 15:15 – 16:45R 1.007

Vorlesung #10

Ende

SS 2011 – IBB4C Datenmanagement Fr 15:15 – 16:45 R 1.007 Vorlesung #10 Datensicherheit.

Documents

Transcript of SS 2011 – IBB4C Datenmanagement Fr 15:15 – 16:45 R 1.007 Vorlesung #10 Datensicherheit.