Autorisierungs- und Zugriﬀskontrollmechanismen fur ...In Kapitel 4 wird auf die...

Seminar”Aktuelle Herausforderungen an

Datenschutz und Datensicherheit in modernen

Informationssystemen“ im Sommersemester 2007

am IPD, Universitat Karlsruhe

Autorisierungs- undZugriffskontrollmechanismenfur Kontexte in WfMSvon Selma Mukhtar

Inhaltsverzeichnis

1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Begrifflichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Beispiel Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Zugriffskontrollanforderungen fur Workflow-Systeme . . . . . . . . . . . . . . . . 53.1 Order of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Strict least Privilege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Separation of duty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4 Kontextberucksichtigungen in Zugriffskontrollmechanismen . . . . . . . . . . 64.1 Rollenbasierte Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64.2 Task-basierte Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74.3 Team-basierte Zugriffskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5 Kontext-sensitive Zugriffskontrollmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . 95.1 CoSAWoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.2 WAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.3 Modell von Bertino, Ferrari und Atluri . . . . . . . . . . . . . . . . . . . . . . . 12

6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13A Task-Bearbeitungsablauf in CoSAWoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13B Objekt-Design in CoSAWoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Autorisierungs- und Zugriffskontrollmechanismen fur Kontexte in WfMS 3

1 Einleitung

Benutzer eines Workflow-Management-Systems sind meist die Angestellten ei-ner Organisation und daher menschlich. Uberall, wo Menschen beteiligt sind, istmit Fehlern aufgrund eines Versehens oder gar mit Betrug zu rechnen. Fehlersind jedoch nur moglich, wenn Zugriffsrechte auf geschutzte Informationen falschgenutzt werden. Daher sollten Zugriffsrechte nur gewahrt werden, wenn sie unbe-dingt von den entsprechenden Angestellten zum Erledigen ihrer Arbeit benotigtwerden.Der Zugriff, der einem bestimmten Angestellten auf eine bestimmte Informationgewahrt wird, verandert sich abhangig vom Kontext dieser Information in derOrganisation. Beispielsweise ist der Zugriff auf eine Bestellung vor deren Geneh-migung anders als danach.Daher ist es wichtig, den Kontext der tatsachlich zu verrichtenden Arbeit beider Entscheidung, ob ein Zugriff gewahrt wird oder nicht, zu berucksichtigen.

Mit der Kontext-Sensitivitat von Zugriffskontrollmechanismen in Workflow-Management-Systemen befasst sich diese Arbeit, die im Rahmen des Seminars

”Aktuelle Herausforderungen an Datenschutz und Datensicherheit in modernenInformationssystemen“ am Institut fur Programmstrukturen und Datenorgani-sation (IPD) der Universitat Karlsruhe im Sommersemester 2007 entstanden ist.

In Kapitel 2 werden einige Begrifflichkeiten im Zusammenhang mit Workflowserlautert und anschließend ein Beispiel-Workflow, bei dem es um die Einreichungeines Schadensfalls bei einer Versicherung geht, vorgestellt. Dieses Beispiel wirdim Laufe dieser Arbeit genutzt, um bestimmte Sachverhalte zu veranschaulichen.Kapitel 3 beinhaltet einige Anforderungen an Kontext-sensitive Zugriffskontrolle.In Kapitel 4 wird auf die Kontextberucksichtigungen in Zugriffskontrollmecha-nismen eingegangen. Zum Schluss werden in Kapitel 5 drei kontext-sensitiveZugriffskontrollmodelle vorgestellt.

2 Workflows

2.1 Begrifflichkeiten

Ein Workflow ist eine vordefinierte Abfolge von Aktivitaten in einer Organisati-on. Das Ziel ist dabei eine (Teil-)Automatisierung der Ausfuhrung. Ein Workflowwird von einem Workflow-Management-System gesteuert.Ein Workflow-Management umfasst die Modellierung, Spezifikation, Simulation,Ausfuhrung und Steuerung im Zusammenhang mit Workflows. Ein Workflow-Management-System ist ein (re-)aktives Basis-Software-System. Es steuert dieAusfuhrung eines Workflows und unterstutzt die Entwicklung von Workflow-Management-Anwendungen.Eine Task bezeichnet die kleinste Einheit von Arbeit, die verrichtet werdenmuss, um ein bestimmtes Geschaftsziel zu erreichen. Sie wird durch eine Task-Definition genau festgelegt. Diese bestimmt, welche Arbeit auf welchen Objekten

