Institut für Wirtschaftsinformatikwebdoc.sub.gwdg.de/ebook/serien/lm/arbeitsberichte_wi2/... ·...

Arbeitsbericht Nr. 22/2004 Hrsg.: Matthias Schumann

Robert Schmaltz

Zugriffsschutz für verteilte Wissens-managementsysteme

Georg-August-Universität Göttingen

Institut für Wirtschaftsinformatik Professor Dr. Matthias Schumann

Platz der Göttinger Sieben 5 37073 Göttingen Telefon: + 49 551 39 - 44 33 + 49 551 39 - 44 42 Telefax: + 49 551 39 - 97 35 www.wi2.wiso.uni-goettingen.de

© Copyright: Institut für Wirtschaftsinformatik, Abteilung Wirtschaftsinformatik II, Georg-August-Universität Göttingen.

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheber-

gesetzes ist ohne Zustimmung des Herausgebers unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Über-

setzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Alle Rechte vorbehalten.

Inhaltsverzeichnis II

Inhaltsverzeichnis

1 Einleitung .....................................................................................................................................1

2 Begriffe und Konzepte von Sicherheit und Zugriffsschutz........................................................2

2.1 Sicherheitsrichtlinien und Sicherheitsmodelle ..........................................................................2

2.2 Grundlegende Strategien des Zugriffsschutzes .......................................................................3

2.3 Konzepte zur Umsetzung des Zugriffsschutzes.......................................................................5

2.4 Weiterführende Forschungsgebiete ........................................................................................8

3 Praktische Umsetzungen von Zugriffsschutzkonzepten............................................................9

3.1 Praktische Umsetzungen des Reference Monitors ................................................................10

3.2 Umsetzungsvarianten der Access Control Database .............................................................12

3.3 Standards für den anwendungs- und unternehmensübergreifenden Zugriffsschutz ..............14

4 Anforderungen an den Zugriffsschutz......................................................................................17

5 Beispielhafte Rechtemanagementarchitekturen ......................................................................21

5.1 Zentralisierte Wissensmanagement-Systeme........................................................................22

5.1.1 Grundlegender Aufbau und Einsatzbereiche.................................................................22

5.1.2 Implementierungsvarianten des Reference Monitor ......................................................23

5.1.3 Implementierungsvarianten der Access Control Database ............................................24

5.1.4 Ausgestaltung des Rollenmodells .................................................................................26

5.1.5 Administration der Zugriffsrechte..................................................................................28

5.2 Dezentrale Wissensmanagement-Systeme ...........................................................................30

5.2.1 Grundlegender Aufbau und Einsatzbereiche.................................................................30

5.2.2 Implementierungsvarianten des Reference Monitor ......................................................31

5.2.3 Implementierungsvarianten der Access Control Database ............................................32

5.2.4 Ausgestaltung des Rollenmodells .................................................................................37

5.2.5 Administration der Zugriffsrechte..................................................................................38

6 Fazit ............................................................................................................................................39

Literaturverzeichnis ........................................................................................................................42

Abbildungsverzeichnis III

Abbildungsverzeichnis

Abbildung 2-1: Grundprinzip der Rollenbasierten Zugriffskontrolle............................. 5

Abbildung 2-2: Grundprinzip des Reference Monitor .................................................. 6

Abbildung 2-3: Beispielhafte Zugriffskontrollmatrix..................................................... 7

Abbildung 2-4: Zugriffskontrollmatrix in der Lernplattform CLIX.................................. 7

Abbildung 3-1: Implementierungsvarianten des Reference Monitors........................ 10

Abbildung 3-2: Implementierungsvarianten der Access Control Database............... 14

Abbildung 3-3: Standards für die Zugriffskontrolle.................................................... 17

Abbildung 4-1: Anforderungen an Zugriffskontrollsysteme für Kooperationen.......... 21

Abbildung 5-1: Varianten des Reference Monitor ..................................................... 24

Abbildung 5-2: Zugriffsschutz im zentralisierten System........................................... 25

Abbildung 5-3: Varianten der ACD............................................................................ 26

Abbildung 5-4: Varianten des Rollenmodells ............................................................ 28

Abbildung 5-5: Varianten der Privilegienverwaltung ................................................. 29

Abbildung 5-6: Varianten des Reference Monitor im dezentralen System................ 32

Abbildung 5-7: Zugriffsschutz im dezentralen System mit Verzeichnisdienst ........... 34

Abbildung 5-8: Zugriffsschutz im dezentralen System mit Zertifikaten...................... 35

Abbildung 5-9: Varianten der dezentralen Speicherung der Nutzerdaten................. 36

Abbildung 5-10: Rollen- und credentialbasierte Autorisierung .................................. 38

Abbildung 5-11: Varianten der Privilegienverwaltung im dezentralen System .......... 39

Abbildung 6-1: Dezentrales vs. zentrales System..................................................... 41

Abkürzungsverzeichnis IV

Abkürzungsverzeichnis

ACD Access Control Database

ACL Access Control List

ACM Access Control Matrix

AS Anwendungssystem

CMS Content Management System

DAC Discretionary Access Control

DRM Digital Rights Management

DSML Directory Services Markup Language

DV Datenverarbeitung

ERP Enterprise Resource Planning

IP Internet Protocol

IT Informationstechnologie

LDAP Lightweight Directory Access Protocol

MAC Mandatory Access Control

MS Microsoft

PKI Public Key Infrastructure

RBAC Role Based Access Control

RFC Request for Comments

RM Reference Monitor

SAML Security Assertion Markup Language

TCP Transmission Control Protocol

XACML Extensible Access Control Markup Language

XML eXtensible Markup Language

1 Einleitung 1

1 Einleitung

In einem Wissensmanagementsystem, das in einer Kooperation genutzt wird, werden vielfäl-

tige Inhalte gespeichert, die vor einem Zugriff durch unberechtigte Benutzer geschützt wer-

den müssen. Zum einen können dort Marketingunterlagen, gemeinsame Standards oder

Verfahrensweisen verwaltet werden, die für alle Partner zugänglich sein müssen. Zum ande-

ren können Inhalte vorgehalten werden, die Wettbewerbsvorteile einzelner Kooperationsteil-

nehmer berühren und daher nur sehr selektiv mit Partnern geteilt werden können, etwa im

Fall von technischen Konstruktionsunterlagen. Dies erfordert die Integration von Rechtema-

nagementkonzepten in den Entwurf von Wissensmanagementanwendungen. Insbesondere

in verteilten Wertschöpfungsstrukturen ist es erforderlich, Inhalte abgestimmt auf die Sicher-

heitsbedürfnisse der Beteiligten nur einzelnen Nutzergruppen zugänglich zu machen.

Insbesondere wenn Informationssysteme externen Partnern zugänglich gemacht werden,

müssen sie die Möglichkeit bieten, Inhalte und Funktionen mit feiner Granularität frei-

zugeben. Dies ermöglicht auf der einen Seite eine effektive Zusammenarbeit mit einem

Minimum an Medienbrüchen und für den Benutzer spürbaren Systemgrenzen. Auf der ande-

ren Seite können aber auch die Bedürfnisse nach dem Schutz von unternehmenskritischen

Daten und Systemen erfüllt werden. In diesem Zusammenhang zeigen Sicherheitsmaßnah-

men, deren Wirkung auf einzelne Anwendungen beschränkt ist, deutliche Mängel. Insbeson-

dere führen sie zu einem sehr hohen Administrationsaufwand, da Nutzer und die ihnen

zugeordneten Zugriffsrechte über zahlreiche Anwendungen verteilt gepflegt werden müssen.

Zudem fehlt bei dieser zersplitterten Verwaltung der Rechte die Möglichkeit, eine Übersicht

über die Befugnisse einzelner Nutzer zu gewinnen und diese nach einheitlichen Kriterien zu

verteilen bzw. zu widerrufen. Auch aus Nutzersicht erschwert eine anwendungsspezifische

Zugriffskontrolle die Arbeit mit der IT, da zahlreiche Login-Informationen gepflegt werden

müssen und Rechte für jedes Einzelsystem aufs Neue beantragt werden müssen.

Daher ist zu untersuchen, ob und wie eine anwendungs- und unternehmensübergreifende

Zugriffskontrolle, insbesondere im Kontext von Wissensmanagementsystemen für Koopera-

tionen, umgesetzt werden kann. Dazu wird zunächst in Kapitel 2 eine kurze Einführung in

prinzipielle Konzepte und Begriffe des Zugriffsschutzes gegeben. Darauf folgend werden in

Kapitel 3 bestehende Umsetzungen von Sicherheitssystemen in für das Wissensmanage-

ment relevanten Anwendungen diskutiert. In Kapitel 4 werden dann Anforderungen an

Zugriffsschutzsysteme für Wissensmanagement-Anwendungen erarbeitet und in Kapitel 5

wird gezeigt, wie diese in zentralen und dezentralen Systemen umgesetzt werden. Ein kur-

zes Fazit schließt die Ausführungen.

Literaturverzeichnis 2

2 Begriffe und Konzepte von Sicherheit und Zugriffsschutz

Im folgenden Abschnitt werden die grundlegenden Begriffe und Techniken des Zugriffs-

schutzes eingeführt. Unter Zugriff können unterschiedliche Aktivitäten verstanden werden, die

ein Nutzer auf Systemobjekte (etwa Dokumente) ausführen kann, z. B. lesen und schreiben,

aber auch die Veränderung von Attributen wie Freigaben etc. Der Zugriffschutz ist ein Teil der

Datensicherheit. Im Rahmen der Datensicherheit werden bestimmte Schutzziele verfolgt.

Diese werden im Allgemeinen in Vertraulichkeit, Integrität, Verfügbarkeit und Zurechenbarkeit

unterteilt (vgl. Hansen/Neumann 2001, S. 174; Damker 2002, S. 209). Zur Erreichung dieser

Ziele dienen systemunabhängig festgelegte Sicherheitsrichtlinien und Sicherheitsmechanis-

men in den Systemen, die diese Richtlinien umsetzen. Bei der Erstellung der Richtlinien kann

eine Reihe von grundlegenden Strategien zum Einsatz kommen (vgl. Kap. 2.2). Die grundle-

genden Konzepte, die bei der Umsetzung von Sicherheitsmechanismen relevant sind, werden

in Kap. 2.3 vorgestellt. Kap. 2.4 enthält eine Abgrenzung zu den verwandten Forschungsge-

bieten Trust Management und Digital Rights Management.

2.1 Sicherheitsrichtlinien und Sicherheitsmodelle

Zum Entwurf eines sicheren Wissensmanagementsystems ist es zunächst erforderlich, Si-

cherheitsrichtlinien für die Anwendung zu spezifizieren. In ihnen ist genau festgelegt, welche

Aktionen die einzelnen Einheiten des Systems ausführen dürfen und welche nicht. Unter

Einheiten werden in diesem Kontext Nutzer, Dienste, Daten, Maschinen etc. verstanden (vgl.

Tanenbaum/Steen 2002, S. 414 ff.). Die Sicherheitsrichtlinien werden im Allgemeinen unab-

hängig von der späteren Implementierung im Rahmen des Fachkonzeptes festgelegt, um eine

von konkreten Produkten unabhängige Spezifikation der Sicherheitsanforderungen zu ermög-

lichen (vgl. z.B. Coetzee/Eloff 2003, S. 286).

Zur Umsetzung der Sicherheitsrichtlinien dienen dann Sicherheitsmechanismen, die nach

Tanenbaum/Steen (2002, S. 415) in vier Gruppen eingeteilt werden können:

• Verschlüsselung: Mittels Verschlüsselung werden Daten in ein für Außenstehende

nicht verständliches Format umgewandelt. Damit lässt sich die Vertraulichkeit von Da-

ten sicherstellen. Da die Verschlüsselung im Allgemeinen auf Betriebssystem- bzw.

Netzwerkebene erfolgt und nicht durch das Wissensmanagementsystem implementiert

wird, ist sie hier nur am Rande von Interesse.


• Authentifizierung: Diese Verfahren dienen dazu, die behauptete Identität einer Ein-

heit zu verifizieren. Sie werden häufig durch Passwortabfragen realisiert. Die Authenti-

fizierung ist ein Problemkreis, der für alle IT-Systeme relevant ist (vgl. z.B.

Hansen/Neumann 2001, S. 175). Sie zeigt keine wissensmanagementspezifischen

Besonderheiten, denn die Art und Weise, wie die Identität eines menschlichen oder

maschinellen Kommunikationspartners überprüft wird, ist unabhängig von den später

genutzten Funktionen. Folglich wird sie hier ebenfalls nur knapp betrachtet.

• Autorisierung: Im Anschluss an die Authentifizierung muss festgestellt werden, ob die

Einheit die angeforderten Operationen ausführen darf. In diesem Bereich liegt das

Kernproblem der Sicherung von Wissensmanagementsystemen, denn hier müssen

Benutzern Zugriffsrechte zugeordnet werden. Dieser Problembereich ist im Wissens-

management von besonderer Bedeutung, da die hier vergebenen Rechte darüber

bestimmen, wer auf gespeichertes Wissen zugreifen, es nutzen, weiterverarbeiten,

weitergeben oder verändern kann. Zudem ist die Autorisierung an die Gegebenheiten

und Anforderungen der Kooperation anzupassen, wobei nur wenig allgemein akzep-

tierte Verfahren, Vorgehensweisen und Implementierungen existieren.

• Im Rahmen des Auditing wird nachvollzogen, welche Einheiten welche Operationen

ausgeführt haben. Dies dient insbesondere dazu, Sicherheitslücken aufzuspüren und

zu analysieren. Beim Auditing werden im wesentlichen Nutzeraktivitäten aufgezeichnet

und ausgewertet. Insbesondere die Auswertungen sind als ex-ante Kontrollen außer-

halb des Systems durchzuführen (vgl. Tanenbaum/Steen 2002, S. 416) und daher an

dieser Stelle nicht Teil des Betrachtungsgegenstandes.

In Zusammenhang mit der Autorisierung werden oft die Termini Objekt und Subjekt verwen-

det. Ein Objekt bezeichnet dabei eine zu schützende Einheit eines Systems (Datei, Dokument,

Funktion,…) und ein Subjekt eine zugreifende Einheit (vgl. Eckert 2003, S. 177). Wenn den

Subjekten Rechte zugeordnet werden sollen, kann dabei nach verschiedenen Grundsätzen

vorgegangen werden. Die wesentlichen Strategien dafür werden im Folgenden erläutert.

2.2 Grundlegende Strategien des Zugriffsschutzes

Die drei wichtigsten Zugriffsstrategien sowohl im Bereich der wissenschaftlichen Forschung

als auch in der Praxis sind Discretionary Access Control (DAC), Mandatory Access Control

(MAC) und Role Based Access Control (RBAC) (vgl. Eckert 2003, S. 180 ff.; Sandhu 2001, S.

22).


DAC und MAC waren insbesondere in den 70er und 80er Jahren die dominanten Zugriffsstra-

tegien. DAC (auch als benutzerbestimmte oder diskrete Zugriffskontrolle bezeichnet) kommt

aus dem Bereich der akademischen und industriellen Forschung und basiert darauf, dass der

Zugriff auf Objekte grundsätzlich gestattet ist. Diese Zugriffe kann der für das Objekt verant-

wortliche Eigentümer (owner) jedoch einschränken. Dazu werden auf der Ebene der Objekte

Sicherheitsfestlegungen getroffen. Systemweite Zugriffsregeln können mit DAC also nicht

erstellt werden. Zudem können unautorisierte Informationsflüsse mit diesem Modell nur

schwer vermieden werden, da Nutzer Zugriffsrechte an andere Benutzer und Objekte weiter-

geben können. Weiterhin besteht die Gefahr von widersprüchlichen Rechtevergaben, wenn

beispielsweise ein Subjekt durch die Erlaubnis eine Operation auszuführen impliziten Zugriff

auf ein Objekt erlangt, ihm der Zugriff auf dieses Objekt aber durch eine explizite Regel verbo-

