6.4 Zugriffsschutz in Datenbanken

Transkript

1 6.4 Zugriffsschutz in Datenbanken Relationale Datenbank besteht aus einer Menge von Tabellen (Relationen). Tabellen werden über Referenzen verbunden. Tabellen werden mengentheoretisch verknüpft und verarbeitet. Datenbank-Schema beschreibt die Tabellen. Zeilen der Tabelle werden als Tupel, die Spalten als Attribute bezeichnet. Wir beschäftigen uns nun mit Zugriffsschutzmechanismen in relationalen Datenbanken. Eine relationale Datenbank besteht aus einer Menge von Tabellen (Relationen), die durch Referenzen verknüpft sind. Die in den Tabellen gespeicherten Daten werden durch Operatoren mengenorientiert verknüpft und verarbeitet. Ein Datenbank-Schema beschreibt eine Tabelle, eine Instanz eines Schemas ist dann eine spezielle Ausprägung, d.h. Belegung der Tabelle mit Daten. Eine Zeile in einer Tabelle wird als Tupel bezeichnet, die Spalten als Attribute. 1

2 6.4 Zugriffsschutz in Datenbanken Beispiel: Primärschlüssel Signatur Autor Titel BenutzerNr Name Adresse Bücher Tupel ISBN30 ISBN32 ISBN40 Grass Heinz Kochrezepte Blechtrommel Benutzer Fritz Anna Berlin Hamburg Attribute Ausleihe Buch ISBN32 Leser 200 enthält Fremdschlüssel Der Primärschlüssel identifiziert die Tupel in der Tabelle eindeutig. Fremdschlüssel realisieren Verweise zwischen Tupeln unterschiedlicher Tabellen. 2

3 6.4 Zugriffsschutz in Datenbanken SQL ist Anfragesprache, die die Definition, Anfrage und Änderung einer Datenbank ermöglicht. Schemadefinition: create table Bücher (Signatur varchar(12) not null, Autor varchar(15), Titel varchar(30) not null); Einfügen von Tupeln: insert into Bücher values (`ISBN32`, `Heinz`, `Kochrezepte`); SQL ist eine deklarative Anfragesprache, bei der der Benutzer angibt, welche Daten ihn oder sie interessieren. Eine neue Tabelle wird mit dem create table Befehl erzeugt. Um eine Tabelle mit Daten zu füllen, wird der Befehl insert verwendet. 3

4 6.4 Zugriffsschutz in Datenbanken Einfache SQL-Anfragen: liefert Menge von Paaren (Signatur, Titel) vom Autor Grass select Signatur, Titel from Bücher where Autor = 'Grass'; liefert Menge von Tripeln select * from Benutzer where Name = Fritz'; Anfragen können mit dem select Befehl gestellt werden. Beispiele zeigt die Folie. 4

5 6.4 Zugriffsschutz in Datenbanken Anfragen über mehrere Relationen select Titel from Bücher, Ausleihe, Benutzer where Name = Anna' and BenutzerNr = Leser and Signatur = Buch; 5

6 6.4 Zugriffsschutz in Datenbanken Sichten (views) sind virtuelle Tabellen die bei jeder Verwendung ad-hoc aus den realen Tabellen generiert werden. create view Präferenzen(Name, Titel) as select Name, Titel from Bücher, Ausleihe, Benutzer where Benutzer = Leser and Signatur = Buch; select Titel from Präferenzen where Name = Anna'; Sichten bieten virtuelle Tabellen an, die nur einen Ausschnitt des gesamten Modells zeigen. Für virtuelle Tabellen werden keine neuen Tabellen angelegt, sondern sie werden bei jeder Verwendung neu berechnet. 6

7 6.4 Zugriffsschutz in Datenbanken Formulierung von Schutzstrategien in SQL Zugangskontrolle meist über Passwörter. Autorisierung erfolgt über die Kommandos grant und revoke zum Zuweisen bzw. Entziehen von Privilegien. Privilegien: Rechte, Typen von SQL Statements auf Daten auszuführen (z.b. SELCET, INSERT, DELETE etc.) Werden Benutzern und Rollen zugeordnet. Erzeuger hat alle Privilegien auf den Daten. Die Zugangskontrolle bei Datenbanken erfolgt meistens über Passwörter. Die Passwörter werden üblicherweise bei der Einrichtung der Benutzererkennung verschlüsselt gespeichert. In SQL existiert ein Befehl zur Vergabe von Privilegien (grant) und einer zum Entzug von Privilegien (revoke). Privilegien sind Rechte, Typen von SQL Statements auf Daten auszuführen. So kann einem Benutzer beispielsweise das SELECT-Kommando auf einer Tabelle gewährt oder das INSERT-Kommando auf einer View entzogen werden. Die Privilegien können direkt an Benutzer, aber auch an Rollen vergeben werden. In diesem Fall haben dann alle Mitglieder einer Rolle die der Rolle zugewiesenen Privilegien. Der Erzeuger von Daten hat alle Privilegien auf den Daten. 7

