6.4 Zugriffsschutz in Datenbanken

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
6.4 Zugriffsschutz in Datenbanken
Primärschlüssel
Beispiel:
Signatur
Bücher
ISBN30
ISBN32
Tupel
Autor
Titel
Grass
Heinz
BenutzerNr Name
Blechtrommel
Benutzer
Kochrezepte
Adresse
100
Fritz
Berlin
200
Anna
Hamburg
ISBN40
Attribute
Ausleihe
Buch
Leser
ISBN32
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
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
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
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.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
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
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
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
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
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
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
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
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
6.4 Zugriffsschutz in Datenbanken
Beispiel 1:
Owner:
Klaus:
Owner:
GRANT Update ON Movie TO Klaus
WITH GRANT OPTION;
GRANT Update ON Movie TO Anna;
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
6.4 Zugriffsschutz in Datenbanken
Beispiel 2:
Owner:
Klaus:
Owner:
GRANT Update ON Movie TO Klaus
WITH GRANT OPTION;
GRANT Update ON Movie TO Anna;
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 UpdatePrivileg 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
6.4 Zugriffsschutz in Datenbanken
Beispiel 3:
Owner:
Owner:
Klaus:
Owner:
GRANT Update ON Movie TO Klaus
WITH GRANT OPTION;
GRANT Update ON Movie TO Anna;
GRANT Update ON Movie TO Anna;
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
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.
Rollenhierarchie:
Rolle A
Rolle B
Rolle C
Rolle D
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
6.4 Zugriffsschutz in Datenbanken
Operationshierarchie:
UPDATE-Privileg beinhaltet
SELECT- und
DELETE-Privileg.
UPDATE
SELECT
DELETE
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
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 WebSchnittstelle, bei der man sich mit seinem Benutzernamen und seinem Passwort anmelden muss.
20
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
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
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 SQLAnfragen, bevor die SQL-Anfrage auf die Datenbank angewendet wird.
23
6.5 XACML
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 http://www.parthenoncomputing.com
SUN http://sunxacml.sourceforge.net
Lagash Systems: XACML.NET: http://mvpos.sourceforge.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
6.5 XACML
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.
http://www.oasis-open.org
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
6.5 XACML
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
6.5 XACML
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
6.5 XACML
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
6.5 XACML
Überblick
setzt Zugriffsschutzentscheidung durch
Policy Enforcement
Point (PEP)
request
(native)
Access Requester
request + [subject +
resource + action]
decision request
Policy Decision
Point (PDP)
entscheidet
Zugriff
bzgl. Politik
response
context
handler
permit
access
Ressource
response (native)
erzeugt XACML
Anfrage,
Erzeugt Antwort
Attribute für Subjekt,
Ressource,Umgebung
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
6.5 XACML
Politik-Sprachmodell
Policy
Target
1..*
Subject
1 1
1..*
0..1
1
1
0..1
1
Resource
1..*
Action
Rule Combining
Algorithm
1
1
0..*
Rule
1
1
Condition 0..1
1
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
6.5 XACML
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
6.5 XACML
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
6.5 XACML
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
6.5 XACML
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
6.5 XACML
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 PermitEntscheidung Priorität.
35
6.5 XACML
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
6.5 XACML
Politiken können in einer
PolicySet zusammengefasst
werden.
1
Policy Set
0..*
1
PolicySet besteht aus einer
Menge von Policies, einem
Target und einem Policy
Combining Algorithmus.
1
1
Policy Combining
Algorithm
1
1
Target
0..1
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
6.5 XACML
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
6.5 XACML
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
6.5 XACML
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
6.5 XACML
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
6.5 XACML
Beispiel:
Politik: Jeder Benutzer mit einer E-Mail 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 EMail von medico.com jede Aktion auf jeder Ressource auszuführen.
42
6.5 XACML
Policy-Header
<Policy xmlns="urn:oasis:names:tc:xacml:1.0:policy"
http://www.oasis-open.org/tc/xacml/1.0/
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
6.5 XACML
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
6.5 XACML
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 e-mail 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 E-Mail 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
6.5 XACML
Rule-Target Alle Benutzer mit E-Mail 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 E-Mail von
medico.com besitzen. Dies wird im Rule-Target spezifiziert unter dem Element <Subject> spezifiziert.
46
6.5 XACML
Regel soll anwendbar sein auf alle Ressourcen und alle
Aktionen.
<Resources> <AnyResource/> </Resources>
<Actions> <AnyAction/> </Actions>
</Target>
</Rule>
</Policy>
Da die Regel für alle Ressourcen und Aktionen gilt, gibt es für die Einträge der Elemente <Ressources>
und <Actions> die Werte <AnySubject/> und <AnyAction/>.
47
6.5 XACML
XACML-Anfrage:
Bart Simpson, mit E-Mail "[email protected]", will seine
medizinische Akte bei Medi Corp. lesen.
<Request xmlns="urn:oasis:names:tc:xacml:1.0:context"
http://www.oasis-open.org/tc/xacml/1.0/cs-xacml-schema-context-01.xsd">
<Subject>
<Attribute AttributeId="subject:subjectid"
DataType="data-type:Name">
<AttributeValue> [email protected] </AttributeValue>
</Attribute>
</Subject>
Können mehrere Subjekte und Attribute sein.
Wir betrachten nun eine Anfrage, für die der Zugriffsschutz bzgl. der XACML-Politik der vorigen
Folien entschieden werden soll. Die Anfrage stammt von Bart Simpson mit der E-Mail
[email protected]. Er möchte auf seine Akte bei der Medi Corp. Lesend zugreifen. Die XACMLAnfrage muss diese Information über Subject (Bart Simpson mit E-Mail [email protected]), über
Ressource (Akte bei Medi Corp) und die Aktion (lesen) enthalten. Das <Subject>-Element der
XACML-Anfrage spezifiziert daher, dass der Anfragende die E-Mail [email protected] besitzt. In
einer XACML-Anfrage können mehrere Subjekte definiert werden.
48
6.5 XACML
Ressource, auf die das Subjekt (bzw. die Subjekte)
zugreifen wollen.
Es kann nur eine Ressource pro Anfrage angegeben werden.
<Resource>
<Attribute AttributeId="resource:ufspath"
DataType="http://www.w3.org/2001/XMLSchema#anyURI">
<AttributeValue>
/medico/record/patient/BartSimpson
</AttributeValue>
</Attribute>
</Resource>
Das Element <Ressource> spezifiziert die Ressource, auf die das Subjekt eine Aktion
ausführen will. Im Beispiel ist das die Datei /medico/record/patient/BartSimpson. Pro
XACML-Anfrage kann es immer nur einen <Ressource>-Eintrag geben.
49
6.5 XACML
Aktion, die das Subjekt (bzw. die Subjekte) auf der
Ressource durchführen will.
Es kann nur eine Aktion pro Anfrage angegeben werden.
<Action>
<Attribute AttributeId="action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue> read </AttributeValue>
</Attribute>
</Action>
</Request>
Im <Action>-Element wird die gewünschte Aktion spezifiziert. In diesem Beispiel ist die Aktion read,
da die Akte von Bart gelesen werden soll. Wie bei Ressourcen, kann es auch bei Aktionen nur einen
Eintrag pro XACML-Anfrage geben.
50
6.5 XACML
Der Prozess Decision Point (PDP) erhält den Anfrage Kontext und
sucht nach anwendbaren Policies.
Dazu wird das Subject, Ressource und Aktion der Anfrage mit dem
Subjekt, Ressource und Aktion des Policy verglichen.
Im Beispiel:
Policy-Ressource <AnySubject/> beinhaltet Anfrage-Ressource.
Policy-Aktion <AnyAction/> beinhaltet Anfrage-Aktion.
Policy-Subject *@medico.com betrifft nicht das AnfrageSubjekt [email protected]
 Regel nicht anwendbar für diese Anfrage