ten ist (vgl. Eckert 2003, S. 181; Wörndl 2003, S. 32).

MAC (auch mandatorische oder systembestimmte Zugriffskontrolle) stammt aus dem Bereich

der militärischen und Sicherheitsforschung. Dabei können systemweite Festlegungen für

Zugriffsrechte getroffen werden, die grundsätzlich über individuelle Rechtezuweisungen domi-

nieren. Dazu werden die Objekte und Nutzer in starre Sicherheitsklassen eingeordnet. MAC

verfolgt eher einen Ansatz, der alle Zugriffe verbietet, die nicht explizit erlaubt sind.

In der aktuellen Diskussion zu Zugriffsschutzverfahren dominiert das Konzept der Rollen-

basierten Zugriffskontrolle RBAC, das sich in Forschung und Praxis als Standard durchge-

setzt hat (vgl. Sandhu 2001, S. 22). Dabei werden die Rechte nicht für einzelne Subjekte

definiert, sondern für aufgabenbezogene Rollen. Den Subjekten können dann eine oder meh-

rere Rollen zugeordnet werden. Die Rollen können in Hierarchien geordnet werden, wobei

eine Vererbung der Rechte möglich ist. Eine Übertragung von Rechten durch die Nutzer ist

jedoch ausgeschlossen. Mittels RBAC können sowohl MAC und DAC abgebildet werden, das

Modell enthält keine grundsätzliche Festlegung bezüglich der Freigabe von Zugriffen (vgl.

Osborn/Sandhu/Munawer 2000, S. 85 ff.). Die Zuordnung der Subjekte zu Rollen erleichtert

die Administration der Zugriffsberechtigungen erheblich, da Zugriffsberechtigungen nicht mehr

für jeden Nutzer einzeln gepflegt werden müssen. Abb. 2-1 verdeutlicht den rollenbasierten

Zugriff (vgl. Hansen/Neumann 2001, S. 229).


Abbildung 2-1: Grundprinzip der Rollenbasierten Zugriffskontrolle

Für Wissensmanagementanwendungen sind die beiden erstgenannten Zugriffsstrategien nur

eingeschränkt geeignet. DAC ist insbesondere problematisch, weil die Zugriffsberechtigungen

für jedes Objekt gesondert gepflegt werden müssen. In einem System, in dem große Zahlen

von Objekten (Dokumenten) und Subjekten (Nutzern) verwaltet werden müssen, ist diese

Vorgehen sehr pflegeintensiv und es ist kaum möglich, konsistente Zugriffsstrategien für

bestimmte Benutzergruppen festzulegen (vgl. Hildman/Bartholdt 1999, S. 106). MAC hinge-

gen ist durch die starre Ordnung der Schutzklassen und seine beschränkte Ausdrucksfähig-

keit vielfach zu restriktiv und durch die systemweit einheitlichen Zugriffsklassen sehr inflexibel

(vgl. Wörndl 2003, S. 32). Zudem widerspricht die restriktive Philosophie des Systems, das

nur explizit erlaubte Zugriffe zulässt, dem Ziel, Wissen möglichst unkompliziert zu teilen und

verfügbar zu machen. Rollenbasierte Zugriffskonzepte ermöglichen es hingegen, zum einen

die Administration durch die Gruppierung von Privilegien zu Rollen stark zu vereinfachen und

zum anderen beliebige Kontrollstrategien umzusetzen.

2.3 Konzepte zur Umsetzung des Zugriffsschutzes

Um die von den Systembetreibern festgelegten Zugriffsstrategien technisch umzusetzen sind

zwei grundlegende Konzepte relevant. Sie bilden die Grundlage der meisten bestehenden

Forschungsarbeiten und praktischen Implementierungen: der Reference Monitor (vgl. Ferraio-

lo/Kuhn/Chandramouli 2003a, S. 31) und die Zugriffskontrolldatenbank (Access Control Data-

base, vgl. Park 2003, S. 9).

Der Reference Monitor (RM) ist ein theoretisches Konzept. Er repräsentiert die Hard- oder

Software, die die Zugriffsstrategie durchsetzt. Dabei werden alle Zugriffe von Subjekten auf

Objekte über den RM abgewickelt, der anhand von Daten aus einer Zugriffskontrolldatenbank

entscheidet, ob der Zugriff erlaubt ist oder nicht (vgl. Abb. 2-2; Ferraiolo/Kuhn/Chandramouli

2003a, S. 31 ff.). In vielen Implementierungen ist der Reference Monitor auf Betriebssystem-


ebene angesiedelt (etwa bei Windows NT/2000, vgl. Swift et al. 2002). Er kann aber auch auf

der Anwendungsebene integriert werden (vgl. z.B. Park/Sandhu 2002, S. 58). Auch die

Zugriffskontrolldatenbank ist nur ein theoretisches Konstrukt, das unterschiedliche Weise

umgesetzt werden kann. Das gleiche gilt für die Protokolldatei (Audit File), in der Überwa-

chungsinformationen für eine nachträgliche Auswertung der erfolgten Aktionen gespeichert

werden. Die konkrete Umsetzung von Reference Monitor und Access Control Database, also

das Teilsystem eines Computersystems, das über die Zulässigkeit bestimmter Operationen

entscheidet, wird auch als Zugriffskontrollsystem bezeichnet (vgl. Stiemerling/Won/Wulf 2000,

S. 319).

Abbildung 2-2: Grundprinzip des Reference Monitor

Die Access Control Database kann auf unterschiedliche Weise realisiert werden. Das in For-

schung und Praxis etablierte Grundmodell für diese Zuordnung ist die Zugriffskontrollmatrix

(Access Control Matrix, ACM, vgl. Park 2003, S. 8). Diese ist eine zweidimensionale Matrix,

die in ihren Zeilen die Subjekte und in ihren Spalten die Objekte darstellt. An den Schnittpunk-

ten werden dann die jeweiligen Zugriffsrechte gespeichert (vgl. Tanenbaum/Steen 2002, S.

448 ff.). Abb. 2-3 zeigt eine beispielhafte ACM. Die möglichen Zugriffsrechte können natürlich

noch deutlich feiner aufgeteilt sein und andere Aktivitäten, etwa das Recht, Dateien auszufüh-

ren oder das Senden bzw. Empfangen von Daten enthalten. Abb. 2-4 zeigt die Schnittstelle

zur ACM in einer Lernplattform. Über Änderungen an der Matrix können die Zugriffsrechte im

System verändert werden. Da die Matrix insbesondere bei großen Systemen oft schwach

besetzt ist und zudem sehr groß wird, wird sie in der Regel nicht als ganzes umgesetzt, son-

dern zeilen- oder spaltenweise implementiert.


Objekt 1 Objekt 2 Objekt 3 Objekt 4

Subjekt 1 Read read/write

Subjekt 2 read/write,

owner

Subjekt 3 read read/write

Abbildung 2-3: Beispielhafte Zugriffskontrollmatrix

Bei einer Umsetzung der ACM in Spalten werden allen Objekten Listen mit Zugriffsrechten

von Subjekten zugeordnet, die als Zugriffskontrolllisten (Access control list, ACL) bezeichnet

werden. Leere Matrixelemente entfallen. Dieses Verfahren hat den Vorteil, dass schnell fest-

gestellt werden kann, wer Zugriff auf ein Objekt hat, und dass Zugriffsrechte einfach widerru-

fen werden können. ACLs bieten jedoch nur schwierig einen Überblick über die Frage, welche

Rechte ein bestimmter Nutzer hat und skalieren bei großen Subjektzahlen schlecht.

Als Alternative kann die ACM zeilenweise über Zugriffsausweise (Capabilities) realisiert wer-

den. In diesem Fall wird jedem Subjekt eine gesicherte Liste von Zugriffsrechten zugeordnet,

die bei Zugriffsversuchen übermittelt werden. Bei der Zugriffskontrolle muss dann lediglich die

Gültigkeit der Capability überprüft werden, nicht die Identität des Subjektes. Man kann damit

auch die Vergabe von Rechten von der Zugriffsprüfung trennen. Zudem entfällt die Durchsu-

chung möglicherweise umfangreicher ACLs. Anhand der Capabilities kann ein einfacher

Überblick über die Zugriffsrechte des Nutzers generiert werden, allerdings ist die Widerrufung

von ausgegebenen Berechtigungen problematisch.

Abbildung 2-4: Zugriffskontrollmatrix in der Lernplattform CLIX


2.4 Weiterführende Forschungsgebiete

Die traditionelle Zugriffskontrolle umfasst Systeme, die einen serverseitigen Reference Moni-

tor haben und Zugriffsrechte zu bekannten Benutzern zuordnen. Sie sind grundsätzlich für

geschlossene Systemumgebungen konzipiert worden, wie sie etwa in klassischen Multiuser-

Systemen anzutreffen sind. Daneben existieren weitere Forschungsrichtungen, die ebenfalls

die Autorisierung des Zugriffs auf Objekte behandeln. Sie unterscheiden sich in zwei wesentli-

chen Dimensionen von den klassischen Modellen: Zum einen bezüglich der Bekanntheit der

Benutzer und zum anderen bezüglich des serverseitigen Reference Monitor. In diesem Zu-

sammenhang sind insbesondere Trust Management und Digital Rights Management hervor-

zuheben (vgl. Park/Sandhu 2002, S. 58).

Trust Management bezeichnet Forschungsrichtungen, die sich auf die Autorisierung unbe-

kannter Nutzer konzentrieren. Dabei werden Zugriffsrechte auf der Basis von Eigenschaften

oder Zugriffsausweisen der Nutzer vergeben, die von dritten Stellen zugesichert wurden und

in digitalen Berechtigungsnachweisen oder Zertifikaten hinterlegt sind. Im Gegensatz zur

traditionellen Zugriffskontrolle müssen die Nutzer selbst also dem den Zugriff gewährenden

System nicht bekannt sein. In diesem Kontext sind etwa Forschungen zu Public Key Infra-

strukturen relevant. Auch diese Forschungen konzentrieren sich jedoch auf die Kontrolle des

Zugriffs auf serverseitig gespeicherte Objekte (vgl. Park 2003, S. 10). Der Einsatz von Trust

Management Technologien kann insbesondere in verteilten Systemen sinnvoll sein, wenn

nicht alle potenziellen Nutzer bekannt sind bzw. an zentraler Stelle verwaltet werden sollen.

Trust Management wird an dieser Stelle nicht weiter vertieft, da im Wissensmanagement eine

Authentifizierung der Nutzer vor dem Zugriff auf potenziell wettbewerbsrelevantes Wissen

vorausgesetzt werden kann.

Die Forschungsrichtung des Digital Rights Management (DRM) beschäftigt sich im Gegensatz

dazu mit der Kontrolle des Zugriffs durch einen clientseitigen Reference Monitor. Schwerpunkt

ist die Kontrolle des Zugriffs auf bereits verteilte, auf dem Client lokal gespeicherte Objekte.

Dabei kann der clientseitige Reference Monitor ggf. mit einer serverseitigen Lösung kombi-

niert werden. Die dort diskutierten Technologien sind zwar im Kontext von Bezahlinhalten,

insbesondere digitalem Medienvertrieb, entstanden (vgl. Liu/Safavi-Naini/Sheppard 2003),

können grundsätzlich aber auch im Zusammenhang mit der Kontrolle von vertraulichen Do-

kumenten eingesetzt werden (vgl. Park/Sandhu 2002, S. 58). Es ist allerdings anzumerken,

dass die Wirksamkeit von DRM-Lösungen auf existierenden Hardwareplattformen, die den

Zugriff von Software auf Hardware und Speicherinhalte sowie die Ausführung von Program-

men nur sehr eingeschränkt kontrollieren können, grundsätzlich eingeschränkt ist. Bislang

wurden nahezu alle softwarebasierten Kopierschutzsysteme kompromittiert (vgl. Becker 2003,


S. 11; 288). Dazu ist von Seiten des Nutzers in vielen Fällen nur ein Minimum an Fachwissen

erforderlich. Es wird bezweifelt, ob dieser Zustand ohne hardwareseitig verankerte „Trusted

Computing“-Technologien, die die Ausführung von Programmen auf zertifizierte Software

einschränken, geändert werden kann (vgl. Park/Sandhu 2002, S. 58). Aufgrund dieser schwa-

chen Schutzmöglichkeiten ist der Nutzen von DRM für das Wissensmanagement, insbesonde-

re den Schutz sensiblen Wissens, zweifelhaft. Es wird daher in den folgenden Betrachtungen

ausgeklammert.

Diese mangelnde Wirksamkeit der clientseitigen Kontrollmechanismen hat einen bedeutsa-

men Nebeneffekt: es ist zwar möglich, den Zugriff auf serverseitig gespeichertes Wissen zu

kontrollieren. Sobald es jedoch an ein Clientsystem übertragen wird, zur Anzeige, Speiche-

rung oder Weiterverarbeitung, ist eine Kontrolle nur noch sehr eingeschränkt möglich. Daher

kann eine missbräuchliche Weiternutzung von geteiltem Wissen nur auf nicht-technischer

Ebene verhindert werden, etwa durch Vertraulichkeitsvereinbarungen.

3 Praktische Umsetzungen von Zugriffsschutzkonzepten

Um zu illustrieren, wie die in Kap. 2 genannten Konzepte (insbesondere Reference Monitor

und Access Control Database) praktisch umgesetzt werden können, wird im folgenden ein

kurzer Überblick über existierende Varianten von Zugriffsschutzmechanismen gegeben. Dabei

wird ein Schwerpunkt auf solche Anwendungen gelegt, die auch im Wissensmanagement

relevant sind. Zudem wäre eine Untersuchung bestehender Zugriffsschutzkonzepte für Wis-

sensmanagement-Systeme wünschenswert, die in Kooperationen eingesetzt werden. Unter-

suchungen zu diesem Thema fehlen aber bislang in der Literatur.

Dabei kann gemäß dem in Kap. 2.3 vorgestellten Reference Monitor Konzept eine Untertei-

lung in drei Gruppen vorgenommen werden: Zum ersten sind Ansätze zur Implementierung

des RM zu betrachten, der auf Betriebssystemebene oder in den Wissensmanagement-

Anwendungen realisiert werden kann. Zum zweiten sind Varianten der Access Control Data-

base zu betrachten, also Möglichkeiten, die Zugriffsinformationen zu speichern. Schließlich ist

es sinnvoll, Austauschformate für Zugriffskontrollinformationen zu behandeln, denn diese

Informationen müssen sowohl zwischen den verschiedenen Anwendungen ausgetauscht

werden, die im Wissensmanagement zum Einsatz kommen, als auch zwischen den kooperie-

renden Partnern. Das Audit File sei an dieser Stelle vernachlässigt, da es als nachträglich zu

nutzendes Kontrollinstrument eine eher untergeordnete Rolle spielt.


3.1 Praktische Umsetzungen des Reference Monitors

Traditionelle Zugriffsschutzkonzepte sind vielfach auf der Betriebssystemebene angesiedelt.

Dabei sind die zu kontrollierenden Operationen in der Regel beschränkt auf Dateizugriffe,

wobei die Granularität der Operationen grob ist (im Bell-LaPadula Modell werden bspw. nur

die Abstufungen read-only, append, execute, read-write, control unterschieden, vgl. Eckert

2003, S. 204). Dieser Ansatz scheint im Bereich von Wissensmanagement-Systemen nur

eingeschränkt sinnvoll zu sein, da viele Inhalte dort nicht in Dateien, sondern als Einträge in

Datenbanken gespeichert werden. Insbesondere Dokumente, die in Content- und Dokumen-

tenmanagementsystemen, Forschungsdatenbanken etc. abgelegt sind, werden nicht in ein-

zelnen Dateien verwaltet Somit ist eine Zugriffskontrolle mit einer feineren Granularität als auf

Dateiebene erforderlich. Zudem sind ggf. weitere Operationen, z.B. Freigabeprozeduren, zu

berücksichtigen, die auf Dateiebene nicht oder nur schwierig abgebildet werden können.

Tatsächlich haben sich Anwendungen, deren Zugriffsschutz auf den Funktionen sicherer

