Zugriffsschutz für verteilte Wissensmanagementsysteme. Arbeitsbericht Nr. 22/2004. Robert Schmaltz

Transkript

1 Georg-August-Universität Göttingen Institut für Wirtschaftsinformatik Professor Dr. Matthias Schumann Platz der Göttinger Sieben Göttingen Telefon: Telefax: Arbeitsbericht Nr. 22/2004 Hrsg.: Matthias Schumann Robert Schmaltz Zugriffsschutz für verteilte Wissensmanagementsysteme

2 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 Urhebergesetzes ist ohne Zustimmung des Herausgebers unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Alle Rechte vorbehalten.

3 Inhaltsverzeichnis II Inhaltsverzeichnis 1 Einleitung Begriffe und Konzepte von Sicherheit und Zugriffsschutz Sicherheitsrichtlinien und Sicherheitsmodelle Grundlegende Strategien des Zugriffsschutzes Konzepte zur Umsetzung des Zugriffsschutzes Weiterführende Forschungsgebiete Praktische Umsetzungen von Zugriffsschutzkonzepten Praktische Umsetzungen des Reference Monitors Umsetzungsvarianten der Access Control Database Standards für den anwendungs- und unternehmensübergreifenden Zugriffsschutz Anforderungen an den Zugriffsschutz Beispielhafte Rechtemanagementarchitekturen Zentralisierte Wissensmanagement-Systeme Grundlegender Aufbau und Einsatzbereiche Implementierungsvarianten des Reference Monitor Implementierungsvarianten der Access Control Database Ausgestaltung des Rollenmodells Administration der Zugriffsrechte Dezentrale Wissensmanagement-Systeme Grundlegender Aufbau und Einsatzbereiche Implementierungsvarianten des Reference Monitor Implementierungsvarianten der Access Control Database Ausgestaltung des Rollenmodells Administration der Zugriffsrechte Fazit...39 Literaturverzeichnis...42

4 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 Abbildung 3-2: Implementierungsvarianten der Access Control Database Abbildung 3-3: Standards für die Zugriffskontrolle Abbildung 4-1: Anforderungen an Zugriffskontrollsysteme für Kooperationen Abbildung 5-1: Varianten des Reference Monitor Abbildung 5-2: Zugriffsschutz im zentralisierten System Abbildung 5-3: Varianten der ACD Abbildung 5-4: Varianten des Rollenmodells Abbildung 5-5: Varianten der Privilegienverwaltung Abbildung 5-6: Varianten des Reference Monitor im dezentralen System Abbildung 5-7: Zugriffsschutz im dezentralen System mit Verzeichnisdienst Abbildung 5-8: Zugriffsschutz im dezentralen System mit Zertifikaten Abbildung 5-9: Varianten der dezentralen Speicherung der Nutzerdaten Abbildung 5-10: Rollen- und credentialbasierte Autorisierung Abbildung 5-11: Varianten der Privilegienverwaltung im dezentralen System Abbildung 6-1: Dezentrales vs. zentrales System... 41

5 Abkürzungsverzeichnis IV Abkürzungsverzeichnis ACD ACL ACM AS CMS DAC DRM DSML DV ERP IP IT LDAP MAC MS PKI RBAC RFC RM SAML TCP XACML XML Access Control Database Access Control List Access Control Matrix Anwendungssystem Content Management System Discretionary Access Control Digital Rights Management Directory Services Markup Language Datenverarbeitung Enterprise Resource Planning Internet Protocol Informationstechnologie Lightweight Directory Access Protocol Mandatory Access Control Microsoft Public Key Infrastructure Role Based Access Control Request for Comments Reference Monitor Security Assertion Markup Language Transmission Control Protocol Extensible Access Control Markup Language extensible Markup Language

6 1 Einleitung 1 1 Einleitung In einem Wissensmanagementsystem, das in einer Kooperation genutzt wird, werden vielfältige Inhalte gespeichert, die vor einem Zugriff durch unberechtigte Benutzer geschützt werden 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 anderen können Inhalte vorgehalten werden, die Wettbewerbsvorteile einzelner Kooperationsteilnehmer berühren und daher nur sehr selektiv mit Partnern geteilt werden können, etwa im Fall von technischen Konstruktionsunterlagen. Dies erfordert die Integration von Rechtemanagementkonzepten in den Entwurf von Wissensmanagementanwendungen. Insbesondere in verteilten Wertschöpfungsstrukturen ist es erforderlich, Inhalte abgestimmt auf die Sicherheitsbedü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 freizugeben. 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 anderen Seite können aber auch die Bedürfnisse nach dem Schutz von unternehmenskritischen Daten und Systemen erfüllt werden. In diesem Zusammenhang zeigen Sicherheitsmaßnahmen, deren Wirkung auf einzelne Anwendungen beschränkt ist, deutliche Mängel. Insbesondere 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 Kooperationen, 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 Wissensmanagement 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 kurzes Fazit schließt die Ausführungen.

