Authorisierungs- und Zugriffskontrollmechanismen für Kontexte in WfMS

http://dbis.ipd.uka.de/861.php

-Selma Mukhtar-

Betreuerin: Jutta Mülle

Authorisierungs- undZugriffskontrollmechanismen

für Kontexte in WfMS

Seminar des DBIS am IPD im Sommersemester 2007:Aktuelle Herausforderungen an Datenschutz und

Datensicherheit in modernen Informationssystemen

212.07.2007 Authorisierungs- und Zugriffskontrollmechanismen für Kontexte in WfMS

Motivation

Benutzer sind menschlich, Betrug und versehentliche Fehler daher möglich, indem Zugriffsrechte falsch benutzt werden

Zugriffsrechte sollten nur gewährt werden, wenn sie unbedingt benötigt werden

Der Zugriff, der einem bestimmten Angestellten auf eine bestimmte Information gewährt wird, verändert sich abhängig vom Kontext dieser Information in der Organisation

Z.B. Ist der Zugriff auf eine Bestellung vor deren Genehmigung anders als danach

Zugriffskontrollanforderungen verändern sich ständig

Zugriffskontrolle sollte bei der Entscheidung, ob ein Zugriff gewährt wird oder nicht, den Kontext der tatsächlich zu verrichtenden Arbeit berücksichtigen.


Gliederung

Workflows Zugriffskontrollanforderungen für Wf-Systeme Rollenbasierte Zugriffskontrolle (RBAC) Kontextberücksichtigungen in RBAC Ein kontext-sensitives Zugriffskontrollmodell Zusammenfassung


Workflows – Begrifflichkeiten I

Workflow: Vordefinierte Abfolge von Aktivitäten/Tasks in einer

Organisation Ziel: (Teil-) Automatisierung der Ausführung Wird von Workflow-Management-System gesteuert

Workflow-Management: Umfasst Modellierung, Spezifikation, Simulation, Ausführung

und Steuerung im Zusammenhang mit Workflows

Workflow-Management-System: (Re-) aktives Basis-Software-System Steuert die Ausführung eines Workflows Unterstützt die Entwicklung von Workflow-Management-

Anwendung

Workflows

Anforderungen

RBAC

Kontexte & RBAC CoSAWoE

Schluß


Workflows – Begrifflichkeiten I

Task: Kleinste Einheit von Arbeit, die verrichtet werden muss, um

ein bestimmtes Geschäftsziel zu erreichen Definiert durch Task-Definiton: bestimmt welche Arbeit auf

welchen Objekten durch welche Benutzer gemacht werden muss.

Geschäftsprozess: Folge von Schritten, um ein Geschäftsresultat zu erzielen Prozess-Definition ist eine Ansammlung von Tasks

Workflows

Anforderungen

RBAC


Schluß


Workflows – Beispiel I

Workflows

Anforderungen

RBAC


Schluß


Workflows – Beispiel II

Workflow: „Schadensfalleinreichung bei einer Versicherung“

Task 1: Initialisierung des Prozesses, Erzeugung eines neuen

Dokuments namens „Schadensfall-Ablaufplan“ Ein Schadensfall-Ablaufplan kann aus einem Schadensfall-

Formular, einem Polizeibericht, Zeugenberichten und –aussagen bestehen

Diese Task wird durch einen Sachbearbeiter (Clerk) ausgeführt

Task 2: Folgt der Beendigung von Task 1 Automatische Entscheidung, getroffen durch das System

basierend auf Workflow-Kontrolldaten, in diesem Fall dem Wert des Schadens, der während Task 1 erfasst wurde

Workflows

Anforderungen

RBAC


Schluß


Workflows – Beispiel III


Geschäftsregeln: Spezifizieren die Bedingungen für die auszuführenden Tasks Route 2-7 wird genommen, wenn der Wert des Schadens

5000 nicht übertrifft Route 2-3 wird genommen, wenn er 5000 übertrifft

Worklist: Benutzer kommuniziert mit einem Wf-System durch eine

Worklist Ein Work Item ist eine Task-Instanz, die einem Benutzer

durch die Workflow Engine zugewiesen wird Die Worklist eines Managers würde eine Liste von allen

Schadensfällen enthalten, die genehmigt werden müssen.