8 6.4 Zugriffsschutz in Datenbanken GRANT-Kommando zum Zuweisen von Privilegien. GRANT <privileges> ON <object> TO [<users> <role>] [WITH GRANT OPTION] GRANT OPTION: Recht, Privilegien an andere Benutzer weiterzureichen. Nach dem GRANT-Kommando hat der <user> das <privilege> auf dem <object> (Zugriffsmatrix) Das Grant-Kommando weist ein Privileg (z.b. SELECT, UPDATE) auf einem Objekt (z.b. eine Tabelle, Sicht) einem Benutzer oder einer Rolle zu. Betrachtet man die Zugriffsschutzmatrix als unterliegendes Modell, bewirkt das Grant-Kommando das Zufügen des Privilegs in die Matrix in der Spalte des Objekts und der Zeile des Benutzers bzw. der Rolle. Wird die GRANT OPTION verwendet, so darf der Benutzer das zugewiesene Privileg ebenfalls anderen Benutzern gewähren. 8

9 6.4 Zugriffsschutz in Datenbanken Beispiele: GRANT INSERT, SELECT ON Movie TO Klaus Klaus darf anfragen an die Tabelle Movie stellen und neue Tupel zufügen. GRANT DELETE ON Movie TO Anna WITH GRANT OPTION Anna kann Tupel der Tabelle Movie löschen und andere Benutzer ebenfalls dazu autorisieren. GRANT UPDATE (price_day) ON Movie TO movie_staff Alle Mitglieder der Rolle movie_staff können das Attribut price_day (und nur dieses) von Tupeln der Tabelle Movie ändern. Diese Folie zeigt einige Beispiele für das Grant-Kommando. 9

10 6.4 Zugriffsschutz in Datenbanken Revoke-Kommando zum Entziehen von Privilegien. REVOKE <privileges> ON <object> FROM [<users> <role>] RESTRICT RESTRICT: entziehe das Privileg nur, wenn das Privileg nicht von einem der <users> an andere weitergereicht wurde. Wird ein Privileg von mehreren Benutzern gegeben, muss das Privileg von allen diesen Benutzern entzogen werden, um das Privileg zu verlieren. Mit dem Revoke-Kommando lassen sich einem Benutzer oder einer Rolle Privilegien wieder entziehen. Das Schlüsselwort Restrict spezifiziert, dass Privilegien einem Benutzer jedoch nicht entzogen werden können, wenn dieser das Privileg schon weitergegeben hat, da dann auch allen diesen Benutzen das Privileg entzogen werden müsste. Ein solches transitives Entziehen des Privilegs ist mit diesem einfachen Revoke-Kommando jedoch nicht möglich. Außerdem wird einem Benutzer das Privileg durch ein Revoke-Kommando nicht entzogen, wenn dem Benutzer das Privileg noch von anderen Benutzern gewährt wurde. Um ein Privileg zu verlieren, müssen also alle Benutzer, die dieses Privileg gewährten, ein Revoke ausführen. 10

11 6.4 Zugriffsschutz in Datenbanken Beispiel 1: Owner: GRANT Update ON Movie TO Klaus; Owner: GRANT Update ON Movie TO Anna; Owner: REVOKE Update ON Movie FROM Klaus RESTRICT; Owner und Anna haben das Privilege Update Klaus hat das Privileg Update nicht mehr In diesem Beispiel wird Klaus das Update-Privileg auf die Tabelle Movie vom Owner entzogen. 11

12 6.4 Zugriffsschutz in Datenbanken Beispiel 2: Owner: Klaus: GRANT Update ON Movie TO Klaus WITH GRANT OPTION; GRANT Update ON Movie TO Anna; Owner: REVOKE Update ON Movie FROM Klaus RESTRICT; Revoke hat keinen Effekt: Owner, Anna und Klaus haben das Privileg Update. In diesem Beispiel hat das Revoke-Kommando keinen Effekt auf die Privileg-Zuordnung. Klaus kann das Update-Privileg nicht entzogen werden, da Klaus das Update-Privileg schon an Anna weitergegeben hat. 12