4 Autorisierungs- und Zugriffskontrollmechanismen fur Kontexte in WfMS

durch welche Benutzer gemacht werden muss.Ein Geschaftsprozess ist eine Folge von Schritten, um ein Geschaftsresultat zuerzielen. Eine Prozess-Definition ist eine Ansammlung von Tasks.

2.2 Beispiel Workflow

Im Folgenden wird das Workflow-Beispiel aus [1] zur besseren Veranschaulichungverwendet. Bei diesem Beispiel handelt es sich um die Einreichung eines Schadens-falls bei einer Versicherung. In Abb. 1 ist die entsprechende Prozess-Definitiondargestellt. Dieser Prozess besteht insgesamt aus zehn verschiedenen Tasks, wo-

Abbildung 1. Prozess-Definition”Schadensfalleinreichung bei einer Versicherung“ [1]

bei bei der ersten Task der gesamte Prozess initialisiert und ein Dokument na-mens ”Schadensfall-Ablaufplan“ erzeugt wird. Dieses Dokument kann aus wei-teren Dokumenten bestehen wie beispielsweise einem Kostenvoranschlag odereinem Unfallbericht. Die zu dieser Task dazugehorige Rolle ist der Sachbearbei-ter. Ein Inhaber dieser Rolle darf die erste Task ausfuhren.Nachdem die erste Task ausgefuhrt wurde, folgen Task 2 und Task 6. Task 2 isteine automatische Entscheidung, die durch das System getroffen wird und aufWorkflow-Kontrolldaten basiert. In diesem Fall sind die Workflow-Kontrolldatender Wert des Schadens. Dieser wurde wahrend der Ausfuhrung von Task 1 erfasst.Bei Task 6 handelt es sich um die Vervollstandigung des Schadensgutachterbe-richts.Route 2-7 und Route 3-4 sind Beispiele fur Geschaftsregeln. Diese legen die Bedin-gungen fur die auszufuhrenden Tasks fest. Beispielsweise wird Route 2-7 genom-men, wenn der Wert des Schadens 5000 nicht ubertrifft. Analog wird Route 3-4genommen, wenn der Versicherungstyp einer Fahrzeugversicherung entspricht.Alle weiteren Tasks und Regeln von Abb.1 folgen dem gleichen Grundsatz.Benutzer kommunizieren mit einem Workflow-System uber eine Worklist. Ein


Work-Item ist eine Task-Instanz, die einem Benutzer durch die Workflow-Enginezugewiesen wird. Die Worklist eines Managers wurde im Beispiel aus Abb.1 eineListe aller Schadensfalle enthalten, die genehmigt werden mussen.Es werden viele Prozess-Instanzen von derselben Prozess-Definition instanzi-iert. Aus der Prozess-Definition im Beispiel werden Prozess-Instanzen fur je-den Schadensfall, der eingereicht wurde, erzeugt. Jede Prozess-Instanz erzeugtdann eine Task-Instanz basierend auf den Task-Definitionen in der betreffendenProzess-Definition. Prozess- und Task-Instanzen nutzen entsprechende Workflow-Kontrolldaten, wie z.B. den Wert des Schadens, um die Regeln in der Prozess-Definition zu schatzen.

3 Zugriffskontrollanforderungen fur Workflow-Systeme

In diesem Abschnitt werden drei Anforderungen an kontext-sensitive Zugriffskon-trolle vorgestellt, die in [1] als essentiell dargestellt werden. Die Anforderungensind ”Order of events“, ”Strict least Privilege“ und ”Separation of duty“.

3.1 Order of events

Das Grundprinzip von ”Order of events“ besteht darin, dass das Gewahrenvon bestimmten Zugriffsrechten von der erfolgreichen Beendigung anderer Tasksabhangt. Im vorgestellten Beispiel kann ein Schadensfall nicht anerkannt werden,wenn nicht das Kundenprofil vervollstandigt wurde. Der Mechanismus sollte da-her in der Lage sein zu erkennen, an welchem Punkt er bei der Bearbeitung desSchadensfalls angelangt ist.

3.2 Strict least Privilege