Betriebssysteme nicht auf breiter Front durchgesetzt (vgl. Sandhu 2003, S. 68). Abb. 3-1 zeigt

die verschiedenen Varianten der Implementierung des Reference Monitor.

Abbildung 3-1: Implementierungsvarianten des Reference Monitors

Wenn Daten in einer Datenbank gespeichert werden, ist es zudem denkbar, die Zugriffskon-

trolle auf der Ebene der Datenbank durchzuführen. Grundsätzlich verfügen gängige relatio-

nale Datenbanksysteme (etwa von Informix oder Oracle) über umfangreiche

Sicherheitsfunktionen. Diese ermöglichen es, rollenbasierte Zugriffssteuerungen auf der Ebe-

ne von Tabellen und Datenbankoperationen umzusetzen (vgl. Ferraiolo/Kuhn/Chandramouli

2003b, S. 266 ff.). Dies ermöglicht zwar eine feinere Zugriffssteuerung als auf Betriebssys-

temebene, bei Wissensmanagement-Anwendungen greifen Nutzer jedoch meist nicht direkt


auf die Datenbank zu. Vielmehr nutzen sie Anwendungssysteme, etwa Content Management

Systeme (CMS) oder Skill Management Systeme, die ihrerseits die Datenbank als Speicher-

medium nutzen. Daher ist ein Zugriffsschutz auf Datenbankebene aus mehreren Gründen

problematisch. Zunächst kann er zwar Operationen auf Datenebene abfangen, etwa das

Lesen oder Schreiben in Tabellen. Es ist jedoch nicht möglich, die Weiterverarbeitung der

Daten im Anwendungssystem zu überwachen, um etwa festzulegen, ob ein Nutzer diese

kopieren oder an anderer Stelle speichern kann. Zudem stellt die Verarbeitung von Zugriffs-

verweigerungen des Datenbanksystems ein Problem dar. Diese verursachen herstellerspezifi-

sche Fehlermeldungen, welche vom Anwendungssystem korrekt interpretiert werden

müssten, damit es auch im Fall einer Zugriffsverweigerung in einem konsistenten Zustand

bleibt und eine für den Nutzer verständliche Reaktion zeigen kann. Schließlich stellt die Reali-

sierung des Zugriffsschutzes auch einen Verstoß gegen das Designprinzip der 3-Ebenen-

Architektur dar, da es Funktionen der Anwendungslogik (die Definition und Prüfung von Be-

rechtigungen) in der Datenbank implementiert. Damit wird die funktionale Trennung zwischen

Daten- und Anwendungslogikschicht verletzt.

Da eine Zugriffskontrolle auf Betriebssystem- bzw. Datenbankebene problematisch ist, wird

der Reference Monitor auf der Ebene des Anwendungssystems umzusetzen sein. Dies wird

bei einer Vielzahl wissensmanagementrelevanter Systeme so gehandhabt, ohne dass der RM

als dezidierte Komponente für den Nutzer in Erscheinung tritt. Anwendungssysteme, die über

integrierte Zugriffskontrollfunktionen verfügen, überprüfen die Zulässigkeit von angefragten

Operationen. Der für die Überprüfung zuständige Teil der Software übernimmt damit die Funk-

tion eines Reference Monitor.

Dies ist beispielsweise bei CMS der Fall. Diese können Funktionen bzw. Rollen verwalten, die

bestimmte Verantwortlichkeiten im Publikationsprozess abbilden. Dabei kann der Zugriff auf

Operationen (etwa Bearbeiten oder Freischalten) und Objekte (Texte, Layouts) geregelt wer-

den, die eng auf die Aufgaben des Systems abgestimmt sind (vgl. Bodendorf 2003, S. 88).

Auf ähnliche Weise können in Workflow Management Systemen Zuständigkeiten und relevan-

te Ressourcen für Gruppen von Mitarbeitern definiert werden. Dabei ist es möglich, die Aus-

führung bestimmter Aktionen auf autorisierte Mitarbeiter (-gruppen) zu beschränken. Das

Workflowsystem überprüft dabei bei Nutzerzugriffen auf bestimmte Funktionen, ob der Nutzer

über die erforderliche Rolle verfügt (vgl. z.B. Ahn et al. 2000). Grundsätzlich steht bei

Workflow-Systemen aber die Zuordnung der Aufgaben zu den relevanten Mitarbeitern im

Vordergrund, nicht der Schutz von Inhalten vor unautorisierten Zugriffen.

Auch die großen, marktgängigen Groupware-Pakete verfügen über integrierte Zugriffsschutz-

mechanismen auf Anwendungsebene, wobei im allgemeinen Rollenbasierte Konzepte unter-


stützt werden (vgl. Hansen/Neumann 2001, S. 442). Das marktführende System, Lotus No-

tes/Domino, unterstützt beispielsweise Berechtigungen auf der Ebene von Servern, Daten-

banken oder einzelnen Dokumenten, die wiederum nach unterschiedlichen Funktionen

unterteilt werden können. Auf der Serverebene kann beispielsweise festgelegt werden, welche

Nutzer Anfragen an welchen Port eines Servers stellen dürfen. Auf Dokumentenebene kann

unter anderem festgelegt werden, dass bestimmte Teile von Dokumenten nur von autorisier-

ten Nutzern eingesehen werden dürfen oder dass ein Verschicken von Dokumenten an ande-

re Clients eine digitale Signatur zur Identifikation des Absenders erfordert. Dabei ist die die

Veränderung der ACLs auf Administratoren beschränkt, die wiederum in unterschiedliche

Kompetenzbereiche eingeteilt werden können (vgl. Tanenbaum/Steen 2002, S. 690 ff. sowie

ausführlich Tworek/Chiesa 2004).

Auch in Portalsystemen sind meist eigene Rechteverwaltungskomponenten enthalten. Diese

definieren, ähnlich wie in CMS, Gruppen von Nutzern, denen jeweils spezifische Portalfunkti-

onen zugänglich sind (vgl. Puschmann 2003, S. 99 ff.). Der Portalserver des IBM WebSphere

Portal kontrolliert beispielsweise alle Zugriffe innerhalb des Portals. Dazu gibt es ein Portlet,

mit Zugriffsrechte verwaltet werden können. Zugriffe auf die über das Portal erreichbaren

Ressourcen, etwa Funktionen von ERP-Software, können auf der Ebene von Portalkompo-

nenten rollenspezifisch freigegeben werden. Daneben können auch Funktionen des Portals

(z.B. durchsuchen, anzeigen ändern, personalisieren, löschen, verschieben und sperren) auf

Seitenebene gezielt beschränkt werden. Zudem können Hierarchien von Administratorrechten

festgelegt werden (vgl. IBM Corp. 2004).

Wenn eine Rechteverwaltung auf Anwendungsebene erfolgt, müssen die Rechte jeweils

anwendungsspezifisch definiert und vergeben werden. Dabei nutzt jede Anwendung bzw.

jedes Anwendungspaket einen eigenen Reference Monitor. Es ist anzumerken, dass sich die

Zugriffskontrolle auf Anwendungsebene oft von der Zugriffskontrolle auf unteren Ebenen in

sofern unterscheidet, als nicht zulässige Zugriffe bzw. Operationen nicht mit einer Fehlermel-

dung quittiert werden, sondern auf der Ebene der Benutzeroberfläche ausgeblendet werden

und somit von vorneherein nicht ausgeführt werden können.

3.2 Umsetzungsvarianten der Access Control Database

Auch für die Speicherung der Zugriffskontrolldaten, also der Subjekte, Rollen und Privilegien

existieren verschiedenen Ansätze. Dabei kann zwischen eher zentralen Ansätzen in Form von

Verzeichnisdiensten und eher dezentralen Varianten unterschieden werden.


Verzeichnisdienste kommen in erster Linie bei der Zugriffskontrolle auf Betriebssystemebene

zum Einsatz. Ein Verzeichnisdienst ist eine leseoptimierte Datenbank, in der Bindungen zwi-

schen Namen von Objekten und Attributen gespeichert und durchsucht werden können (vgl.

Coulouris/Dollimore/Kindberg 2002, S. 434 ff.). Dabei werden die Daten in hierarchischen

Bäumen gespeichert. In einem Verzeichnisdienst können zum einen die in einem Netzwerk

verfügbaren Ressourcen mit ihren ACLs und zum anderen die Benutzer mit weiteren Attribu-

ten (etwa Gruppenzugehörigkeiten und Passwörtern) gespeichert werden. Die Attribute sind

dabei nicht festgelegt, sondern können vom Administrator des Verzeichnisdienstes definiert

werden. Es existiert eine große Anzahl kommerzieller und freier Implementierungen von Ver-

zeichnisdiensten, die sich jedoch bezüglich der internen Struktur (hierarchische Bäume) äh-

neln und über standardisierte Schnittstellen verfügen (z.B. LDAP, vgl. Kap. 3.3). Beispiele sind

MS Active Directory, Novell eDirectory oder Netscape Directory Server. Der Verzeichnisdienst

kann auch als Speichermedium für den Zugriffsschutz auf Anwendungsebene dienen. Ver-

zeichnisdienste werden insbesondere in großen Unternehmen mit hohen Nutzerzahlen einge-

setzt, in denen ein zentrales Nutzermanagement gewünscht oder notwendig ist. Sie werden

primär dazu genutzt, Passwörter für alle angeschlossenen Anwendungen zentral zu verwalten

und zu ändern und erlauben den Aufbau von Single-Sign-On Funktionen. Zudem ermöglichen

sie eine zentrale Überwachung und Verwaltung der im Verzeichnis festgelegten Berechtigun-

gen. Diese Funktionen können auch im Wissensmanagement genutzt werden, etwa um den

Zugriff auf eine große Zahl von Speichersystemen (Content- und Dokumentenmanagement,

Groupware etc.) zu vereinfachen und zu vereinheitlichen.

Alternativ kann die Access Control Database auch komplett in einer Anwendung umgesetzt

werden. In diesem Fall enthält das Anwendungssystem sowohl die Daten über die Nutzer als

auch die ACL der einzelnen Ressourcen. Dies ist etwa bei der internen Zugriffskontrolle von

Lotus Notes/Domino der Fall (vgl. Tanenbaum/Steen 2002, S. 690). Anwendungsspezifische

Sicherheitsmechanismen sind derzeit weit verbreitet und werden in zahlreichen Groupware-

und Portalsystemen verwendet, um den Zugriff auf einzelne Systemfunktionen einzuschrän-

ken. Diese können eng auf Funktionen der jeweiligen Anwendung abgestimmt werden, verur-

sachen aber Probleme hinsichtlich der Verwaltung.

Zudem sind Kombinationen dieser Ansätze möglich, da die Access Control Database nicht

notwendigerweise als physische Einheit implementiert werden muss. So besteht zum Beispiel

die Möglichkeit, in einem zentralen Verzeichnisdienst Nutzer und Rollenzugehörigkeiten zu

speichern. Bei einer Anfrage durch einen Nutzer werden nun diese Rollenzugehörigkeiten von

einem Anwendungssystem geprüft. Dazu wird kontrolliert, ob die intern gespeicherte ACL des

angefragten Objektes eine Zugriffserlaubnis für eine der Rollen des Nutzers enthält (vgl. z.B.

Park/Ahn/Sandhu 2001). Ähnlich nutzen auch viele Portalsysteme LDAP-Verzeichnisse zur


Übernahme von Nutzerdaten, verfügen aber weiterhin über eigene Rollenverwaltungen (vgl.

Puschmann 2003, S. 98; Eberhardt et al. 2002, S. 48 ff.). Die folgende Abbildung zeigt die

Varianten im Überblick. Diese Variante kann sinnvoll sein, wenn die Nutzerdaten zur Verein-

fachung der Administration zentralisiert werden sollen, gleichzeitig jedoch keine zentrale

Verwaltung der Rechte gewünscht wird. Dies kann beispielsweise der Fall sein, wenn beste-

hende Anwendungssysteme genutzt werden sollen, die zwar die Nutzerdaten über eine

Schnittstelle aus dem Verzeichnis beziehen können, jedoch weiterhin eine interne Verwaltung

der Berechtigungen benötigen.

Abbildung 3-2: Implementierungsvarianten der Access Control Database

3.3 Standards für den anwendungs- und unternehmensübergreifenden Zugriffs-schutz

Beim Wissensmanagement in Kooperationen muss die Zugriffskontrolle über mehrere An-

wendungen und über mehrere Partner verteilt erfolgen. Also ist der Austausch von Zugriffs-

kontrollinformationen notwendig, wenn diese nicht in jedem eingesetzten Anwendungssystem

einzeln gepflegt werden sollen. Für diesen Austausch sind entsprechende Standards erforder-

lich.

Insbesondere kann zwar die Zugriffskontrolldatenbank für mehrere Anwendungen ganz oder

teilweise zusammengefasst werden. Zugleich ist es jedoch für eine fein granulare Kontrolle

notwendig, dass der Reference Monitor anwendungsspezifische Funktionen kontrollieren

kann. Wenn mehrere Anwendungen, welche ggf. von unterschiedlichen Anbietern stammen,

eine gemeinsame Access Control Database nutzen sollen, sind Standards erforderlich, die die

Definition universeller Schnittstellen zur ACD erlauben.

Einer der wichtigsten Standards im Bereich des Zugriffsschutzes ist das Lightweight Directory

Access Protocol (LDAP). Es hat sich als Standardprotokoll für den Zugriff auf Verzeichnis-

dienste etabliert. Ursprünglich wurde es für einen vereinfachten Zugriff auf Verzeichnisse nach


dem X.500-Standard über TCP/IP entwickelt, mittlerweile wird es aber von allen gängigen

Verzeichnisdiensten unterstützt (vgl. Park/Ahn/Sandhu 2001, S. 21). Die mittels LDAP abzu-

fragenden Verzeichniseinträge bestehen aus Objekten, die eine Sammlung von Attributen

enthalten und Informationen über ein reales Objekt repräsentieren. Die Attribute können hin-

sichtlich Bedeutung und Syntax erweitert werden und somit genutzt werden, um beliebige

Informationen über Objekte zu speichern. Die von einem Verzeichnis verwendeten Objekte

und ihre Attribute werden in einem Schema festgelegt, das bei einer Anfrage übermittelt wird.

Es existieren einige Schemata mit festgelegten Beschreibungselementen (vgl. z.B. RFC 2252;

RFC 2256). Diese enthalten im Allgemeinen Attribute zur Beschreibung von Personen bzw.

Organisationen (etwa Distinguished Names, Organisationseinheiten, Adressen, Zertifikate

etc.), jedoch kaum zugriffskontrollspezifische Attribute. Für die Nutzung und Interpretation

weiterer Attribute, die etwa anwendungsspezifische Zugriffsrechte enthalten, sind folglich

gesonderte Übereinkünfte zu treffen (vgl. Tuttle/Ehlenberger 2004, S. 33).

Eine Alternative zu LDAP stellt die XML-basierte Directory Services Markup Language

(DSML) dar (vgl. OASIS 2001; Tuttle/Ehlenberger 2004, S. 639 ff.). Sie kann ebenfalls zur

Interaktion mit Verzeichnissen genutzt werden und besitzt einen mit LDAP vergleichbaren

Funktionsumfang. Da DSML weniger verbreitet ist als LDAP stellt sich die Frage, ob durch

den Einsatz dieses Standards ein Zusatznutzen realisierbar ist, der über die Interpretierbarkeit

durch XML-basierte Anwendungen hinausgeht.

LDAP hat zwar weite Verbreitung erreicht, es kann aber nur eine Teilaufgabe, nämlich den

Zugriff auf die Access Control Database abdecken. Die Entwicklung weiterer Standards im

Bereich des Austausches von Zugriffskontrolldaten hat erst in jüngster Zeit begonnen. Dabei

sind insbesondere SAML und XACML von Bedeutung, die im Folgenden erläutert werden (vgl.

Coetzee/Eloff 2003, S. 287).

Die Security Assertion Markup Language SAML dient dazu, Informationen über Benutze-