Workflows

Anforderungen

RBAC


Schluß


Workflows – Beispiel III


Es werden viele Prozess-Instanzen von der selbem Prozess-Definition instanziiert

Aus der Prozess-Definition im Beispiel werden Prozess-Instanzen für jeden Schadensfall, der eingereicht wurde, erzeugt

Jede Prozess-Instanz erzeugt dann eine Task-Instanz basierend auf den Task-Definitionen in der betreffenden Prozess-Definition

Prozess- und Task-Instanzen nutzen entsprechende Workflow-Kontrolldaten, wie z.B. den Wert des Schadens, um die Regeln in der Prozess-Definition zu schätzen

Workflows

Anforderungen

RBAC


Schluß


Zugriffskontrollanforderungen I

Anforderungen an Kontext-sensitive Zugriffskontrolle:

Order of events Strict least Privilege Separation of duty

Workflows

Anforderungen

RBAC


Schluß


Zugriffskontrollanforderungen II

Order of events:

Gewähren bestimmter Zugriffsrechte hängt von der erfolgreichen Beendigung anderer Tasks ab

Z.B. Kann der Schadensfall nicht anerkannt werden, wenn nicht das Kundenprofil vervollständigt wurde

Der Mechanismus sollte daher in der Lage sein zu erkennen, an welchem Punkt er bei der Bearbeitung des Schadensfalls ist

Workflows

Anforderungen

RBAC


Schluß


Zugriffskontrollanforderungen III

Strict least Privilege:

Least Privilege: Ein Benutzer bekommt minimale Rechte, die nötig sind, um seine Arbeit zu verrichten

D.h. er bekommt Rechte auf Tasks, die er zu irgendeinem Zeitpunkt während seiner Arbeit ausführen muss

Die Tatsache, dass manche dieser Rechte für viele tägliche Tasks überflüssig sind, wird bei Strict least Privilege beachtet

Strict Least Privilege: Rechte werden weiter eingeschränkt auf die minimalen Rechte, die zu einem bestimmten Zeitpunkt für eine bestimmte Task benötigt werden.

Z.B. sollte ein Manager, der den Schadensfall-Ablaufplan inizialisiert, nur die Sachbearbeiter-Rechte erhalten, die nötig sind um die Task auszuführen, nicht aber die Rechte, um den Schadensfall zu genehmigen oder zu verweigern

Workflows

Anforderungen

RBAC


Schluß


Zugriffskontrollanforderungen IV

Separation of duty: Verlangt zwei oder mehr verschiedene Personen, die für den

Abschluss eines Geschäftsprozesses verantwortlich sind

Erschwert Betrug, da dafür eine Verschwörung nötig ist und dadurch erhöhtes Risiko der Betrüger

Z.B. sollten Schadensgutachter (assessor) und Manager disjunkte Rechte haben. Außerdem müssen laut Prozess-Definition beide beteiligt sein

Separation-of-duty-Anforderungen werden häufig als Geschäftsregeln formuliert, z.B. „Ein Scheck benötigt zwei verschiedene Unterschriften“

Workflows

Anforderungen

RBAC


Schluß


Role-based Access Control (RBAC) I

Workflows

Anforderungen

RBAC


Schluß


Role-based Access Control (RBAC) II

Benutzern (U) werden Rollen (R) durch eine Benutzer-Rollen-Zuweisungsrelation (UA) zugewiesen

Die Zugriffsrechte (P), die in Verbindung stehen mit einer Rolle, werden in der Rollen-Zugriffsrechte-Zuweisungsrelation (PA) wiedergegeben

Die Zugriffsrechteabstraktion (P) wird in diesem Modell wiedergegeben als die für ein Objekt (O) verfügbaren Methoden (M)

Workflows

Anforderungen

RBAC


Schluß


Role-based Access Control (RBAC) III

Z.B. könnte ein Benutzer das Recht erhalten die „Schadensfall-Genehmigen“-Methode für ein „Schadensfall-Formular“-Objekt auszuführen

Ein Benutzer erhält die Zugriffsrechte verbunden mit den Rollen, die er für die Session (S) einnimmt

Eine Session ist ein zeitgebundenes Konstrukt, um Benutzer, Rollen und Zugriffsrechte miteinander zu verbinden