7 Literaturverzeichnis 2 2 Begriffe und Konzepte von Sicherheit und Zugriffsschutz Im folgenden Abschnitt werden die grundlegenden Begriffe und Techniken des Zugriffsschutzes 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 Sicherheitsmechanismen 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 grundlegenden 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 Forschungsgebieten Trust Management und Digital Rights Management. 2.1 Sicherheitsrichtlinien und Sicherheitsmodelle Zum Entwurf eines sicheren Wissensmanagementsystems ist es zunächst erforderlich, Sicherheitsrichtlinien 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 unabhängig von der späteren Implementierung im Rahmen des Fachkonzeptes festgelegt, um eine von konkreten Produkten unabhängige Spezifikation der Sicherheitsanforderungen zu ermöglichen (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 Daten 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.

8 Literaturverzeichnis 3 Authentifizierung: Diese Verfahren dienen dazu, die behauptete Identität einer Einheit zu verifizieren. Sie werden häufig durch Passwortabfragen realisiert. Die Authentifizierung 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 Wissensmanagement 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 akzeptierte 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ßerhalb 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 verwendet. 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).

9 Literaturverzeichnis 4 DAC und MAC waren insbesondere in den 70er und 80er Jahren die dominanten Zugriffsstrategien. 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 verantwortliche 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 weitergeben 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 verboten 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 dominieren. 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 Rollenbasierten Zugriffskontrolle RBAC, das sich in Forschung und Praxis als Standard durchgesetzt 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 mehrere 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).