”Strict least Privilege“ baut auf dem ”Least Privilege“-Prinzip auf. Dabei be-kommt ein Benutzer die minimalen Rechte, die notig sind, damit er seine Arbeitverrichten kann. D.h., er bekommt nur Rechte auf Tasks, die er zu irgendeinemZeitpunkt wahrend seiner Arbeit ausfuhren muss. Die Tatsache, dass manche die-ser Rechte fur viele Tasks, die ein Benutzer taglich ausfuhren muss, uberflussigsind, wird bei dem ”Strict least Privilege“-Prinzip berucksichtigt. Dabei werdendie gewahrten Rechte weiter eingeschrankt. Ein Benutzer erhalt nur die mini-malen Rechte, die er zu einem bestimmten Zeitpunkt fur eine bestimmte Taskbenotigt.Im vorgestellten Beispiel sollte ein Manager, der den Schadensfall-Ablaufplaninitialisiert, nur die Sachbearbeiterrechte erhalten, die notig sind, um die Taskauszufuhren, nicht aber die Rechte, um den Schadensfall zu genehmigen oder zuverweigern.

3.3 Separation of duty

”Separation of duty“ verlangt zwei oder mehr verschiedene Personen, die fur denAbschluss eines Geschaftsprozesses verantwortlich sind. Dadurch soll ein Betrug


erschwert werden, da fur einen Betrug in diesem Fall eine Verschworung notigware, bei der die Betruger ein erhohtes Risiko eingehen wurden. Im Beispiel soll-ten Schadensgutachter und Manager disjunkte Rechte haben. Beide sind lautProzess-Definition beteiligt. ”Separation of duty“-Anforderungen werden haufigals Geschaftsregeln formuliert, z.B. ”Ein Scheck benotigt zwei verschiedene Un-terschriften“.

4 Kontextberucksichtigungen inZugriffskontrollmechanismen

In diesem Abschnitt werden die Zugriffskontrollmechanismen RBAC, TBAC undTMAC und deren Kontext-Sensitivitat beschrieben.

4.1 Rollenbasierte Zugriffskontrolle

Das Prinzip der rollenbasierten Zugriffskontrolle (kurz: RBAC) ist in Abb. 2dargestellt. Es besteht aus Benutzern, Rollen, Sessions und Zugriffsrechten. Da-

Abbildung 2. RBAC [1]

bei werden Benutzern Rollen durch eine Benutzer-Rollen-Zuweisungsrelationzugewiesen. Die Zugriffsrechte, die in Verbindung mit einer Rolle stehen, wer-den in der Rollen-Zugriffsrechte-Zuweisungsrelation wiedergegeben. Die Zugriffs-rechteabstraktion wird in diesem Modell als die fur ein Objekt verfugbarenMethoden wiedergegeben. Im Beispiel konnte ein Benutzer das Recht erhal-ten, die ”Schadensfall-Genehmigen“-Methode fur ein ”Schadensfall-Formular“-Objekt auszufuhren.Ein Benutzer erhalt die Zugriffsrechte verbunden mit den Rollen, die er fur eineSession einnimmt. Eine Session ist ein zeitgebundenes Konstrukt, um Benutzer,Rollen und Zugriffsrechte miteinander zu verbinden.Rollen sind in einer Rollenhierarchie untereinander partiell geordnet. Rollen er-ben die Rechte derjenigen Rollen, die in der partiellen Ordnung kleiner sind als


sie selbst. Abb. 3 zeigt ein Beispiel einer Rollenhierarchie. Rolle r1 ist den Rollen

Abbildung 3. Rollenhierarchie [1]

r2 und r3 dabei ubergeordnet. Die sind wiederum r4 ubergeordnet. r1 erbt dieRechte, die mit r2 und r3 verbunden sind. r1 und r5 stehen durch die Rollenhier-archie nicht miteinander in Verbindung.RBAC unterstutzt Prinzipien wie ”Separation of duty“ oder ”least Privilege“,erzwingt sie aber nicht. ”Separation of duty“ kann erreicht werden, indem dieMitgliedschaft zweier Rollen sich gegenseitig ausschließt.

”Least Privilege“ wird durch RBAC unterstutzt, da es einem Benutzer erlaubt,eine Rolle einzunehmen, die weniger Rechte hat, als er bekommen konnte.

4.2 Task-basierte Zugriffskontrolle