Workflows

Anforderungen

RBAC


Schluß


Role-based Access Control (RBAC) IV

Vererbung durch Rollenhierarchie:

Rollen sind untereinander partiell geordnet Rollen erben die Rechte derjenigen Rollen, die in der

partiellen Ordnung kleiner sind als sie selbst.

Workflows

Anforderungen

RBAC


Schluß

Rolle r1 ist den Rollen r2 und r3 übergeordnet, die wiederum sind r4 übergeordnet

r1 erbt die Rechte, die mit r2 und r3 verbunden sind

r1 und r5 stehen durch die Rollenhierarchie nicht miteinander in Verbindung


RBAC und Kontext

RBAC unterstützt Prinzipien wie „Separation of duty“ oder „least privilege“, aber erzwingt sie nicht

Separation of duty: Kann erreicht werden, indem die Mitgliedschaft zweier Rollen

sich gegenseitig ausschließt durch disjunkte Rollenhierarchien

Im Beispiel sind dann Schadensgutachter und Manager in verschiedenen Rollenhierarchien, die Rechte von Schadensgutachter und Manager sind disjunkt

Least Privilege: RBAC erlaubt einem Benutzer, eine Rolle einzunehmen, die

weniger Rechte hat, als er bekommen könnte

Workflows

Anforderungen

RBAC


Schluß


Ein kontext-sensitives Zugriffskontrollmodell (CoSAWoE) I

Workflows

Anforderungen

RBAC


Schluß


Ein kontext-sensitives Zugriffskontrollmodell (CoSAWoE) II

CoSAWoE ersetzt RBAC nicht, sondern baut darauf auf

Kontextinformation:

Der Kontext der Arbeit wird bestimmt durch die Prozess-Definition (PD)

Eine Prozess-Definition besteht aus mehreren Task-Definitionen (TD), die gemäß eines Task-Netzwerks (TN) angeordnet sind

Die Bedingungen, die die zu verfolgende Route bestimmen, sind Teil des Task-Netzwerks

Workflows

Anforderungen

RBAC


Schluß


Ein kontext-sensitives Zugriffskontrollmodell (CoSAWoE) III


Kontextinformation:

Die Rolle, die dazu geeignet ist, eine bestimmte Task auszuführen, wird durch die Task-Rollen-Zuweisungsrelation (TDR) bestimmt

Die Prozess-Instanz-Relation (PI) behält die Übersicht über alle instanziierten Prozesse

Die Task-Instanz-Relation (TI) behält die Übersicht über alle Task-Instanzen

Das Task-Instanz-Netzwerk (TIN) verbindet die Task-Instanzen ähnlich wie TN die Task-Definitionen kombiniert

Workflows

Anforderungen

RBAC


Schluß


Ein kontext-sensitives Zugriffskontrollmodell (CoSAWoE) III


Kontextinformation:

Separation of duty wird mithilfe einer Konflikt-Task-Menge (CT) in diesem Modell implementiert.

Wenn zwei Tasks zur CT gehören, dann müssen sie durch verschiedene Benutzer ausgeführt werden

Workflows

Anforderungen

RBAC


Schluß


Ein kontext-sensitives Zugriffskontrollmodell (CoSAWoE) IV


Session-Kontrolle:

Workflows

Anforderungen

RBAC


Schluß


Ein kontext-sensitives Zugriffskontrollmodell (CoSAWoE) V


Session-Kontrolle:

Herkömmliche Sessions zeigen die verstrichene Zeit vom Einloggen des Benutzers beim Server bis zu seinem Ausloggen an

Hier wird eine Session für nur eine einzige Task benutzt

Authentifiziert sich ein Benutzer einmal gegenüber dem System, erhält er noch keine Rechte

Workflows

Anforderungen

RBAC


Schluß


Ein kontext-sensitives Zugriffskontrollmodell (CoSAWoE) VI


Session-Kontrolle:

Wenn ein Benutzer an einem Workitem in der Worklist arbeitet, wird eine Workflow-Session errichtet und der Benutzer erhält die angemessenen Rechte

Sobald der Benutzer aufhört an der bestimmten Task zu arbeiten, wird die Workflow-Session geschlossen und alle damit verbundenen Rechte entzogen

