Stabsche Integritätsbedingungen – CHECK

Sta$sche Integritätsbedingungen – CHECK-­‐Constraints §  CHECK-­‐Klausel CHECK (cond-exp)
•  cond-­‐exp ist eine beliebige SQL-­‐Suchbedingung §  Verwendung als •  Wertebereichsbedingung (VALUE bezeichnet zul. Wert) -  CREATE DOMAIN ALTER AS INT CHECK (VALUE > 18 AND VALUE < 70) •  APributbedingung (kann APribut referenzieren) -  CREATE TABLE PERS (... GEHALT DEC (9,2) CHECK (GEHALT < 120.000,00)) •  Tabellenbedingung (kann alles APribute der Tabelle referenzieren) -  CREATE TABLE PERS (... CHECK (GEHALT < (120.000,00 * (ALTER / 18))) §  Bedeutung: Es darf kein Tupel in der Tabelle geben, für das die CHECK-­‐
Bedingung den Wahrheitswert false ergibt •  unknown durch Nullwerte führt nicht zur Integritätsverletzung! •  leere Tabelle erfüllt "jede" Integritätsbedingung Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 47 Tabellenübergreifende CHECK-­‐Constraints §  CHECK-­‐Constraints können beliebige Tabellen der DB referenzieren §  Beispiele •  CREATE DOMAIN ALTER AS INT CHECK (VALUE > 18 AND VALUE < 70) •  CREATE TABLE PRODUKT (... Verkaufs_Preis DECIMAL (9, 2) CHECK (Verkaufs_Preis <= (SELECT MIN (Preis) FROM Konkurrenz_Preise))) •  CREATE TABLE ABT (ANR ABTNR PRIMARY KEY, ANZAHL-­‐ANGEST INT NOT NULL CHECK (ANZAHL-­‐ANGEST = (SELECT COUNT(*) FROM PERS P WHERE P.ANR = ANR)) . . .) •  CREATE TABLE PERS (... CHECK (GEHALT < (SELECT GEHALT FROM PERS M WHERE MNR=M.MNR)) Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 48 SQL-­‐Zusicherungen (Asser-ons) CREATE ASSERTION
assertion
(
CHECK
SQL condition
)
§  Zusicherungen (asser$ons) sind allgemeine Integritätsbedingungen •  beziehen sich oo auf mehrere Rela$onen -  natürlichere Formulierung im Vergleich zu Tabellenbedingungen •  lassen sich als eigenständige DB-­‐Objekte definieren §  Eine Zusicherung gilt als erfüllt, wenn ihre SQL-­‐Bedingung nicht zu false evaluiert wird §  Beispiele -  CREATE ASSERTION ANZ-­‐ANG CHECK (NOT EXISTS (SELECT * FROM ABT A WHERE A. ANZAHL-­‐ANGEST <> (SELECT COUNT (*) FROM PERS P WHERE P.ANR = A.ANR))) INITIALLY DEFERRED -  CREATE ASSERTION EXIST-­‐ABT CHECK ( (SELECT COUNT (*) FROM ABT) > 0) Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 49 Schwierigkeiten bei Integritätskontrolle x4.y4
Polygon
PktNr X
1
x1
2
x2
3
x3
4
x4
5
x5
6
x6
7
x7
§  Polygon und seine rela$onale Id
Y
...
Darstellung P3
y1
x3.y3
x5.y5
P3
y2
CREATE TABLE Polygon P3
y3
(Id CHAR(5) NOT NULL, P3
y4
x2.y2
PktNr INTEGER NOT NULL, P3
y5
x6.y6
P3
P3
y6
X DECIMAL NOT NULL, P3
y7
Y DECIMAL NOT NULL, …
PRIMARY KEY (Id, PktNr)); x1.y1
x7.y7
•  Mehrere Polygone (Id) sind in Rela$on Polygon enthalten •  Posi$on jedes Punktes (PktNr) in „Liste“ der Polygon-­‐Punkte erforderlich! §  Wie lassen sich folgende Integritätsbedingungen formulieren? •  Folgeänderungen bei „Füge neuen Eckpunkt von P3 zwischen (x2,y2) und (x3,y3) ein!“ •  Die Linien eines Polygons sollen sich nicht kreuzen! •  Der Umfang U eines Polygons darf nicht größer als Konstante c sein! U =∑
n
i=2
Informa$onssysteme 2015 (xi − xi−1 )2 + (y1 − yi−1 )2 + (x1 − xn )2 + (y1 − yn )2
Kapitel 6. Sichten, Integrität und Zugriffskontrolle 50 Ausblick auf Vorlesung "Datenbanksysteme" §  Deskrip$ve Formulierungen sind hier sehr schwierig! §  Idee: Explizite und möglichst deskrip$ve Beschreibung von Sachverhalten, Ak$onen usw. durch Regeln, die eine DBS-­‐
kontrollierte Reak$on erlauben. §  Anwendungsunabhängige Spezifika$on und Handhabung von Regeln (à SQL-­‐Trigger) •  Vereinfachung der Anwendungsentwicklung •  einfachere Wartbarkeit •  Wiederbenutzung von Code •  garan$erte Auslösung von „Geschäosregeln“ (business rules) Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 51 Zusammenfassung Integritätsbedingungen §  Modellinhärente Integritätsbedingungen in SQL •  PRIMARY KEY, UNIQUE, NOT NULL, FOREIGN KEY •  ermöglichen verfeinerte Abbildung von ER-­‐Schemata §  Prüfzeitpunkt von Integritätsbedingungen •  Verzögerung der Überprüfung (DEFERRED) •  explizite Überprüfung mit SET CONSTRAINTS ... IMMEDIATE §  Referen$elle Ak$onen •  ermöglichen automa$sierte DB-­‐Änderungen als Reak$on auf Änderung/Löschen von referenzierten Tupeln •  Eindeu$gkeit von referen$ellen Ak$onen anstreben! §  Beliebige sta$sche Integritätsbedingungen •  CHECK-­‐Constraints, assoziiert mit Wertebereichen, Tabellen •  Zusicherungen (Asser$ons) als unabhängige Integritätsbedingungen Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 52 Datenschutz und Zugriffskontrolle in DBS §  Datenschutz •  Ziele und technische Maßnahmen •  Schutzmechanismen in Datenbanksystemen §  Autorisierungsmodell mit expliziten Zugriffsrechten §  Zugriffskontrolle in SQL •  Vergabe und Kontrolle von Zugriffsrechten •  Probleme des Rechteentzugs §  Verfeinerung des Autorisierungsmodells •  Implizite Autorisierung bei Hierarchien •  Rollenkonzept in SQL §  Sicherheitsprobleme in sta$s$schen DBs •  Inferenzkontrolle Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 53 Beobachtung §  Immer mehr Daten werden gespeichert, von Programmen analysiert und zwischen ihnen ausgetauscht. §  Neue Dimensionen beim Sammeln von Daten und dem daraus resul$erenden Gefährdungspoten$al: E-­‐*, Data Warehousing, Data Mining, Seman$c Web, . . . §  Wesentliche Schwachpunkte exis$erender Schutzkonzepte: mangelnde Differenzierbarkeit und Einheitlichkeit §  Die Anzahl der Angreifer (Schnüffler, Hacker, Viren, . . .) nimmt zu! Deshalb sind verlässliche Systeme gefragt! (Verfügbarkeit, Sicherheit, Schutz vor APacken, Vertrauenswürdigkeit, ...) Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 54 Ziele des technisch-­‐organisatorischen Datenschutzes §  Verfügbarkeit Verfahren und Daten stehen zeitgerecht zur Verfügung und können ordnungsgemäß angewendet werden. §  Vertraulichkeit Auf Verfahren und Daten darf nur befugt zugegriffen werden. §  Integrität Daten aus Verfahren bleiben unversehrt, zurechenbar und vollständig. §  Transparenz Erhebung, Verarbeitung und Nutzung personenbezogener Daten müssen mit zumutbarem Aufwand nachvollzogen, überprüo und bewertet werden können. §  UnverkePbarkeit Verfahren sind so einzurichten, dass deren Daten nicht oder nur mit unverhältnismäßig hohem Aufwand für einen anderen als den ausgewiesenen Zweck erhoben verarbeitet und genutzt werden können (technisch-­‐
organisatorische Gewährleistung der Zweckbindung) §  Intervenierbarkeit Verfahren sind so zu gestalten, dass sie dem Betroffenen die Ausübung der ihm zustehenden Rechte wirksam ermöglichen Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 55 Datenschutz §  Legisla$ve Maßnahmen (Datenschutzgesetze) •  Festlegung, welche Daten in welchem Umfang schutzbedüroig sind •  Vorschrioen, die Missbrauch der Daten entgegenwirken •  (Festlegung, welche Daten von wem gespeichert werden dürfen, welcher Zugriff auf Daten erlaubt ist, welche Weitergabe der Daten zulässig ist usw.) •  BDSG will schutzwürdige Belange der Betroffenen schützen §  Technische Maßnahmen •  ZutriPs-­‐ und Zugangskontrolle, Authen$sierung •  Weitergabekontrolle in Rechnernetzen •  Zugriffs-­‐ und Verfügbarkeitsskontrolle: Isola$on der Benutzer und BetriebsmiPel, Schutz der Geräte •  Zugriffskontrolle: Autorisierung des Zugriffs auf gemeinsame Daten •  Datenflusskontrolle beim Datentransport •  Inferenzkontrolle bei sta$s$schen DB Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 56 Technische Maßnahmen des Datenschutzes Zutrittskontrolle
Zugangskontrolle
Weitergabekontrolle
Rechnerumgebung
Rechner
Prozess1
Prozess2
Prozess3
AP1
AP2
DBS
LOGIN
Zugriffskontrolle
SchutzInfo
Eingabekontrolle
Zugriffskontrolle
Verfügbarkeitskontrolle
Datei
Zugriffskontrolle
DB
è Das „schwächste Glied“ in einer Kette von Maßnahmen bestimmt die Sicherheit des Gesamtsystems
Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 57 Schutzmechanismen in Datenbanksystemen §  Iden$fika$on und Authen$sierung •  erforderlich, um Zugang zum DBS zu erhalten •  Iden$fika$on des Benutzers (meist Benutzernamen) •  Authen$sierung prüo die Iden$tät (meist Passwort) §  Autorisierung und Zugriffskontrolle •  Autorisierungsregeln legen erlaubten Zugriff auf Sicherheitsobjekte durch Sicherheitssubjekte fest •  Zugriffskontrolle nutzt Autorisierungsregeln, um Durchführung von Opera$onen zu erlauben bzw. zu unterbinden §  Audi$ng •  Buchführung über alle sicherheitsrelevanten DB-­‐Opera$onen, z.B. um Autorisierungsregeln zu verifizieren oder um Kompromi~erungen zu erkennen Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 58 Autorisierungsmodell §  Explizite Autorisierung (Discre-onary Access Control, DAC) •  Der Zugriff auf ein Objekt o kann nur erfolgen, wenn für den Benutzer (Subjekt s) ein Zugriffsrecht (Privileg p) vorliegt •  Autorisierungsregel (o, s, p) legt eine explizite starke Autorisierung mit posi$vem Recht fest §  Schutzinforma$on als Zugriffsmatrix •  Subjekte: Benutzer, Programme, Terminals •  Objekte: Programme (Anwendungs-­‐, Dienstprogramme), DB-­‐Objekte (Rela$onen, Sichten, APribute) •  Zugriffsrechte: Lesen, Ändern, Ausführen, Erzeugen, Weitergabe von Zugriffsrechten usw., ggf. abhängig von Terminal, Uhrzeit usw. Objekte
Subjekte,
Benutzer
O1
B1
P1, P2
O2
O3
Pi
P1
P1
P2, P3
B3
..
.
P2, P3
P2
Pi
P1
Informa$onssysteme 2015 P1, P2
On
P3
B2
Bm
…
Kapitel 6. Sichten, Integrität und Zugriffskontrolle Pi, Pk
59 Autorisierungs-­‐ und Überwachungssystem aus Kontext: Si, Terminal, Uhrzeit
gewünschte
Autorisierung
gewünschte
Systemleistung
Si, Ok, Pj
ggf. Uhrzeit, Terminal
Autorisierungssystem
Vergabe und Entzug
von Zugriffsrechten
Schreiben
Ok, Pj
Schutzinfo.
Lesen
Überwachungssystem
Annahme oder Anweisung
von Aufträgen
Verfeinerungen des Modells gestaPen eine implizite Autorisierung von Subjekten, Opera$onen und Objekten durch Nutzung entsprechender Hierarchien. Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 60 Autorisierungsmodell (2) §  Autorisierung •  zentrale Vergabe der Zugriffsrechte (DBA) •  dezentrale Vergabe der Zugriffsrechte durch Eigentümer der Objekte §  Objektgranulat •  wertunabhängige oder •  wertabhängige Objek•estlegung §  Wirksamkeit der Zugriffskontrolle beruht auf drei Annahmen: •  fehlerfreie Benutzer-­‐Iden$fika$on/-­‐Authen$sierung •  erfolgreiche Abwehr von (unerwarteten) Eindringlingen (vor allem strikte Isola$on der Benutzer-­‐ und DBS-­‐Prozesse sowie Weitergabekontrolle) •  Schutzinforma$on ist hochgradig geschützt! Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 61 Autorisierungsiden$fikatoren in SQL §  Iden$fika$on/Authen$sierung in SQL nicht standardisiert! •  typischerweise mit Benutzerkennung/Passwort •  oo in Kombina$on mit dem Betriebssystem §  Autorisierungsiden$fikator (authoriza-on iden-fier – authID) •  iden$fiziert einen Benutzer im SQL DBS •  wird verwendet, um den Besitzer eines Objekts (Tabelle, Sicht, Modul, Stored Procedure, ...) zu benennen -  Default: Benutzer, der das Objekt erzeugt (CREATE ...) – später mehr •  kann Zugriffsrechte auf Objekten besitzen und ggf. weitergeben •  charakterisiert einen aktuellen Benutzer (current authID), der mit dem DBS interagiert und Opera$onen ausführen will (à Zugriffskontrolle) -  kann sich bei Ausführung von Programmen, Stored Procedures ändern! Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 62 Autorisierungsiden$fikatoren in SQL (2) §  Autorisierungs-­‐Stack (in SQL) -­‐ Beispiel 1.  Daniel beginnt eine SQL-­‐Sitzung ... 2.  ... und führt ein Modul (Programm mit eingebePetem SQL) aus ... 3.  ... das eine Stored Procedure ruo, die Julia gehört ... Autorisierungs-Stack
AuthID
Rollenname
Julia
(null)
3. Stored Procedure
(null)
AW-Prog.
2. Embedded SQL
Daniel
(null)
1. Betriebssystem-Login
Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 63 Zugriffsrechte (Privileges) Zugriffsrecht auf benöGgt für USAGE Domäne Nutzung von Domain in CREATE TABLE SELECT Tabelle Lesen aller Spalten INSERT, INSERT(x) Tabelle, Spalte Einfügen in Tabelle/Spalte UPDATE, UPDATE(x) Tabelle, Spalte Ändern von Tabelle/Spalte DELETE Tabelle Löschen von Tupeln REFERENCES, REFERENCES(x) Tabelle, Spalte Definieren von Integritätsbedingungen §  Besitzer erhält automa$sche alle sinnvollen Zugriffsrechte §  CREATE VIEW benö$gt Zugriffsrechte auf die in der FROM-­‐Klausel referenzierte(n) Tabellen/Sicht(en) •  SELECT, sowie weitere für änderbare Sichten §  Erzeugung einer „abhängigen” Rela$on erfordert REFERENCES-­‐Recht auf von Fremdschlüsseln referenzierten Rela$onen. §  SELECT und INSERT, UPDATE, REFERENCES ohne Spaltenangaben gelten für alle Spalten, auch für neu hinzukommende! Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 64 Zugriffskontrolle in SQL §  Vergabe von Rechten | ALL PRIVILEGES}
GRANT {privileges-commalist
ON accessible-object TO grantee-commalist
[WITH GRANT OPTION]
§  Objekte (accessible-­‐object) •  Rela$onen, Sichten, Domänen, ... §  Empfänger (grantee) •  Liste von Benutzern bzw. PUBLIC •  Liste von Rollennamen (später mehr) §  WITH GRANT OPTION ermöglicht Weitergabe des Zugriffsrechts §  Beispiele •  GRANT SELECT ON Abt TO PUBLIC •  GRANT INSERT, DELETE ON Abt TO Mueller, Weber WITH GRANT OPTION •  GRANT UPDATE (Gehalt) ON Pers TO Schulz •  GRANT REFERENCES (Pronr) ON Projekt TO PUBLIC Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 65 Sichten zur Zugriffskontrolle §  Sicht-­‐Konzept erlaubt wertabhängigen Zugriffsschutz •  Untermengenbildung, Verknüpfung von Rela$onen, Verwendung von Aggregat-­‐Funk$onen •  Umsetzung durch Anfragemodifika$on möglich §  Beispiele •  Angestellten-­‐Sicht für Filiale in Kaiserslautern CREATE VIEW KL-­‐PERS AS SELECT P.* FROM PERS P, ABT A WHERE P.ANR=A.ANR AND A.ORT='KL' GRANT SELECT ON KL-­‐PERS TO MAIER •  Sta$s$k-­‐Sicht CREATE VIEW STATISTIK(BERUF, D_GEHALT) AS SELECT BERUF, AVG(GEHALT) FROM PERS GROUP BY BERUF GRANT SELECT ON STATISTIK TO PUBLIC §  Welche Privilegien werden benö$gt •  für die Defini$on der Sichten? •  fü Opera$onen auf den Sichten? Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 66 Rücknahme von Zugriffsrechten §  REVOKE zur Rücknahme von Zugriffsrechten REVOKE [GRANT OPTION FOR] privileges-commalist
ON accessible-object FROM grantee-commalist
{RESTRICT | CASCADE}
•  Beispiele: REVOKE DELETE ON Abt FROM Weber CASCADE REVOKE GRANT OPTION FOR INSERT ON Abt FROM Mueller §  Wünschenswerte Entzugsseman$k Der Entzug eines Rechtes ergibt einen Schutzzustand, als wenn das Recht nie erteilt worden wäre. è ggf. fortgesetztes Zurücknehmen von Zugriffsrechten §  Probleme •  Rechteempfang aus verschiedenen Quellen •  verschiedene Entzugsseman$ken: -  zeitabhängige Interpreta$on -  zeitunabhängige Interpreta$on è Führen der Abhängigkeiten in einem Autorisierungsgraph erforderlich Informa$onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 67