Autorisierungsgraph mit zeitabhängiger Interpreta4on

Autorisierungsgraph mit zeitabhängiger Interpreta4on §  Der Entzug eines Rechtes ergibt einen Schutzzustand, als wenn das Recht nie erteilt worden wäre. •  Vergabe von Zeitstempeln für jedes Zugriffsrecht bei Autorisierung •  Zykel und "Duplikate" (mit versch. Zeitstempeln) möglich •  Bei GRANT OPTION: nachfolgende GRANTs wären zum gleichen Zeitpunkt mglw. gescheitert §  Beispiel 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 WITH GRANT OPTION 40 : B: GRANT SELECT, UPDATE ON Pers TO C WITH GRANT OPTION 50 : C: GRANT UPDATE ON Pers TO D WITH GRANT OPTION 60 : E: GRANT UPDATE ON Pers TO C WITH GRANT OPTION 70 : A: REVOKE INSERT, UPDATE ON Pers FROM C CASCADE Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 69 Autorisierungsgraph mit zeitabhängiger Interpreta4on (2) §  Verfahren für "X: REVOKE R FROM Y CASCADE" •  Löschen der Kante(n) für R von X à Y •  Falls Y Recht R noch aus anderen Quellen hält, -  bes4mme kleinsten Zeitstempel minTS für diese Recht für Y -  lösche aus Y ausgehende Kanten für R mit TS < minTS (à REVOKE ... CASCADE) •  sonst: lösche alle aus Y ausgehende Kanten für R (à REVOKE ... CASCADE) §  Beispiel: 70 : A: REVOKE INSERT, UPDATE ON Pers FROM C CASCADE Autorisierungsgraph
vor Ausführung
des REVOKE
A
10 : I, U, GO
50 : U, GO
C: minTS(I) = 10
C
C: minTS(U) = 10
20 : U, GO
D
C: minTS(S) = 40
30 : U, GO
B
Informa4onssysteme 2015 40 : S, U, GO
60 : U, GO
Kapitel 6. Sichten, Integrität und Zugriffskontrolle E
70 Autorisierungsgraph mit zeitunabhängiger Interpreta4on §  Der rekursive Entzug eines Rechtes wird nicht fortgesetzt, sobald der Geber noch mindestens ein gleiches Recht für das Objekt von einer unabhängigen Quelle hat. è Erfordert Überprüfung der Quellenunabhängigkeit §  Beispiel 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 Weitere Vergabe E ist keine unabhängige Quelle!
E: GRANT UPDATE ON Pers TO C WITH GRANT OPTION (Zykel im Graph)
A
I, U, GO
U, GO
C
D
U, GO
S, U, GO
U, GO
B
E
Rücknahme A: REVOKE INSERT, UPDATE ON Pers FROM C CASCADE B: REVOKE SELECT, UPDATE ON Pers FROM C CASCADE Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 71 Alterna4ven bei zeitunabhängiger Interpreta4on §  Alterna4ve 1 •  Verbot von Zyklen (abhängigen Quellen) im Autorisierungsgraph •  beim REVOKE CASCADE muss nur geprüi werden, ob noch eingehende Kanten exis4eren. In dem Fall wird der Rechteentzug nicht fortgesetzt. §  Alterna4ve 2 (auch im SQL-­‐Standard gefordert) •  der Besitzer eines Objekt wird ausgezeichnet, bei ihm beginnt die Rechtevergabe •  beim REVOKE CASCADE wird geprüi, ob noch ein Pfad vom Besitzer zum Knoten exis4ert. Dann wird der Rechteentzug nicht fortgesetzt. §  Beispiel zu Alterna4ve 2 (mit Besitzer A) A
I, U, GO
U, GO
C
D
S, I, U,
D, GO
U, GO
S, U, GO
U, GO
B
E
Rücknahme A: REVOKE INSERT, UPDATE ON Pers FROM C CASCADE B: REVOKE SELECT, UPDATE ON Pers FROM C CASCADE Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 72 Verfeinerungen des Autorisierungsmodells §  Implizite Autorisierung •  hierarchische Anordnung von Subjekten, Objekten und Opera4onen •  explizite Autorisierung auf einer Hierarchiestufe bewirkt implizite Autorisierungen auf anderen Hierarchiestufen §  Nega4ve Autorisierung •  stellt ein Verbot des Zugriffs (¬p) dar •  kann explizit und implizit erfolgen §  Schwache Autorisierung •  kann als Standardeinstellung verwendet werden (Leserecht eines Objektes für gesamte Gruppe, die aus Teilgruppen besteht) •  erlaubt Überschreibung durch starkes Verbot (Teilgruppe erhält explizites Leseverbot) •  Schreibweise: [ . . . ] Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 73 Verfeinerungen des Autorisierungsmodells (2) §  Autorisierungsalgorithmus wenn es eine explizite oder implizite starke Autorisierung (o, s, p) gibt, dann erlaube die Opera4on wenn es eine explizite oder implizite starke nega4ve Autorisierung (o, s, ¬p) gibt dann verbiete die Opera4on ansonsten wenn es eine explizite oder implizite schwache Autorisierung [o, s, p] gibt, dann erlaube die Opera4on wenn es eine explizite oder implizite schwache nega4ve Autorisierung [o, s, ¬p] gibt, dann verbiete die Opera4on sonst verbiete die Opera4on Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 74 Verfeinerungen des Autorisierungsmodells (3) §  Implizite Autorisierung von Subjekten •  Einführung von Rollenhierarchien •  zwei ausgezeichnete Posi4onen -  eine eindeu4ge Rolle mit der maximalen Menge an Rechten (z.B. Präsident, Systemadministrator) Präsident
-  eine eindeu4ge grundlegende Rolle (z.B. Angestellter, Hiwi) Dekan
Professor
wissenschaftlicher
Angestellter
Abteilungsleiter
Verwaltungsangestellter
Angestellter
§  Explizite posi4ve Autorisierung è implizite posi4ve Autorisierung auf allen höheren Hierarchiestufen §  Explizite nega4ve Autorisierung è implizite nega4ve Autorisierung auf allen niedrigeren Hierarchiestufen Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 75 Rollenkonzept in SQL §  Rollenkonzept •  bisher: (explizite) Zuordnung von Zugriffsrechten zu Benutzern •  SQL:1999 erlaubt die Defini4on von Rollen •  Ziel: Vereinfachung der Defini4on und Verwaltung komplexer Mengen von Zugriffsrechten -  Erzeugung von Rollen und Vergabe von Zugriffsrechten (Autorisierungen) -  Kontrolle der Ak4vitäten (Einhaltung der vorgegebenen Regeln) Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 76 Rollenkonzept in SQL (2) §  Wich4ge Rollen (nicht standardisiert!) •  Systemadministrator -  Sie „besitzt“ sämtliche Ressourcen des DBS und ist zur Ausführung einer jeden DB-­‐Anweisung autorisiert. -  Rolle verwaltet eine DBS-­‐Instanz, die mehrere DBS umfassen kann. -  Bei DB2/UDB gibt es beispielsweise zwei Untergruppen: Systemkontrolle und Systemwartung. •  DB-­‐Administrator -  Rolle gilt für eine spezielle DB mit allen Zugriffsrechten. •  Anwendungsentwickler -  typische Zugriffsrechte: Verbindung zur DB herstellen (CONNECT), Tabellen erzeugen, AWPs an DB binden -  Zugriffsrechte beziehen sich auf Menge spezieller DB-­‐Objekte. -  Kapselung von Rechten durch AWP bei sta4schem SQL •  Endbenutzer -  Rechte für Ad-­‐hoc-­‐Anfragen -  CONNECT-­‐ und EXECUTE-­‐Rechte für AWPs Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 77 Rollenkonzept in SQL (3) §  Defini4on von Rollen •  CREATE ROLE Revisor CREATE ROLE Hauptrevisor §  Vergabe von Rechten •  GRANT INSERT ON TABLE Budget TO Revisor §  Zuweisung GRANT role-granted-commalist TO grantee-commalist
von Rollen [WITH ADMIN OPTION]
•  Rollen werden Benutzern und Rollen explizit zugewiesen. è Zuweisung von Rollen an Rollen ermöglicht implizite Vergabe! •  WITH ADMIN OPTION erlaubt die Weitergabe von Rollen. •  Beispiel: GRANT Revisor TO Weber WITH ADMIN OPTION §  Entzug REVOKE [ADMIN OPTION FOR] role-revoked-commalist
von Rollen FROM grantee-commalist
{RESTRICT | CASCADE}
•  Beispiele REVOKE Revisor FROM Weber RESTRICT REVOKE ADMIN OPTION FOR Revisor FROM Weber CASCADE •  WITH ADMIN OPTION ist „vorsich4g” einzusetzen Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 78 Rollenkonzept in SQL (4) §  Anwendung •  Momentaner Rechtebesitz Revisor : P1, P2, P5 Hauptrevisor : P3, P4 Benutzer Schmidt : P1 P1 P2 P3 P4 P5 P6 Revisor ✔︎ ✔ Hauptrevisor Schmidt ✔ ✔ ✔ ✔ §  Auswirkung folgender Opera4onen •  Zuweisung von Rollen GRANT Revisor TO Hauptrevisor WITH ADMIN OPTION •  „A role can contain other roles”! GRANT Hauptrevisor TO Schmidt •  Evolu4on von Rollen Grant P6 ON TABLE X TO Revisor è Wer bekommt aktuell P6? •  Entzug von Rollen Revoke Revisor FROM Hauptrevisor RESTRICT Revoke Revisor FROM Hauptrevisor CASCADE è Implemen4erung der Rollenvergabe erfolgt sinnvollerweise referenziert und nicht materialisiert! Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 79 Zusammenfassung Datenschutz & Zugriffskontrolle §  Aufeinander abges4mmte Sicherheitskonzepte sind wesentlich •  Zugangskontrolle •  starke Verfahren zur Authen4sierung •  kryptographische Maßnahmen zur Datenübertragung •  Isola4on der Prozesse •  Prinzip der Zugriffskontrolle: Least Privilege Principle •  Sicherungsanforderungen gelten allgemein in Rechensystemen und insbesondere zwischen Anwendung und DBS è Das „schwächste Glied“ in der Kexe der Sicherheitsmaßnahmen bes4mmt die Sicherheit des Gesamtsystems! §  Zugriffskontrolle in DBS •  wertabhängige Festlegung der Objekte (Sichtkonzept) •  Vielfalt an Rechten erwünscht •  zentrale vs. dezentrale Rechtevergabe •  verschiedene Entzugsseman4ken bei dezentraler Rechtevergabe •  Rollenkonzept: vereinfachte Verwaltung komplexer Mengen von Zugriffsrechten Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 80 Katalog, Schema und Metadaten in SQL §  SQL-­‐Umgebung (environment) besteht aus •  einer Instanz eines DBMS zusammen mit •  einer Menge von Daten in Katalogen (als Tabellen organisiert) •  einer Reihe von Nutzern (authoriza4on iden4fiers) und Programmen (modules) §  Wich4ge Elemente der SQL-­‐Umgebung gehört zu
(0,*)
(0,*)
(1,1)
Cluster
ist in
(1,*)
zugeordnet
Informa4onssysteme 2015 SQL-Umgebung
(1,1)
(0,*)
Katalog
(1,*)
unterteilt
(1,1)
Kapitel 6. Sichten, Integrität und Zugriffskontrolle Schema
81 Datendefini4on nach SQL (2) §  SQL-­‐Schema •  Katalog kann man als DB (in der DB) ansehen •  SQL-­‐Schemata sind Hilfsmixel zur logischen Gruppierung von Objekten innerhalb einer solchen DB •  Datendefini4onsteil von SQL enthält Anweisungen zum Erzeugen, Ändern und Löschen von Schemaelementen §  Kataloge •  bestehen aus SQL-­‐Schemata und können innerhalb einer SQL-­‐
Umgebung op4onal auf ein oder mehrere Cluster verteilt werden. •  Sinn dieser Clusterbildung ist die Zuordnung von genau einem Cluster zu jeder SQL-­‐Sitzung und dadurch wiederum die Zuordnung einer Menge von Daten bzw. Katalogen zu dieser Sitzung §  SQL erlaubt prinzipiell Schema/Katalogübergreifende Datenzugriffe mit Hilfe von "qualifizierten Namen" Beispiel: SELECT * FROM C1.S1.PRODUCTS p, C2.S1.SALES s WHERE p.id = s.pid and p.price > 100 Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 82 Defini4on von Schemata §  Anweisungssyntax (vereinfacht) CREATE SCHEMA [schema] [AUTHORIZATION user]
[DEFAULT CHARACTER SET char-set]
[schema-element-list]
•  Defini4on aller Defini4onsbereiche, Basisrela4onen, Sichten (Views), Integritätsbedingungen und Zugriffsrechte erfolgt im Rahmen eines Schemas •  Jedes Schema ist einem Benutzer (user) zugeordnet, z.B. DBA -  Benutzer ist automa4sch Besitzer (owner) der Objekte (z.B. Tabellen) des Schemas •  Schema erhält Benutzernamen, falls keine explizite Namensangabe erfolgt §  D1: Benennung des Schemas CREATE SCHEMA Beispiel-­‐DB AUTHORIZATION DB-­‐Admin Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 83 Elemente des SQL-­‐Schemas Schema
Tabelle
Basistabelle
Sicht
Sicht
Integritätsbedingung
Tabellenbedingung
Referentielle
Integritätsbedingung
Freie Bedingung
CHECK-Bedingung
Domäne
Domänenbedingung
Zeichensatz
Zeichenordnung
Zeichensatztransformation
Zugriffsrecht
Legende:
ist
hat
Zugriffsrecht auf
Tabelle
Zugriffsrecht auf Spalte
Benutzer
Informa4onssysteme 2015 Zugriffsrecht auf
anderes Objekt
Kapitel 6. Sichten, Integrität und Zugriffskontrolle 84 Informa4ons-­‐ und Defini4onsschema §  Ziel der SQL-­‐Normierung •  möglichst große Unabhängigkeit der DB-­‐Anwendungen von speziellen DBS •  einheitliche Sprachschnixstelle genügt nicht! •  Beschreibung der gespeicherten Daten und ihrer Eigenschaien (Metadaten) nach einheitlichen und verbindlichen Richtlinien ist genauso wich4g §  Zweischich4ges Defini4onsmodell zur Beschreibung der Metadaten •  Informa4onsschema -  Bietet einheitliche Sichten in normkonformen Implemen4erungen -  Ist für den Benutzer zugänglich und somit die definierte Schnixstelle zum Katalog Informationsschema
•  Defini4onsschema -  Beschreibt hypothe4sche Katalogstrukturen, also Meta-­‐Metadaten -  Erlaubt „Altsysteme“ mit abweichenden Implemen4erungen normkonform zu werden Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle Definitionsschema
85 Das Defini4onsschema REFERENTIAL_
CONSTRAINTS
Refs primary key/
unique constr.
is for.
key
primary key /
unique
constr.
for.
key
ASSERTIONS
SCHEMATA
owner
default
character set
check
or
xor
TABLE_
CONSTRAINTS
CHECK_
CONSTRAINTS
KEY_COLUMN_
USAGE
CHECK_TABLE_
USAGE
DOMAIN_
CONSTRAINTS
DOMAINS
CHECK_COLUMN_
USAGE
or
DATA_TYPE_
DESCRIPTOR
CHAR SET
>0
TABLES
or
COLUMNS
COLLATIONS
default
collation
VIEW_TABLE
USAGE
VIEW_COLUMN_
USAGE
VIEW
CHARACTER_
USAGE
target
COLUMN_
PRIVILEGES
TABLE_ PRIVILEGES
grantor
grantee
grantor
USAGE_
PRIVILEGES
grantee
grantor
or
TRANSLATIONS
grantee
USERS
Informa4onssysteme 2015 source
Kapitel 6. Sichten, Integrität und Zugriffskontrolle SQL_LANGUAGES
86 Zusammenfassung – Schemata und Metadaten §  SQL-­‐Umgebung •  Zugriff auf SQL-­‐Kataloge mit SQL-­‐Schemata, die ein SQL-­‐Cluster zugeordnet sind §  SQL-­‐Schema •  enthält Objekte (Tabellen, Sichten, Constraints, ...) •  hat einen zugeodneten Benutzer als Besitzer der Objekte §  Standardisierter Zugriff auf Metadaten •  jeder Katalog enthält ein Informa4onsschema zum Zugriff auf Metadaten, welche die Objekte aller Schemata des Katalogs beschreiben •  die zugrundeliegenden Metadatenstrukturen sind in einem konzeptuellen Defini4onsschema beschrieben •  Benutzer sieht immer nur die Metadaten von Objekten, auf die er auch Zugriff hat! Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 87