Thomas und Sandhu beschreiben in [6], [7] und [8] ein Task-basiertes Zugriffs-kontrollmodell (TBAC). Bei diesem Zugriffsmodell stehen die Tasks im Mittel-punkt, im Gegensatz zur herkommlichen Benutzer-Objekt-Sichtweise. Im Unter-schied zu RBAC berucksichtigt TBAC die kontextuelle Information uber laufen-de Tasks.In TBAC besteht eine Task auf einer hoheren Ebene aus mehreren Untertasksmit einer Vielzahl von Abhangigkeiten zwischen den Tasks. Diese Abhangigkeitenlegen fest, ob ein bestimmtes Zugriffsrecht tatsachlich gewahrt wird. Dies spie-gelt die Idee eines Geschaftsprozesses wider, der aus einem Tasknetzwerk besteht,indem die Tasks gemaß bestimmter Geschaftsregeln miteinander verbunden sind.Der Geschaftsprozess entspricht einer Task auf einer hoheren Ebene, die mehre-re Tasks benotigt, um ausgefuhrt zu werden. Die Geschaftsregeln zwischen denTasks entsprechen den Abhangigkeiten zwischen Tasks, beispielsweise kann einSchadensfall nicht anerkannt werden, wenn nicht der Schadensgutachterberichtvervollstandigt wurde.Die Basis fur die Modellierung der Zugriffskontrolle in TBAC bilden Autori-

sierungsschritte (”Authorization Steps“). Dabei werden die Eigenschaften vonTasks naher betrachtet. Ein Autorisierungsschritt funktioniert analog zur Bewil-ligung einer Unterschrift in der Papierwelt. Solch ein Autorisierungsschritte ist inAbb. 4 dargestellt. Damit ist eine Menge von Bevollmachtigten (”Trustee-Set“)verbunden. Ein Mitglied dieser Menge von Bevollmachtigten wird irgendwanneinmal den Autorisierungsschritt bewilligen, wenn dieser instanziiert wurde. Die-ser Bevollmachtigte wird Ausfuhrungsbevollmachtigter (”Executor trustee“) des


Abbildung 4. Autorisierungsschritt [8]

entsprechenden Schrittes genannt. Die Menge der Rechte des Ausfuhrungsbe-vollmachtigten (”Executor Permissions“) sind die Zugriffsrechte, die der Aus-fuhrungsbevollmachtigte benotigt, um den Autorisierungsschritt aufzurufen undzu bewilligen. In der Papierwelt impliziert eine Unterschrift unter etwas, dassbestimmte Rechte bewilligt wurden. Analog dazu gibt es in TBAC eine Mengean Zugriffsrechten, die durch jeden Autorisierungsschritt bewilligt werden. Diesist die Menge der freigegebenen Rechte (”Enabled Permissions“). Ein Schutzzu-stand (”Protection State“) ist die Vereinigung der Rechte des Ausfuhrungsbevoll-machtigten und der freigegebenen Rechte eines Autorisierungsschritts. Genausowie Befugnisse, die durch eine Unterschrift bewilligt werden, nur fur eine be-schrankte Zeit gultig sind, wird in TBAC eine Gultigkeitsperiode und ein Le-benszyklus mit jedem Autorisierungsschritt verbunden.In TBAC ([7]) werden Konflikte zwischen Tasks als eine wichtige Art und Weiseerkannt, um ”Separation of duty“ zum Ausdruck zu bringen.

4.3 Team-basierte Zugriffskontrolle

In [5] wird ein weiterer Zugriffskontrollmechanismus vorgestellt, der Team-basiertist und Kontexte benutzt. C-TMAC basiert auf der Integration von RBAC undTBAC. Das Prinzip von C-TMAC ist in Abb. 5 dargestellt. C-TMAC bestehtaus den funf verschiedenen Entitatenmengen Benutzer, Rollen, Teams, Kontex-te und Zugriffsrechte und aus einer Menge von Sessions. Ein Benutzer stehtwahrend der gesamten Lebenszeit einer Session in Verbindung mit dieser Sessi-on. Der Kontext enthalt Informationen bezuglich der benotigten Datenobjektefur eine bestimmte Task und kontextuelle Informationen bezuglich Speicherstel-len und Zeitintervalle etc. Die Team-Entitat wird genutzt, um eine Gruppe vonBenutzern in bestimmten Rollen zu reprasentieren, die das Ziel verfolgen, einebestimmte Task in einem bestimmten Kontext auszufuhren. Wahrend einer Ses-sion kann ein Benutzer an einer Vielzahl von Teams teilnehmen. Jede Session


Abbildung 5. C-TMAC [5]

