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
© Copyright 2024 ExpyDoc
