Vorlesung Datenbanken

Transkript

1 Vorlesung Datenbanken Kapitel 6 Institut für Informatik

2 2 Überblick Assertions Trigger und Regeln Zugriffsrechte

3 3 Zugriffsrechte und Integritätsbedingungen Zugriffsrechte gewährleisten, dass nur autorisierte Benutzer auf die Daten zugreifen nur autorisierte Benutzer die Daten ändern Integritätsbedingungen vermeiden, bei autorisierten Zugriffen, (versehentliche) Änderungen der Datenbank, die die Datenbank in einen inkonsistenten Zustand überführen würde Domainconstraints / Wertebereichseinschränkungen und referentielle Integrität bereits in Kapitel 4 besprochen hier noch allgemeine Integritätsbedingungen

4 4 Assertions Prädikat, das eine Bedingung an die Datenbank beschreibt, die immer erfüllt sein soll. SQL-Syntax: create assertion <assertion-name> check <predicate> Assertions werden vom System automatisch überprüft (Aufwand!?)

5 5 Assertions - Beispiele Die Summe aller Kreditbeträge bei einer Zweigstelle muss kleiner sein als die Summe aller Kontostände bei der Zweigstelle: create assertion sum_constraint check (not exists (select * from branch where (select sum(amount) from loan where loan.branch_name = branch.branch_name) >= (select sum(balance) from account where account.branch_name = branch.branch_name)))

6 6 Assertions - Beispiele Für jeden Kredit muss es einen Kreditnehmer mit einem Konto, dessen Kontostand größer als ist, geben: create assertion balance_constraint check (not exists (select * from loan where not exists (select * from (borrower natural inner join depositor) natural inner join account where loan.loan_number = borrower.loan_number and account.balance >= 1000)))

7 7 Trigger und Regeln Trigger werden automatisch als Reaktion auf eine Änderung in der Datenbank ausgeführt Regeln (im Sinne von PostgreSQL) werden automatisch vom Query- und Updateprozessor verwendet, um eine Anfrage zu modifizieren Trigger- bzw. Regelmechanismus müssen für einen Trigger bzw. eine Regel spezifizieren unter welchen Bedingungen er/sie ausgeführt wird welche Aktionen bei seiner/ihrer Anwendung ausgelöst werden SQL3 standardisiert Trigger viele Datenbanksysteme unterstützen Trigger oder Regeln

8 8 Trigger in SQL3 create trigger <Name> [after before] <Ereignisse> on <Relation> [referencing old row as <Name>, new row as <Name>] [referencing old table as <Name>, new table as <Name>] [for each row for each statement ] [when <Bedingung>] begin <Aktion> end

9 9 Trigger in SQL3... Ereignisse: or-verknüpfungen von einfachen Ereignissen Einfache Ereignisse: insert delete update of <Attributliste> Aktion: SQL-Anweisung before: Trigger vor dem Ereignis ausführen after: Trigger nach dem Ereignis ausführen

10 10 Trigger in SQL3 for each row: Trigger für jede Änderung eines Datensatzes ausführen for each statement: Trigger nur einmal für die Operation ausführen old new row as: altes bzw. neues Tupel unter dem angegebenen Namen zugreifbar referencing old new table as: alte bzw. neue Relation unter dem angegebenen Namen zugreifbar

11 11 Triggerbeispiel - Szenario Bank duldet keine Kontoüberziehung, sondern erzeugt bei negativen Kontoständen einen Kredit: setze den Kontostand auf 0 erzeuge einen Kredit in der entsprechenden Höhe Kreditnummer ist Kontonummer beim Anlegen eines Kontos muss der Kontostand > 0 sein

12 12 Triggerbeispiel... Kredit einrichten, falls Konto überzogen wird: create trigger overdraft1 after update of balance on account referencing old row as orow, new row as nrow for each row when nrow.balance < 0 and orow.balance > 0 begin insert into loan(loan_number, branch_name, amount) values(orow.account_number, orow.branch_name, - nrow.balance); insert into borrower(customer_id, loan_number) (select customer_id, account_number from depositor as T where orow.account_number = T.account_number); update account set balance = 0 where account.account_number = orow.account_number; end

13 13... Triggerbeispiel... Gutschrift auf überzogenes Konto mit dem Kredit verrechnen: create trigger overdraft2 after update of balance on account referencing old row as orow, new row as nrow for each row when orow.balance = 0 begin update loan set amount = amount - nrow.balance where loan_number = orow.account_number; end

14 14... Triggerbeispiel... Falls noch eine Restschuld vorhanden ist, Kontostand auf 0 setzen: create trigger overdraft3 after update of amount on loan referencing old row as orow, new row as nrow for each row when nrow.amount > 0 begin update account set balance = 0 where account_number = orow.loan_number; end

