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 C: mints(i) = 10 C: mints(u) = 10 C: mints(s) = 40 A 10 : I, U, GO 50 : U, GO 20 : U, GO C D 30 : U, GO B 40 : S, U, GO 60 : U, GO E Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 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: GRANT UPDATE ON Pers TO C WITH GRANT OPTION E ist keine unabhängige Quelle! (Zykel im Graph) A I, U, GO C U, GO D B S, U, GO U, GO E U, GO 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 S, I, U, D, GO C U, GO D B S, U, GO U, GO E U, GO 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) - eine eindeu4ge grundlegende Rolle (z.b. Angestellter, Hiwi) Dekan Präsident Abteilungsleiter Professor wissenschaftlicher Angestellter 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 von Rollen GRANT role-granted-commalist TO grantee-commalist [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 von Rollen REVOKE [ADMIN OPTION FOR] role-revoked-commalist 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,*) SQL-Umgebung (1,1) (0,*) Cluster ist in (1,*) zugeordnet (0,*) (1,1) Katalog (1,*) (1,1) unterteilt Schema Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 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 Integritätsbedingung Basistabelle Sicht Tabellenbedingung Sicht Referentielle Integritätsbedingung Freie Bedingung CHECK-Bedingung Domäne Domänenbedingung Zeichensatz Zugriffsrecht Zeichenordnung Zeichensatztransformation Zugriffsrecht auf Tabelle Legende: ist hat Zugriffsrecht auf Spalte Benutzer Zugriffsrecht auf anderes Objekt Informa4onssysteme 2015 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 Informationsschema Implemen4erungen - Ist für den Benutzer zugänglich und somit die definierte Schnixstelle zum Katalog Defini4onsschema - Beschreibt hypothe4sche Katalogstrukturen, also Meta- Metadaten Definitionsschema - Erlaubt Altsysteme mit abweichenden Implemen4erungen normkonform zu werden Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 85

Das Defini4onsschema Refs primary key/ unique constr. REFERENTIAL_ CONSTRAINTS is for. key primary key / unique constr. xor for. key check ASSERTIONS or owner default character set SCHEMATA TABLE_ CONSTRAINTS CHECK_ CONSTRAINTS DOMAIN_ CONSTRAINTS DOMAINS KEY_COLUMN_ USAGE CHECK_TABLE_ USAGE CHECK_COLUMN_ USAGE or DATA_TYPE_ DESCRIPTOR CHAR SET TABLES >0 COLUMNS or COLLATIONS VIEW_TABLE USAGE VIEW VIEW_COLUMN_ USAGE CHARACTER_ USAGE default collation TABLE_ PRIVILEGES COLUMN_ PRIVILEGES USAGE_ PRIVILEGES grantor grantee grantor grantee grantor grantee or target source TRANSLATIONS USERS SQL_LANGUAGES Informa4onssysteme 2015 Kapitel 6. Sichten, Integrität und Zugriffskontrolle 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