13 6.4 Zugriffsschutz in Datenbanken Revoke-Kommando zum transitiven Entziehen von Privilegien. REVOKE [GRANT OPTION FOR] <privileges> ON <object> FROM <users> {RESTRICT CASCADE} CASCADE: Entziehe das Recht auch allen Benutzern, denen das Privileg von diesen <users> gegeben wurde. RESTRICT: Entziehe das Privileg nur, wenn das Privileg nicht von einem der <users> an andere weitergereicht wurde. Es gibt auch eine Variante des Revoke-Kommandos zum transitiven Entziehen von Privilegien. Dies wird durch das Schlüsselwort Cascade spezifiziert, bei dem dann auch allen Benutzern das Privileg entzogen wird, die das Privileg von dem Benutzer bekamen, auf dem das Revoke-Kommando aufgerufen wird. 13

14 6.4 Zugriffsschutz in Datenbanken GRANT OPTION FOR: Entziehe das Recht zum Weiterreichen des Privilegs an andere Benutzer. Außerdem kann das Recht zum Weiterreichen von Privilegien einem Benutzer wieder entzogen werden. Dies geschieht mit dem Ausdruck GRANT OPTION FOR. 14

15 6.4 Zugriffsschutz in Datenbanken Beispiel 1: Owner: Klaus: GRANT Update ON Movie TO Klaus WITH GRANT OPTION; GRANT Update ON Movie TO Anna; Owner: REVOKE Update ON Movie FROM Klaus CASCADE; Owner hat das Privileg Update. Anna und Klaus wurde das Privileg entzogen. In diesem Beispiel hat das Entziehen des Update-Privilegs vom Benutzer Klaus auch den Entzug des Privilegs vom Benutzer Anna zur Folge, da Anna das Privileg von Klaus gewährt wurde. Da Klaus dieses Privileg nicht mehr hat, darf es somit auch Anna nicht mehr von ihm haben. 15

16 6.4 Zugriffsschutz in Datenbanken Beispiel 2: Owner: Klaus: GRANT Update ON Movie TO Klaus WITH GRANT OPTION; GRANT Update ON Movie TO Anna; Owner: REVOKE GRANT OPTION FOR Update ON Movie FROM Klaus CASCADE; Owner und Klaus haben das Privileg Update. Anna wurde das Privileg Update entzogen. Klaus wurde das GRANT-Recht entzogen. In diesem Beispiel wird Klaus das Recht zum Weiterreichen des Update-Privilegs entzogen. Da das Revoke-Kommando mit der Option CASCADE aufgerufen wurde, muss das Update-Privileg auch allen Benutzern entzogen werden, die das Privileg von Klaus gewährt bekamen. Da Anna das Update- Privileg von Klaus gewährt wurde, muss Anna das Privileg somit entzogen werden. Klaus selbst hat noch das Update-Privileg, da der Owner nur das Recht zum Weiterreichen des Privilegs entzogen hat, nicht das Privileg selbst. 16

17 6.4 Zugriffsschutz in Datenbanken Beispiel 3: Owner: Owner: Klaus: GRANT Update ON Movie TO Klaus WITH GRANT OPTION; GRANT Update ON Movie TO Anna; GRANT Update ON Movie TO Anna; Owner: REVOKE GRANT OPTION FOR Update ON Movie FROM Klaus CASCADE; Owner, Klaus und Anna haben das Update Privileg. Klaus hat das GRANT-Privileg nicht mehr. In diesem Beispiel wird Klaus wieder das Recht zum Weiterreichen des Update-Privilegs vom Owner entzogen. Da Klaus das Privileg an Anna weitergereicht hat, müsste es demnach auch Anna entzogen werden. Da Anna das Update-Privileg jedoch auch vom Owner selbst gewährt wurde, behält sie das Privileg. 17