Wird diese XACML-Anfrage nun vom PDP des XACML-Systems bzgl. der XACML-Politik
ausgewertet, wird zunächst entschieden, ob die Politik für die Anfrage anwendbar ist. Dies ist der Fall,
da das PolicyTarget alle Subjekte, Ressourcen und Aktionen betrifft. Dann werden die Regeln der
Politik auf ihre Anwendbarkeit bzgl. der XACML-Anfrage untersucht. Die einzige Regel der Politik
war anwendbar für alle Ressourcen und Aktionen, jedoch nur für Subjekte mit einer E-Mail bei
medico.com. Da das Subjekt der Anfrage jedoch die E-Mail [email protected] hat, ist die Regel bzgl.
Der Anfrage nicht anwendbar. Da dies die einzige Regel der Politik ist, ist damit auch die gesamte
Politik nicht anwendbar (nach Definition des Rule-Combining Algorithmus deny-overrides).
51
6.5 XACML
Erstellen der Antwort
Rule Combining Algorithmus: Deny-overrides
 Policy-Auswertung ergibt NotApplicable
<Response xmlns="urn:oasis:names:tc:xacml:1.0:context"
http://www.oasis-open.org/tc/xacml/1.0/cs-xacml-schema-context-.xsd">
<Result>
<Decision> NotApplicable </Decision>
</Result>
</Response>
Der PDP erstellt daher eine Antwort mit NotApplicable für die Zugriffsentscheidung.
52