ist also eine Abbildung eines Benutzers auf eine Untermenge von Teams, denener angehort. Die Kontexte, die ein Benutzer nutzen kann, sind die Vereinigungaller Kontexte derjenigen Teams, bei denen er Mitglied ist.Die Zugriffskontrolle unter der Benutzung von kontextueller Information wieZeitintervalle auf bestimmte Objekte geschieht wie folgt. Wahrend der Log-in-Phase muss ein Benutzer das Identifikations- und Autorisierungsprozedere ver-vollstandigen und passende Berechtigungsnachweise vorzeigen wie beispielsweiseBenutzer-ID und Passwort. Danach muss der Benutzer eine Untermenge vonRollen auswahlen von der Menge an Rollen, die ihm zugewiesen wurden. Gemaßdieser Auswahl wird eine bestimmte Menge von Rollen-basierten Zugriffsrechtenbewilligt (genannt: Session-Rollen-Zugriffsrechte).Nach der Rollenauswahl muss der Benutzer eine Untermenge von Teams auswahlen.Nach der Vervollstandigung der Teamauswahl wird die Zugriffsrechtemenge desBenutzers mit der Zugriffsrechtemenge des Teams kombiniert.Da Teams als Gruppen von aktuellen Task-Kontexten gesehen werden konnen,bedeutet das, wenn ein Benutzer Mitglied eines Teams ist, erlangt er auch denKontext seiner Task. Der Team-Kontext wird in Form von Wertebereichen aus-gedruckt. Fur jedes Team gibt es eine Vielzahl von Systemvariablen, die Werte-mengen fur die ausgewahlten kontextuellen Informationen enthalten.Die endgultige Zugriffsrechtemenge von einem Benutzer wird gefiltert unter Be-nutzung des aktuellen Kontexts von seinem Team. Samtliche darauffolgendenBenutzerzugriffsanfragen werden nur gestattet, wenn die benotigten rollenbasier-ten Zugriffsrechte bereits bewilligt wurden und nur wenn sich die aktuellen Werteder Kontextvariablen innerhalb des Intervalls des Team-Kontexts befinden.

5 Kontext-sensitive Zugriffskontrollmodelle

In diesem Abschnitt werden die Kontext-sensitiven Zugriffskontrollmodelle Co-SAWoE, WAM und das Modell von Bertino, Ferrari und Atluri vorgestellt.


5.1 CoSAWoE

CoSAWoE ist ein Kontext-sensitives Zugriffskontrollmodell entwickelt von Rein-hardt Botha in [1], das auf RBAC aufbaut. Dieses Modell ist sehr stark ablauf-orientiert und geht auf den Task-Kontext ein, d.h., es berucksichtigt die zeitlicheReihenfolge der Abarbeitung und den Zusammenhang der Tasks untereinander.In Abb. 6 ist das Grundprinzip von CoSAWoE dargestellt. Der Kontext der

Abbildung 6. CoSAWoE [1]

Arbeit wird bestimmt durch die Prozess-Definition. Eine Prozess-Definition be-steht aus mehreren Task-Definitionen, die gemaß eines Task-Netzwerks angeord-net sind. Die Bedingungen, die die zu verfolgende Route bestimmen, sind Teildes Task-Netzwerks. Die Rolle, die dazu geeignet ist, eine bestimmte Task aus-zufuhren, wird durch die Task-Rollen-Zuweisungsrelation bestimmt. Die Prozess-Instanz-Relation behalt die Ubersicht uber alle instanziierten Prozesse und dieTask-Instanz-Relation behalt die Ubersicht uber alle Task-Instanzen. Das Task-Instanz-Netzwerk verbindet die Task-Instanzen ahnlich wie das Task-Netzwerkdie Task-Definitionen kombiniert.

”Separation of duty“ wird mithilfe einer Konflikt-Task-Menge in diesem Modellimplementiert. Wenn zwei Tasks zur Konflikt-Task-Menge gehoren, dann mussensie durch verschiedene Benutzer ausgefuhrt werden.Das spezielle Konzept der Session-Kontrolle bei CoSAWoE ist in Abb. 7 dar-gestellt. Herkommliche Sessions zeigen die verstrichene Zeit vom Einloggen desBenutzers beim Server bis zu seinem Ausloggen an. In CoSAWoE wird eine Ses-sion fur nur eine einzige Task benutzt. Authentifiziert sich ein Benutzer einmalgegenuber dem System, erhalt er noch keine Rechte. Wenn ein Benutzer an ei-nem Workitem in der Worklist arbeitet, wird eine Workflow-Session errichtetund der Benutzer erhalt die angemessenen Rechte. Sobald der Benutzer aufhort,an der bestimmten Task zu arbeiten, wird die Workflow-Session geschlossen undalle damit verbundenen Rechte werden entzogen. Eine Session wird daher ge-nutzt, um die Rechte eines Benutzers fur die Dauer der Arbeit an einer Task zu