18 6.4 Zugriffsschutz in Datenbanken Explizite Verwaltung der Zugriffsrechte mit GRANT und REVOKE ist für große Systeme aufwendig. Implizite Autorisierung für Subjekte und Operationen durch Anordnung in Hierarchien. Rolle B Rolle A Rolle D Rolle C Rollenhierarchie: Rolle B und C haben implizit die Privilegien von D. Rolle A hat implizit die Privilegien von Rolle B und C (und damit D). Die Grant- und Revoke-Kommandos geben die Möglichkeit, explizit Zugriffe auf Daten zu erlauben. Existieren viele Datenobjekte, wird die Menge der Autorisierungsregeln komplex und schwer verwaltbar. Daher existiert eine implizite Autorisierung. Bei dieser werden Subjekte bzw. Operationen hierarchisch angeordnet. Eine Autorisierung auf einer bestimmten Stufe der Hierarchie bewirkt, dass implizit Autorisierungen auf anderen Hierarchiestufen gelten. Für eine implizite Autorisierung von Subjekten werden Rollenhierarchien eingeführt. Eine Rolle hat dann implizit alle Privilegien der in der Hierarchie unter der Rolle liegenden Rollen. 18

19 6.4 Zugriffsschutz in Datenbanken Operationshierarchie: SELECT UPDATE DELETE UPDATE-Privileg beinhaltet SELECT- und DELETE-Privileg. Analog zu Rollenhierarchien können Operationshierarchien festgelegt werden. Bei der Hierarchie der Folie beinhaltet beispielsweise ein Privileg zum Update auch die Privilegien Select und Delete. 19

20 6.4.1 SQL Injection Einschleusen eigener Befehle in die SQL-Datenbank. Beispiel: Ein häufiger Angriff auf relationale Datenbanken ist SQL-Injection. SQL-Injection bezeichnet das Einschleusen von eigenen Befehlen in eine SQL-Datenbank. Als Beispiel betrachten wir eine Web- Schnittstelle, bei der man sich mit seinem Benutzernamen und seinem Passwort anmelden muss. 20

21 6.4.1 SQL Injection Code, der den Login durchführt: Language=VBScript %> <%... If Request.ServerVariables("CONTENT_LENGTH") > 0 Then strusername = Trim(Request.Form("UName")) strpassword = Trim(Request.Form("UPwd")) Set rs = Server.CreateObject("ADODB.Recordset") rs.open "select * from users where UserName='" & strusername &_ "' AND UserPassword='" & strpassword & "'"... End If %> Das dahinterliegende Skript konstruiert aus den Eingaben für das Passwort und den Benutzernamen eine SQL-Anfrage. 21

22 6.4.1 SQL Injection SQL String, wenn sich der Administrator mit admin / admin einloggt: select * from users where UserName='admin' AND UserPassword='admin' SQL String, wenn man sich mit ' OR '1'='1 und ' OR '1'='1 einloggt: select * from users where UserName='' OR '1'='1' AND UserPassword='' OR '1'='1' Gibt man nun für Benutzername und Passwort den String admin ein, so ergibt sich die erwartete SQL-Anfrage, bei der der UserName und das UserPassword auf admin geprüft werden. Gibt man jedoch für Benutzername und Passwort folgende Kombination ein: ' OR '1'='1 und ' OR '1'='1, so ergibt sich eine SQL-Anfrage, deren where-bedingung immer erfüllt ist und womit ohne das gültige Passwort auf Daten zugegriffen werden kann. 22

23 6.4.1 SQL Injection Weitere Angriffe sind möglich, um über Fehlermeldungen Informationen über das Datenbank-Schema zu erlangen. Problem bei SQL-Injection: Keine Überprüfung der Eingaben auf Quotes ( ) Gegenmaßnahme: Validieren der SQL-Statements auf ihre Gültigkeit. Das grundlegende Problem bei SQL-Injection ist die fehlende Filterung der Eingaben auf mögliche Quotes. Eine Gegenmaßnahme gegen SQL-Injection Angriffe liegt daher in der Validierung der SQL- Anfragen, bevor die SQL-Anfrage auf die Datenbank angewendet wird. 23

24 XACML = extensible Access Control Markup Language XML-basierter Standard zur Beschreibung von Zugriffsschutzpolitiken. Universelle Sprache für beliebige Werkzeige und Umgebungen (Interoperabilität). OASIS Spezifikation 1.1 (7.8.03) Existierende Implementierungen: Parthenon Computing SUN Lagash Systems: XACML.NET: Die extensible Access Control Markup Language (XACML) ist ein XML-basierter Standard der OASIS zur Beschreibung von Zugriffsschutzstrategien. Die XACML stellt eine universelle Sprache für Zugriffsschutzstrategien zur Verfügung, mit der Strategien für eine Vielzahl von Werkzeugen und Umgebungen beschrieben werden können. 24