10 Literaturverzeichnis 5 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 hingegen ist durch die starre Ordnung der Schutzklassen und seine beschränkte Ausdrucksfähigkeit 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. Ferraiolo/Kuhn/Chandramouli 2003a, S. 31) und die Zugriffskontrolldatenbank (Access Control Database, 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-

11 Literaturverzeichnis 6 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 Überwachungsinformationen 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 Forschung 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 Schnittpunkten 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ühren 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, sondern zeilen- oder spaltenweise implementiert.

12 Literaturverzeichnis 7 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 festgestellt werden kann, wer Zugriff auf ein Objekt hat, und dass Zugriffsrechte einfach widerrufen 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 werden. 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 Durchsuchung 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

13 Literaturverzeichnis Weiterführende Forschungsgebiete Die traditionelle Zugriffskontrolle umfasst Systeme, die einen serverseitigen Reference Monitor 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 wesentlichen Dimensionen von den klassischen Modellen: Zum einen bezüglich der Bekanntheit der Benutzer und zum anderen bezüglich des serverseitigen Reference Monitor. In diesem Zusammenhang sind insbesondere Trust Management und Digital Rights Management hervorzuheben (vgl. Park/Sandhu 2002, S. 58). Trust Management bezeichnet Forschungsrichtungen, die sich auf die Autorisierung unbekannter 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 Infrastrukturen 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 kombiniert 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 Dokumenten 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 Programmen nur sehr eingeschränkt kontrollieren können, grundsätzlich eingeschränkt ist. Bislang wurden nahezu alle softwarebasierten Kopierschutzsysteme kompromittiert (vgl. Becker 2003,

14 Literaturverzeichnis 9 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 schwachen Schutzmöglichkeiten ist der Nutzen von DRM für das Wissensmanagement, insbesondere den Schutz sensiblen Wissens, zweifelhaft. Es wird daher in den folgenden Betrachtungen ausgeklammert. Diese mangelnde Wirksamkeit der clientseitigen Kontrollmechanismen hat einen bedeutsamen Nebeneffekt: es ist zwar möglich, den Zugriff auf serverseitig gespeichertes Wissen zu kontrollieren. Sobald es jedoch an ein Clientsystem übertragen wird, zur Anzeige, Speicherung 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 Wissensmanagement-Systeme wünschenswert, die in Kooperationen eingesetzt werden. Untersuchungen zu diesem Thema fehlen aber bislang in der Literatur. Dabei kann gemäß dem in Kap. 2.3 vorgestellten Reference Monitor Konzept eine Unterteilung 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 Database 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 kooperierenden Partnern. Das Audit File sei an dieser Stelle vernachlässigt, da es als nachträglich zu nutzendes Kontrollinstrument eine eher untergeordnete Rolle spielt.

15 Literaturverzeichnis 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 Dokumentenmanagementsystemen, Forschungsdatenbanken etc. abgelegt sind, werden nicht in einzelnen 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 Zugriffskontrolle auf der Ebene der Datenbank durchzuführen. Grundsätzlich verfügen gängige relationale Datenbanksysteme (etwa von Informix oder Oracle) über umfangreiche Sicherheitsfunktionen. Diese ermöglichen es, rollenbasierte Zugriffssteuerungen auf der Ebene von Tabellen und Datenbankoperationen umzusetzen (vgl. Ferraiolo/Kuhn/Chandramouli 2003b, S. 266 ff.). Dies ermöglicht zwar eine feinere Zugriffssteuerung als auf Betriebssystemebene, bei Wissensmanagement-Anwendungen greifen Nutzer jedoch meist nicht direkt

16 Literaturverzeichnis 11 auf die Datenbank zu. Vielmehr nutzen sie Anwendungssysteme, etwa Content Management Systeme (CMS) oder Skill Management Systeme, die ihrerseits die Datenbank als Speichermedium 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 Zugriffsverweigerungen des Datenbanksystems ein Problem dar. Diese verursachen herstellerspezifische 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 Realisierung des Zugriffsschutzes auch einen Verstoß gegen das Designprinzip der 3-Ebenen- Architektur dar, da es Funktionen der Anwendungslogik (die Definition und Prüfung von Berechtigungen) 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 Funktion 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 werden, 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 relevante Ressourcen für Gruppen von Mitarbeitern definiert werden. Dabei ist es möglich, die Ausfü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 Zugriffsschutzmechanismen auf Anwendungsebene, wobei im allgemeinen Rollenbasierte Konzepte unter-

17 Literaturverzeichnis 12 stützt werden (vgl. Hansen/Neumann 2001, S. 442). Das marktführende System, Lotus Notes/Domino, unterstützt beispielsweise Berechtigungen auf der Ebene von Servern, Datenbanken 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 autorisierten Nutzern eingesehen werden dürfen oder dass ein Verschicken von Dokumenten an andere 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 Portalfunktionen 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 Portalkomponenten 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 Fehlermeldung 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.

18 Literaturverzeichnis 13 Verzeichnisdienste kommen in erster Linie bei der Zugriffskontrolle auf Betriebssystemebene zum Einsatz. Ein Verzeichnisdienst ist eine leseoptimierte Datenbank, in der Bindungen zwischen 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 Attributen (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 Verzeichnisdiensten, die sich jedoch bezüglich der internen Struktur (hierarchische Bäume) ähneln 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. Verzeichnisdienste werden insbesondere in großen Unternehmen mit hohen Nutzerzahlen eingesetzt, 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 Berechtigungen. 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 Groupwareund Portalsystemen verwendet, um den Zugriff auf einzelne Systemfunktionen einzuschränken. Diese können eng auf Funktionen der jeweiligen Anwendung abgestimmt werden, verursachen 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

19 Literaturverzeichnis 14 Ü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 Vereinfachung der Administration zentralisiert werden sollen, gleichzeitig jedoch keine zentrale Verwaltung der Rechte gewünscht wird. Dies kann beispielsweise der Fall sein, wenn bestehende 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 Zugriffsschutz Beim Wissensmanagement in Kooperationen muss die Zugriffskontrolle über mehrere Anwendungen und über mehrere Partner verteilt erfolgen. Also ist der Austausch von Zugriffskontrollinformationen notwendig, wenn diese nicht in jedem eingesetzten Anwendungssystem einzeln gepflegt werden sollen. Für diesen Austausch sind entsprechende Standards erforderlich. 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 Verzeichnisdienste etabliert. Ursprünglich wurde es für einen vereinfachten Zugriff auf Verzeichnisse nach

20 Literaturverzeichnis 15 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 abzufragenden Verzeichniseinträge bestehen aus Objekten, die eine Sammlung von Attributen enthalten und Informationen über ein reales Objekt repräsentieren. Die Attribute können hinsichtlich 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 Benutzerauthentifikation, -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 Autorisierung 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