Abbildung 7. Session-Kontrolle in CoSAWoE [1]

kontrollieren. CoSAWoE erfullt daher die ”Strict least Privilege“-Anforderung.Eine Session steht in Verbindung zu einer einzigen Rolle.

5.2 WAM

Das ”Workflow Authorization Model“ (WAM) ist ein Zugriffskontrollmodell, dasvon Atluri und Huang in [2] entwickelt wurde. In diesem Modell wird Benutzernnur wahrend der Ausfuhrung einer Task Zugriff auf Objekte gewahrt. Es wirdein ”Authorization Template“ mit jeder Task verbunden. Dabei wird mithilfeeines gefarbten und zeitgesteuerten Petri-Netzes gezeigt, wie das Gewahren undEntziehen von Zugriffsrechten synchronisiert werden kann.Dieses Petri-Netz ist wie folgt aufgebaut:Die Stellen des Petri-Netzes sind aufgeteilt in Stellen, die Tasks, und Stellen,die Benutzer reprasentieren. Bei zwei aufeinanderfolgenden Tasks t1 und t2 gibtes drei verschiedene Zustande: ”t1 wird gerade ausgefuhrt“, ”t1 wurde beendet,aber t2 noch nicht angefangen“ und ”t2 wird gerade ausgefuhrt“.Transitionen zeigen den Anfang und das Ende einer Task an.Da es zwei verschiedene Arten von Stellen gibt, gibt es auch vier verschiedenegerichtete Kanten, die die Stellen und Transitionen verbinden.

– Kanten, die Transitionen und Task-Stellen verbinden, reprasentieren die ver-schiedenen Arten von Input-Objekten fur eine Task.

– Kanten, die Transitionen und Benutzer-Stellen verbinden, reprasentieren dieverschiedenen Privilegien, die gewahrt werden, wenn eine Task startet.

– Kanten, die Task-Stellen und Transitionen verbinden, reprasentieren denTyp der Output-Objekte fur eine Task.

– Kanten, die Benutzer-Stellen und Transitionen verbinden, reprasentieren diePrivilegien, die entzogen werden, sobald eine Task endet.


Gefarbte Token reprasentieren die verschiedenen Objekt-Privileg-Paare und dieverschiedenen Objekte. Des Weiteren gibt es noch Zeitlimits fur Tasks. Diese wer-den durch weitere Vorbedingungen fur das Feuern einer Transition ausgedruckt.Benutzer erhalten die Rechte, die durch die Tokens in den Benutzer-Stellen aus-gedruckt werden, nur, solange die Tokens vorhanden sind.

”Order of events“ ist das Hauptanliegen des WAM-Modells. WAM beachtet, dasssich Zugriffsrechte verandern, sobald bestimmte Tasks beendet wurden. Zugriffs-rechte sind mithilfe eines Autorisierungsprofils direkt mit einer Task verbunden.Dass Zugriffsrechte basierend auf einem Authorisierungsprofil direkt mit einerTask verbunden sind, impliziert, dass ”Strict Least privilege“ durch das Autori-sierungsprofil von WAM unterstutzt wird. WAM erkennt jedoch nicht, dass eineTask zu willkurlichen Zeiten eingestellt werden kann. Daher trifft WAM keineMaßnahmen dafur, Zugriffsrechte wahrend inaktiver Phasen wieder zu entziehen.In [4] stellen Huang und Atluri ein Web-basiertes Workflow-Management-Systemnamens ”SecureFlow“ vor, das auf WAM aufbaut. Innerhalb dieses ”Secure-Flow“ kann ”Separation of duty“ mithilfe von ”Authorization Templates“ aus-gedruckt werden. Da ”Authorization Templates“ mit Tasks verbunden sind, be-schrankt sich ”Separation of duty“ bei diesem Modell auf Tasks. Es besteht keineMoglichkeit ”Separation of duty“ fur Benutzerrollen zu erzwingen.

5.3 Modell von Bertino, Ferrari und Atluri