25 Organization for the Advancement of Structured Information Standards (OASIS) 1993: SGML Open Konsortium zur Entwicklung von Interoperabilitäts-Richtlinien für Produkte, die die Standard Generalized Markup Language (SGML) unterstützen. 1998: OASIS Standards für Sicherheit (PKI, XACML), Web services, elektronisches Veröffentlichen, Interoperabilität in und zwischen elektronischen Marktplätzen etc. Die OASIS (Organization for the Advancement of Structured Information Standards) ist ein Konsortium, dass die Entwicklung weltweiter Standards für E-Business Anwendungen zum Ziel hat. Diese Standards betreffen Sicherheit, Web Services, elektronisches Veröffentlichen, Interoperabilität zwischen elektronischen Marktplätzen etc. Die Standards sollen helfen, dass Produkte verschiedener Hersteller miteinander interagieren können. OASIS ist aus der SGML Open entstanden, die sich mit der Entwicklung von Interoperabilitäts-Richtlinien bzgl. der Standard Generalized Markup Language (SGML) befasste. 25

26 XACML-Komponenten Policy Administration Point (PAP) Erstellt die Sicherheitsstrategie (security policy) und speichert diese in einem Repository. Policy Enforcement Point (PEP) Setzt dien Zugriffsschutz durch. Policy Information Point (PIP) Hält Informationen bereit, die zur Auswertung der Politik bzgl. einer Anfrage benutzt werden können. Policy Decision Point (PDP) Wertet die Politiken aus und bestimmt, ob der Zugriff der Anfrage erlaubt oder verboten ist. Die Folie zeigt und beschreibt kurz die wichtigsten Komponenten im XACML-Modell. 26

27 Ablauf einer Zugriffsschutzentscheidung für den Zugriff eines Subjekts auf eine Ressource: 1. PAPs schreiben Politiken und machen diese für den PDP verfügbar. 2. Das Subjekt (Access Requester) sendet eine Anfrage an den PEP. 3. Der PEP sendet die Anfrage an den Context Handler im Anfrage-Format weiter. Der PEP kann weitere Information hinzufügen (über Subjekt, Ressource oder Aktion). 4. Der Context Handler erstellt eine XACML-Anfrage, möglicherweise mittels weiterer Informationen vom PIP. Der Context Handler schickt die XACML-Anfrage an den PDP. Möchte ein Subjekt auf eine Ressource mittels einer bestimmten Aktion zugreifen, wird mittels des XACML-Modells der Zugriff entschieden. Der Ablauf dieser Zugriffsschutzentscheidung ist wie folgt. 1. Zunächst müssen PAPs Politiken schreiben, die sie dem PDP verfügbar machen. 2. Der Access Requester sendet eine Anfrage (z.b. eine CORBA-, J2EE- oder SOAP-Anfrage) zum Zugriff auf eine Ressource zum PEP. 3. Der PEP sendet diese Anfrage im ursprünglichen Format weiter zum Context Handler. Dabei können vom PEP neben der eigentlichen Anfrage weitere Information an den Context Handler geschickt werden, die das Subjekt, die auszuführende Aktion oder die Ressource näher beschreiben. 4. Der Context Handler erzeugt aus diesen Informationen eine XACML-Anfrage. Dazu können weitere Informationen zum Subjekt, der Ressource oder der Umgebung vom PIP angefordert werden. Der Context Handler schickt die XACML-Anfrage and den PDP. 27

28 5. Der PDP wertet die für die Anfrage anwendbaren Politiken aus. Sendet einen Antwort-Kontext (inklusive Zugriffsentscheidung) an den Context Handler. 6. Der Context Handler transformiert den Antwort-Kontext in das vom PEP benötigte Format und sendet ihn an den PEP. 7. PEP setzt die Antwort um (Zugriff erlaubt/verboten) 5. Der PDP identifiziert die anwendbaren Politiken und wertet die XACML-Anfrage bzgl. dieser Politiken aus. Der PDP gibt einen Antwort-Kontext inklusive der Zugriffsschutzentscheidung an den Context Handler zurück. 6. Der Context Handler transformiert den Antwort-Kontext in das Antwort-Format des PEP und sendet die Antwort an den PEP. 7. Der PEP setzt die Antwort um: Wenn der Zugriff erlaubt ist, erlaubt der PEP den Zugriff auf die Ressource. Ansonsten wird der Zugriff auf die Ressource abgelehnt. 28