15 15... Triggerbeispiel Falls die Restschuld beglichen wurde, so wird der Kredit gelöscht und der Kontostand gesetzt: create trigger overdraft4 after update of amount on loan referencing old row as orow, new row as nrow for each row when nrow.amount <= 0 begin update account set balance = -nrow.amount where account_number = orow.loan_number; delete from borrower where loan_number = orow.loan_number; delete from loan where loan_number = orow.loan_number; end

16 16 Trigger und Assertions... Integritätsbedingung "Die Summe aller Kreditbeträge bei einer Zweigstelle muss kleiner sein als die Summe aller Kontostände bei der Zweigstelle" kann durch Assertions überprüft werden besser: Verwendung von before-triggern, die die Zulässigkeit einer Operation überprüfen durch Trigger gegebenenfalls Abbruch der Transaktion definiere im Beispiel Trigger bei Einrichtung und Veränderung eines Kredits Trigger bei Löschung und Veränderung eines Kontos noch besser: Änderungen über Prozeduren (Kapitel 7), die das gewünschte Verhalten implementieren aber Nutzung kann nicht erzwungen werden

17 17... Trigger und Assertions... create trigger sum_constraint_trigger1 before insert, update of amount on loan referencing old table as otable, new table as ntable for each statement when (exists (select * from branch where (select sum(amount) from ntable where ntable.branch_name = branch.branch_name) >= (select sum(balance) from account where account.branch_name = branch.branch_name))) begin rollback work end

18 18... Trigger und Assertions create trigger sum_constraint_trigger2 before delete, update of balance on account referencing old table as otable, new table as ntable for each statement when (exists (select * from branch where (select sum(amount) from loan where loan.branch_name = branch.branch_name) >= (select sum(balance) from ntable where ntable.branch_name = branch.branch_name))) begin rollback work end

19 19 externe Trigger... manchmal müssen Trigger externe Ereignisse auslösen Beispiel: Bestellung einer Ware Trigger können nicht unmittelbar externe Ereignisse auslösen Trigger können entsprechende Daten in separate Tabellen schreiben, die von anderen Prozessen beobachtet werden Beispiel: inventory(item, level); Produkte im Lager minlevel(item, level); wann neu bestellen? reorder(item, amount); welche Bestellmengen? orders(item, amount); offene Bestellungen

20 20... externe Trigger create trigger reorder_trigger after update of level on inventory referencing old row as orow, new row as nrow for each row when nrow.level <= (select level from minlevel where minlevel.item = orow.item) and orow.level > (select level from minlevel where minlevel.item = orow.item) begin insert into orders (select item, amount from reorder where reorder.item = orow.item) end

21 21 Regeln in PostgreSQL create rule name as on event to object [ where condition ] do [ instead ] action Event: select, update, insert und delete Object: Tabelle oder Attribut Condition: SQL - Bedingung Action: eine oder mehrere Anfragen Conditon und Action können Bezeichner new und old enthalten new für insert und update old für select, update und delete instead ursprüngliche Anfrage wird ersetzt spezielle Anfrage nothing

22 22 Regeln - Modifikationen über Sichten... create view branch_loan as select loan_number, branch_name from loan create rule branch_loan_ins as on insert to branch-loan do instead insert into loan (branch_name, loan_number, amount)values (new.branch_name, new.loan_number, 0)

23 23... Regeln - Modifikationen über Sichten... create rule branch_loan_up as on update to branch_loan do instead update loan set branch_name = new.branch_name, loan_number = new.loan_number where loan_number = old.loan_number

24 24... Regeln - Modifikationen über Sichten create rule branch_loan_del as on delete to branch_loan do instead delete from loan where loan_number = old.loan_number

25 25 Trigger und Regeln in PostgreSQL Trigger und Regeln sind sehr ähnlich Trigger werden aufgrund von Änderungen an Objekten ausgelöst Regeln werden aufgrund von Operationen ausgelöst und können diese ersetzen

26 26 Sicherheit DBMS Authentifizierung (Identifikation des Benutzers) und Autorisierung (Vergabe von Rechten an die Benutzer) Betriebssystem unberechtigte Zugriffe auf Datenbanken über die Betriebssystemebene müssen unterbunden werden Netzwerk unberechtigtes Lesen von Nachrichten muss unterbunden werden Authentifizierung muss auch über das Netz gewährleistet sein physische Ebene traditionelle Sicherungsmethoden menschliche Ebene Umgang mit dem Datenbankaccount

27 27 Zugriffsrechte - Arten des Zugriffs Zugriffe auf Daten lesen (Read Authorization) einfügen (Insert Authorization) verändern (Update Authorization) löschen (Delete Authorization) Veränderung des Schemas Anlegen und Löschen von Indizes (Index Authorization) Anlegen neuer Relationen (Resource Authorization) Ändern von Relationenschemata (Alteration Authorization) Löschen von Relationen (Drop Authorization)