Das letzte hier vorgestellte Zugriffkontrollmodell stammt von Bertino, Ferra-ri und Atluri in [3]. Es handelt sich dabei um ein Bedingungs-Analyse- und -Durchsetzungsmodell, das mit dem Workflow-System zusammenwirkt, um Benutzer-Rollen-Zuweisungen fur jede Task zu bestimmen.In diesem Modell ist eine Task mit einer Menge von Rollen verbunden, die dieseTask ausfuhren durfen. Die Rollen sind untereinander global geordnet, ahnlichwie bei der Rollenhierarchie in RBAC. Rollen, die mit derselben Task in Verbin-dung stehen und nicht untereinander global geordnet sind, konnen lokal geordnetsein. Diese lokale Ordnung bestimmt die Ordnung der bevorzugten Rollen, umdiese Task auszufuhren. Diese lokale Ordnung bezieht sich lediglich auf eine Task.In diesem Modell gibt es eine logische Sprache, um Zugriffskontrollbedingungenals Klauseln auszudrucken. Diese Sprache wird intern zur Analyse und Durch-setzung von Bedingungen genutzt.Die Sprache besteht aus Konstanten, Variablen und Pradikaten, die Bedingun-gen durch Regeln der FormH ← A1, ..., An, notB1, ..., notBm, mit m,n ≥ 0spezifizieren. Eine Bedingung kann durch eine oder mehrere Regeln ausgedrucktwerden.In diesem Modell werden diese Regeln auf Konsistenz hin uberpruft, d.h., alleBedingungen sollten theoretisch erfullbar sein.Eine Rollenplanung ist zustandig fur das Auflisten aller mit den gegebenen Bedin-gungen moglichen Rollen-Task-Zuweisungen. In diesem Modell wird ein Grapherzeugt, der alle moglichen Rollen-Task-Zuweisungen darstellt.Dieses Modell konzentriert sich hauptsachlich auf Bedingungen und unterstutzt


und erzwingt somit umfangreich das ”Separation of duty“-Prinzip. ”Strict leastprivilege“ und ”order of events“ werden jedoch nicht unterstutzt.

6 Zusammenfassung

Ziel dieser Arbeit war die Kontext-Sensitivitat von Zugriffskontrollmechanismenin Workflow-Management-Systemen herauszustellen. Dazu wurden zunachst eini-ge Workflow-Begrifflichkeiten erlautert und das Workflow-Beispiel ”Einreichungeines Schadensfalls bei einer Versicherung“ vorgestellt. Danach wurden die Anfor-derungen an Kontext-sensitive Zugriffskontrolle ”Order of events“, ”Strict leastPrivilege“ und ”Separation of duty“ beschrieben. Mit diesem Hintergrund wur-den daraufhin Kontextberucksichtigungen in Zugriffskontrollmechanismen unter-sucht. Zum Schluss wurde auf einige Kontext-sensitive Zugriffskontrollmodelle,die auf den vorgestellten Zugriffskontrollmechanismen aufbauen, naher eingegan-gen.In dieser Arbeit wurde gezeigt, wie durch Kontextunterstutzung Schutz undSicherheit von Workflow-Daten vor versehentlichem oder beabsichtigtem un-rechtmaßigem Zugriff durch die Workflow-Benutzer verbessert werden kann.

A Task-Bearbeitungsablauf in CoSAWoE

1. Benutzer besitzt Rolle aus Rollen-Hierarchie2. Benutzer identifiziert sich erfolgreich gegenuber System3. Benutzer bekommt Worklist, darin sind enthalten

(a) alle bereits akzeptierten aktiven Tasks(b) inaktive Tasks,

wenn passende Rolle fur Task von Benutzer eingenommen wurdewenn alle SoD-Anforderungen erfullt sind

4. Benutzer entscheidet sich dafur, an einer Task zu arbeiten5. Zugriffskontrollmodul bestimmt die Rolle, die fur die Task benotigt wird (mit

den minimal benotigten Rechten, d.h., es kann auch eine Rolle unterhalb derAusgangsrolle in der Rollenhierarchie sein)

6. Benutzer darf an Task arbeiten

B Objekt-Design in CoSAWoE