29 Überblick 6.5 XACML setzt Zugriffsschutzentscheidung durch Access Requester Policy Decision Point (PDP) entscheidet Zugriff bzgl. Politik request Policy Enforcement permit (native) Point (PEP) access request + [subject + response (native) resource + action] decision request response Attribute für Subjekt, Ressource,Umgebung context handler erzeugt XACML Anfrage, Erzeugt Antwort Ressource Policy Administration Point (PAP) erstellt die Politik Policy Information Point (PIP) Enthält Informationen zu Attributen von Subjekten, Ressourcen, Aktionen, Umgebungen Diese Folie zeigt nochmals den gesamten Ablauf in einem Diagramm: Möchte ein Benutzer auf eine Ressource in einer bestimmten Weise zugreifen (z.b. ein Bankangestellter möchte sich ein Konto ansehen), so würde das System des Benutzers eine Anfrage zum Zugriff auf die Ressource stellen. Diese Anfrage würde vom Policy Enforcement Point (PEP) entgegengenommen. Der PEP erstellt dann seinerseits eine Anfrage basierend auf der Identität und den Attributen des Benutzers, der Aktion, die ausgeführt werden soll und möglicherweise weitere benötigte Informationen. Der PEP sendet diese Anfrage an den Context Handler, der die Anfrage des Client-Systems in eine XACML-Anfrage transformiert und an den Policy Decision Point weitersendet. Zur Konstruktion der XACML-Anfrage kann der Context Handler weitere Informationen vom Policy Information Point erfragen. Der PDP wertet die XACML-Anfrage auf Grundlage der anwendbaren Zugriffsschutzstrategien (die der PAP definiert hat) aus. Der PDP liefert eine Antwort an den Context Handler zurück, die entweder den Zugriff erlaubt oder verbietet. Der Context-Handler wandelt die XACML-Antwort in das ursprüngliche Anfrage-Format um und schickt es an den PEP. Der PEP setzt dann die Antwort durch. 29

30 Politik-Sprachmodell 0..1 Target * 1..* 1..* Subject Resource Action Condition Policy 1 1 Rule Combining Algorithm * Rule Effect Aus welchen Elementen eine Politik in XACML aufgebaut ist, zeigt das Klassendiagramm der Folie. Einer Politik (policy) ist ein Rule Combining Algorithm und eine Menge von Regeln (rule) zugeordnet. Jede Regel kann eine Bedingung (condition) haben, hat genau einen Effekt (effect) und möglicherweise ein Target. Ein Target kann aus einer Menge von Subjekten, Ressourcen oder Aktionen bestehen. Auch eine Politik kann einem Target zugeordnet werden. 30

31 Rule Beschreibt eine Zugriffsschutzregel. Besteht aus einen Target, einem Effect und einer Condition. Das Target einer Regel kann entfallen, wenn es mit dem Target der Policy übereinstimmt. Rule Target Menge von Ressourcen, Subjekten und Aktionen, auf die die Regel anwendbar ist. Falls anwendbar auf alle Entitäten eines Datentyps: <AnySubject/>, <AnyResource/> bzw. <AnyAction/> Regeln bestehen aus einem Target, einem Effect und möglicherweise einer Condition. Das Target einer Regel identifiziert die Ressourcen, Subjekte und/oder Aktionen, auf die die Regel anwendbar ist. Wenn die Regel zu allen Entitäten eine bestimmten Datentyps anwendbar ist, wird ein XML-Element <AnySubject/>, <AnyResource/> oder <AnyAction/> verwendet. Wenn die Regel kein Target hat, dann stimmt es mit dem Target der Policy überein. 31

32 Condition Funktion, die True, False oder Indeterminate zurückgibt. Bei Indeterminate liegen nicht genug Informationen für eine Entscheidung vor. Effect Wenn Rule-Condition True, wird entweder Permit oder Deny zurückgegeben. Ansonsten ist die Regel NotApplicable. Eine Condition ist eine Funktion, die entweder zu True, False oder Indeterminate ausgewertet wird. Indeterminate zeigt an, dass nicht genug Informationen vorlagen, um die Condition zu True oder False auszuwerten. Der Effect einer Regel ist entweder Permit oder Deny. 32