Eine Session wird daher genutzt, um die Rechte eines Benutzers für die Dauer der Arbeit an einer Task zu kontrollieren

Eine Session steht in Verbindung zu einer einzigen Rolle

Workflows

Anforderungen

RBAC


Schluß


Zusammenfassung

Zusammenfassung:

Anforderungen an kontext-sensitive Zugriffskontrolle Wie kontext-sensitiv ist RBAC? Ein kontext-sensitives Zugriffskontrollmodell

Außerdem erwähnenswert in diesem Zusammenhang:

TBAC und Kontexte Modelle die TBAC verwenden und deren Kontext-Sensitivität

WAM BFA

TMAC und KontexteNäheres dazu in der Ausarbeitung zu diesem Vortrag.

Workflows

Anforderungen

RBAC


Schluß


Schluss

Vielen Dank für Ihre Aufmerksamkeit!

Fragen?

Kontakt: [email protected]


Quellen

CoSAWoE – A Model for Context-sensitive Access Control in Workflow Environments, Reinhardt A. Botha

A Context-sensitive Access Control Model and Prototype Implementation, Damian G. Cholewka, Reinhardt A. Botha, Jan H.P. Eloff


Anhang


Role-based Access Control (RBAC) IV

Vererbung durch Rollenhierarchie:

Rollen sind untereinander partiell geordnet Rollen erben die Rechte derjenigen Rollen, die in der

partiellen Ordnung kleiner sind als sie selbst.

Workflows

Anforderungen

RBAC


Schluß

x


Anhang - RBAC und Kontext

RBAC unterstützt Prinzipien wie „Separation of duty“ oder „least privilege“, aber erzwingt sie nicht

Separation of duty: Kann erreicht werden, indem die Mitgliedschaft zweier Rollen

sich gegenseitig ausschließt durch disjunkte Rollenhierarchien

Workflows

Anforderungen

RBAC


Schluß


Zugriffskontrollmechanismen – RBAC I

WfMS

Mechaninsmen RBAC TMAC

Kontexte

Beispiele

Schuss


Zugriffskontrollmechanismen – RBAC II

Role Based Access Control (RBAC) Verfahren zur Zugriffskontrolle auf Systemressourcen Zuordnung Rollen – Zugriffsrechte Zuordnung Benutzer – Rollen

Benutzer: Mensch Rolle: Funktion im Unternehmen Zugriffsrecht: Authorisierung Task im Wf-System auszuführen

Rollenhierarchie und Vererbung von Zugriffsrechten Systemadministrator

WfMS


Kontexte

Beispiele Schuss

RBAC gewährleistet, dass nur authorisierte Benutzer auf bestimmte Daten zugreifen können.


Zugriffskontrollmechanismen – TMAC I

Team-based Access Control (TMAC) Zugriffskontrollverfahren für gemeinschaftliche Aktivitäten

Team: Kollektion an Benutzern in best. Rollen Benutzer eines Teams erhalten Zugang zu Team-Ressourcen

WfMS


Kontexte

Beispiele Schuss


Zugriffskontrollmechanismen – TMAC II

TMAC Beispiel für aktives Sicherheitsmodell: Berücksichtigt Kontext laufender Aktivitäten Flexibles Modell, viele verschiedene Zugangsrichtlinien Strenge, just-in-time Aktivierung von Zugriffsrechten

TMAC ist hybrides Zugriffskontrollmodell: Vorteile von rollenbasierten Zugriffsrechtezuweisung (RBAC) und Flexibilität feinkörniger Zugriffsrechteaktivierung

WfMS


Kontexte

Beispiele Schuss


Kontextbasierte Zugriffskontrolle

Kontextinformation: Zugriffszeitpunkt, Zugriffsort, Ort des gewünschten Objekts,

transaktionsspezifische Werte

Kontextinformationen müssen beachtet werden bei Beeinflussung eines Zugriffskontrollsystem zur Laufzeit

WfMS

Mechaninsmen

Kontexte Einbindung Erzeugung

Beispiele

Schuss


Kontexte – C-TMAC I

WfMS

Mechaninsmen


Beispiele

Schuss


Kontexte – C-TMAC II

Kontextbasierter Team-Zugriffskontrollansatz Basiert auf der Integration von RBAC und TMAC