Das Objekt-Design in CoSAWoE wird in [1] anhand des Beispiels eines Bestell-formulars erlautert, das in Abb. 8 dargestellt ist. Die dazugehorige hierarchischeSicht zeigt Abb.9. Das Bestellungsformular-Objekt besteht aus einer Reihe klei-nerer Objekte, z.B. dem ”Lieferadresse“-Objekt. Das ”Lieferadresse“-Objekt be-steht wiederum aus einer Menge kleinerer Objekte wie z.B. ”Adresszeile1“. Esmacht jedoch nur Sinn, Methoden auf das ”Lieferadresse“-Objekt als Ganzesanzuwenden (z.B. das Andern der Lieferadresse).


Abbildung 8. Ein typisches Bestellformular [1]

Abbildung 9. Hierarchische Sicht des Bestellformulars [1]


Es gibt abstrakte Methoden wie z.B. ”Bestellung-Genehmigen“. Diese abstrak-ten Methoden konnen durch atomare Methoden ausgedruckt werden, die sichereignen, wenn die abstrakten Rechte ausgefuhrt werden. Mogliche atomare Me-thoden im Zusammenhang mit dem ”Bestellformular“-Objekt:

– Delete-Methode: Moglichkeit, ein Objekt zu zerstoren– Add-Methode: Moglichkeit, eine neue Instanz eines Objekts zu erzeugen– View-Methode: Moglichkeit, den Inhalt eines Objekts anzusehen– Edit-Methode: Moglichkeit, den Inhalt eines Objekts zu verandern

Ein Zugriffsrechte-Profil ist ein Schnappschuss der Zugriffskontrollanforderun-gen von einem Objekt zu einem bestimmten Zeitpunkt. In der Tabelle vonAbb. 10 ist ein Zugriffsrechte-Profil fur ein Bestellformular zum Zeitpunkt, wennder Lagerbestand nachbestellt wird, dargestellt. Das Objekt nimmt wahrend

Abbildung 10. Zugriffsrechte-Profil fur ein Bestellformular [1]

der Ausfuhrung eines Ablaufs verschiedene Zustande ein (”Order of Events“).Zu jedem Zustand kann ein anderes Zugriffsrechte-Profil erstellt werden. DieseZugriffsrechte-Profile konnen evtl. zusammengefasst werden zu abstrakten Zu-griffsrechten. Einerseits kann der administrative Aufwand durch dieses Zusam-menfassen verringert werden. Andererseits darf nicht zu viel zusammengefasstwerden, um ”Strict least Privilege“ zu erreichen.

Literatur

[1] CoSAWoE - A Model for Context-sensitive Access Control in Workflow Environ-ments, Reinhardt A. Botha, November 2001.

[2] V. Atluri and W.-K. Huang, An Authorization Model for Workflows. In Procee-dings of the 5th European Symposium on Research in Computer Security, number1146 in Lecture Notes in Computer Science, 44-64, Springer-Verlag, Sep 1996.

[3] E. Bertino, E. Ferrari and V. Atluri, Specification and Enforcement of Autho-rization Constraints in Workflow Management Systems. ACM Transactions onInformation and System Security, 2(1):65-104, Feb 1999.

[4] W.-K. Huang and V. Atluri, SecureFlow: A Secure Webenabled Workflow Mana-gement System. In V. Atluri, (editor) Proceedings of the 4th ACM Workshop onRole-based access control, 83-94, ACM, Fairfax, VA, USA, October 1999.

[5] Georgiadis, C.K. et al.: Flexible Team-Based Access Control Using Contexts. ACMWorkshop on Role-Based Access Control, Chantilly, Virginia, USA, 2001, pp. 21-27.


[6] R. Thomas and R. Sandhu, Towards a task-based paradigm for flexible and adap-table access control in distributed applications. In Proceedings of 1992-1993 ACMSIGSAC New Security Paradigms Workshop, 138-142, 1993.

[7] R. Thomas and R. Sandhu, Conceptual Foundations for a Model of Task-basedAuthorizations. In Proceedings of the 7th IEEE Computer Security FoundationsWorkshop, 66-79, Franconia, NH, June 1994.

[8] R. K. Thomas, R. S. Sandhu: Task-based Authorization Controls(TBAC): A Fami-ly of Models forActive and Enterprise-orientedAuthorization Management. Procee-dings of the IFIP WG11.3 Workshop on Database Security, Lake Tahoe, California,August 11-13, 1997.

Autorisierungs- und Zugriﬀskontrollmechanismen fur ...In Kapitel 4 wird auf die...

Documents

Transcript of Autorisierungs- und Zugriﬀskontrollmechanismen fur ...In Kapitel 4 wird auf die...