33 Policy Besteht aus Target, Rules und Rule-Combination Algorithmus. Policy Target Subjekte, Ressourcen und Aktionen, auf die die Politik angewendet werden soll. Kann explizit angegeben werden oder implizit aus den Rule-Targets berechnet werden. Eine Policy besteht aus einem Target, einer Menge von Regeln und einem Rule-Combination Algorithmus. Das Policy-Target spezifiziert die Subjekte, Ressourcen und Aktionen, auf die die Politik anwendbar ist. Die Target-Elemente der Politik können explizit angegeben werden oder anhand der Targets der Regeln der Policy berechnet werden. Jede Policy hat einen Rule-Combination Algorithmus zum Kombinieren der Politik-Regeln im Falle einer Zugriffsschutzentscheidung. Verschiedene von der Spezifikation vorgeschlagene Algorithmen zeigen die nächsten Folien. 33

34 Rule-Combination Alghoritmus Bestimmt, wie die Ergebnisse der Regelauswertung für die Auswertung der Politik ausgewertet werden. Deny-Overrides Wenn eine Regel in der Politik zu Deny ausgewertet wird, ist das Gesamtergebnis Deny. Wenn einige Regeln zu Permit ausgewertet werden und der Rest der Regeln zu NotApplicable, ist das Gesamtergebnis Permit. Sind alle Regeln NotApplicable, so ist die gesamte Politik NotApplicable. Der Deny-Overrides Algorithmus gibt Deny-Entscheidungen Priorität, d.h. wenn nur eine Regel der Politik den Zugriff verbietet, so ist die Gesamtzugriffsentscheidung ein Deny. Nur wenn keine der Regeln ein Deny liefert, kann es für das Gesamtergebnis ein Permit geben. Dazu muss allerdings mindestens eine der Regeln ein Permit liefern. Sind alle Regeln der Politik nicht anwendbar für die Zugriffsentscheidung, so ist auch die Politik nicht anwendbar. 34

35 Permit-Overrides Wenn eine Regel in der Politik zu Permit ausgewertet wird, ist das Gesamtergebnis Permit. Wenn einige Regeln zu Deny ausgewertet werden und der Rest der Regeln zu NotApplicable, ist das Gesamtergebnis Deny. Sind alle Regeln NotApplicable, so ist die gesamte Politik NotApplicable. Der Permit-Overrides Algorithmus gibt im Gegensatz zum Deny-Overrides Algorithmus einer Permit- Entscheidung Priorität. 35

36 First-applicable Regeln werden nach der Reihe ausgewertet, die durch die Politik gegeben ist. Sobald eine Regel anwendbar ist (d.h. Target ist identifiziert und Rule-Condition ist True), dann ist das Gesamtergebnis der Effect der Regel, d.h. entweder Permit oder Deny. Ist keine Regel anwendbar, so ist die Politik NotApplicable. Der Algorithmus First-Applicable läuft die Regeln der Politik der Reihe nach durch und sucht nach der ersten anwendbaren Regel. Die Auswertung dieser Regel (entweder Deny oder Permit) ist dann das Ergebnis der Zugriffsschutzentscheidung bzgl. der Politik. Falls keine der Regeln anwendbar sein sollte, ist die gesamte Politik nicht anwendbar. 36

37 Politiken können in einer PolicySet zusammengefasst werden. 1 Policy Set 1 0..* PolicySet besteht aus einer Menge von Policies, einem Target und einem Policy Combining Algorithmus. 1 Target Policy Combining Algorithm 1 0..* Policy Man kann mehrere Politiken auch zu einer PolicySet zusammenfassen. Diese Menge von Politiken wird dann ebenfalls einem Target zugeordnet und man muss einen Policy-Combining Algorithmus definieren, der die Zugriffsschutzergebnisse der einzelnen Politiken der PolicySet zu einem Gesamtergebnis kombiniert. Beispiele solcher Kombinierungsalgorithmen zeigen die nächsten Folien. Viele dieser Algorithmen sind analog zu den Algorithmen zum Kombinieren von Regeln. 37

38 Policy Combining Algorithmus Deny-Overrides eine Policy Deny => PolicySet Deny mindestens eine Policy Permit, Rest NotApplicable => PoliySet Permit Alle Policies sind NotApplicable => PoliySet NotApplicable Der Deny-Overrides Algorithmus gibt dem Deny einer Politik Priorität. 38

39 Permit-Overrides eine Policy Permit => PolicySet Permit mindestens eine Policy Deny, Rest NotApplicable => PoliySet Deny Alle Policies sind NotApplicable => PoliySet NotApplicable Der Permit-Overrides Algorithmus gibt dem Permit einer Politik Priorität. 39