28 28 Zugriffsrechte und Sichten Benutzer können Zugriffsrechte auf eine Sicht haben, ohne Rechte an Relationen zu haben, auf denen die Sicht basiert Beispiel: Bankmitarbeiter kennt Namen von Kreditnehmern, darf aber nicht auf Kreditinformationen zugreifen: verweigere Zugriff auf die Relation loan erlaube Zugriff auf die Sicht cust_loan: create view cust_loan as select branch_name, customer_name from (borrower natural inner join loan) natural inner join customer Zugriffsrechte müssen geprüft werden, bevor Query-Processor die Sicht in einer Anfrage durch die Sichtdefinition ersetzt

29 29 Rechte auf neuen Relationen und Sichten Benutzer, der eine Relation anlegt, erhält automatisch alle Rechte für den Zugriff auf die Relation Benutzer, der eine Sicht anlegt, erhält nicht automatisch vollständige Rechte auf dieser Sicht Rechte auf den Relationen, über denen die Sicht definiert ist, übertragen sich auf die Sicht Fehler wird ausgelöst, falls beim Anlegen der Sicht dem Benutzer keinerlei Rechte eingeräumt werden können

30 30 Delegation von Rechten Benutzer kann Rechte an andere delegieren Rechtevergabe kann für jedes Recht in einem Autorisierungsgraphen veranschaulicht werden: Benutzer als Knoten darstellen DBA ist ein Knoten gerichtete Kante verbindet Knoten für Benutzer U i mit dem Knoten für Benutzer U j, falls U i U j das entsprechende Recht eingeräumt hat Benutzer U hat ein Recht, wenn ein Pfad vom Knoten des DBA zum Knoten des Benutzers U in dem zugehörigen Autorisierungsgraphen existiert

31 31 Autorisierungsgraph - Beispiel... U 1 U 4 DBA U 2 U 5 U 3

32 32... Autorisierungsgraph - Beispiel U 1 U 4 DBA widerruft Recht für U 1 DBA U 2 U 5 U 3

33 33 Zyklen im Autorisierungsgraph... entstehen, wenn Benutzer sich gegenseitig ein Recht einräumen U 1 DBA U 2 U 3

34 34... Zyklen im Autorisierungsgraph... DBA widerruft Recht für U 2 U 1 DBA U 2 U 2 behält das Recht über U 3 U 3

35 35... Zyklen im Autorisierungsgraph U 1 DBA widerruft Recht für U 3 DBA U 2 U 3 U 2 behält das Recht über U 3? U 3 behält das Recht über U 2? Nein daher: alle Kanten müssen Bestandteil eines Pfades sein, der beim DBA beginnt

36 36 SQL - Delegation von Rechten... grant <Liste von Rechten> on <Name einer Relation oder Sicht> to <Liste mit Benutzern> Arten von Rechten auf Daten (DBMS-spezifisch): lesen (select) einfügen (insert) verändern (update) löschen (delete)... Arten von Rechten auf dem Schema der Datenbank (DBMS-spezifisch): Anlegen von Fremdschlüsseln (references) Anlegen von Sichten (create view) Anlegen von Relationen (create table)...

37 37... SQL - Delegation von Rechten Alle Rechte: all privileges Liste mit Benutzern kann auch public sein Rechte können auch with grant option vergeben werden Rechteempfänger kann dann weiter delegieren

38 38 SQL Widerrufen von Rechten revoke <Liste von Rechten> on <Name einer Relation oder Sicht> from <Liste mit Benutzern> [restrict cascade] Liste der Privilegien kann all sein Liste mit Benutzern kann public sein cascade widerruft Rechte kaskadierend restrict widerruft Rechte nur über eine Ebene, Fehler wird ausgelöst, wenn Rechte kaskadierend widerrufen werden müssen

39 39 SQL - Delegation von Rechten - Beispiele grant select on branch to U 1 with grant option with grant option erlaubt Delegation von Rechten grant update (amount) on loan to U 1, U 2, U 3 Rechte für die Veränderung des Attributs amount revoke select on branch from U 1, U 2, U 3 cascade kaskadierend Rechte widerrufen revoke select on branch from U 1, U 2, U 3 restrict Recht nicht kaskadierend widerrufen revoke grant option for select on branch from U 1 Recht zur Delegation widerrufen

40 40 Rollen Rollen ermöglichen die Vergabe von Rechten an eine Gruppe von Benutzern Rechte werden mit Rollen verknüpft Benutzer können Rollen erhalten SQL3 unterstützt Rollen: create role teller create role manager grant select on branch to teller grant update (balance) on account to teller grant all privileges on account to manager grant teller to manager grant teller to alice, bob grant manager to avi

41 41 Grenzen der SQL-Mechanismen keine Autorisierung auf Datensatzebene Web-basierte Zugriffe erfolgen über Anwendungsserver, die unter einer Benutzerkennung laufen Autorisierung muss bei Web-basierten Zugriffen durch den Anwendungsserver erfolgen feinere Autorisierung möglich Autorisierung im Anwendungscode Sicherheitslöcher sind schwieriger zu finden