Besteht aus Benutzern, Rollen, Zugriffsrechten, Teams, Kontexten und einer Sessions-Kollektion

Benutzer/Rollen-, Rollen/Zugriffsrechte-, Benutzer/Team- und Team-/Kontextzuweisung sind many-to-many Relationen

Benutzer wird einer Session während deren Lebensdauer fest zugewiesen

Kontext: Beinhaltet Informationen bezügl. der Daten, die für eine Aktivität benötigt werden (Orte, Zeitintervalle)

WfMS

Mechaninsmen


Beispiele

Schuss


Beispiele – interorganisatorische Workflows I

WfMS

Mechaninsmen

Kontexte

Beispiele i.o. Workflows Webb. Wfs

Schuss

Interorganisatorische Workflows: Workflow, der sich über mehrere Organisationen erstreckt „virtuelles Unternehmen, das spezielle Mission unterstützt“ Bietet Lösungen für Data-Sharing und Arbeitskoordination auf

globalem Level Sobald Workflow designed wurde, Zuordnung jeder Task zu

Organisation und Host


Beispiele – interorganisatorische Workflows II

WfMS

Mechaninsmen

Kontexte


Schuss

Zugriffskontrollanforderungen:

(1) Trennung der Workflow-Sicherheitsinfrastruktur auf Anwendungslevel von der Sicherheitsstruktur auf Organisationslevel

(2) Feinkörnigkeit und Kontextbasiertheit

(3) Unterstützung dynamischer Constraints


Beispiele – interorganisatorische Workflows III

WfMS

Mechaninsmen

Kontexte


Schuss

Erfüllung der Zugriffskontrollanforderungen:

(1) Einführung von Rollendomains als Rollenstrukturschnittstelle, Abbildung der organisationseigenen Rollenstruktur auf die Rollendomain für einen Workflow

(2) Unterscheidung Zwischen den verschiedenen Tasks innerhalb eines Prozesses durch Einführung von task-spezifischen Zugriffskontrollmodulen (TACM)


Beispiele – interorganisatorische Workflows IV

WfMS

Mechaninsmen

Kontexte


Schuss

Erfüllung der Zugriffskontrollanforderungen:

(3) History-basierte ZugriffskontrolleMonitor-Server unterhält Log mit Ausführungs-HistoryTask, die Ausführungs-History benötigt, um Zugriffskontrollentscheidung zu machen, fragt bei Monitor-Server an


Beispiele – Webbasierte Workflow-Systeme mit RBAC I

Webbasierte Workflow-Systeme: Unterstützen dynamische Geschäftsprozesse in heterogenen

Computersystemen Meist nur minimales Sicherheitskonzept

Im folgenden: Schliessen dieser Sicherheitslücke mit RBAC User-Pull-Stil,

eine Art im Web an Benutzerattribute zu gelangen

WfMS

Mechaninsmen

Kontexte


Schuss


Beispiele – Webbasierte Workflow-Systeme mit RBAC II

WfMS

Mechaninsmen

Kontexte


Schuss


Zusammenfassung/Ausblick

Es wurden Zugriffskontrollmechanismen im Zusammenhang mit Workflows vorgestellt

WfMS

Mechaninsmen

Kontexte

Beispiele

Schuss


Zugriffskontrollmechanismen – TBAC

Task-based Access Control (RBAC) Weiteres Zugriffskontroll- und Authorisierungsverfahren Task-orientiertes Sicherheitsmodell

TBAC berücksichtigt Kontextinformationen Zugriffsrechte werden einsatzsynchron

vergeben/zurückgenommen

Motivation

Mechaninsmen RBAC TBAC TMAC

Kontexte

WAM

Beispiele Schuss


Motivation

WFs sind Prozesse in Geschäftsumgebungen WFs bestehen aus mehreren Tasks Nur authorisierte Benutzer sollen Tasks ausführen dürfen Größte Bedrohung durch Insider

Notwendigkeit geeigneter Authorisierungs- und Zugriffskontrollmechanismen

Authorisierungs- und Zugriffskontrollmechanismen für Kontexte in WfMS

Documents

Transcript of Authorisierungs- und Zugriffskontrollmechanismen für Kontexte in WfMS