40 First-applicable Auswertung der Policies nach Liste in der PolicySet Erste anwendbare Policy wird ausgewertet (Target ist anwendbar und Policy wertet zu Permit oder Deny aus) Ergebnis der Policy-Auswertung wird Ergbenis der PolicySet-Auswertung Ist keine Policy Anwendbar, ist die PolicySet NotApplicable. Der First-Applicable Algorithmus benutzt die erste anwendbare Politik zur Zugriffsschutzentscheidung. 40

41 Only-one-applicable Wenn keine Policy der PolicySet anwendbar ist, ist die PolicySet NotApplicable. Wenn mehr als eine Policy der PolicySet anwendbar ist, dann ist die PolicySet Indeterminate. Wenn genau eine Policy der PolicySet anwendbar ist, dann ist die Auswertung der PolicySet gegeben durch die Auswertung der einen Policy. Der Only-one-applicable Algorithmus betrachtet das Ergebnis einer anwendbaren Politik nur dann, wenn es die einzige anwendbare Politik der PolicySet ist. Ist keine Politik anwendbar, dann ist die PolicySet nicht anwendbar. Sind mehrere Politiken anwendbar, dann liefert die Auswertung der PolicySet Indeterminate. 41

42 Beispiel: Politik: Jeder Benutzer mit einer im medico.com Namensraum darf jede Aktion auf jeder Ressource durchführen. Abschließend noch ein Beispiel einer in XACML spezifizierten Politik und einer XACML-Anfrage. Die in natürlicher Sprache formulierte Politik zeigt die Folie. Sie gestattet jedem Benutzer mit einer E- Mail von medico.com jede Aktion auf jeder Ressource auszuführen. 42

43 Policy-Header 6.5 XACML <Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy" cs-xacml-schema-policy.xsd" PolicyId="identifier:example:SimplePolicy" RuleCombiningAlgId= "identifier:rule-combining-algorithm:deny-overrides"> <Description> Medi Corp access control policy </Description> Die XACML-Politik startet mit einem Header, in dem der Namensraum und die XACML-Version spezifiziert werden. Außerdem bekommt die Politik einen Namen und der Algorithmus zum Kombinieren der Regeln wird angegeben. In diesem Beispiel wird der Deny-overrides Algorithmus benutzt. Es kann noch eine Beschreibung der Politik hinzugefügt werden. 43

44 Politik-Target Politik ist anwendbar für jeden Benutzer, jede Ressource und jede Aktion <Target> <Subjects> <AnySubject/> </Subjects> <Resources> <AnyResource/> </Resources> <Actions> <AnyAction/> </Actions> </Target> Das PolicyTarget dieser Politik sind alle Subjekte, alle Ressourcen und alle Aktionen. Daher gibt es für die entsprechenden Einträge die Werte <AnySubject/>, <AnyRessource/>, <AnyAction/>. 44

45 Es gibt eine Regel in der Politik. Wenn die Regel anwendbar ist, dann liefert sie Permit. <Rule RuleId= "urn:oasis:names:tc:xacml:1.0:example:simplerule" Effect="Permit"> <Description> Any subject with an name in the medico.com domain can perform any action on any resource. </Description> In der Politik gibt es nur eine Regel, die Benutzern mit medico.com Zugriff auf alle Ressourcen und Aktionen erlaubt. Zunächst gibt man der Regel einen Namen und spezifiziert ihren Effekt. In diesem Beispiel ist der Effekt Permit, d.h. wenn die Regel anwendbar ist, liefert sie als Ergebnis Permit. Eine Beschreibung der Regel kann zusätzlich gegeben werden. 45

46 Rule-Target Alle Benutzer mit im medico.com Namensraum Wenn die Subjekte, Ressourcen und Aktionen der Anfrage nicht auf das Rule-Target zutreffen, ist die Regel für diese Anfrage NotApplicable. <Target> <Subject> <SubjectMatch MatchId=" function:name-match"> <SubjectAttributeDesignator AttributeId="subject:subject-id" DataType="datatype:Name"/> <AttributeValue DataType="datatype:Name"> medico.com </AttributeValue> </SubjectMatch> </Subject> Das Rule-Target spezifiziert die Subjekte, Ressourcen und Aktionen, auf die die Regel anwendbar sein soll. Es wird gefordert, dass die Regel auf alle Subjekte angewandt werden soll, die eine von medico.com besitzen. Dies wird im Rule-Target spezifiziert unter dem Element <Subject> spezifiziert. 46