rauthentifikation, -autorisierung, und –eigenschaften zu übertragen. Damit soll es beim Einsatz

von SAML in Single-Sign-On Systemen möglich sein, eine Anmeldung an einem System

vorzunehmen und die Anmeldeinformationen in sicherer, standardisierter Form an andere

Systeme zu übermitteln, die damit keine erneuten Prüfungen mehr vornehmen müssen. Damit

können auch Sicherheitssysteme unterschiedlicher Hersteller zur Authentifizierung und Auto-

risierung gemischt werden (vgl. OASIS 2004; Macvittie 2003, S. 71 ff.). Dabei standardisiert

SAML ähnlich wie LDAP jedoch nur das Übertragungsformat, nicht jedoch konkrete Inhalte

der zu übertragenden Nutzereigenschaften. Die bisherigen Implementierungen von SAML

haben eher den Charakter von Forschungsprototypen (vgl. Jeong 2004, S. 891 ff.;

Shin/Jeong/Shin 2004, S. 557 ff.), eine Unterstützung in kommerzieller Anwendungssoftware

ist bislang eher selten. Allerdings haben namhafte Softwarehersteller (etwa Microsoft, Novell


und Sun ihre Unterstützung zugesagt und auch die Liberty Alliance nutzt SAML für ihren

Identitätsmanagement-Ansatz. Ob der Standard größere praktische Bedeutung finden wird ist

bleibt jedoch abzuwarten.

XACML (eXtensible Access Control Markup Language) ist ein Standard, der eine Syntax zur

Formulierung konkreter Zugriffskontrollstrategien bereitstellt (vgl. Lorch et al. 2003, S. 26).

Insbesondere können Attribute und Funktionen zu Ihrer Auswertung bei der Formulierung von

Zugriffsregeln genutzt werden. Dabei gibt es eine Reihe von Standarddatentypen und –

funktionen, es sind aber auch Erweiterungen möglich. Im Konzept von XACML kann eine

Policy Enforcement Point genannte Softwarekomponente Beschreibungen über den zugrei-

fenden Nutzer und den gewünschten Zugriff an einen Policy Decision Point senden, der auf-

grund der vom Administrator festgelegten Zugangsregeln die Autorisierungsentscheidung

übernimmt. Damit können Regeln an zentraler Stelle verwaltet, aber von unterschiedlichen

Anwendungen genutzt werden. Es existieren prototypische Implementierungen (vgl. z.B. Sun

Microsystems Inc. 2003; Lorch et al. 2003, S. 25 ff.; Park/Moon/Sohn 2003, S. 112 ff.), bislang

wird XACML jedoch kaum von kommerziellen Anwendungssystemen unterstützt. Zudem

fehlen nutzerfreundliche Werkzeuge zur Erstellung und Prüfung der Kontrollstrategien (vgl.

Lorch et al. 2003, S. 34).

SAML und XACML sind für den Aufbau verteilter Wissensmanagement-Lösungen interessant,

da sie das Problem des Austausches von Zugriffskontrollinformationen über Plattformen und

Anwendungen hinweg lösen können. Insbesondere XACML bietet das Potenzial, ein übergrei-

fendes Rechtemanagement für mehrere im Wissensmanagement gemeinsam genutzte An-

wendungen zu realisieren. Dafür ist jedoch eine Integration von Standardkonformen

Reference Monitors in die einzelnen Anwendungen ebenso erforderlich, wie eine Einigung auf

die zu nutzenden Beschreibungssystematiken für Nutzer und Ressourcen. Abb. 3-3 enthält

eine Übersicht über die relevanten Standards.


Standard Einsatzgebiet

LDAP • Zugriff auf Verzeichnisdienste

• Abfrage und Manipulation Informationen in Verzeichnissen

DSML • Zugriff auf Verzeichnisdienste

• Ähnlich LDAP, aber XML-basiert

SAML • Übertragung von Zugriffskontrollinformationen

• Standardformat zur Weitergabe von Anmeldedaten

• Keine Festlegung der Inhalte

XACML • Formulierung von Zugriffsregeln

• Regelformulierung mit Attributen und Funktionen zu ihrer Auswertung

• Enthält Architekturkonzept zur Verteilung der Kontrollaufgaben

Abbildung 3-3: Standards für die Zugriffskontrolle

4 Anforderungen an den Zugriffsschutz

Im Folgenden werden Wissensmanagementsysteme für Kooperationen betrachtet. Eine Ko-

operation ist dabei als gemeinsame Leistungserstellung mehrerer Partner definiert, die recht-

lich und wirtschaftlich selbstständig sind. Die Partner entfalten also auch außerhalb der

Kooperation wirtschaftliche Aktivitäten (vgl. Veil/Hess 2002, S. 270 ff.)

Der in ein Wissensmanagement-System für Kooperationen integrierte Zugriffsschutz hat einer

Reihe von Anforderungen zu genügen. Dabei sind zunächst die allgemeinen Ansprüche an

die Informationstechnologie für das Wissensmanagement in Kooperationen zu erfüllen (vgl.

ausführlich Schmaltz/Hagenhoff 2003a). In diesem Zusammenhang sind die wesentlichen

Anforderungen plattformübergreifende Integrationsfähigkeit, flexible Einbindung, variable

Konfiguration, Überbrückung sprachlicher Differenzen und partnerspezifische Zugriffssteue-

rung. Zudem ist zu untersuchen, ob weitere, für das Anwendungsgebiet spezifische Anforde-

rungen zu berücksichtigen sind.

Im Rahmen der Anforderungen an Wissensmanagement-Systeme für Kooperationen ist zu-

nächst erforderlich, dass die Systeme plattformübergreifend integrierbar sind. Der Zugriffs-

schutz in einem Wissensmanagement-System sollte von einer möglichst großen Zahl

unterschiedlicher Systeme angesprochen werden können. Dies gilt insbesondere für die

Verwaltung von Nutzern und Rollen, denn die Anlage und Pflege dieser Daten ist aufwändig

und sollte nicht redundant erfolgen. Daher sollte das System es erlauben, die Datenverwal-

tung an zentraler Stelle vorzunehmen und existierende Strukturen, insbesondere Nutzerver-

waltungssysteme weiter zu verwenden. Dafür ist ein Zugriff auf die bestehenden


Nutzermanagementsysteme der Partner, die ggf. unterschiedliche Schnittstellen und Be-

schreibungssystematiken einsetzen, erforderlich. Um den Austausch zu erleichtern, müssen

existierende Standards unterstützt werden, sowohl für den Zugriff auf die Speichersysteme, in

denen die Zugriffsdaten hinterlegt sind, als auch für die Kodierung von Zugriffsrechten (vgl.

Coetzee/Eloff 2003, S. 392).

Die Anforderung nach einer flexiblen Einbindung bedeutet insbesondere, dass sich die

Systeme von Kooperationspartnern, die in die Kooperation eintreten bzw. sie wieder verlas-

sen, ohne großen Programmieraufwand an ein kooperatives System ankoppeln und sich

wieder davon trennen lassen. Diese Forderung beinhaltet auch, dass die einzelnen Partner-

systeme soweit möglich auch ohne eine zentrale Instanz lauffähig sind. Dies ist sinnvoll, da

ein Wissensmanagement-System so unabhängig von der Kooperation weiter genutzt werden

kann. Damit wird das Risiko der Investition, welches ein potenzielles Nutzungshemmnis dar-

stellt, gesenkt. Diese Anforderung ist insbesondere in dynamischen Kooperationsformen

relevant, in denen die Zusammensetzung der teilnehmenden Unternehmen veränderlich ist.

Allerdings ist anzumerken, dass auch sehr dynamische Kooperationsformen, etwa virtuelle

Unternehmen, in der Regel nur auf der Auftragsebene ständigen Veränderungen unterworfen

sind, während die Beziehungsebene, also der Pool der Teilnehmer, längerfristig existiert (vgl.

Wohlgemuth 2002, S. 19). Begrenzte Investitionen in kooperationsübergreifende Systeme

können also auch hier sinnvoll sein.

Als dritte Anforderung müssen Wissensmanagement-Systeme variabel konfigurierbar sein.

Sie sollen den Aufgabenträgern Wissen und Informationen bedarfsgerecht zur verfügung

stellen und auch in dynamischen Kooperationen einfach an wechselnde Bedürfnisse anzu-

passen sein (Schmaltz/Hagenhoff 2003a, S. 30). Diese Anforderung bezieht sich primär auf

die Präsentation der enthaltenen Inhalte. Daher ist sie für den Zugriffsschutz nicht relevant.

Allerdings sollte die Präsentationsschicht, insbesondere bei der Anzeige von Suchergebnis-

sen und Inhalten, die Zugriffsberechtigungen des jeweiligen Nutzers auswerten. So kann die

Anzeige von Treffern, die wegen fehlender Zugriffsrechte nicht nutzbar sind, unterdrückt

werden. Dies hilft, die Informationslast zu reduzieren.

Viertens soll IT im Wissensmanagement zur Überbrückung sprachlicher Differenzen bei-

tragen. Diese Anforderung ist für ein Zugriffsschutzsystem nicht relevant, da der Zugriff auf

eine Ressource von Ihrem Verständnis bzw. Inhalt unabhängig zu regeln ist.

Den größten Beitrag können Zugriffsschutzsysteme für die fünfte Anforderung, die flexible

Steuerung des Zugriffs, leisten. Hier bilden die Sicherheitssysteme idealerweise eine Quer-

schnittsfunktion im Sinne eines Reference Monitors, die den Zugriff auf alle schützenswerten

Ressourcen kontrolliert. Die Möglichkeiten des Zugriffsschutzes stellen sich wie folgt dar:


In einem Wissensmanagementsystem sind grundsätzlich drei Arten von Ressourcen zu unter-

scheiden. Zum einen existieren Inhalte, die für alle Kooperationsteilnehmer zugänglich sein

sollen und daher keinen Zugriffsschutz benötigen bzw. allen Kooperationspartnern offen

stehen. Beispielhaft sind hier etwa Beschreibungen der eigenen Leistungen zu nennen, an-

hand derer die Partner weitere Kooperationspotenziale abschätzen können. Als zweite Grup-

pe sind Inhalte zu nennen, die nicht geteilt werden sollen und nur internen Nutzern zu öffnen

sind. Dies können etwa Verfahrensdokumentationen sein, die eine Explizierung von Unter-

nehmensgeheimnissen darstellen und aufgrund ihrer kritischen Bedeutung für den Unterneh-

menserfolg nicht veröffentlicht werden können. Als dritte Gruppe sind Ressourcen zu nennen,

die selektiv freigegeben werden sollen. Diese Problematik ist insbesondere dann relevant,

wenn Kompetenzen im Netzwerk mehrfach besetzt sind (vgl. Schmaltz/Hagenhoff 2003b, S.

31). Dann kann es erforderlich sein, dass Wissen (z.B. interne Produkt- oder Verfahrensdo-

kumentationen) zwar den Partnern in einem aktuellen Projekt geöffnet werden sollen, nicht

jedoch anderen Kooperationsteilnehmern.

Um eine selektive Freigabe von Wissen zu ermöglichen, ist es zudem erforderlich, die Festle-

gung der Zugriffsrechte mit feiner Granularität vorzunehmen. Wenn einzelne Ressourcen (z.B.

Dokumente) freigegeben werden können, nicht nur ganze Speichersysteme, haben die Part-

ner die Möglichkeit, einander gezielt die erforderlichen Inhalte zugänglich zu machen, ohne

dabei pauschale Freigaben erteilen zu müssen oder Einzeldokumente händisch zu selektieren

und zu versenden.

Da das Wissen auf verschiedene Partnerunternehmen verteilt ist, für die es jeweils intellektu-

elles Kapital und damit eine Form von Eigentum darstellt (vgl. Oelsnitz/Hahmann 2003, S. 23),

müssen die Partner zudem unabhängig über die Zugriffsstrategie entscheiden können. Daher

muss der Zugriffsschutz auf der Ebene der Partnerunternehmen die Möglichkeit bieten, flexi-

bel unterschiedliche Zugriffsstrategien zu definieren. Dies steht im Gegensatz zu herkömmli-

chen Unternehmensstrukturen, wo diese Strategien im Allgemeinen zentral für die gesamte

Organisation definiert werden (vgl. z.B. Ferraiolo/Kuhn/Chandramouli 2003b, S. 39 ff.).

Damit sind die kooperationsspezifischen Anforderungen abgedeckt. In der Literatur zu

Zugriffskontrollsystemen werden zudem weitere Anforderungen genannt, die im Zusammen-

hang mit diesen Systemen als wesentlich erachtet werden. Dabei werden insbesondere Nut-

zerfreundlichkeit und ein angemessenes Kosten-Nutzen-Verhältnis erwähnt (vgl.

Stiemerling/Won/Wulf 2000, S. 319; Stevens/Wulf 2001, S. 376 Sandhu 2003, S. 66).

Gerade wenn die Zugriffsrechte dezentral von unterschiedlichen Verantwortlichen definiert

werden, ist es notwendig, dass diese Festlegungen für die Nutzer einfach nachvollziehbar

sind, um fehlerhafte Zuordnungen zu vermeiden. Insbesondere müssen die Auswirkungen


bestehender Privilegienzuordnungen und die Auswirkungen von Änderungen deutlich werden.

Zudem sollte die Nutzung der Sicherheitsmechanismen für den Nutzer möglichst transparent

und mit wenig Aufwand im täglichen Einsatz verbunden sein. Dies ist im Bereich des Wis-

sensmanagement besonders wichtig, da die Nutzung von Wissensmanagement-Systemen oft

als Zusatzbelastung wahrgenommen wird. Um Nutzungsbarrieren abzubauen, sollten die

Sicherheitsmechanismen daher möglichst im Hintergrund und ohne manuelle Eingriffe funkti-

onieren. Außerdem können die Zugriffsrechte bei entsprechend designten Schnittstellen von

Nutzern ohne DV-Fachkenntnisse administriert werden. Da somit keine speziell geschulten

Spezialisten benötigt werden, wird die Delegation der Rechteverwaltung an dezentrale Ver-

antwortliche vereinfacht (vgl. Hildman/Bartholdt 1999, S. 108 ff.).

Bei der Konzeption des Sicherheitskonzeptes ist zudem zu beachten, dass Sicherheit und

Zugriffsschutz nicht absolut sein können. Der gewährte Schutz muss gegen Faktoren wie

Kosten und Nutzerfreundlichkeit abgewogen werden (vgl. Sandhu 2003, S. 68). Da das Kos-

ten-Nutzen-Verhältnis von Anwendungssystemen im betrieblichen Einsatz stets gewahrt

bleiben muss (vgl. Kütz 2003, S. 125 ff.), ist dieser Aspekt schon bei der Planung eines

Zugriffsschutzkonzeptes mit einzubeziehen. Die folgende Tabelle (Abb. 4-1) fasst die Anforde-

rungen zusammen.


Anforderung Wesentliche Aspekte

Plattformübergreifende Integ-

rierbarkeit

• Nutzung existierender Nutzermanagement-

und Zugriffsschutzsysteme

• Vermeidung redundanter Datenpflege

Flexible Koppelung • Einbindung neuer Partner mit geringem Pro-

grammieraufwand

• Nutzbarkeit der Systeme auch außerhalb der

Kooperation

Koo

pera

tions

spez

ifisc

he A

nfor

deru

ngen

Flexibler Zugriffsschutz • Selektive Freigabe

• Feine Granularität der Zugriffsrechte

• Individuelle Zugriffsstrategien der Partner

Nutzerfreundliche Bedienung • Einfache Nachvollziehbarkeit von Rechte-

entscheidungen

• Geringer Nutzungsaufwand im Alltag

Allg

emei

ne A

nfor

-

deru

ngen

Angemessener Aufwand • Kosten sind gegen Schutzbedürfnisse abzu-

wägen

Abbildung 4-1: Anforderungen an Zugriffskontrollsysteme für Kooperationen

5 Beispielhafte Rechtemanagementarchitekturen

Im folgenden Kapitel werden beispielhafte Konzepte für den rollenbasierten Zugriffsschutz in

Wissensmanagementsystemen entworfen. Dazu ist zunächst zu klären, welche grundlegende

Architektur einem solchen System zugrunde liegt, denn Faktoren wie die Speicherung von

Inhalten und Nutzerdaten haben wesentlichen Einfluss auf die Umsetzung des Zugriffs-

schutzes.

Für den Aufbau eines Wissensmanagement-Systems sind unterschiedliche Varianten denk-

bar, die in Abhängigkeit von der Art der Kooperation Vor- und Nachteile haben. Dabei kann

grundsätzlich zwischen zentralisierten Systemen und verteilten Systemen unterschieden

werden.


5.1 Zentralisierte Wissensmanagement-Systeme

Im Folgenden wird zunächst der grundlegende Aufbau eines zentralisierten Wissens-

management-Systems mit möglichen Einsatzbereichen beleuchtet. Danach werden Umset-

zungsvarianten der wesentlichen Komponenten, Reference Monitor und Access Control

Database, beleuchtet. Zudem werden die Gestaltung des Rollenmodells und die Administra-

tion der Rollen und untersucht.

5.1.1 Grundlegender Aufbau und Einsatzbereiche

Zentralisierte Systeme zeichnen sich dadurch aus, dass alle wesentlichen Funktionen in

einem allein stehenden, von allen Kooperationspartnern genutzten System umgesetzt werden.

Dabei gibt es einen zentralen Server zu Speicherung und Suche von Dokumenten, für Kom-

munikationsfunktionen, Werkzeuge zur Zusammenarbeit etc., auf den die einzelnen Nutzer

aus den Partnerunternehmen über einen Web-Browser oder eine andere, mit geringen Funk-

tionen ausgestattete Client-Software zugreifen.

Diese Architekturen sind zum einen in fokalen Partnerschaften sinnvoll, in denen ein Partner

die Führung der Leistungserstellung innehat und wesentliche koordinierende Funktionen

sowohl bezüglich der Leistungserstellung als auch bezüglich des IT-Einsatzes ausübt (vgl.

z.B. Laartz 2002, S. 19; Stevens/Wulf 2002, S. 196 ff.). Diese Systeme sind oft mit Extranets

(vgl. Horn 1999, S. 265) vergleichbar, bei denen der fokale Partner seine interne IT für koope-

rierende Unternehmen öffnet. Alternativ können sie auch von der Netzwerkleitung oder einem

beauftragten externen Dienstleister betrieben werden. Sie sind für Netzwerke attraktiv, deren

Partner nur geringe Bereitschaft für Investitionen in gemeinsam genutzte Systeme zeigen,

etwa in Kooperationen von sehr kleinen Partnern. Zudem können zentrale Systeme auch

dann eingesetzt werden, wenn die Partner stark heterogene Prozesse und IT-Infrastrukturen

nutzen (vgl. Staiger 2003, S. 32 ff.).

Grundsätzlich bieten diese Systeme eher geringes Potenzial für einen Wissensaustausch

zwischen Partnern. Im Fall eines fokalen Partners, der das gemeinsam genutzte System

kontrolliert, bestehen Hindernisse für einen intensiven Wissensaustausch. Zum einen kann die

Nutzung solcher Systeme die Angst vor Kontrollverlusten stärken, da eigenes Wissen in ei-

nem „fremden“ System gespeichert wird. Dies ist insbesondere bei wettbewerbsrelevantem

Wissen problematisch, das bei fehlenden Kontrollmöglichkeiten wahrscheinlich nicht zur

Verfügung gestellt wird. Zudem kann das System, im Gegensatz zu den in Kap. 4 spezifizier-

ten Anforderungen, nicht außerhalb der Kooperation weitergenutzt werden, da die Infrastruk-

tur unter der Kontrolle des Betreibers bleibt. Verlässt ein Partner also die Kooperation, kann er


die Inhalte, die er in das System eingebracht hat, nicht länger nutzen. Die Investitionen in die

Kodifizierung von Wissen sowie in die Bestückung des Systems mit Inhalten von sind so mit

höherem Risiko behaftet.

Um in einem zentralisierten Wissensmanagement-System eine Zugriffskontrolle umzusetzen,

ist zunächst ein Reference Monitor erforderlich, der die Zugriffsinformationen auswertet.

5.1.2 Implementierungsvarianten des Reference Monitor

Um die Anforderungen einer feingranularen Zugriffskontrolle zu erfüllen, muss der Reference

Monitor die Rechte auf der Ebene von Anwendungsfunktionen verwalten können (vgl. Kap.

3.1). Um dies zu erreichen sind zwei Varianten denkbar: Zum einen kann der RM Teil der

einzelnen Anwendungen des Wissensmanagement-Systems sein. In diesem Fall erfolgt die

Prüfung der Zugriffsrechte in jeder Anwendung durch eine eigenständige Komponente. Alter-

nativ ist es möglich, einen zentralen Reference Monitor zu implementieren, der alle Anwen-

dungszugriffe prüft. Er muss dann allerdings eng mit den Anwendungen verzahnt sein und die

Möglichkeit bieten, spezifische Funktionen bzw. Funktionsgruppen abzubilden.

Der Rückgriff auf Reference Monitors in den einzelnen Anwendungen ermöglicht die Weiter-

nutzung entsprechender Komponenten der Anwendungssysteme. Allerdings kann in diesem

Fall nicht gewährleistet werden, dass alle Anwendungen eine gewählte Kontrollstrategie um-

setzen können, da RM-Implementierungen oft auf eine bestimmte Strategie festgelegt sind

und proprietäre Mechanismen nutzen (vgl. Coetzee/Eloff 2003, S. 290). Ob es möglich ist,

anwendungsübergreifende Rollen zu definieren, hängt in diesem Fall davon ab, ob in einer

zentralen Zugriffskontrolldatenbank ein gemeinsames Modell der möglichen Privilegien ver-

waltet werden kann. Nur wenn es möglich ist, die Privilegien für alle Systeme an zentraler

Stelle zu verwalten und die Einzelanwendungen auf die gemeinsame ACD zugreifen können,

können Rollenmodelle definiert werden, die alle Systemfunktionen umfassen. Dies ist aber

wichtig, um die Übersichtlichkeit und damit die einfache Nutzbarkeit des Systems zu gewähr-

leisten, da ansonsten eine Vielzahl einzelner Rollenmodelle für die einzelnen Anwendungen

gepflegt werden müssen.

Ein zentraler Reference Monitor kann, ähnlich wie in dem XACML zugrunde liegenden Modell,

so gestaltet sein, dass die Anwendungen nur noch eine Komponente enthalten, die den

Zugriff erlaubt oder verweigert. Die Zugriffsentscheidung, bei der die Angaben zur angeforder-

ten Aktion mit den Privilegien abgeglichen werden, wird jedoch von einer übergreifenden

Systemkomponente getroffen, die der einzelnen Anwendung nur noch eine ja/nein Antwort

übermittelt. Der zentrale Reference Monitor überwacht so alle Funktionen der einzelnen An-


wendungen. Dies hat den Vorteil, dass für ihn ein Modell der Zugriffsrechte definiert werden

kann, das Zugriffe auf alle Anwendungen abdeckt. So können in einer Rolle alle relevanten

Aktivitäten, unabhängig von der Anwendung, in der sie umgesetzt sind, zusammengefasst

werden. Für einen dezentralen Content-Verantwortlichen können die erlaubten Zugriffe etwa

Publikationsfreigaben im CMS sowie die Administration eines Forums umfassen. Dabei muss

der zentrale RM einen rollenbasierten Zugriffsschutz implementieren, der die Definition belie-

biger Kontrollstrategien erlaubt, um der Anforderung der Umsetzung partnerspezifischer Poli-

cies gerecht zu werden. Die folgende Tabelle (Abb. 5-1) fasst zusammen, wie die

unterschiedlichen Varianten des Reference Monitor die Anforderungen erfüllen.

Anforderung Reference Monitor in Anwen-

dung

Zentraler Reference Monitor

Plattformübergreifende

Integrierbarkeit

• Entfällt da zentrales System

Flexible Koppelung • Keine autonome Nutzung, da zentrales System

Flexibler Zugriffs-

schutz

• Feine Granularität da anwen-

dungsspezifisch

• Feine Granularität bei entspre-

chender Modellierung

Nutzerfreundliche

Bedienung

• Unabhängig von Ort des RM, abhängig von Rollenmodell und

Schnittstelle

Angemessener Auf-

wand

• Weiternutzung existierender

Strukturen

• Modifikation der Anwendungen

erforderlich

Abbildung 5-1: Varianten des Reference Monitor

5.1.3 Implementierungsvarianten der Access Control Database

Die Access Control Database enthält die Zugriffsinformationen, die der RM auswertet. Sie

kann, wie in Abschnitt 3.2 ausgeführt, für die einzelnen Anwendungen ganz oder teilweise

zentralisiert werden. Eine Datenhaltung, die vollständig auf der Ebene einzelner Anwendun-

gen erfolgt ist wenig sinnvoll, da die Nutzerinformationen mehrfach gespeichert werden und

so Datenredundanzen entstehen. Zudem widerspricht sie dem Ziel der Übersichtlichkeit und

einfachen Administrierbarkeit und erschwert es durch das Fehlen einer zentralen Authentifizie-

rung, das System zu nutzen.

Gegebenenfalls können anwendungsspezifischen Sicherheitsmechanismen mittels eines

Single-Sign-On (SSO) Produktes zusammengefasst werden. In diesem Bereich existieren

zum einen Lösungen, die primär Zugriffskontrollsysteme auf Betriebssystemebene zusam-


menfassen (vgl. z.B. Ferraiolo/Kuhn/Chandramouli 2003b, S. 274 ff.). Diese können in einer

zentralen Managementsoftware vorgenommene Änderungen in die ACDs untergeordneter

Systeme schreiben und eine zentrale Nutzerauthentifizierung vornehmen. Ihre Management-

fähigkeiten sind jedoch auf explizit unterstützte Plattformen beschränkt und unterliegen den-

selben Einschränkungen wie die Zugriffskontrolle auf Betriebssystembasis (vgl. Kap. 3.1).

Ähnliches gilt für Web Access Control Werkzeuge, deren Funktionen sich zudem auf den

Zugriff auf Hyperlinks konzentrieren (vgl. Black 2002). Daher sind die handelsüblichen Single-

Sign-On Werkzeuge für den hier verfolgten Einsatzzweck nur wenig geeignet.

Folglich ist es erforderlich, spezifisch für das Wissensmanagement-System geeignete Varian-

ten der ACD zu implementieren.

Eine Zusammenfassung von Zugriffskontrollinformationen für unterschiedliche Anwendungen

erfordert natürlich, dass diese über entsprechende Schnittstellen zur gemeinsamen ACD

verfügen. Ist dies gegeben, so ist es zunächst denkbar, die Nutzerinformationen inklusive der

Rollenzuordnungen an zentraler Stelle zu speichern (etwa in einem Verzeichnisdienst). Diese

Lösung bietet den Vorteil, dass die Authentifizierung an zentraler Stelle möglich wird, was

wiederum die Nutzbarkeit des Systems vereinfacht. Zudem können kompatible Verzeichnisse

externer Partner an das gemeinsame Verzeichnis angebunden werden, was eine mehrfache

Speicherung von Nutzerdaten überflüssig macht.

Weiterhin müssen die Zuordnungen der Privilegien, also der konkreten Zugriffsrechte zu den

Rollen gespeichert werden. Wenn dies in den einzelnen Anwendungen erfolgt, müssen die

Zuordnungen auch über die anwendungsspezifischen Mechanismen gepflegt werden. Dann

ist es aber nicht möglich, anwendungsübergreifende Rollen festzulegen. Dadurch werden die

Pflege der Rollen und die Überwachung der vergebenen Rechte erschwert.

Abbildung 5-2: Zugriffsschutz im zentralisierten System

Es ist also sinnvoller, alle Nutzer-, Rollen- und Privilegieninformationen in einer Datenbank

zusammenzufassen. Für diese Aufgabe muss zunächst ein Modell aller zu kontrollierenden


Funktionen erstellt werden (vgl. Lorch et al. 2003, S. 26). Anhand dieses Modells können nun

Rollen mit Privilegien für alle definierten Funktionen angelegt und an zentraler Stelle verwaltet

werden. Abbildung 5-2 zeigt den Aufbau des dargestellten Systems: in einer gemeinsamen

ACD werden Subjekte (Nutzer), Ihre Rollen und die den Rollen zugeordneten Privilegien

abgelegt. Ein zentraler Reference Monitor kontrolliert den Zugriff auf alle Anwendungen. Eine

Übersicht über die verschiedenen ACD-Varianten liefert Abb. 5-3.

Anforderung Zentrale Nutzerdaten, Privile-

gienzuordnungen in AS

Gemeinsame ACD für Nutzer,

Rollen und Privilegien


Integrierbarkeit

• Entfällt da zentrales System


Flexibler Zugriffs-

schutz

• Flexibilität ist unabhängig von Speicherung der Zugriffsdaten,

hängt von Rechtemodell und Administration ab

Nutzerfreundliche

Bedienung

• eingeschränkt durch verteilte

Pflege der Privilegien

• ermöglicht SSO

• gut durch zentrale Rollenadmi-

nistration

• ermöglicht SSO

Angemessener Auf-

wand

• separate Softwarekomponente

erforderlich

• separate Softwarekomponente

erforderlich

• einfachere Administration

Abbildung 5-3: Varianten der ACD

5.1.4 Ausgestaltung des Rollenmodells

Neben den Mechanismen zur Zugriffskontrolle ist auch zu klären, wie das verwendete Rol-

lenmodell gestaltet wird. Im klassischen RBAC-Modell (vgl. Sandhu et al. 1996, S. 38 ff.) sind

verschiedene Varianten vorgesehen. Insbesondere kann das Grundmodell um Rollenhierar-

chien und Constraints (Einschränkungen der Zuweisung) erweitert werden. Rollenhierarchien

ermöglichen es, Privilegien von untergeordneten an übergeordnete Rollen zu vererben. Wenn

zum Beispiel eine Rolle „Nutzer Allgemein“ existiert, die Zugriffsrechte auf alle öffentlichen

Dokumente hat, so können diese Rechte an die übergeordneten Gruppen „Nutzer Controlling“

und „Nutzer Marketing“ vererbt werden. Somit müssen sie nicht erneut angelegt werden, was

zu einem erheblich reduzierten Administrationsaufwand führt. Dies ist insbesondere Vorteilhaft

wenn Rollen häufig neu angelegt bzw. geändert werden. Allerdings wird Vererbungs-

mechanismen stellenweise eine fehlende Übersichtlichkeit vorgeworfen, da insbesondere bei


umfangreichen, mehrstufigen Modellen für die Nutzer nicht immer erkennbar ist, welche Privi-

legien wo angelegt wurden und welchen Effekt sie haben (vgl. Stiemerling/Won/Wulf 2000, S.

320). Zudem wird die Flexibilität durch die Übertragung der Rechte aus anderen Rollen gerin-

ger, da übergeordnete Rollen in einem Separaten Ast des Rollenbaumes angelegt werden

müssen, wenn sie Privilegien von untergeordneten Rollen nicht erhalten sollen (etwa im Bei-

spiel des Geschäftsführers, der im gegensatz zum ihm unterstellten Buchhalter Rechnungsda-

ten nur lesen, nicht aber schreiben darf).

Constraints ermöglichen es, die Zuweisung von Nutzern zu Rollen auf verschiedene Weise zu

beschränken (vgl. Sandhu 1998, S. 240 ff.). Dazu existieren drei Arten von Constraints: ge-

genseitige Ausschlüsse, Kardinalitäten und Vorbedingungen. Mit dem gegenseitigen Aus-

schluss von Rollen kann definiert werden, dass zwei Rollen nicht dem gleichen Nutzer

zugewiesen werden können (z.B. kann ein Nutzer nicht gleichzeitig Buchhalter und Buchprü-

fer sein). Über Kardinalitäten für Rollen kann festgelegt werden, dass Rollen nur eine festge-

legte Anzahl von Mitgliedern haben dürfen (etwa dass es nur ein Mitglied der Rolle

„Abteilungsleiter“ gibt). Vorbedingungen können für die Zuweisung zu einer Rolle benötigte

Kompetenzen ausdrücken (ein Nutzer muss bspw. erst Projektmitglied sein, bevor er Projekt-

manager werden kann). Ob diese Mechanismen für Wissensmanagement-Anwendungen

benötigt werden, ist im Einzelfall zu entscheiden. Insbesondere der gegenseitige Ausschluss

von Rollen kann in Einzelfällen erforderlich sein, beispielsweise durch regulatorische Erfor-

dernisse wie im Kreditwesen oder in Unternehmensberatungen (vgl. Ferraio-

lo/Kuhn/Chandramouli 2003b, S. 44). Im Fall von Kardinalitäten und Vorbedingungen dürfte

ein Verzicht jedoch möglich sein, zumal diese Beschränkungen auch auf organisatorischer

Ebene abgefangen werden können.

Prinzipiell besteht ein Trade-off, wenn die Ausdrucksstärke des Rollenmodells erhöht wird. Auf

der einen Seite wird die Administration insbesondere bei umfangreichen Rollenmodellen

vereinfacht, da Vererbungen die Anzahl der manuell anzulegenden Rechte reduzieren und

Constraints den Administrator bei der Anlage neuer Nutzer entlasten. Auf der anderen Seite

wird ein ausdrucksstärkeres Modell tendenziell unübersichtlicher. Zudem steigt der Implemen-

tierungsaufwand mit der Anzahl der Funktionen.

Abb. 5-5 fasst die unterschiedlichen Varianten des Rollenmodells zusammen.


Anforderung Einfaches Rollen-

modell

Rollenhierarchien Constraints


Integrierbarkeit

• Unabhängig vom Rollenmodell, da technisch bedingt

Flexible Koppelung • Unabhängig vom Rollenmodell, da technisch bedingt

Flexibler Zugriffsschutz • Ermöglicht starke

Differenzierung der

Rollen

• Differenzierung

eingeschränkt durch

vererbte Rechte

• Verstärkte Aus-

druckskraft des

Modells

Nutzerfreundliche

Bedienung

• Trade-off zwischen Ausdrucksstärke und Übersichtlichkeit

• Mächtiges Modell vereinfacht Anlage neuer Nutzer/Rollen

Angemessener Auf-

wand

• Trade-off zwischen höheren Implementierungskosten bei größerer

Ausdruckskraft und geringerem Administrationsaufwand

Abbildung 5-4: Varianten des Rollenmodells

5.1.5 Administration der Zugriffsrechte

Schließlich ist festzulegen, wie die Administration, also die Zuweisung der Rollen zu Nutzern

und der Privilegien zu Rollen vorgenommen wird. In einer zentralisierten Struktur ist zunächst

davon auszugehen, dass eine oberste Instanz existiert, die als Administrator für die Zuwei-

sung von Rollen und Privilegien verantwortlich ist bzw. die Verantwortung an andere delegie-

ren kann (vgl. Ferraiolo/Kuhn/Chandramouli 2003b, S. 158 ff.).

Die Zuweisung von Rollen zu Nutzern kann durch einen zentralen Administrator erfolgen. In

diesem Fall müssen alle Nutzer durch den Betreiber im System angelegt und zu Rollen zuge-

ordnet werden. Alternativ kann dies auch an Verantwortliche in den Partnerunternehmen

delegiert werden. Da das Rollenmodell für alle Beteiligten gleich ist, bietet eine Dezentralisie-

rung hier keine Vorteile bezüglich der partnerspezifischen Gestaltung der Zugriffskontrolle.

Allerdings kann sie bei großen Nutzerzahlen den Administrator entlasten, was jedoch mit

verringerten Kontrollmöglichkeiten einhergeht.

Um die Forderung nach möglichst weitgehender Kontrolle der Teilnehmer über ihre Inhalte zu

erreichen, ist es jedoch erforderlich, ihnen die Definition der Privilegien für die von ihnen

erstellten Inhalte zu überlassen. Um dieses Ziel zu erreichen, kann für jeden Partner ein ge-

schützter Bereich im System eingerichtet werden. Die Möglichkeit, Rechte für diesen Bereich

zuzuweisen, wird an den jeweiligen Partner delegiert. Inhalte können damit selektiv nach

eigenem Ermessen freigeben werden. Allerdings hat der zentrale Rollenadministrator, und


damit der Betreiber des Systems, nach wie vor die Oberhoheit über die Zugriffsrechte, da er

die Delgierung der Rechte für die privaten Bereiche (ggf. missbräuchlich) verändern kann (vgl.

Abb. 5-4).

Anforderung Zentralisierte Privilegienfestle-

gung

Dezentralisierte Privilegienfest-

legung


Integrierbarkeit

• entfällt, da zentrales System


Flexibler Zugriffs-

schutz

• Keine partnerspezifischen

Festlegungen möglich

• Kontrolle über Zugriff auf ge-

schützte Bereiche

• Eingeschränkt durch zentrale

Administration

Nutzerfreundliche

Bedienung

• Komplex durch große Anzahl

von Privilegien

• Delegation vereinfacht Admi-

nistrationsaufgabe

Angemessener Auf-

wand

• Einfach umzusetzen • Erfordert ggf. System-

erweiterung um verteilte Admi-

nistration

Abbildung 5-5: Varianten der Privilegienverwaltung

Um eine möglichst feine Granularität der Zugriffsrechte zu erreichen, müssen Privilegien nicht

nur für einzelne Systemfunktionen, sondern auch für einzelne Ressourcen (etwa Dokumente)

festgelegt werden. Dies kann auf Partnerebene jeweils durch einen Administrator für den

geschützten Bereich geschehen, es kann aber auch an eine untergeordnete Rolle (z.B. die

eines Autors) delegiert werden. Um konsistente Privilegienzuweisungen für gleichartige Inhal-

te zu gewährleisten, erscheint es sinnvoll, Standardeinstellungen für Inhalteklassen festzule-

gen. So kann zum Beispiel der Einblick in Angebotskalkulationen auf interne Nutzer

beschränkt werden, während Projektstatusberichte grundsätzlich für Projektteilnehmer offen

stehen. Die Festlegung bzw. Änderung dieser Voreinstellungen kann der Administratorrolle

übertragen werden. So wird der einzelne Nutzer von der expliziten Definition der Rechte für

die von ihm erstellten Inhalte entlastet. Alternativ kann auch der Ort der Publikation über die

Rechtezuweisung entscheiden, indem etwa in einem virtuellen „Team Room“ abgelegte Inhal-

te standardmäßig für alle Teammitglieder freigegeben werden, aber von Nutzern außerhalb

des Teams nicht einzusehen sind.

Die Anforderungen an das Rechtemenagement können in der hier behandelten zentralisierten

Architektur nur teilweise erfüllt werden: Die Nutzung existierender Nutzermanagementsysteme


ist über die Einbindung externer Verzeichnisdienste zumindest eingeschränkt möglich. Eben-

so kann durch eine zentrale Nutzerdatenbank die redundante Pflege von Nutzerdaten vermie-

den werden. Da keine echte Integration externer WM-Systeme stattfindet, ist die Einbindung

neuer Partner unproblematisch. Auch die partnerspezifische Gestaltung der Rechte ist mög-

lich, wird jedoch durch die zentrale Administratorrolle eingeschränkt. Nachteilig wirkt sich

jedoch aus, dass Systeme nach dieser Architektur an den fokalen Partner und damit an den

Bestand der Kooperation gebunden sind. Dies kann die Bereitschaft zur Nutzung erheblich

schmälern.

5.2 Dezentrale Wissensmanagement-Systeme

Auch für dezentrale Wissensmanagement-Systeme ist zunächst der generelle Aufbau zu

klären. Danach werden, analog zu Kap. 5.1, Umsetzungsvarianten für RM und ACD unter-

sucht, gefolgt von Gestaltung und Administration des Rechtemodells.

5.2.1 Grundlegender Aufbau und Einsatzbereiche

Als Alternative zum Einsatz eines zentralen Systems kann es sinnvoll sein, eine Integration

der Wissensmanagement-Systeme der Kooperationspartner anzustreben. Ein solches Vorge-

hen ist angebracht, wenn die Kooperationsbeziehungen stabil sind, so dass Investitionen in

Integrationsmaßnahmen langfristig genutzt werden können (vgl. Staiger 2003). Zudem ist eine

Integration attraktiv, wenn die einzelnen Partner bereits über große Bestände von Ressourcen

verfügen, die Kooperationsteilnehmern zugänglich gemacht werden sollen. Über die Schaf-

fung von Schnittstellen kann dann eine redundante Speicherung von Inhalten vermieden

werden. Zudem können Inhalte von Partnern für die eigenen Mitarbeiter transparent in beste-

hende Systeme zur Wissenssuche eingebunden werden. Wenn die aufwändige Mehrfachsu-

che in verschiedenen Systemen entfällt, wird der Zugriff auf relevantes Wissen für die

Mitarbeiter erheblich vereinfacht.

Die Nutzung dezentraler Systeme kann zudem die Angst vor Kontrollverlusten bei den Betei-

ligten verringern, denn grundsätzlich behält jeder Teilnehmer die physische Kontrolle über die

Infrastruktur zur Speicherung seines Wissens. So können Inhalte auch nach Ende der Koope-

ration weiter genutzt werden. Die Spezifität der Investition und damit das Risiko sinken, wenn

das genutzte Wissensmanagementsystem mit dem Ende der Kooperation nicht in der Hand

einer dritten Partei bleibt. Da die Teilnehmer ferner auch wirtschaftliche Aktivitäten außerhalb

der Kooperation verfolgen, ist es sinnvoll, wenn das System auch für nicht kooperationsbezo-


gene Inhalte genutzt werden kann, um den Mitarbeitern einen einheitlichen Zugriff auf alles

Unternehmenswissen zu bieten, unabhängig von den Aktivitäten bei denen es entstanden ist.

Es ist allerdings unwahrscheinlich, dass Kooperationsteilnehmer für diese Aufgabe ein Sys-

tem nutzen, dass sie nicht kontrollieren, denn dann würde ein Ende der Kooperation den

Verlust aller Inhalte bedeuten. Also sind dezentrale Systeme sinnvoll, auf die die einzelnen

Partner jederzeit vollen Zugriff haben. Sind die Wissensmanagement-Anwendungen auch für

kooperationsunabhängige Aktivitäten nutzbar, tritt zudem eine weitere Verringerung des In-

vestitionsrisikos ein, was die Bereitschaft der Partner zum Aufbau von Wissensmanagement-

Lösungen erhöhen kann.

Einschränkend ist zu erwähnen, dass die Integration von Wissensmanagementsystemen

immer mit hohem Aufwand verbunden ist, da eine Vielzahl von Schnittstellen geschaffen

werden muss und interorganisationale Abstimmungsprozesse (etwa hinsichtlich der zu ver-

wendenden Datenformate) erforderlich sind. Daher ist eine solche enge Koppelung nur dann

sinnvoll, wenn die Kooperation stabil ist und im Rahmen der Zusammenarbeit eine erhebliche

Wertschöpfung erfolgt. Nur dann rechtfertigt der Gewinn aus der Zusammenarbeit die Investi-

tionen in gemeinsame Systeme.

In diesem Fall ist es jedoch erforderlich, die Sicherheitsmechanismen nicht nur innerhalb der

eigenen Plattform zu etablieren, sondern auch Zugriffe von externen Systemen zu steuern.

5.2.2 Implementierungsvarianten des Reference Monitor

Ähnlich wie im Fall der zentralisierten Systeme ist es zunächst sinnvoll, auch in den dezentra-

len Teilsystemen jeweils einen Reference Monitor zu etablieren, der ihre Funktionen komplett

überwachen kann, damit die einzelnen Partner systemweite Rollenkonzepte definieren kön-

nen. Ein zentraler RM, der sämtliche Funktionen aller Partnersysteme überwacht, erscheint

aber nicht sinnvoll. Zum einen widerspricht er dem Ziel, das System unabhängig von der

Kooperation nutzbar zu gestalten, da die Einzelsysteme dann zwingend auf die zentrale Kom-

ponente angewiesen wären. Zum anderen entsteht in dieser Konstellation wieder eine zentra-

le Administratorposition, die alle Zugriffsentscheidungen manipulieren kann. Schließlich ist

auch zu berücksichtigen, dass ein kooperationsweit integrierter Reference Monitor aufgrund

der großen Zahl anzubindender Systeme einen extrem hohen Implementierungsaufwand und

eine sehr aufwändige Modellierung der Rollen und Privilegien (inklusive aller möglichen

Zugriffe auf alle Teilsysteme) zur Folge hat (vgl. Abb. 5-6). Für den RM innerhalb der Partner-

systeme gilt jedoch das in Kap. 5.1 gesagte.


Anforderung Reference Monitor auf Koopera-

tionsebene

Reference Monitor auf Partner-

ebene


Integrierbarkeit

• Erfordert Zugriff aller Anwen-

dungen auf RM

• Keine Abstimmung der Partner-

systeme nötig

Flexible Koppelung • Keine eigenständige Nutzung • Eigenständige Nutzung möglich

Flexibler Zugriffs-

schutz

• Feine Granularität bei entsprechender Modellierung

Nutzerfreundliche

Bedienung

• Unabhängig von Ort des RM, abhängig von Rollenmodell und

Schnittstelle

Angemessener Auf-

wand

• Integration aller Partnersysteme

notwendig

• Keine Koppelung der Partner

auf RM-Ebene erforderlich

Abbildung 5-6: Varianten des Reference Monitor im dezentralen System

Für die dezentralen Reference Monitors ist es zunächst unerheblich, ob Nutzer von intern

oder extern zugreifen. Sie überprüfen lediglich, ob der Nutzer die für die angefragte Aktion

erforderliche Rolle hat. Diese Informationen über externe Nutzer müssen in einer Access

Control Database abrufbar sein.

5.2.3 Implementierungsvarianten der Access Control Database

Im Folgenden ist es angebracht, die Zuordnungen von Rollen zu Nutzern sowie von Privile-

gien zu Rollen getrennt voneinander zu betrachten, da sie in unterschiedlicher Form gespei-

chert werden können. Die Nutzer und ihre Rollen können auf der Ebene der Kooperation an

zentraler Stelle hinterlegt werden. Dabei werden dem Nutzer zunächst nur Rollen zugewiesen,

die seinen Funktionen im Netzwerk entsprechen. Welche Zugriffsrechte die einzelnen Rollen

dann haben, kann auf der Ebene der Partner dann individuell bestimmt werden, um eine

eigenständige Verwaltung der Zugriffsrechte zu ermöglichen.

Für die Speicherung der Nutzerinformationen und Rollenzuordnungen kommen wieder unter-

schiedliche Varianten in Frage. Dabei erscheint es sinnvoll, die relevanten Daten so zu spei-

chern, dass sie für alle Partner zugänglich sind. So kann der Forderung nach geringen

Datenredundanzen entsprochen werden. Fehlt etwa eine zentrale Nutzerdatenbank, müssten

alle potenziell zugreifenden Nutzer in den Systemen aller Partner gepflegt werden und sich

dort authentifizieren.

Für die gemeinsame Datenspeicherung ist es möglich, einen kooperationsweiten Verzeichnis-

dienst anzulegen, in dem Nutzerdaten und Rollenzuordnungen gespeichert werden. Ist dieser


als zentrale Komponente ausgestaltet, ergibt sich wieder das Problem, dass die einzelnen

Teilsysteme zwingend auf das gemeinsame Verzeichnis angewiesen sind und nicht autonom

funktionieren. Zudem ist eine koordinierende Stelle für Administration und Wartung des Ver-

zeichnisses erforderlich.

Alternativ können dezentrale, bei den Partnern angesiedelte (und ggf. bereits existierende)

Verzeichnisdienste in einer Baumstruktur zusammengefasst werden. Dies erlaubt z.B. MS

Active Directory (vgl. Maslo/Feller/Simon 2003, S. 311 ff.). Dabei enthält ein gemeinsames,

zentrales Wurzelverzeichnis Informationen darüber, welche anderen Verzeichnisse zur Ko-

operation gehören. Diese anderen Verzeichnisse werden bei den Partnern eingerichtet und

gewartet und sind auch ohne das Wurzelverzeichnis lauffähig. Authentifizierungen an einem

der Verzeichnisse können auch von anderen Verzeichnissen aus der zusammengefassten

Struktur als gültig anerkannt werden. Wenn sich ein Nutzer also an seinem „Heimatverzeich-

nis“ anmeldet, werden die dort gespeicherten Informationen (insbesondere die Rollen) auch

von den Verzeichnissen anderer Partner als gültig anerkannt. Zwischen den Partnern muss

dann allerdings dahingehend Vertrauen bestehen, dass die Nutzer korrekt authentifiziert

werden und ihnen die richtigen Rollen zugewiesen werden. Dies kann ggf. durch Einblick in

die Verzeichnisstruktur der Partner oder ex post durch Logfileanalyse kontrolliert werden. Für

diese Variante ist es zudem erforderlich, dass sich die Partner auf ein gemeinsames Rollen-

modell einigen, in dem die möglichen Aufgabenbereiche festgehalten werden. Bei einigen

Verzeichnisdiensten muss zudem das Schema (das Datenmodell der Verzeichniseinträge) für

alle Teile der Verzeichnisstruktur, also für alle Partner, identisch sein (vgl. z.B. Mas-

lo/Feller/Simon 2003 , S. 231 ff.; Tuttle/Ehlenberger 2004, S. 63 ff.). Diese Voraussetzung

setzt der Einbindung bestehender Verzeichnisse enge Grenzen, da die Festlegung der Daten-

strukturen erfahrungsgemäß problematisch ist und oft unternehmensspezifisch erfolgt (vgl.

vgl. z.B. Maslo/Feller/Simon 2003 , S. 238).

In den Verzeichniseinträgen der einzelnen Nutzer können unterschiedliche Rollenmitglied-

schaften abgelegt werden. Dies können unternehmensübergreifende Rollen im Rahmen der

Kooperation sein, beispielsweise Projektmitgliedschaften oder Unternehmenszugehörigkeiten.

Sie können aber auch um partnerindividuelle, interne Einträge ergänzt werden.

Die Zuordnung von Rollen zu Privilegien sollte, immer lokal erfolgen, um zum einen der For-

derung nach individuell gestaltbaren Zugriffsstrategien gerecht zu werden und zum anderen

die Administration durch die dezentrale Verwaltung zu vereinfachen. Die Speicherung der

Zuordnung von Privilegien zu Rollen erfolgt dann in den Partnersystemen. Die ACLs der

einzelnen Ressourcen können Privilegien für kooperationsweit gültige und für lokale Rollen

enthalten (vgl. Abb. 5-3).


Abbildung 5-7: Zugriffsschutz im dezentralen System mit Verzeichnisdienst

Kommt der Einsatz eines Verzeichnisdienstes nicht in Frage, etwa weil inkompatible Systeme

der Partner weiter verwendet werden sollen, ist auch eine Speicherung der Rollenzuordnun-

gen in Zertifikaten möglich. Zertifikate können auch genutzt werden, wenn eine sehr große

Zahl von Nutzern und Partnern verwaltet wird und die Administration eines Verzeichnisses

aus diesem Grund zu aufwändig wird. Zertifikate stammen aus dem Bereich der Public Key

Infrastrukturen (PKI, vgl. Tanenbaum 2003, S. 828 ff.) und dienen dazu, Aussagen über den

Besitzer des Zertifikates in gesicherter Form zu übertragen. Zertifikate können einen öffentli-

chen Schlüssel an einen Nutzer binden (im Fall von Identitätszertifikaten), sie können aber

auch zur verbindlichen Festlegung anderer Eigenschaften des Nutzers, wie etwa Rollenzuge-

hörigkeiten, dienen (im Fall von Attributzertifikaten). Diese Zertifikate werden von einer ver-

trauenswürdigen Instanz (Trust Center) digital signiert, so dass jeder, der dem Trust Center

vertraut, auch den im Zertifikat gemachten Angaben vertrauen kann (vgl. Zhou/Meinel 2004,

S. 536 ff; Chadwick/Otenko 2003, S. 277 ff.).

Eine zertifikatsbasierte Lösung hat einige Vorteile gegenüber Verzeichnisdiensten. So benöti-

gen die Zertifikate keinen geschützten zentralen Speicher. Da sie durch die Signatur manipu-

lationssicher sind, können sie dezentral bei den Nutzern bzw. in den Partnersystemen

gespeichert werden. Außerdem entfällt bei einer zertifikatsbasierten Lösung die Anbindung

der Partner an einen Verzeichnisdienst. Jeder Nutzer, der bei seiner Anfrage ein gültiges

Zertifikat übermittelt, kann für Zugriffe autorisiert werden. Ein Zugriff auf den Verzeichnisdienst

in dem seine Nutzerdaten gespeichert werden entfällt . Abb. 5-3 zeigt diese Variante, wobei


die Anwendungssysteme aus Gründen der Übersichtlichkeit ausgespart wurden. Die Zertifika-

te werden nach der Vergabe beim Trustcenter nicht mehr gespeichert.

Abbildung 5-8: Zugriffsschutz im dezentralen System mit Zertifikaten

Allerdings ergeben sich bei zertifikatsbasierten Lösungen auch Nachteile. Zunächst ist die

Nutzerfreundlichkeit von existierenden PKI-Ansätzen oft schwach. Insbesondere die Vergabe

von Zertifikaten an die Nutzer ist problematisch (vgl. Gutmann 2003, S. 45 ff.). Um der Anfor-

derung an eine einfache Nutzbarkeit gerecht zu werden, müssten die Vergabe, Verwaltung

und Übergabe der Zertifikate für den Nutzer weitgehend transparent ablaufen. Dies erfordert

wiederum eine enge Integration der Zertifikatsmechanismen in die sie nutzenden Applikatio-

nen, was den Aufwand für die Implementierung der Systeme erheblich steigen lässt. Der

Vorteil einer einfachen Anbindung neuer Nutzer wird dadurch weitgehend zunichte macht, da

keine Standardkomponenten für die Zertifikateverwaltung existieren. Zudem ist der Rückruf

nicht mehr gültiger Zertifikate problematisch (vgl. Gutmann 2002, S. 44 ff.). Die üblicherweise

verwendeten Listen zurückgerufener Zertifikate erlauben hier keine vollständige und zuverläs-

sige Kontrolle. Weiterhin ist es in diesem Szenario zwar nicht mehr erforderlich, einen ge-

meinsam nutzbaren Verzeichnisdienst aufzubauen, die Kooperation muss jedoch ein

Trustcenter zur Vergabe der Zertifikate einrichten und betreiben, das die Korrektheit der bean-

tragten Zertifikate prüft und sie signiert. Ob der Aufwand für den Betrieb im Vergleich zu ei-

nem Verzeichnisdienst signifikant reduziert werden kann ist also offen.

Ähnlich wie im Fall der Verzeichniseinträge gibt es zudem auch für die Attributzertifikate kaum

Standards für die zu verwendenden Beschreibungselemente, diese müssen also zunächst

von den Kooperationsteilnehmern ausgehandelt werden.


Schließlich ist zu erwähnen, dass in der Literatur vorgeschlagen wird, die Zertifikate der de-

zentralen Teilnehmer in einem gemeinsamen LDAP-Verzeichnis zu speichern (vgl.

Zhou/Meinel 2004; Chadwick 2003. Damit lässt sich die Rückrufproblematik umgehen, da

ungültige Zertifikate aus dem Verzeichnis gelöscht werden können. Zudem sind die Sicher-

heitsanforderungen an das Verzeichnis erheblich geringer, da die Zertifikate selbst manipula-

tionssicher sind. Da bei dieser Variante jedoch sowohl ein Verzeichnisdienst als auch ein

Trustcenter betrieben werden müssen, ist sie mit hohem Aufwand verbunden, dem nur ein

geringer Zusatznutzen gegenüber steht.

Eine Übersicht der verschiedenen Varianten der Speicherung von Nutzerdaten wird in der

folgenden Tabelle gegeben (Abb. 5-9).

Anforderung Zentrales Verzeich-

nis

Dezentrales Ver-

zeichnis

Zertifikate


Integrierbarkeit

• Entfällt, da zentral • Eingeschränkt

möglich

• (Speicher-) System-

unabhängig

Flexible Koppelung • Keine eigen-

ständige Nutzung

• Eigenständige

Nutzung möglich

• Eigenständige

Nutzung möglich

Flexibler Zugriffsschutz • Zentrale Administ-

ration erforderlich

• Dezentral administ-

rierbar

• Trustcenter für

Vergabe erfor-

derlich

Nutzerfreundliche

Bedienung

• Zentrale Administ-

ration aufwändig

• Datenpflege durch

Partner möglich

• Zertifikatshandling

muss in AS integ-

riert werden

Angemessener Auf-

wand

• Einfach mit Stan-

dardsoftware um-

setzbar

• Dezentralisierung

erhöht Implemen-

tierungskosten

• Wenig Standard-

software für Zertif i-

kate

Abbildung 5-9: Varianten der dezentralen Speicherung der Nutzerdaten

Die Speicherung der Rollen-Privilegien-Zuordnungen sollte auf der Ebene der Partner erfol-

gen. Ein zentrales Verzeichnis für die Rollen-Privilegien-Zuordnungen ist nicht sinnvoll, da

erhebliche Integrationsaktivitäten der Partner verlangt und einen eigenständigen Betrieb der

systeme unmöglich macht. Zudem bietet es keinen Mehrnutzen, da die Zugriffsrechte ohnehin

dezentral verwaltet werden. Für die Partner bietet es keinen Mehrwert, zu wissen, wie die

Rechte anderer Partner ausgestaltet sind. Zudem kann eine solche Transparenz aus ge-

schäftsstrategischen Gründen unerwünscht sein (vgl. Hildman/Bartholdt 1999, S. 108).


5.2.4 Ausgestaltung des Rollenmodells

Für die Ausgestaltung des Rollenmodells gilt zunächst das in Abschnitt 5.1.4 gesagte, da sich

die Anforderungen an die Ausdrucksstärke und die Einfachheit des Modellierungssystems in

den beiden Szenarien nicht unterscheiden.

Allerdings wird auch hier ein gemeinsames Rollenmodell für die Kooperation vorausgesetzt.

Wenn es nicht gelingt bzw. nicht gewünscht ist, ein solches Modell zu definieren, ist es mög-

lich, auch die Zuordnung von Nutzern zu Rollen dezentral vorzunehmen. Dazu kann eine

Variante des Zugriffsschutzmodells eingesetzt werden, die im Bereich der Entwicklung verteil-

ter Systeme verstärkt diskutiert wird (vgl. Thompson/Essiari/Mudumbai 2003; Lorch et al.

2003). In diesem Fall werden in Verzeichnissen bzw. Zertifikaten nicht Rollenzugehörigkeiten,

sondern zugriffsrelevante Eigenschaften von Nutzern, sog. Credentials, abgelegt (vgl. Pernul

2004, S. 98 ff.; Coetzee/Eloff 2003, S. 290 ff.). Diese können z.B. Unternehmenszugehörig-

keit, Projektmitgliedschaft oder Lieferverhältnisse beinhalten. Durch Kombinationen dieser

Credentials kann dann jeder Partner lokale Rollen definieren, die den externen Nutzern beim

Zugriff zugewiesen werden. Dadurch entfallen die Pflege der Rollenzuweisungen für einzelne

Nutzer und der Aufbau eines kooperationsweiten Rollenmodells. Die Partner erhalten in die-

sem Modell größere Freiheit bei der Rollendefinition und -vergabe, so können etwa Rollen

beim Vorliegen bestimmter Kombinationen von Attributen zugewiesen werden (z.B. Projekt-

mitgliedschaft in Projekt A und Firmenangehörigkeit in Firma X). Allerdings ist auch in diesem

Fall zumindest eine Einigung auf ein Modell gültiger Credentials erforderlich, um eine maschi-

nelle Interpretation der Eigenschaften zu ermöglichen. Zudem sind die existierenden credenti-

albasierten Systeme weitgehend auf dem Entwicklungsstand von Forschungsprototypen,

Insbesondere existieren nur wenige Anwendungen zur Bestimmung von Rollen bzw. Zugriffs-

rechten anhand von Credentials. Auch Erfahrungen zur Nutzerfreundlichkeit und Transparenz

des Modells liegen nicht vor. Abb. 5-11 enthält einen Vergleich der beiden Varianten.


Anforderung Kooperationsweites Rollenmo-

dell

Credential-basierte Autorisierung


Integrierbarkeit

• Unabhängig vom Rollenmodell, da technisch bedingt

Flexible Koppelung • Unabhängig vom Rollenmodell, da technisch bedingt

Flexibler Zugriffs-

schutz

• Kooperationsweites Modell

erforderlich

• größere Flexibilität bei Rollen-

definition

Nutzerfreundliche

Bedienung

• Abhängig von Ausdrucksstärke

des Modells

• Nicht geklärt

Angemessener Auf-

wand

• Abhängig von Funktionsumfang • Eigenentwicklungen notwendig

Abbildung 5-10: Rollen- und credentialbasierte Autorisierung

5.2.5 Administration der Zugriffsrechte

Die Verwaltung der Zugriffsrechte ist abhängig davon, wie ACD und Rollenmodell ausgestaltet

sind. Dabei vereinfacht eine dezentrale Verzeichnisstruktur die Delegation von Rollen-

zuweisungen, erfordert jedoch Vertrauen zwischen den Partnern. Ist diese nicht gegeben,

müssen die Zuweisungen zentral durch eine vertrauenswürdige Instanz erfolgen. Dies ist auch

im zertifikatsbasierten System notwendig, in dem das Trust Center diese Kontrollfunktion beim

signieren der Zertifikate übernimmt.

Die Verwaltung der Rollen-Privilegien-Zuordnung muss auf der Ebene der Partner erfolgen.

Zum einen können so die individuell erforderlichen Privilegien einfacher bestimmt werden,

zum anderen ermöglicht es die dezentrale Verwaltung, individuelle Strategien festzulegen, die

Inhalte selektiv freigeben und nicht durch Außenstehende manipuliert werden können. So

kann ein ausreichend flexibler Zugriffsschutz realisiert werden (vgl. Abb. 5-10).


Anforderung Zentralisierte Privilegienfestle-

gung

Dezentralisierte Privilegienfest-

legung


Integrierbarkeit

• Integration aller ACDs erforder-

lich

• Privilegienverwaltung und

-speicherung unabhängig

Flexible Koppelung • keine autonome Nutzung bei

zentralem Privilegien-

management

• Privilegienmanagement unab-

hängig

Flexibler Zugriffs-

schutz

• Keine eigenständige Rechte-

zuweisung

• Vollständig unabhängige,

selektive Strategien umsetzbar

Nutzerfreundliche

Bedienung

• Komplex durch große Anzahl

von Privilegien

• Delegation vereinfacht Admi-

nistrationsaufgabe

Angemessener Auf-

wand

• Erfordert Einrichtung zentraler

Managementlösung

• Ggf. Nutzung bestehender

Systeme möglich

Abbildung 5-11: Varianten der Privilegienverwaltung im dezentralen System

Mit einem dezentralen System wird es einfacher möglich, die Anforderungen an den Zugriffs-

schutz zu erfüllen als in einem zentralen System. Um existierende Nutzermanagementsyste-

me zu integrieren und redundante Datenhaltung zu vermeiden, eignet sich eine gemeinsame

Nutzerdatenbank auf der Basis eines Verzeichnisdienstes mit standardisierten Schnittstellen.

Dabei sind jedoch ggf. die Datenschemata zu integrierender Verzeichnisse anzupassen. Sind

die Verzeichnisse hierarchisch so angeordnet, dass jeder Partner die Daten seiner Mitarbeiter

verwaltet, können sie zudem voneinander getrennt weiter genutzt werden.

6 Fazit

Der Aufbau einer partner- und systemübergreifenden Sicherheitsinfrastruktur wird regelmäßig

mit hohem Aufwand verbunden sein, da Schnittstellen zwischen Anwendungen, ggf. vorhan-

denen externen Reference Monitors und Speichersystemen für Nutzer, Rollen und Privilegien

geschaffen werden müssen. Dem gegenüber steht jedoch die Möglichkeit, einen umfassen-

den, anwendungs- und kooperationsübergreifenden Schutz sensiblen Wissens zu erreichen.

Außerdem wird die Usability eines Wissensmanagement-Systems für Sicherheits-

administratoren und Nutzer entscheidend verbessert, wenn sowohl die Administration als

auch Authentifizierung an zentraler Stelle gebündelt werden und nicht verteilt in einer Vielzahl

von Systemen erforderlich sind.


Dabei können zentrale, gemeinsam genutzte Wissensmanagement-Systeme und dezentrale,

gekoppelte Anwendungen die an den Zugriffsschutz gestellten Anforderungen in unterschied-

lichem Maß erfüllen.

Ein zentrales System, auf dass alle Anwender über Browser zugreifen und dass nicht in die

Anwendungslandschaft der Partner integriert ist, vermeidet das Problem, dass unterschiedli-

che Softwareplattformen vom Sicherheitssystem anzusprechen sind. Eine integrierte Lösung

kann hier mit relativ geringem Aufwand Nutzerdaten über Verzeichnisdienste bereitstellen, die

von einer Vielzahl von Anwendungen über Standardschnittstellen angesprochen werden

können.

Allerdings weist das zentrale System den Nachteil auf, dass es fest an die Kooperation ge-

bunden ist und somit keine unabhängige Nutzung erlaubt. Dies erlaubt das gekoppelte Sys-

tem, wenn die Verzeichnisse in einer Hierarchie angeordnet sind oder Zertifikate zur

Speicherung der Nutzerdaten verwendet werden.

Ein flexibler, partnerspezifischer Zugriffsschutz ist in beiden Systemvarianten möglich, wenn

rollenbasierte Zugriffsschutzkonzepte zum Einsatz kommen. In der zentralen Lösung kann die

Administration bestimmter Privilegien delegiert werden, die Eigenständigkeit wird jedoch durch

die Präsenz eines übergeordneten Administrators eingeschränkt. In der dezentralen Lösung

haben die Partner volle Kontrolle über die Zugriffsrechte. Eine credentialbasierte Lösung kann

die Flexibilität durch den Wegfall eines gemeinsamen Rollenmodells weiter flexibilisieren.

Ob die beiden nicht kopperationsspezifischen Anforderungen erfüllt werden ist nicht pauschal

zu beantworten. Grundsätzlich begünstigen dezentrale Systeme die Administration und Nut-

zung, indem Verantwortung an die Partner delegiert wird, die wiederum nur einen Ausschnitt

des Systems zu verwalten haben. Allerdings spielen auch hier nicht betrachtete Faktoren wie

die Benutzerschnittstelle eine wichtige Rolle bei der Usability.

Bezüglich des Aufwandes gilt die oben getroffene Aussage, dass eine Integration von Sicher-

heitssystemen immer aufwändig ist. Dabei ist die zentrale Lösung naturgemäß einfacher zu

realisieren, da Schnittstellen zu den Partnern entfallen. Dieser Ersparnis ist jedoch das erhöh-

te Investitionsrisiko durch die Spezifität des Systems gegenüber zu stellen.

In Abb. 6-1 werden die Aussagen nochmals in Stichworten zusammengefasst.


Anforderung Zentrales Wissensmanagement-

System

Dezentrale Koppelung von

Systemen


Integrierbarkeit

• Nicht relevant • Gemeinsame Nutzerdatenver-

waltung mit Verzeichnisdienst

Flexible Koppelung • Nicht möglich • Möglich mit Verzeichnis-

hierarchie/ Zertifikaten

Flexibler Zugriffs-

schutz

• Möglich durch Delegation,

eingeschränkt durch zentralen

Administrator

• Volle Autonomie bei Privile-

gienverwaltung

Nutzerfreundliche

Bedienung

• Eingeschränkt bei zentraler

Verwaltung

• tendenziell Entlastung durch

dezentrale Administration

Angemessener Auf-

wand

• kostengünstiger, aber spezifi-

sche Investition

• aufwändige Integration, aber

nicht an Kooperation gebunden

Abbildung 6-1: Dezentrales vs. zentrales System


Literaturverzeichnis

Ahn et al. 2000: Ahn, G./Sandhu, R./Kang, M./Park, J.: Injecting RBAC to secure a Web-based work-

flow system, Proceedings of the fifth ACM workshop on Role-based access control, Berlin, Ger-

many 2000, S. 1-10.

Becker 2003: Becker, E.: Digital rights management: technological, economic, legal and political as-

pects, Berlin 2003.

Black 2002: Black, D.: Portal Security: Managing Identities and Relationships in a Competitive Econ-

omy, San Jose, CA 2002.

Bodendorf 2003: Bodendorf, F.: Daten- und Wissensmanagement, Berlin 2003.

Chadwick 2003: Chadwick, D.: Deficiencies in LDAP When Used to Support PKI. In: Association for

Computing Machinery: Communications of the ACM 46 (2003) 3, S. 99-104.

Chadwick/Otenko 2003: Chadwick, D. W./Otenko, A.: The PERMIS X.509 role based privilege man-

agement infrastructure. In: Future generation computer systems 19 (2003) 2, S. 277-290.

Coetzee/Eloff 2003: Coetzee, M./Eloff, J. H. P.: Virtual enterprise access control requirements, Pro-

ceedings of the 2003 annual research conference of the South African institute of computer sci-

entists and information technologists on Enablement through technology, 2003, S. 285-294.

Coulouris/Dollimore/Kindberg 2002: Coulouris, G./Dollimore, J./Kindberg, T.: Verteilte Systeme: Kon-

zepte und Design, 3. Aufl., München 2002.

Damker 2002: Damker, H.: Sicherheitsaspekte von P2P-Anwendungen in Unternehmen, In: Schoder,

D./Fischbach, K./Teichmann, R.: Peer-to-Peer, Berlin 2002, S. 209-228.

Eberhardt et al. 2002: Eberhardt, C. T./Gurzki, T./Hinderer, H./Bullinger, H.: Marktübersicht Portal

Software: für Business-, Enterprise-Portale und E-Collaboration, Stuttgart 2002.

Eckert 2003: Eckert, C.: IT-Sicherheit: Konzept - Verfahren - Protokolle, 2, München 2003.

Ferraiolo/Kuhn/Chandramouli 2003a: Ferraiolo, D. F./Kuhn, D. R./Chandramouli, R.: Role-based access

control, Boston, Mass. 2003.

Gutmann 2002: Gutmann, P.: PKI: It's Not Dead, Just Resting. In: Computer 35 (2002) 8, S. 41-49.

Gutmann 2003: Gutmann, P.: Plug-and-Play PKI: A PKI Your Mother Can Use, Washington, DC 2003.

Hansen/Neumann 2001: Hansen, H. R./Neumann, G.: Grundlagen betrieblicher Informations-

verarbeitung, 8, Stuttgart 2001.

Hildman/Bartholdt 1999: Hildman, T./Bartholdt, J.: Managing Trust between Collaborating Companies

using outsourced Role Based Access Control. In: Association for Computing Machinery / Special

Interest Group on Security Audit and Control: SIGSAC security audit control review, Bd. 5 (1999)

S. 105-112.

Horn 1999: Horn, T.: Internet, Intranet, Extranet: Potentiale im Unternehmen, München 1999.

IBM Corp. 2004: IBM Corp., WebSphere Portal Information Center, URL: http://publib.boulder.ibm.com/

pvc/wp/502/smbi/de/InfoCenter/index.html, Abruf: 28.05.2004.


Jeong 2004: Jeong, J.: Java-Based Single Sign-On Library Supporting SAML (Security Assertion

Markup Language) for Distributed Web Services. In: Lecture notes in computer science 3007

(2004) S. 891-894,.

Kütz 2003: Kütz, M.: Kennzahlen in der IT: Werkzeuge für Controlling und Management, 1, Heidelberg

2003.

Laartz 2002: Laartz, J.: E-Collaboration und Cross-Enterprise Applications - Eine geschäftliche Per-

spektive. In: IM 17 (2002) 4, S. 18-25.

Liu/Safavi-Naini/Sheppard 2003: Liu, Q./Safavi-Naini, R./Sheppard, N. P.: Digital rights management for

content distribution, Proceedings of the Australasian information security workshop conference

on ACSW frontiers 2003, Adelaide, Australia 2003, S. 49-58.

Lorch et al. 2003: Lorch, M./Proctor, S./Lepro, R./Kafura, D./Shah, S.: First experiences using XACML

for access control in distributed systems, Proceedings of the 2003 ACM workshop on XML secu-

rity, Fairfax, Virginia 2003, S. 25-37.

Macvittie 2003: Macvittie, L.: Workshop - Speaking SAML. In: Network computing 14 (2003) 22, S. 71.

Maslo/Feller/Simon 2003: Maslo, A./Feller, P./Simon, A.: Windows Server 2003: Migration, Administra-

tion, Praxistipps, München 2003.

OASIS 2001: OASIS, Directory Services Markup Language (DSML) v2.0 [OASIS 200201], URL:

http://www.oasis-open.org/committees/dsml/docs/DSMLv2.doc, Abruf: 25.5.2004.

OASIS 2004: OASIS, Technical Overview of the OASIS Security Assertion Markup Language (SAML)

V1.1, URL: http://www.oasis-open.org/committees/download.php/6837/sstc-saml-tech-overview-

1.1-cd.pdf, Abruf: 26.5.2004.

Oelsnitz/Hahmann 2003: Oelsnitz, D. v. d./Hahmann, M.: Wissensmanagement: Strategie und Lernen

in wissensbasierten Unternehmen, Stuttgart 2003.

Osborn/Sandhu/Munawer 2000: Osborn, S./Sandhu, R./Munawer, Q.: Configuring role-based access

control to enforce mandatory and discretionary access control policies. In: ACM Trans. Inf. Syst.

Secur. 3 (2000) 2, S. 85-106.

Park 2003: Park, J.: Usage Control: A Unified Framework for Next Generation Access Control, Fairfax,

Virginia 2003.

Park/Ahn/Sandhu 2001: Park, J./Ahn, G./Sandhu, R.: Role-based Access Control on the Web Using

LDAP, Niagara on the Lake, Ontario, Canada 2001.

Park/Moon/Sohn 2003: Park, N./Moon, K./Sohn, S.: Certificate validation service using XKMS for com-

putational grid, Proceedings of the 2003 ACM workshop on XML security, Fairfax, VA 2003, S.

112-120.

Park/Sandhu 2002: Park, J./Sandhu, R.: Towards usage control models: beyond traditional access

control, Proceedings of the seventh ACM symposium on Access control models and technolo-

gies, Monterey, CA 2002, S. 57-64.

Pernul 2004: Pernul, G.: Autorisierung und Zugriffskontrolle bei Wissensportalen. In: Das Wirtschafts-

studium 33 (2004) 1, S. 94-100.

Puschmann 2003: Puschmann, T.: Collaboration Portale, St. Gallen 2003.


Sandhu 1998: Sandhu, R.: Role-based Access Control. In: Advances in computers 46 (1998) S. S. 238-

287.

Sandhu 2001: Sandhu, R.: Future Directions in Role-Based Access Control Models. In: Lecture notes in

computer science 2052 (2001) S. 22-26.

Sandhu 2003: Sandhu, R.: Good-Enough Security. In: IEEE Internet Computing 7 (2003) 1, S. 66-68.

Sandhu et al. 1996: Sandhu, R. S./Coyne, E. J./Feinstein, H. L./Youman, C. E.: Role-Based Access

Control Models. In: Computer 29 (1996) 2, S. 38-48.

Schmaltz/Hagenhoff 2003a: Schmaltz, R./Hagenhoff, S., Informationstechnologie zur Unterstützung des

Wissensmanagements in Kooperationen, Arbeitspapiere der Abt. Wirtschaftsinformatik II, Nr. 9,

2003. (a)

Shin/Jeong/Shin 2004: Shin, D./Jeong, J./Shin, D.: Design and Implementaion of a Single Sign-On

Library Supporting SAML for Grid and Web Services Security. In: Lecture notes in computer

science 3033 (2004) S. 557-564,

Staiger 2003: Staiger, M.: Neues Wissen gemeinsam aufbauen und nutzen. In: Wissensmanagement

(2003) 3, S. 32-34.

Stevens/Wulf 2001: Stevens, G./Wulf, V.: Elektronische Archive in virtuellen Organisationen. In: Infor-

matik-Spektrum 24 (2001) 6, S. 369-377.

Stevens/Wulf 2002: Stevens, G./Wulf, V.: A new dimension in access control: studying maintenance

engineering across organizational boundaries, Proceedings of the 2002 ACM conference on

Computer supported cooperative work, New Orleans, Louisiana, USA 2002, S. 196-205.

Stiemerling/Won/Wulf 2000: Stiemerling, O./Won, M./Wulf, V.: Zugriffskontrolle in Groupware - Ein

nutzorientierter Ansatz. In: Wirtschaftsinformatik 42 (2000) 4, S. 318-328.

Sun Microsystems Inc. 2003: Sun Microsystems Inc., XACML: A New Standard Protects Content in

Enterprise Data Exchange, URL: http://java.sun.com/developer/technicalArticles/Security/xacml/

xacml.html, Abruf: 25.05.2004.

Swift et al. 2002: Swift, M. M./Hopkins, A./Brundrett, P./Dyke, C. V./Garg, P./Chan, S./Goertzel,

M./Jensenworth, G.: Improving the granularity of access control for Windows 2000. In: ACM

Trans. Inf. Syst. Secur. 5 (2002) 4, S. 398-437.

Tanenbaum 2003: Tanenbaum, A. S.: Computernetzwerke, 4. Aufl., München 2003.

Tanenbaum/Steen 2002: Tanenbaum, A. S./Steen, M. v.: Distributed systems: principles and para-

digms, Upper Saddle River, NJ 2002.

Thompson/Essiari/Mudumbai 2003: Thompson, M. R./Essiari, A./Mudumbai, S.: Certificate-based

authorization policy in a PKI environment. In: ACM Trans. Inf. Syst. Secur. 6 (2003) 4, S. 566-

588.

Tuttle/Ehlenberger 2004: Tuttle, S./Ehlenberger, A.: Understanding LDAP: Design and Implementation,

2. Aufl., Armonk, NY 2004.

Tworek/Chiesa 2004: Tworek, W./Chiesa, G.: Lotus Security Handbook, 2. Aufl., Armonk, NY 2004.


Veil/Hess 2002: Veil, T./Hess, T.: A Basic Approach Towards Cost Accounting for Virtual Corporations,

In: Franke, U.: Managing Virtual Web Organizations in the 21st Century: Issues and Challenges,

London 2002, S. 270-291.

Wohlgemuth 2002: Wohlgemuth, O.: Management netzwerkartiger Kooperationen: Instrumente für die

unternehmensübergreifende Steuerung, Wiesbaden 2002.

Wörndl 2003: Wörndl, W.: Privatheit bei dezentraler Verwaltung von Benutzerprofilen (Dissertation),

München 2003.

Zhou/Meinel 2004: Zhou, W./Meinel, C.: Implement Role based Access Control with Attribute Certifi-

cates, Phoenix Park, Korea 2004.

Date post:	14-Sep-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Institut für Wirtschaftsinformatikwebdoc.sub.gwdg.de/ebook/serien/lm/arbeitsberichte_wi2/... ·...

Documents