Zugriffskontrolle

Anwendersoftware (AS)
Grundlagen von Datenbanken und
Informationssystemen
Kapitel
p
5:
Integritäts- und Zugriffskontrolle
Holger
H
l
Schwarz
S h
Wintersemester 2009/10
Teile zu diesem Folienskript beruhen auf einer ähnlichen Vorlesung, gehalten von Prof. Dr. T. Härder am
Fachbereich Informatik der Universität Kaiserslautern und Prof. Dr. N. Ritter am Fachbereich Informatik der
Universität Hamburg. Für dieses Skriptum verbleiben alle Rechte (insbesondere für Nachdruck) bei den
Autoren.
Integritäts- und Zugriffskontrolle
Übersicht
•
•
•
•
Semantische Integritätsbedingungen
g
g g
Integritätsbedingungen in SQL
Aktives Verhalten: Trigger
Zugriffskontrolle in SQL
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
2
Integritäts- und Zugriffskontrolle
Konsistenz vs. Integrität
•
•
•
Konsistenz beschreibt die
K
Korrektheit
kth it d
der DB-internen
DB i t
Speicherungsstrukturen,
Zugriffspfade und sonstigen
Verwaltungsinformation
Verwaltungsinformation.
Constraints (Wertebereiche, CheckKlauseln etc.) sind Sprachkonzepte,
die eine Überprüfung
p
g der Konsistenz
durch das DBS gestatten.
•
•
•
Integrität beschreibt die Korrektheit
der Abbildung der Miniwelt in die in
der DB gespeicherten Daten.
Die Integrität kann verletzt sein,
obwohl die Konsistenz der DB
gewahrt bleibt.
Ein DBS kann nur die Konsistenz der
Daten sichern!
Trotzdem spricht man in der DB-Welt von Integritätssicherung
(z. B. Referentielle Integrität, nicht Referentielle Konsistenz).
ƒ Integritätsbedingungen
g
g g (Constraints)
(
) spezifizieren
p
akzeptable
p
DB-Zustände
(und nicht aktuelle Zustände der Miniwelt).
ƒ Änderungen werden nur zurückgewiesen, wenn sie entsprechend der
Integritätsbedingungen als falsch erkannt werden.
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
3
Integritäts- und Zugriffskontrolle
Ziel
Golden Rule nach C. J. Date:
No update operation must ever be allowed to leave any relation or view (relvar)
in a state that violates its own predicate. Likewise no update transaction must
ever be allowed to leave the database in a state that violates its own predicate.
•
•
•
•
Nur DB-Änderungen zulassen, die allen definierten Constraints entsprechen
(offensichtlich ‘falsche’ Änderungen zurückweisen!)
Möglichst hohe Übereinstimmung von DB-Inhalt und Miniwelt (Datenqualität)
Voraussetzung:
ƒ Integritätsbedingungen der Miniwelt sind explizit bekannt zu machen
ƒ die ermöglicht eine automatische Überwachung
Konsistenz der Transaktionsverarbeitung:
ƒ Bei COMMIT müssen alle semantischen Integritätsbedingungen erfüllt sein.
ƒ Zentrale Spezifikation/Überwachung im DBS: „system enforced integrity“
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
4
Integritäts- und Zugriffskontrolle
Klassifikation
Integritätsbedingungen
Ebenen der
Abbildungshierarchie
eines DBS
Reichweite
Blöcke
Attribut
Seiten
Relation
Tupel
mehrere
Relationen
…
Zeitpunkt der
Überprüfbarkeit
sofort
Art der
Überprüfbarkeit
Anlass der
Überprüfung
Zustand
Datenänderung
Übergang
Zeitpunkt
nach
mehreren
Operationen
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
5
Integritäts- und Zugriffskontrolle
Ebenen der Abbildungshierarchie
Anwendungsbereich („Miniwelt“):
Semantische Integritätsbedingungen
Datenmodell zur formalisierten
Abbildung der Miniwelt:
Einhaltung der Relationalen Invarianten,
Invarianten
benutzerdef. Integritätsbedingungen
Repräsentation in einem linearen
Adressraum: Konsistenzbedingungen
von Zugriffspf., Tabellen, Zeigern, usw.
Repräsentation in Dateien: Konsistenzbedingungen
g g und Abbildungsvorschriften
g
bei Blöcken, Seiten, usw.
Physische Repräsentation auf ExternSpeichermedien: Paritäts-, Längenbedingungen, usw.
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
Personen
Gegenstände
Beziehungen
Ereignisse
Relationen, Views, ...
Constraints, Trigger, ...
Sätze Felder
Tabellen Zeiger
Sätze,
Felder, Tabellen,
Seiten,
Seiten Blöcke,
Blöcke Zuordnungstabellen
Datensystem
Zugriffssystem
Speichersystem
Spuren, Zylinder, ...
6
Integritäts- und Zugriffskontrolle
Physische und Logische Konsistenz
•
Physische Konsistenz der DB ist Voraussetzung für logische Konsistenz
ƒ Gerätekonsistenz
ƒ Dateikonsistenz
ƒ Speicherkonsistenz (Aktionskonsistenz; Speicherungsstrukturen
Speicherungsstrukturen,
Zugriffspfade, Zeiger sind konsistent)
•
Logische Konsistenz (TA-Konsistenz)
ƒ modellinhärente Bedingungen (z. B. Relationale Invarianten)
ƒ benutzerdefinierte Bedingungen aus der Miniwelt
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
7
Integritäts- und Zugriffskontrolle
Reichweite
•
Art und Anzahl der von einer Integritätsbedingung (genauer: des die Bedingung
ausdrückenden Prädikats) betroffenen Objekte
ƒ ein Attribut
Bsp.: PNR vierstellige Zahl, NAME nur Buchstaben und Leerzeichen
ƒ mehrere Attribute eines Tupels
p GEHALTS-SUMME einer Abteilung
g muss kleiner sein als JAHRES-ETAT
Bsp.:
ƒ mehrere Tupel derselben Relation
Bsp.:
p kein GEHALT mehr als 20 % über dem Gehaltsdurchschnitt aller
Angestellten derselben Abteilung, PNR ist Primärschlüssel
ƒ mehrere Tupel aus verschiedenen Relationen
Bsp.: GEHALTS-SUMME einer Abteilung muss gleich der Summe der
Attributwerte in GEHALT der zugeordneten Angestellten sein
•
geringere Reichweite = einfachere Überprüfung
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
8
Integritäts- und Zugriffskontrolle
Zeitpunkt der Überprüfbarkeit
•
Unverzögerte Bedingungen ("IMMEDIATE")
ƒ müssen immer erfüllt sein, unabhängig davon, was in der DB passiert
ƒ können sofort nach Auftauchen des Objektes überprüft werden (typisch:
solche, die sich auf ein Attribut beziehen)
•
Verzögerte Bedingungen ("DEFERRED")
ƒ z.B.
z B zyklische Fremdschlüsselbedingungen
ƒ lassen sich nur durch eine Folge von Änderungen erfüllen (typisch: mehrere
Tupel, mehrere Relationen)
ƒ benötigen
b öti
Transaktionsschutz
T
kti
h t (als
( l zusammengehörige
hö i Änderungssequenzen)
Ä d
)
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
9
Integritäts- und Zugriffskontrolle
Art der Überprüfbarkeit
•
Zustandsbedingungen
ƒ betreffen den zu einem bestimmten Zeitpunkt in der DB abgebildeten
Objektzustand
•
Übergangsbedingungen
ƒ Einschränkungen der Art und Richtung von Wertänderungen einzelner oder
mehrerer Attribute
ƒ Beispiele:
- GEHALT eines Angestellten darf niemals sinken
- FAM-STAND
FAM STAND darf nicht von „ledig
ledig“ nach „geschieden
geschieden“ oder von „verheiratet
verheiratet“ nach
„ledig“ geändert werden
ƒ sind am Zustand nicht prüfbar
- entweder sofort bei Änderung oder
- später durch Vergleich von altem und neuem Wert (Versionen)
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
10
Integritäts- und Zugriffskontrolle
Anlass für Überprüfung
•
•
•
Änderungsvorgang in der DB
ƒ alle bisherigen Beispiele implizieren Überprüfung innerhalb der TA
„Verspätete” Überprüfung: Änderung zunächst nur in (mobiler) Client-DB
Ablauf der äußeren Zeit
ƒ z. B. Daten über produzierte und zugelassene Fahrzeuge – Fahrzeug muss
spätestens ein Jahr nach Herstellung angemeldet sein
ƒ nicht
i ht trivial:
t i i l was ist
i t zu tun
t bei
b i Verletzung?
V l t
?
kann an der Realität liegen – abstrakte Konsistenzbedingung erfüllen oder
(inkonsistente) Realität getreu abbilden?
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
11
Integritäts- und Zugriffskontrolle
Übersicht
•
•
•
•
Semantische Integritätsbedingungen
g
g g
Integritätsbedingungen in SQL
Aktives Verhalten: Trigger
Zugriffskontrolle in SQL
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
12
Integritäts- und Zugriffskontrolle
Integritätsbedingungen in SQL
An DB-Schemaelemente gebundene Integritätsbedingungen
ƒ
ƒ
ƒ
ƒ
Bereits eingeführt (siehe Datendefinition):
CHECK-Bedingungen
CHECK
Bedingungen bei CREATE DOMAIN, CREATE TABLE, Attributdefinition
UNIQUE, PRIMARY KEY, NOT NULL
FOREIGN KEY (Fremdschlüsselbedingungen)
Allgemeine Integritätsbedingungen
ƒ
ƒ
ƒ
ƒ
beziehen
b
i h sich
i h typischerweise
t i h
i auff mehrere
h
Relationen
R l ti
lassen sich als eigenständige DB-Objekte definieren
erlauben die Verschiebung
g ihres Überprüfungszeitpunktes
p
g
p
CREATE ASSERTION
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
13
Integritäts- und Zugriffskontrolle
Assertion Anweisung
Assertion-Anweisung
CREATE ASSERTION assertion CHECK (cond-exp) [deferrability]
ƒ Beispiel: Die Relation Abt enthält ein Attribut, in dem (redundant) die Anzahl
d Angestellten
der
A
t llt einer
i
Abteilung
Abt il
geführt
füh t wird.
i d Es
E gilt
ilt folgende
f l
d Zusicherung:
Z i h
CREATE ASSERTION A1
C C (NOT
CHECK
( O EXISTS
S S
(SELECT * FROM Abt A
WHERE A.Anzahl_Angest <>
(SELECT COUNT (*) FROM Pers
P
P
WHERE P.Anr = A.Anr)));
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
14
Integritäts- und Zugriffskontrolle
Überprüfungszeitpunkt
deferrability ::= [ NOT ] DEFERRABLE
[ INITIALLY { DEFERRED | IMMEDIATE } ]
ƒ Jeder Constraint bzgl. einer SQL2-Transaktion ist zu jedem Zeitpunkt
in einem von zwei Modi: IMMEDIATE oder DEFERRED
IMMEDIATE Constraint
IMMEDIATE:
C
t i t wird
i d am Ende
E d einer
i
SQL-Anweisung
SQL A
i
überprüft
üb
üft
DEFERRED: Constraint wird erst am Ende der Transaktion überprüft
ƒ Der Default-Modus für Constraints ist NOT DEFERRABLE
ƒ Der Default für Constraints, die als DEFERRABLE angegeben sind, ist
IMMEDIATE
ƒ Anweisung SET CONSTRAINTS erlaubt den Wechsel des Modus
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
15
Integritäts- und Zugriffskontrolle
Überprüfungszeitpunkt steuern
SET CONSTRAINT {ALL | assertion-commalist}{IMMEDIATE | DEFERRED}
ƒ Überprüfung kann durch Constraint-Modus gesteuert werden
ƒ Zuordnung gilt für die aktuelle Transaktion
ƒ Bei benamten Constraints ist eine selektive Steuerung der Überprüfung
möglich; so können ‚gezielt‘ Zeitpunkte vor COMMIT ausgewählt werden.
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
16
Integritäts- und Zugriffskontrolle
Übersicht
•
•
•
•
Semantische Integritätsbedingungen
g
g g
Integritätsbedingungen in SQL
Aktives Verhalten: Trigger
Zugriffskontrolle in SQL
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
17
Integritäts- und Zugriffskontrolle
Aktives vs. Passives Verhalten
aktiv
passiv
AWP
DB-Op
DB-Op
Ereigniserkennung
DD
Zusttandsänderu
ungen
D B S
Datensystem
Zugriffssystem
Speichersystem
Aktionen
DB
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
18
Integritäts- und Zugriffskontrolle
Aktives Verhalten
•
•
•
Bisher
ƒ Integritätsbedingungen beschreiben, was innerhalb der DB gültig und zulässig
ist.
Neue Idee
ƒ Spezifikation und Durchführung von Reaktionen auf bestimmte Situationen
oder Ereignisse in der DB
ƒ „Zusammenhangsregel
Zusammenhangsregel“ (kausale,
(kausale logische oder „beliebige
beliebige“ Verknüpfung)
statt statischem Prädikat
ƒ Je mehr Semantik des modellierten Systems explizit repräsentiert ist,
umso mehr kann das DBS „aktiv
aktiv“ werden!
Oft synonyme Nutzung der Begriffe:
Trigger, Regel, Aktive Regel, Produktionsregel, Alerter
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
19
Integritäts- und Zugriffskontrolle
Trigger
•
•
Idee
ƒ automatische Korrektur des DB-Zustandes
ƒ Starten von Folgeänderungen zur Wahrung der DB-Integrität
Allgemeines
ƒ „triggernde“ Operation wird als Event bezeichnet
ƒ Reaktion auf Event besteht aus Folge von DB-Operationen
AFTER <Event> ON <Table> DO <DML-Operation>, ...
ƒ DBS muss das Auftreten der Events erkennen und die zugehörigen
Operationen durchführen
ƒ in relationalen Systemen sind i. allg. nur Modifikationsoperationen als Events
vorgesehen
ƒ in objektorientierten Systemen kann i. allg. jeder Aufruf einer Methode ein
Event sein
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
20
Integritäts- und Zugriffskontrolle
Ausführung von Triggern
•
•
möglich
ƒ rekursive Auflösung von Triggern
ƒ mehrere Trigger für einen Event
Ausführungskontrolle
ƒ Problem:
Datenänderungen triggern Regeln, die Daten ändern, die Regeln triggern, die
Daten ändern,
ändern ...
ƒ Terminierung
ƒ Reihenfolge der Regelausführung
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
21
Integritäts- und Zugriffskontrolle
Trigger in SQL:1999
•
•
•
Trigger werden schon seit ~1985 in relationalen DBS eingesetzt
Ihre Standardisierung wurde jedoch erst in SQL:1999 vorgenommen
Syntax:
CREATE TRIGGER
•
trigger-name
Darüber hinaus können festgelegt werden:
ƒ
ƒ
ƒ
ƒ
ƒ
Auslösender Event
Übergangsvariablen/Übergangstabellen
Triggergranulat
Bedingung
DML-Operationen
DML
Operationen
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
22
Integritäts- und Zugriffskontrolle
Auslösender Event
•
Wann soll ein Trigger ausgelöst werden?
ƒ Zeitpunkte:
- BEFORE: vor der auslösenden Operation
- AFTER: nach der auslösenden Operation
p
ƒ auslösende Operation: INSERT / DELETE / UPDATE
INSERT
BEFORE
UPDATE
ON
OF
AFTER
table-name
attribute-name
DELETE
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
23
Integritäts- und Zugriffskontrolle
Übergangsvariablen/Übergangstabellen
•
Wie spezifiziert man (bei Übergangsbedingungen) Aktionen?
ƒ Bezug auf verschiedene DB-Zustände erforderlich
NEW
AS
correlation-var
AS
table-var
OLD
REFERENCING
NEW TABLE
OLD TABLE
•
Übergangsvariablen/Übergangstabellen
ƒ Sie vermerken Einfügungen
g g (bei
(
INSERT),
) Löschungen
g (bei
(
DELETE))
und die alten und neuen Zustände (bei UPDATE).
ƒ Übergangstabellen (transition tables) beziehen sich auf mengenorientierte
Änderungen
g
ƒ Übergangsvariablen (transition variables) beziehen sich auf tupelweise
Änderungen
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
24
Integritäts- und Zugriffskontrolle
Triggergranulat
• Triggeraktion
gg
pro Tupel
p
p oder p
pro DB-Operation
p
FOR EACH STATEMENT
FOR EACH ROW
• FOR EACH STATEMENT:
mengenorientiertes
Verarbeitungsmodell
Op
t1
t2 ... tn
TRA
TRA: Trigger-Aktion
• FOR EACH ROW:
tupelorientiertes
Verarbeitungsmodell
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
Op
t1
t2
tn
...
TRA
TRA
TRA
25
Integritäts- und Zugriffskontrolle
Übergangsvariablen/Übergangstabellen
BEFORE
INSERT
•
AFTER
NEW ROW
UPDATE
OLD ROW
DELETE
OLD ROW
NEW ROW
NEW ROW
NEW TABLE
OLD ROW
OLD TABLE
NEW ROW
NEW TABLE
OLD ROW
OLD TABLE
Einschränkungen für BEFORE-Trigger:
ƒ Zugriff auf OLD TABLE und NEW TABLE nicht möglich
ƒ Trigger kann keine Änderungen an Tabellen der Datenbank vornehmen
•
Weitere Einschränkungen:
g
ƒ OLD ROW und NEW ROW sind nur bei tupel-orientierten Triggern möglich (FOR EACH
ROW)
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
26
Integritäts- und Zugriffskontrolle
Bedingungen und Operationen
•
Trigger-Ausführung kann vom DB-Zustand abhängig gemacht werden
WHEN
•
(
sql-condition
)
Was soll wie verändert werden?
ƒ mit einer SQL-Anweisung
ƒ mit
i einer
i
Prozedur
P
d aus
PSM-Anweisungen (persistent stored module, stored procedure)
BEGIN
PSM statement
END
;
SQL statement
•
Existiert das Problem der Terminierung und der Auswertungsreihenfolge?
ƒ mehrere Trigger-Definitionen
gg
pro Relation (Tabelle)
p
(
) sowie
ƒ mehrere Trigger-Auslösungen pro Ereignis möglich
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
27
Integritäts- und Zugriffskontrolle
Beispiel: Gehaltssumme
•
•
Gehaltsumme in Abt soll bei Änderungen in Pers, die „Gehälter“ betreffen,
automatisch aktualisiert werden
Es sind Trigger für INSERT/DELETE/UPDATE erforderlich; sie werden bei
Auftreten der spezifizierten Änderungsoperationen sofort ausgeführt
Abt
Pers
Anr
Aname
Ort
Geh_Summe
Pnr
Name
Alter
Gehalt
Anr
Mnr
K51
Planung
Kaiserslautern
43500
406
Coy
47
50000
K55
123
K53
Einkauf
Frankfurt
45200
123
Müller
32
43500
K51
-
K55
Vertrieb
Frankfurt
80000
829
Schmid
36
45200
K53
777
574
Abel
28
30000
K55
123
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
28
Integritäts- und Zugriffskontrolle
Beispiel: Gehaltssumme
CREATE TRIGGER T1
AFTER INSERT ON Pers
REFERENCING NEW ROW AS NP
FOR EACH ROW
UPDATE Abt A
SET A.Geh_Summe = A.Geh_Summe+NP.Gehalt
WHERE A.Anr = NP.Anr;
• DB-Zustand nach:
INSERT INTO Pers VALUES (234, 'Pluto', 19, 20000, 'K55', 123);
Abt
Pers
Anr
Aname
Ort
Geh_Summe
Pnr
Name
Alter
Gehalt
Anr
Mnr
K51
Planung
Kaiserslautern
43500
406
Coy
47
50000
K55
123
K53
Einkauf
Frankfurt
45200
123
Müller
32
43500
K51
-
K55
Vertrieb
Frankfurt
100000
829
Schmid
36
45200
K53
777
574
Abel
28
30000
K55
123
234
Pluto
19
20000
K55
123
T i
Trigger
T1
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
29
Integritäts- und Zugriffskontrolle
Beispiel: Gehaltssumme
CREATE TRIGGER T2
AFTER UPDATE OF Gehalt ON Pers
REFERENCING OLD ROW AS OP NEW ROW AS NP
FOR EACH ROW
UPDATE Abt A
SET A.Geh_Summe = A.Geh_Summe+(NP.Gehalt-OP.Gehalt)
WHERE A.Anr = NP.Anr;
• DB-Zustand nach:
UPDATE Pers SET Gehalt = 60000 WHERE Pnr = 406;;
Abt
Pers
Anr
Aname
Ort
Geh_Summe
Pnr
Name
Alter
Gehalt
Anr
Mnr
K51
Planung
Kaiserslautern
43500
406
Coy
47
60000
K55
123
K53
Einkauf
Frankfurt
45200
123
Müller
32
43500
K51
-
K55
Vertrieb
Frankfurt
110000
829
Schmid
36
45200
K53
777
574
Abel
28
30000
K55
123
234
Pluto
19
20000
K55
123
T i
Trigger
T2
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
30
Integritäts- und Zugriffskontrolle
Beispiel: Gehaltssumme
• Alternative zu T2:
Trigger T3 wird pro Statement ausgelöst
CREATE TRIGGER T3
AFTER UPDATE OF Gehalt ON Pers
REFERENCING OLD TABLE AS OT NEW TABLE AS NT
FOR EACH STATEMENT
UPDATE Abt
Ab A
SET A.Geh_Summe = A.Geh_Summe+
(SELECT SUM(Gehalt) FROM NT WHERE Anr=A.Anr)(SELECT SUM(Gehalt)
SUM(G h lt) FROM OT WHERE Anr=A.Anr)
A
AA )
WHERE A.Anr IN (SELECT Anr FROM NT);
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
31
Integritäts- und Zugriffskontrolle
Beispiel: Gehaltssumme
• Trigger
gg T5 bricht UPDATE ggf.
gg mit Fehlermeldung
g ab
CREATE TRIGGER T5
AFTER UPDATE OF Gehalt
G h l ON Pers
P
REFERENCING NEW ROW AS NR
FOR EACH ROW
WHEN (NR.Gehalt
(NR Gehalt > 100000)
SIGNAL SQLSTATE '75000' SET MESSAGE_TEXT='Gehalt zu hoch';
DB2
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
32
Integritäts- und Zugriffskontrolle
Ausführungskontrolle
• Rekursive Auflösung
g von Triggern
gg
CREATE TRIGGER T4
AFTER UPDATE OF Gehalt ON Pers
REFERENCING OLD ROW AS OR
FOR EACH ROW
WHEN (OR.Mnr IS NOT NULL)
UPDATE Pers
SET Gehalt = Gehalt*1.1
WHERE Pnr = OR.Mnr;
Pers
t1
t2
t3
t4
Terminierung?
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
33
Integritäts- und Zugriffskontrolle
Ausführungskontrolle
• Mehrere Trigger
gg für einen Event
CREATE TRIGGER T2
AFTER UPDATE OF Gehalt ON Pers
REFERENCING OLD ROW AS OP NEW ROW AS NP
FOR EACH ROW
UPDATE Abt A
SET A.Geh_Summe
A Geh Summe = A.Geh_Summe+(NP.Gehalt-OP.Gehalt)
A Geh Summe+(NP Gehalt-OP Gehalt)
WHERE A.Anr = NP.Anr;
CREATE TRIGGER T4
AFTER UPDATE OF Gehalt ON Pers
REFERENCING OLD ROW AS OR
FOR EACH ROW
WHEN (OR.Mnr IS NOT NULL)
UPDATE Pers
SET Gehalt = Gehalt
Gehalt*1
1.1
1
WHERE Pnr = OR.Mnr;
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
Reihenfolge?
34
Integritäts- und Zugriffskontrolle
Beispiel: Gehaltssumme
• Ausgangspunkt:
g g p
ƒ ursprünglicher Zustand der Tabellen
ƒ Trigger T2 und T4
• DB
DB-Zustand
Zustand nach:
UPDATE Pers SET Gehalt = 60000 WHERE Pnr = 406;
Abt
Pers
Anr
Aname
Ort
Geh_Summe
Pnr
Name
Alter
Gehalt
Anr
Mnr
K51
5
Planung
a u g
Kaiserslautern
a se s aute
47850
850
406
06
Coy
47
60000
K55
55
123
3
K53
Einkauf
Frankfurt
45200
123
Müller
32
47850
K51
-
K55
Vertrieb
Frankfurt
90000
829
Schmid
36
45200
K53
777
574
Abel
28
30000
K55
123
Trigger T2
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
Trigger T4
35
Integritäts- und Zugriffskontrolle
Beispiel: Polygone
•
•
Umfang eines Polygons soll nicht größer als c sein!
Polygon P3 und seine relationale Darstellung
x4,y4
x3,y3
x5,y5
x2,y2
P3
x1 y1
x1,y1
Id
x6,y6
x7,y7
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
Polygon
PktNr
X
Y
•••
P3
P3
P3
P3
P3
P3
P3
1
2
3
4
5
6
7
x1
x2
x3
x4
x5
x6
x7
y1
y2
y3
y4
y5
y6
yy7
•••
36
Integritäts- und Zugriffskontrolle
Beispiel: Polygone
•
Trigger in PL/SQL von Oracle
CREATE TRIGGER UmfangSQLDialektUpdatePolygon
AFTER UPDATE ON Polygon REFERENCING NEW AS NP
FOR EACH ROW
DECLARE
PktNr INTEGER,,
X1, Y1, Xi, Yi, Ximinus1, Yiminus1 DECIMAL,
Umfang := 0.0 REAL,
CURSOR Stützpunkt IS
SELECT
PktNr, X, Y
FROM
Polygon
WHERE
Id = NP.Id
ORDER BY
PktNr;
...
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
37
Integritäts- und Zugriffskontrolle
Beispiel: Polygone
...
BEGIN
OPEN Stützpunkt;
FETCH Stützpunkt INTO :PktNr, :X1, :Y1;
Ximinus1 := X1;
Yiminus1 := Y1;
LOOP
FETCH Stützpunkt INTO :PktNr,
:PktNr :Xi,
:Xi :Yi;
Umfang := Umfang + SQRT ((Xi-Ximinus1)↑2+(Yi-Yiminus1)↑2);
Ximinus1 := Xi;
Yiminus1 ::= Yi
END LOOP;
CLOSE Stützpunkt;
Umfang
g := Umfang
g + SQRT
Q
((X1-Ximinus1)↑2+(Y1-Yiminus1)↑2);
((
)
(
) );
IF Umfang > c THEN RAISE ERROR
(1000, ‘Aktualisieren von Polygon: Umfang zu groß.‘);
ENDIF;
END;
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
38
Integritäts- und Zugriffskontrolle
Übersicht
•
•
•
•
Semantische Integritätsbedingungen
g
g g
Integritätsbedingungen in SQL
Aktives Verhalten: Trigger
Zugriffskontrolle in SQL
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
39
Integritäts- und Zugriffskontrolle
Zugriffskontrolle
•
•
Technische Maßnahme des Datenschutzes
Kernfrage:
Wie kann ich erreichen, dass Benutzer mit unterschiedlichen Rechten gemeinsam
auf Daten zugreifen können?
¾ Frage nach der Zugriffskontrolle (bei Daten)
•
Zugriffskontrolle (Autorisierung)
ƒ Vergabe von Zugriffsrechten (Lesen, Schreiben, . . .) auf DB-Objekten,
Programmen usw.
ƒ Ziele
- Verhinderung von zufälligen oder böswilligen Änderungen
- möglichst weitgehende Isolation von Programmfehlern
- Verhinderung von unberechtigtem Lesen/Kopieren
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
40
Integritäts- und Zugriffskontrolle
Autorisierungsmodell
•
•
Explizite Autorisierung:
ƒ Dieses Modell wird im Englischen als Discretionary Access Control (DAC)
bezeichnet. Wegen seiner Einfachheit ist DAC weit verbreitet
(„discretionary“ bedeutet in etwa „nach dem Ermessen des Subjekts“).
ƒ 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)
Schutzinformation als Zugriffsmatrix
ƒ Subjekte:
Benutzer Programme
Benutzer,
Programme, Terminals
ƒ Objekte:
Programme (Anwendungs-, Dienstprogramme), DB-Objekte (Relationen,
Sichten Attribute)
Sichten,
ƒ Zugriffsrechte:
Lesen, Ändern, Ausführen, Erzeugen, Weitergabe von Zugriffsrechten usw.,
ggf.
f abhängig
bhä i von Terminal,
T
i l Uhrzeit
Uh it usw.
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
41
Integritäts- und Zugriffskontrolle
Autorisierungsmodell
O bjekte
Subjekte,
Benutzer
B1
O1
O2
P 1,
1 P2
O3
...
On
P3
Pi
P1
B2
P1
P2, P 3
B3
P2, P3
P2
•
•
•
Bm
•
•
P1, P 2
Pi
P1
P i, P k
Zugriffsmatrix ist typischerweise sehr groß und dünn besetzt
besetzt.
Anmerkung:
ƒ Verfeinerungen des Modells gestatten eine implizite Autorisierung von
Subjekten Operationen und Objekten durch Nutzung entsprechender
Subjekten,
Hierarchien.
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
42
Integritäts- und Zugriffskontrolle
Autorisierungs- und Überwachungssystem
Autorisierungs
gewünschte
Autorisierung
Autorisierungssystem
gewünschte
Systemleistung
Schreiben
Vergabe und Entzug
von Zugriffsrechten
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
Schutzinfo.
Lesen
Überwachungssystem
Annahme oder Abweisung
von Aufträgen
43
Integritäts- und Zugriffskontrolle
Zugriffskontrolle
•
•
•
zentrale vs. dezentrale Autorisierung
ƒ zentrale Vergabe der Zugriffsrechte (DBA)
ƒ dezentrale Vergabe der Zugriffsrechte durch Eigentümer der Objekte
Objektgranulat
ƒ wertunabhängige oder
ƒ wertabhängige Objektfestlegung (Sichtkonzept)
Wirksamkeit der Zugriffskontrolle beruht auf drei Annahmen:
ƒ fehlerfreie Benutzer-Identifikation/-Authentisierung
ƒ erfolgreiche
g
Abwehr von (unerwarteten)
(
) Eindringlingen
g g (vor
(
allem strikte
Isolation der Benutzer- und DBS-Prozesse sowie Übermittlungskontrolle)
ƒ Schutzinformation ist hochgradig geschützt!
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
44
Integritäts- und Zugriffskontrolle
Zugriffskontrolle in SQL
•
Vergabe von Rechten
GRANT {privileges-commalist | ALL PRIVILEGES}
ON accessible-object TO grantee-commalist
[WITH GRANT OPTION]
•
•
Rücknahme von Zugriffsrechten
REVOKE [GRANT OPTION FOR] privileges-commalist
ON accessible-object FROM grantee-commalist
{RESTRICT | CASCADE}
Objekte (accessible-object)
(accessible object)
ƒ Relationen bzw. Sichten
ƒ aber auch: Domänen, Datentypen, Routinen usw.
ƒ Sicht-Konzept
Si ht K
t erlaubt
l bt wertabhängigen
t bhä i
Zugriffsschutz
Z iff h t
- Untermengenbildung, Verknüpfung von Relationen,
Verwendung von Aggregat-Funktionen
- Umsetzung durch Anfragemodifikation möglich
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
45
Integritäts- und Zugriffskontrolle
Zugriffskontrolle in SQL
•
Vergabe von Rechten
GRANT {privileges-commalist | ALL PRIVILEGES}
ON accessible-object TO grantee-commalist
[WITH GRANT OPTION]
•
•
Rücknahme von Zugriffsrechten
REVOKE [GRANT OPTION FOR] privileges-commalist
ON accessible-object FROM grantee-commalist
{RESTRICT | CASCADE}
Zugriffsrechte (privileges)
ƒ SELECT, INSERT, UPDATE, DELETE, REFERENCES, USAGE, EXECUTE, . . .
ƒ dynamische Weitergabe von Zugriffsrechten mit WITH GRANT OPTION
- dezentrale Autorisierung
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
46
Integritäts- und Zugriffskontrolle
Zugriffskontrolle in SQL
Recht
Objekt
Recht ist notwendig für …
SELECT
TABLE
• Lesen der Tabelle
• Attributeinschränkung möglich
INSERT
TABLE
• Einfügen in eine Tabelle
• Attributeinschränkung möglich
UPDATE
TABLE
• Ändern von Zeilen einer Tabelle
• Attributeinschränkung möglich
DELETE
TABLE
• Löschen von Zeilen einer Tabelle
TRIGGER
TABLE
• Anlegen eines Triggers
REFERENCES
TABLE
• Erzeugung einer „abhängigen“ Relation erfordert dieses Recht
auff d
den von F
Fremdschlüsseln
d hlü l referenzierten
f
i t Relationen
R l ti
USAGE
DOMAIN
• Nutzung von DOMAINS
EXECUTE
• Aufruf von Prozeduren und Funktionen
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
47
Integritäts- und Zugriffskontrolle
Zugriffskontrolle in SQL
•
Vergabe von Rechten
GRANT {privileges-commalist | ALL PRIVILEGES}
ON accessible-object TO grantee-commalist
[WITH GRANT OPTION]
•
•
Rücknahme von Zugriffsrechten
REVOKE [GRANT OPTION FOR] privileges-commalist
ON accessible-object FROM grantee-commalist
{RESTRICT | CASCADE}
Empfänger (grantee)
ƒ Liste von Benutzern bzw. PUBLIC
ƒ Liste von Rollennamen
Rollen bündeln mehrere Zugriffsrechte und können an Benutzer vergeben
werden
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
48
Integritäts- und Zugriffskontrolle
Beispiele
•
Vergabe von Rechten
GRANT SELECT ON Abt TO PUBLIC
GRANT INSERT, DELETE ON Abt
TO Mueller,
M ll
Weber
W b WITH GRANT OPTION
GRANT UPDATE (Gehalt) ON Pers TO Schulz
GRANT REFERENCES (Pronr) ON Projekt TO PUBLIC
•
Rücknahme von Zugriffsrechten
REVOKE SELECT ON Abt FROM Weber CASCADE
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
49
Integritäts- und Zugriffskontrolle
Rücknahme von Zugriffsrechten
•
•
•
Wünschenswerte Entzugssemantik:
ƒ Der Entzug eines Rechtes ergibt einen Schutzzustand,
als wenn das Recht nie erteilt worden wäre.
Fortgesetztes Zurücknehmen von Zugriffsrechten
ƒ RESTRICT: Zugriffsrecht wird nur zurückgenommen, falls es nicht
weitergegeben wurde; sonst Fehlermeldung
ƒ CASCADE: Zugriffsrecht wird zurückgenommen; zusätzlich werden alle
abhängigen Zugriffsrechte zurückgenommen
Führen der Abhängigkeiten in einem Autorisierungsgraph erforderlich
P bl
Probleme:
ƒ Rechteempfang aus verschiedenen Quellen
ƒ verschiedene Entzugssemantiken:
g
- zeitabhängige Interpretation
- zeitunabhängige Interpretation
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
50
Integritäts- und Zugriffskontrolle
Zeitabhängige Interpretation
•
Vergabe von Zeitstempeln für jede
Autorisierung
10: A: GRANT INSERT, UPDATE ON Pers TO C
WITH GRANT OPTION
20: C: GRANT UPDATE ON Pers TO D
WITH GRANT OPTION
30: D: GRANT UPDATE ON Pers TO E
40: B: GRANT SELECT, UPDATE ON Pers TO C
WITH GRANT OPTION
50: C: GRANT UPDATE ON Pers TO D
WITH GRANT OPTION
A 10: I, U, GO
50: U, GO
C
B
20: U, GO
60: U
F
D
40: S, U, GO
30: U
E
60: U
F
70 : A: REVOKE
INSERT, UPDATE ON Pers
FROM C
60: D: GRANT UPDATE ON Pers TO F
50: U,
U GO
A
C
B
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
40: S
S, U
U, GO
D
E
51
Integritäts- und Zugriffskontrolle
Zeitunabhängige Interpretation
•
Vergabe von Zeitstempeln für jede
Autorisierung
A: GRANT INSERT, UPDATE ON Pers TO C
WITH GRANT OPTION
C: GRANT UPDATE ON Pers TO D
WITH GRANT OPTION
D: GRANT UPDATE ON Pers TO E
WITH GRANT OPTION
B: GRANT SELECT, UPDATE ON Pers TO C
WITH GRANT OPTION
C: GRANT UPDATE ON Pers TO D
WITH GRANT OPTION
I U,
U GO
A I,
C
B
•
D: GRANT UPDATE ON Pers TO F
•
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
U
S U
S,
U, GO
U, GO
F
D
U GO
U,
E
Der rekursive Entzug eines Rechtes
wird nicht fortgesetzt, sobald der
Geber noch mindestens ein gleiches
Recht für das Objekt von einer
unabhängigen
g g Quelle
Q
hat.
Überprüfung der Unabhängigkeit
einer Quelle bei jeder
Rechtevergabe/Rechteentzug
52
Integritäts- und Zugriffskontrolle
Zeitunabhängige Interpretation
A I, U, GO
U
C
B
U, GO
F
D
S, U, GO
U, GO
E
A
F
C
B
A: REVOKE INSERT, UPDATE ON Pers FROM C
U
A
C
B
U, GO
S, U, GO
D
E
S, GO
F
B: REVOKE UPDATE ON Pers FROM C
D
U, GO
E
U
A
E: GRANT UPDATE ON Pers TO C
GRANT U
UPDATE O
ON Pers
e s TO
OF
E: G
C
B
F
D
U, GO
S, U, GO
U
U, GO
E
U
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
53
Integritäts- und Zugriffskontrolle
Zusammenfassung
•
•
•
•
Semantische Integritätskontrolle
ƒ Relationale Invarianten, referentielle Integrität und Aktionen
ƒ Benutzerdefinierte Integritätsbedingungen (assertions)
- zentrale Spezifikation/Überwachung im DBS wird immer wichtiger
Aktives DB-Verhalten zur
ƒ Integritätssicherung
ƒ Wartung abgeleiteter Daten
ƒ Durchführung allgemeiner Aufgaben (Regeln, Alerter, Trigger)
Triggerkonzept
gg
p in SQL99
Q
standardisiert
Verallgemeinertes Konzept: ECA-Regeln (nicht behandelt)
ƒ Event: Welche Events werden unterstützt?
ƒ Condition: Wie komplex sind Conditions?
ƒ Action: Wie komplex sind Actions?
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
54
Integritäts- und Zugriffskontrolle
Zusammenfassung
•
Zugriffskontrolle in DBS
ƒ wertabhängige Festlegung der Objekte (Sichtkonzept)
ƒ Vielfalt an Rechten erwünscht
ƒ zentrale vs.
vs dezentrale Rechtevergabe
ƒ verschiedene Entzugssemantiken bei dezentraler Rechtevergabe
ƒ Rollenkonzept: vereinfachte Verwaltung komplexer Mengen von
Z iff
Zugriffsrechten
ht
© Prof. Dr. B. Mitschang, Dr. H. Schwarz, Universität Stuttgart
55