Nutzerverwaltung und datenbasierte Rechtevergabe für mobile Datenbankanwendungen. - Studienarbeit -

Transkript

1 Nutzerverwaltung und datenbasierte Rechtevergabe für mobile Datenbankanwendungen - Studienarbeit - David Wiese david.wiese@web.de Betreuer Dipl.-Inf. Christoph Gollmick Prof. Dr. Klaus Küspert Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Institut für Informatik Lehrstuhl für Datenbanken und Informationssysteme Ernst-Abbe-Platz Jena Mai 2004 Kurzfassung Mit der zunehmenden Verbreitung mobiler Technik und dem damit einhergehenden Anstieg der Nutzung und Entwicklung mobiler Datenbanksysteme ist ein interessanter Trend in der Anwendungsentwicklung zu beobachten. Die wichtigste Anforderung heißt nun: Anytime, Anywhere Computing. Rechner, Benutzer und Daten sind nicht mehr nur auf einen Ort fixiert, sondern können sich beinahe unabhängig voneinander bewegen. Bei der Vielzahl solcher auf den kommerziellen Einsatz ausgerichteten Anwendungen steht die Anzahl und Vertrauenswürdigkeit der auf gemeinsame Datenbestände zugreifenden Nutzer nicht von Beginn fest. In der vorliegenden Arbeit wird daher zunächst das Konzept einer flexiblen, dynamischen Nutzerverwaltung und eines inhaltsorientierten Rechtekonzepts für das interaktive Reiseinformationssystem HERMES zusammen mit den erforderlichen Grundlagen vorgestellt und im weiteren ausführlich auf die Integration in die Infrastruktur der nutzerdefinierten Replikation eingegangen. Abschließend wird das Zusammenspiel zwischen den Komponenten der zu Grunde gelegenen Architektur und die Korrektheit der beschriebenen Mechanismen an einfachen nachvollziehbaren Testszenarien zum tieferen Verständnis demonstriert.

2

3 Inhaltsverzeichnis 1. Einleitung Grundlagen HERMES - Das interaktive Reiseinformationssystem Nutzerdefinierte Replikation Drei-Stufen-Architektur Details der nutzerdefinierten Replikation Fragmentkonzept Integration von HERMES in die 3-Stufen-Architektur Grundlegende Sicherheitsfunktionen Authentifizierung Autorisierung Authentifizierung, Autorisierung unter DB2 UDB Auditing Übertragungssicherung Zugriffskontrollansätze Benutzerbestimmte Zugriffskontrolle Fähigkeitslisten Zugriffskontrolllisten Weitergabe von Rechten Systembestimmte Zugriffskontrolle Rollenbasierte Zugriffskontrolle Anforderungen an die Zugriffskontrolle von HERMES Zugriffskontrolle in Datenbanksystemen Nutzerverwaltung und Authentifizierung Schemabasierte Rechtevergabe Zugriffskontrolle durch Programmlogik Physische Separation durch Nutzung mehrerer Datenbanken Einsatz von Sichten Trigger Routinen (Prozeduren, Funktionen) Proprietäre Ansätze Oracle Label Security Einführung Analyse und Implementierung Bewertung Authentifizierung und Autorisierung in der 3-Schichten-Architektur Sicherheitsarchitektur des RPS Das Nutzermanagement des RPS Dienste des RPS Rollenbasierte Zugriffskontrolle Implementierung Nutzerpflege durch CREATE/ALTER/DELETE USER Rechtekonzept und Nutzermanagement von HERMES Nutzerverwaltung Rechtekonzept Referential Constraints...36 Einführung...36 Fremdschlüsselproblematik im tupelbasierten Rechtekonzept von HERMES Anwendungsspezifische Autorisierungs- und Authentifizierungs-Routinen auf dem RPS Autorisierung für CREATE REPLICATION VIEW Autorisierung für ALTER REPLICATION VIEW Autorisierung für SYNCHRONIZE Lokale Autorisierungsmechanismen auf dem Client Private Bereiche in herkömmlichen Anwendungen Parametrisierte Sichten Fremdschlüsselbeziehungen von und zu privaten Daten Private Bereiche in HERMES...54 iii

4 Ermitteln der synchronisierenden Nutzer Integration in die RPS-Architektur Testszenarien Autorisierung auf dem Client INSERT DELETE UPDATE Autorisierung auf dem RPS CRISP-Tool CSSP-Tool INSERT DELETE UPDATE Zusammenfassung und Ausblick Zusammenfassung Ausblick...69 Anhang...71 A Java-Skript CRISP.java...71 B Java-Skript CSSP.java...73 Literaturverzeichnis...76 Abbildungsverzeichnis...77 iv

5 1. Einleitung Technische Weiterentwicklungen und die unaufhaltsam fortschreitende Miniaturisierung ermöglichen kompaktere, leistungsstärkere mobile Endgeräte (Notebooks, Personal Digital Assistants, Mobiltelefone). Dies wiederum eröffnet die Perspektive für eine Vielzahl neuartiger Anwendungen unter dem Einsatz mobiler Datenbank- und Informationssysteme. Ein Ziel besteht in der Erschließung von Anwendungsbereichen mit explizitem Orts- und Situationsbezug, die dem Nutzer über die reine Informationsbeschaffung hinaus auf seinen Aufenthaltsort und aktuelle Tätigkeit angepasste Daten lokal für die Informationsverarbeitung bereitstellen. Beispiele hierfür lassen sich im Gesundheitswesen, Verkehr, Vertrieb und auch in interaktiven Reiseinformationssystemen finden. Bedingt durch begrenzte Speicher- und Stromressourcen sowie niederfrequente Netzwerkverbindungen mit vergleichsweise geringen Bandbreiten wird ein Dienst zur nutzerdefinierten Replikation [Gol03] benötigt, der auf einer vorhandenen mobilen Client/Server-Datenbankumgebung aufsetzt und den mobilen Nutzern die benötigten Daten als auch entsprechende unverbundene Manipulationsmöglichkeiten jederzeit kostengünstig zur Verfügung stellt. Die neuartigen Anwendungsbereiche zeichnen sich durch eine potentiell unbegrenzte variable Nutzerzahl aus, die eine effiziente Verwaltung der Nutzer und die Kontrolle derer Zugriffe auf die gemeinsamen Daten erforderlich macht. Die vorliegende Arbeit setzt sich daher den Entwurf eines inhaltsorientierten, feingranularen Rechtekonzepts und einer damit verbundenen flexiblen Nutzerverwaltung zum Ziel. Im Mittelpunkt aller Betrachtungen soll das am Lehrstuhl konzipierte, interaktive, mobile Reiseinformationssystem HERMES [Bau03] stehen. Obwohl spezielle Datenbank-Addons erworben werden können, wie beispielsweise Oracle Label Security (siehe Abschnitt 2.6.), gibt es doch keine optimale Lösung. Daher wird ein prototypisches Konzept für HERMES entwickelt, aufbauend auf einigen Aspekten der Dateiverwaltung unter Unix [Fri03] und gängigen Internetforen. Vorgestellte Prinzipien lassen sich aber auch problemlos auf alternative Anwendungen übertragen. Im Kapitel 2 erfolgt zunächst eine allgemeine Beschreibung des HERMES, der nutzerdefinierten Replikation und der dafür nötigen Architektur. Weiterhin werden die grundlegende Begriffe und Mechanismen zur Realisierung einer Zu-griffskontrollpolitik sowie die Anforderungen an HERMES in Bezug auf die Rechte- und Nutzer- Verwaltung dargelegt. Kapitel 3 beinhaltet die Spezifikationen der Nutzer- und Rechteverwaltung auf Serverund Client-Seite und geht dabei auf Besonderheiten der Replikation ein. Verschiedene Testszenarien zeigen im Kapitel 4 die Funktionalität der beschriebenen Techniken und sollen dem vertiefenden Verständnis dienen. In Kapitel 5 werden schließlich die wichtigsten Inhalte der Arbeit noch einmal zusammengefasst und Ausblicke auf weiterführende Arbeiten gegeben. Im Anhang finden sich die im Verlauf des Textes angesprochenen Java- Skripte zur Unterstützung einer zukünftigen Implementierung. 5

6 2. Grundlagen Ziel dieses Kapitels ist es, die für das Verständnis der Arbeit relevanten Grundlagen umfassend zu erklären. Nachdem im Abschnitt 2.1. HERMES und die zu Grunde liegende Architektur eingeführt werden, beschreibt Abschnitt 2.2. die für Informationssysteme grundsätzlichen Sicherheitsfunktionen. Die darauf aufbauenden Zugriffskontrollansätze finden sich in den Kapiteln 2.3. Es schließt sich ein Anforderungskatalog von HERMES an und im Abschnitt 2.5. werden die Möglichkeiten zur Realisierung von Rechteverwaltungen in Datenbanksystemen ausführlich vorgestellt. Den Schluss dieses Kapitels bildet der Abschnitt 2.6., welcher einen Einblick in das von Oracle angebotene Produkt Oracle Label Security gewährt und dessen Tauglichkeit für das HERMES- Szenario analysiert HERMES - Das interaktive Reiseinformationssystem HERMES hat die Aufgabe, seine Nutzer zum einen bei der Reiseplanung (z.b. Bestimmung von Reiserouten, Suche nach Ortschaften) wunschgemäß zu unterstützen und zum anderen als elektronischer Reisebegleiter, ortsabhängige Informationen bereitzustellen. Zusätzlich soll die HERMES-Anwendung über sogenannte private Bereiche verfügen, in denen ein Anwender vollkommen isoliert und ohne Kenntnis der Präsenz von Daten anderer Nutzer persönliche und vertrauliche Informationen (Reiseberichte, Notizen, Aufzeichnungen) ablegen kann, auf die nur er (lesend und/oder schreibend) zugreifen kann. Der Großteil der Daten, wie Informationen (Öffnungszeiten, Preise, Erfahrungen, Bewertungen, Reiseberichte) über Orte, Sehenswürdigkeiten, Gebäude, Hotels oder Restaurants wird, im Gegensatz zu klassischen Touristenführern, von den mobilen Nutzern selbst und in der Regel vor Ort erstellt und aktualisiert. Nur der kleinere Teil der Information (die sogenannten Basisdaten), wie etwa demographische Fakten (Fläche, Einwohnerzahl) über Orte, wird zentral bereitgestellt und ist durch den Nutzer in der Regel nicht änderbar. Demnach sind vorwiegend die potentiell über die ganze Welt verteilten Nutzer von HERMES am Aufbau und der Pflege des Datenbestandes beteiligt. Sie sammeln die Informationen vor Ort, können diese auf ihren mobilen Geräten zwischenspeichern, manipulieren und letztlich einem zentralen Server zur Verfügung stellen Nutzerdefinierte Replikation Offensichtlich kann eine Auswahl der Daten für die Replikation, aufgrund der Zeit-, Ort- und Situationsabhängigkeit, nicht durch eine zentrale Instanz vorgegeben werden, vielmehr bedarf es einer nutzer- oder anwendungsgesteuerten Replikat-Anforderung zur Laufzeit. Aufgrund der mangelnden Unterstützung der dynamischen Replikatauswahl sowie anschließender unverbundener Verfügbarkeit und Manipulationsmöglichkeit aktueller mobiler Datenbanklösungen, wurde für HERMES und verwandte Anwendungen ein Dienst zur nutzerdefinierten Replikation (NR) entwickelt, der auf einer vorhandenen mobilen Client/Server-Datenbank-Umgebung aufsetzt [Gol00]. Der zyklische Arbeitsablauf (siehe Abbildung 1) der nutzerdefinierten Replikation beginnt zunächst mit der einmaligen Auswahl des für die Replikation freigegebenen Datenbankausschnittes (Replikationsschema), erweitert um Konfliktbehandlungsmethoden, durch den Replikationsadministrator. Anschließend, in der Phase der Replikatdefinition, spezifizieren die Clients bzw. die darauf laufenden Anwendungen im verbundenen Zustand die Schema- und Datenelemente, die für eine spätere unverbundene Phase lokal verfügbar sein sollen sowie deren Verwendungsabsicht, durch das Anfordern von entsprechenden Änderbarkeitszusicherungen (nur lesend, exklusiv oder optimistisch). In der nun notwendigen Synchronisation werden zunächst bereits lokal vorgenommene Änderungen mit dem Serverdatenbestand abgeglichen (Reintegration 1 ), wenn nötig mit einer entsprechenden 1 Bei der ersten Synchronisation bzw. bei unveränderten Client-Daten ist keine Reintegration nötig. 6

7 Kapitel 2. Grundlagen Konfliktbehandlung, gefolgt von der Rückübertragung der entsprechenden (geänderten) Daten zum Client (- DBMS). Anschließend können die replizierten Daten in der als Normalzustand angenommenen, unverbundenen Phase unabhängig von anderen Nutzern, mit den Mitteln des Client-DBMS gelesen und/oder modifiziert (Ergänzung neuer bzw. Änderung bestehender Daten) werden und die Ergebnisse der lokalen Transaktionen zu gegebener Zeit erneut mit dem zentralen Datenbestand synchronisiert werden. Der angesprochene Zyklus entsteht dadurch entweder durch die Re- bzw. Neu-Definition von Replikaten und/oder der Reintegration geänderter Daten. (Re-)Definition der Replikate Reintegration unverbundene Arbeit mit Replikaten Synchronisation Rückübertragung Abbildung 1: Prinzipieller Arbeitszyklus der nutzerdefinierten Replikation Die in der mobilen Kommunikation auftretenden Empfangs- oder Sendeprobleme wie eine temporäre Nicht- Erreichbarkeit, mangelnde Energieversorgung oder das Ausschalten des Geräts durch den Nutzer selbst während einer notwendigen aktiven Verbindungsphase sind kein Bestandteil der Betrachtungen und die Mechanismen zu deren Behandlung werden als gegeben vorausgesetzt Drei-Stufen-Architektur Zur Unterstützung der nutzerdefinierten Replikation und neuerlichen mobilen Anwendungen wie HERMES, in denen Aktivitäten ausschließlich vom Client ausgehen, wird eine Erweiterung des Client-Server-Modells [Gol00] zu einer 3-Stufen-Architektur vorgenommen. Letztere besteht nunmehr aus mehreren mobilen Clients, dem zentralen Quellserver und einem zwischengeschalteten Replication Proxy Server (RPS). Auf dem als gegeben angenommenen Quellserver ist das gesamte Informationsangebot, in Form von Quelldatenbanken, verschiedener bereits betriebener Datenbankanwendungen gespeichert. Trotz der Integration mobiler Clients soll die unveränderte Weiternutzung dieser Anwendungen möglich bleiben. Der RPS speichert alle durch den (die) Replikationsadministrator(en) zur Replikation (durch die mobilen Clients) freigegebenen Quellserverdaten nochmals. Der RPS stellt den Anwendungen alle Dienste bereit, um das vom Quellserver "geerbte" Datenbankschema mobiltauglich zu machen. Dazu gehören die: Abwicklung der drahtlosen Kommunikation mit den mobilen Clients Verarbeitung von Replikations- und Synchronisationsanfragen der Clients automatisierte Behandlung von Änderungskonflikten (Key-Pool-, SLOT-, Escrow-Verfahren) Replikatverwaltung Dabei sollten Änderungen am RPS immer rückabbildbar bleiben, d.h. es dürfen durch den RPS keine über seine "Mobilisierungstätigkeit" hinausgehende Änderungen vorgenommen werden. Zudem ist ein fortlaufender bidirektionaler Datenabgleich zwischen dem RPS und der Quelle nötig, da Datenänderungen auf jeder Seite möglich 7

8 Kapitel 2. Grundlagen sind. Die redundante Datenspeicherung und der beiderseitige Datenaustausch sind jedoch nicht unbegründet und bieten eine Reihe von Vorteilen, beispielsweise die ausbleibende Notwendigkeit der Erweiterung der bestehenden Quellserverfunktionalität, die Entkopplung und Entlastung des Quellservers sowie die Optimierbarkeit der physischen Speicherstruktur auf dem RPS [Mül03]. Die beim Datenabgleich möglicherweise entstehenden Änderungskonflikte werden durch die Strategie "server wins" aufgelöst, d.h. die Änderungen an der Quelle setzen sich durch. Als DBMS des RPS und der Quelle wird DB2 UDB von IBM eingesetzt. Der Datenabgleich mit dem Quellserver erfolgt mit dem DB2 DataPropagator. Um auch Handheld-Geräte zu unterstützen, führt die Wahl des Client-DBMS unweigerlich zu Adaptive Server Anywhere, das von Sybase (bzw. ianywhere) als Bestandteil des SQL Anywhere Studio angeboten wird. Die Realisierung der Synchronisation zwischen dem RPS und den mobilen Clients wird durch das von Sybase bzw. ianywhere angebotene Softwareprodukt MobiLink ermöglicht. Auf die genauen Gründe der konkreten Produktwahl soll hier nicht näher eingegangen werden, da sie in [Mül03] nachgelesen werden können Details der nutzerdefinierten Replikation Die Dienste des RPS können durch eine deskriptive, an SQL angelehnte Sprachschnittstelle genutzt werden. Durch das Anlegen bzw. Registrieren einer, für jede zur Replikation freigegebenen Quelldatenbank, korrespondierenden konsolidierten Datenbank (REGISTER CONSOLIDATED DATABASE) mit entsprechenden konsolidierten Tabellen (CREATE CONSOLIDATED TABLE) spezifiziert ein Replikationsadministrator die den mobilen Clients zur Replikation angebotenen änderbaren oder nicht-änderbaren Daten sowie die zu verwendende Konfliktbehandlung im Falle änderbarer Tabellen. Für jede konsolidierte Datenbank bzw. Tabelle des RPS besitzt der Client wiederum eine separate Replikatdatenbank bzw. Replikattabelle. Demnach liegt jeder Client- Replikatdatenbank genau eine konsolidierte RPS- und damit genau eine Quell-Datenbank zu Grunde. Das konsolidierte und das Replikatschema sollten bis auf Datenbanksystemunterschiede gleich sein. Integritätsbedingungen (Fremdschlüsselbeziehungen, Schlüssel, Check-Bedingungen, Trigger) der Quelle werden weitestgehend automatisch und in Spezialfällen manuell auf das Client- und RPS-DBMS übertragen, um eine frühzeitigen Erkennung von Integritätsverletzungen zu ermöglichen. Jede Anwendung nutzt mindestens eine Quelldatenbank (und damit auch die entsprechende konsolidierte bzw. replizierte Datenbank), kann die Daten aber auch, beispielsweise aus Sicherheitsgründen, auf mehrere Datenbanken verteilen. Es ist zudem nicht ausgeschlossen, dass mehrere Anwendungen eine gemeinsame Datenbank benutzen, obwohl die Praxisrelevanz eines solchen Falles als äußerst gering eingeschätzt werden kann. Für das Anlegen der Replikatdatenbanken sind die mobilen Anwendungen bzw. ein für den Client zuständiger Administrator nötig. Die gezielte Auswahl der zur unverbundenen Arbeit benötigten Daten, kann hingegen dynamisch zur Laufzeit, durch das Anlegen von, auf den konsolidierten Tabellen beruhenden, Replikationssichten (CREATE REPLICATION VIEW) erfolgen. Optional können dabei Änderbarkeitszusicherungen für eine unverbundene lokale Manipulation der Daten angefordert und die Parametrisierung von Konfliktbehandlungsmethoden vorgenommen werden. Durch das logische Konstrukt der Replikationssichten wird die Unterscheidung zwischen den geforderten Daten und den tatsächlich replizierten Daten möglich. Die Menge der durch den Client definierten Replikationssichten bildet ein Fenster, durch das ein bestimmter Ausschnitt der Quelldatenbank sichtbar ist. Der RPS sorgt automatisch dafür, dass alle hierzu benötigten Daten (u.u. mehr als die geforderten) auf den Client übertragen und in den entsprechenden Replikattabellen gespeichert werden. Damit wird die sogenannte "replica unawareness" unterstützt, d.h. die Clients arbeiten auf den lokalen Daten so, als ob sie direkt mit der Server-Datenbank kommunizieren würden. Erzeugt wird dann eine, den Gegebenheiten des Client-DBMS entsprechende, lokale Sicht, welche genau die tatsächlich geforderten Daten, der ihr zu Grunde liegenden (Replikat-) Tabellen selektiert. Änderungen auf der für eine Replikationssicht angelegten lokalen änderbaren Sicht, führen folglich zu Änderungen an den zu Grunde liegenden Replikattabellen. Die Forderungen der lokalen Änderbarkeit von Daten wird als Anforderung einer Änderbarkeitszusicherung bezeichnet. Unterschieden werden optimistische und exklusive Änderbarkeitsanforderungen. Besitzt ein Client eine nicht-exklusive (optimistische) Änderbarkeitszusicherung für die angeforderten Daten, so können auch andere mobile Clients Änderungen an den Daten vornehmen. Die bei der späteren Synchronisation eventuell 8

9 Kapitel 2. Grundlagen auftretenden Konflikte müssen dann den, bei der Erzeugung der Replikationssicht, spezifizierten Konfliktbehandlungsmethoden unterzogen werden. Exklusive Änderbarkeitszusicherungen sichern das alleinige Änderungsrecht an den Daten, schränken aber zugleich die Verfügbarkeit derer erheblich ein. Aus diesem Grund sollten Zusicherungen dieser Art nur vereinzelt und einem kleinen ausgewählten Nutzerkreis eingeräumt werden. Um die Verfügbarkeit nicht komplett zu restringieren, können exklusive Änderbarkeitszusicherungen noch auf INSERT beschränkt werden. Eine Unterteilung in DELETE- und UPDATE-Zusicherungen (auf einzelne Spalten) wie in [Mül03] vorgeschlagen, erfolgt jedoch in der aktuellen Implementierung des RPS aus Komplexitäts- und Performancegründen nicht [Pfe04]. Einem mobilen Client kann eine Änderbarkeitszusicherung nur dann gewährt werden, wenn die anderen Clients gewährten dem nicht entgegen stehen (z.b. nicht zweimal exklusives INSERT für dieselben Daten). Die genaue theoretische Klassifizierung und Kompatibilitäten der Änderbarkeitszusicherungen untereinander können den Arbeiten [Mül03] und [Pfe04] entnommen werden Fragmentkonzept Die Realisierung der nutzerdefinierten Replikation zur anwendungsgesteuerten dynamischen Auswahl relationaler Datenbankinhalte erfordert eine effiziente Verwaltung von Replikatanforderungen tausender mobiler Clients. Das in [GR03] vorgestellte Fragmentkonzept nimmt sich dieses Problems an und stellt eine Lösung vor, die auf der automatischen Gruppierung von semantisch und nach Auswertung der Zugriffsprofile mobiler Nutzer zusammengehörenden Daten zu logischen Verwaltungseinheiten, kurz Fragmenten, basiert. Ein Fragment ist dabei eine Menge horizontaler, vertikaler oder kombinierter Tabellenpartitionen aus einer oder mehreren Tabellen, angereichert mit Zusatzinformationen (z.b. Beziehungen zu anderen Fragmenten) [GR03]. Die nutzerdefinierte Replikation, die sich den Einsatz von Fragmenten als Verwaltungs- und Übertragungsgranulat zu Nutze macht, übernimmt dabei folgende Aufgaben: Vollständige Zerlegung (Fragmentierung) der zur Replikation freigegebenen Daten Angefragte Daten sollten nur einmal auf den Client repliziert werden, egal von wie vielen Replikationssichten sie benutzt werden Für die Integritätssicherung erforderliche Daten (z.b. Tupel aus Fremdschlüsselbeziehungen) gilt es e- benfalls auf den Client zu übertragen Für jeden mobilen Client sind nur die von ihm referenzierten Fragmente abzuspeichern Automatisches Sammeln aller einen Client betreffenden Datenänderungen im unverbundenen Zustand, die dann bei der Synchronisation sofort übertragen werden können Der Anfangszustand der Fragmente wird im laufenden Betrieb automatisch und inkrementell durch die Zugriffsstatistiken der mobilen Nutzer angepasst Eine geeignete Sperrverwaltung der durch die Client-Anwendung spezifizierbaren Änderbarkeits-Modi der Replikation (exklusiv, optimistisch) durch den Einsatz von Granulatsperren auf eine feste Menge vorgegebener Prädikate (Fragmente) Die eigentliche Fragmentbildung verläuft in zwei Schritten. Bei der Schemafragmentbildung werden alle Tabellen zu einem Schemafragment zusammengefasst, die in Beziehung stehen (z.b. durch Fremdschlüsseldefinitionen) und die bei der Replikation immer zusammen übertragen werden sollen. In einem zweiten Schritt, der Datenfragmentbildung wird jedes Schemaframent in einzelne Datenfragmente zerlegt, die jeweils Tupel mit gemeinsamen Merkmalen (Ortsattribute, Integritätsbedingungen, nutzer- oder gruppenbezogene Daten, nur-lese Daten) zusammenfassen. Inwieweit sich das Fragmentkonzept auf die angestrebte Nutzer- und Rechte-Verwaltung vorteilhaft auswirkt, wird im Abschnitt erläutert Integration von HERMES in die 3-Stufen-Architektur HERMES nutzt eine (Quell-)Datenbank und wurde speziell für die mobile Anwendung konzipiert. Es ist daher nicht zweckmäßig, Zugriffe von auf der Quelldatenbank arbeitenden HERMES-Nutzern zu erlauben. Die Quellanwendung von HERMES weiß demnach auch von der Existenz des RPS und nutzt die angebotenen Befehle zur Interaktion mit den Client-Nutzern. 9

10 Kapitel 2. Grundlagen Die anwendungsspezifischen, zur Replikation freigegebenen Quelldaten liegen, wie bereits beschrieben, auf dem RPS als Kopie vor. In der unverbundenen Phase geänderte Daten können bei der Synchronisation nicht einfach in das konsolidierte Schema übernommen werden, da die Arbeit auf dem Client nicht überwacht werden kann und die darauf gespeicherten Daten prinzipiell beliebig manipulierbar sind. Infolgedessen stellt HERMES eine Menge von Prozeduren und Funktionen bereit, die der Identifikation des Nutzers und seiner Rechte bei der Replikation bzw. Synchronisation dienen. Die Parameter und Namen der Routinen sind vom RPS vorgegeben und werden in dem Abschnitt 3.4. näher erläutert. Optional besteht für den RPS nutzende Anwendungen die Möglichkeit des Einsatzes separater RPS-Applikationen. Letztere dienen, ähnlich den Routinen, der Einhaltung von geforderten Sicherheitsrichtlinien und kommunizieren dazu mit den entsprechenden Quell- bzw. Client- Applikationen. Eine Kombination der Mechanismen ist auch möglich und sollte selbst den komplexesten Anforderungen genügen. Es folgt ein Überblick der wichtigsten Funktionen der HERMES-Anwendung seitens Quelle und Client. Eine detaillierte Beschreibung kann [Bau03] und den weiteren Abschnitten entnommen werden. Haupt-Funktionen der HERMES-Client-Anwendung: Übersicht über im System bzw. lokal vorhandene Daten Auswahl von Daten für die Replikation Aktualisierung replizierter Daten (initiiert durch den Nutzer) Reintegration lokal geänderter Daten mit dem zentralen Datenbestand sowie adäquate Benachrichtigung des Nutzers in Konfliktfällen mit evtl. Lösungsvorschlägen Registrieren neuer HERMES-Nutzer und Senden der zu prüfenden Informationen an die HERMES- SERVER-Anwendung Speichern sämtlicher Informationen des einen lokalen HERMES-Nutzers Haupt-Funktionen der HERMES-SERVER-Anwendung (auf der Quelle): Auslösen der Registrierung des Clients beim RPS (Account-Generierung) Speichern und Verwalten der Informationen aller HERMES-Nutzer Abbildung 2 stellt die verwendete Architektur und die Integration von HERMES anschaulich dar, wobei vereinfachend davon ausgegangen wird, dass der Client alle angebotenen Quellanwendungen und zugehörige Datenbanken nutzt und aus diesem Grund alle korrespondierenden Replikatdatenbanken besitzt. Nicht alle Quellserver- Anwendungen nutzen die Möglichkeit eigene Prozeduren oder Funktionen auf dem RPS für ihre Sicherheitspolitik zu implementieren. Vielmehr nutzen sie eigens implementierte RPS-Applikationen (Appl. c-h) für ihre Zwecke. Abbildung 2: Architektur zur Unterstützung neuartiger mobiler Anwendungen 10

11 Kapitel 2. Grundlagen 2.2. Grundlegende Sicherheitsfunktionen Im Folgenden werden die in Informationssystemen notwendigen Grundfunktionen Authentifizierung, Autorisierung, Beweissicherung und Übertragungssicherung beschrieben. Es soll auch auf die für DB2 spezifischen Besonderheiten eingegangen werden Authentifizierung Unter Authentifizierung ist die Verifikation einer vorgegebenen Identität zu verstehen. Grundsätzlich lassen sich drei verschiedene Authentifizierungsansätze unterscheiden [Rup02]: Überprüfung eines Wissensmerkmals ("something you know"): Eine Entität wird aufgrund ihres vorhandenen faktischen Wissens authentifiziert. Die in der Praxis am häufigsten verwendete Variante ist die Abfrage von Wissen, wie z.b. Passwörter oder persönliche Identifikationsnummern. Überprüfung eines Besitzmerkmals ("something you have"): Der Benutzer authentifiziert sich mit Hilfe eines möglichst einfach überprüfbaren und fälschungssicheren Identifikationsausweis (z.b. Magnet- oder Chipkarten) Überprüfung eines Seinsmerkmals ("something you are"): Die Überprüfung der Echtheit einer Identität erfolgt anhand individueller biometrischer Merkmale. Derartige Verfahren wie z.b. die Messung von Fingerabdrücken, Handflächen, der Iris oder auch des individuellen Schreibstils haben sich bisher aufgrund zu hoher Fehleranfälligkeit und Kosten noch nicht durchsetzen können. In mobilen Datenbankanwendungen authentifizieren sich vertrauenswürdige (trusted) Nutzer lediglich auf dem Client (auf Ebene des Betriebssystems durch Login+Passwort oder eines Besitz- bzw. Seinsmerkmals), andernfalls (untrusted) auch auf dem von ihnen angesprochenen Server (Server-Login+Passwort) Autorisierung Unter Autorisierung oder Zugriffskontrolle versteht man die Spezifikation von Regeln, wer welche Art von Zugang unter welchen Bedingungen zu welchen Informationen oder Objekten hat. Bei der Autorisierung wird grundsätzlich zwischen Zugriffsrechteverwaltung und überprüfung unterschieden [Rup02]. Die Verwaltung umfasst das Erteilen, Entziehen und Pflegen von Zugriffsrechten. Vor Ausführung eines Zugriffs muss dann überprüft werden, ob dieser gemäß Rechteverwaltung zulässig ist oder gegen etwaige Bedingungen verstößt. Ein Zugriffsrecht lässt sich dabei vereinfacht als Tripel bestehend aus Subjekt, Objekt und zugehöriger Zugriffsaktion beschreiben und bildet die Beziehungen der Komponenten untereinander ab Authentifizierung, Autorisierung unter DB2 UDB DB2 UDB Version 8.1 besitzt im Gegensatz zu anderen Datenbanksystemen (z.b. Oracle) kein eigenes Nutzerkonzept, sondern verwendet zur Authentifizierung die vom Betriebssystem (oder von einem separaten Produkt wie Kerberos) bereitgestellten Nutzer und Nutzergruppen. Die Autorisierung und Rechtevergabe für die datenbank-spezifische Funktionalität erfolgt dann durch DB2 selbst mittels Privileges (Zugriffsrechte) und Authority level (auch Authorities, dt. Berechtigungsstufen). Diese zwei Mechanismen dienen zur Steuerung des Zugriffs auf den Datenbankmanager und seine Datenbankobjekte. Benutzer können nur auf solche Objekte (z.b. Tabellen, Sichten) zugreifen, für die sie berechtigt sind, d.h. für die sie über das erforderliche Zugriffsrecht oder die erforderliche Berechtigungsstufe verfügen. Privileges erlauben es Nutzern, Datenbankressourcen zu erstellen oder auf sie zuzugreifen. Dabei werden zwei Kategorien von Zugriffsrechten unterschieden, solche, die Aktionen für die Datenbank als Ganzes umfassen (Bsp.: CONNECT-Recht) und Zugriffsrechte, die sich auf einzelne Objekte innerhalb der Datenbank beziehen (z.b. SELECT-Recht auf eine Tabelle). 11

12 Kapitel 2. Grundlagen Authorities gruppieren Zugriffsrechte zur Realisierung eines Rollenkonzepts. DB2 bietet 5 Authority level: SYSADM (Systemadministrator), SYSCTRL (system resource administrator), SYSMAINT (system maintenance administrator), DBADM (Datenbankadministrator) und LOAD, welche jeweils die Zugriffsrechte zusammenfassen, die für die angedachten Aufgaben notwendig sind. Die Rechte der SYS...-Autoritäten werden durch die Mitgliedschaft in spezifischen Betriebssystem-Gruppen erworben. Abbildung 3 ([IBM02a]) veranschaulicht die Hierarchie der Authorities und Privileges noch einmal. SYSADM DBADM SYSCTRL SYSMAINT Database Users with Privileges Abbildung 3: Authorities und Privileges in DB2 Zugriffsrechte werden in der Regel automatisch vergeben (z.b. beim Erstellen eines Datenbankobjekts an den Erzeuger) oder von berechtigten Nutzern mit den SQL-Anweisungen GRANT und REVOKE an einzelne Nutzer oder eine Gruppe von Nutzern explizit erteilt bzw. entzogen. Eine weitere Möglichkeit der Rechtevergabe ist die Zugehörigkeit zu einer der vom Datenbanksystem verwalteten symbolischen Gruppen SYSADM, SYSCTRL, SYSMAINT oder PUBLIC (umfasst alle Nutzer). Eine Übersicht und die Details des Rechtekonzepts können in der entsprechende Dokumentation [IBM02b] nachgelesen werden Auditing Die Beweissicherung (Auditing) trägt zur Erhöhung der Nachvollziehbarkeit, Verbindlichkeit und Integrität bei. Sie dokumentiert alle Informationen über Zugriffe und Zugriffsversuche sämtlicher Subjekte. Die aufgezeichneten Protokolle müssen in regelmäßigen Zeitabständen auf Unregelmäßigkeiten und Regelverstöße überprüft werden. Mit ihrer Hilfe lassen sich die für eine Operation verantwortlichen Subjekte identifizieren und geeignete Maßnahmen und Konsequenzen ableiten [Rup02]. DB2 unterstützt das Auditing über die sogenannte Audit Facility. Letztere erlaubt das Verwalten und die Generierung eines Audit Trails für eine Menge vordefinierter Datenbank-Ereignisse und speichert die Aufzeichnungen in einem Audit-Log-File (siehe [IBM02b]) Übertragungssicherung Daten und Informationen müssen nicht nur innerhalb eines Systems sicher sein, sondern auch bei der Übertragung zwischen den Systemkomponenten und zum Benutzer bzw. Client. Implementierungen der Übertragungssicherung basieren häufig auf kryptographishen Verfahren sowie normierten Kommunikationsprotokollen (z.b. TCP/IP). Für jeglichen Datenstrom vom oder zum Server soll in unserem Fall eine SSL (Secure Socket Layer)-Verbindung genutzt werden, bzw. ein vergleichbares Verfahren vorausgesetzt werden. 12

13 Kapitel 2. Grundlagen 2.3. Zugriffskontrollansätze Zugriffskontrolle regelt den lesenden, ändernden und löschenden Zugriff auf Daten und schützt somit deren Geheimhaltung und Authentizität vor ungewollten (accidental) oder beabsichtigten (malicious) Bedrohungen [Rup02]. Die Aufgabe von Zugriffskontrollmechanismen besteht demnach darin, nur solche direkten Zugriffe auf Daten zuzulassen, die autorisiert worden sind. In der Literatur lassen sich grundsätzlich drei verschiedene Klassen von Zugriffskontrollansätzen unterscheiden: Benutzerbestimmte Zugriffskontrolle (Discretionary Access Control, DAC) Systembestimmte Zugriffskontrolle (Mandatory Access Control, MAC) Rollenbasierte Zugriffskontrolle (Role-based Access Control, RBAC) Benutzerbestimmte Zugriffskontrolle Die benutzerbestimmte Zugriffskontrolle ist eine Maßnahme zur Beschränkung des Zugriffs auf Objekte basierend auf der Identität der Subjekte und/oder Gruppen, denen sie angehören [Kaß95]. Sämtliche Objekte haben einen Eigentümer (Eigentümer-Paradigma), der alle Rechte an dem Objekt besitzt und verwaltet. Er kann sie an weitere Subjekte ohne vorherige Vermittlung und Genehmigung einer zentralen Instanz (zum Beispiel den System- oder Sicherheitsadministrator) weitergeben und auch widerrufen. Die Verwaltung der Rechte und der durch sie beeinflusste Informationsfluss unterliegt somit der Diskretion des einzelnen Benutzers, was dem Zugriffsmodell auch den Namen gab. Mit benutzerbestimmbaren Strategien können objektbezogene Sicherheitseigenschaften nicht von vornherein festgelegt werden. Eine Sicherheitsstrategie kann deshalb nur durch das Zusammenspiel mehrerer Objekte realisiert werden. Zugriffsregeln von DAC-Modellen werden üblicherweise in Zugriffskontrollmatrizen gespeichert (siehe Abbildung 4). Hierbei werden die Subjekte in den Zeilen 1 bis i und die Objekte in den Spalten 1 bis j abgetragen. Der Eintrag in Zeile i und Spalte j enthält die Menge der Zugriffsrechte R ij, die ein Subjekt Si auf ein Objekt O j hat. Mögliche Zugriffsrechte sind Lesen, Schreiben, Löschen oder Anlegen. Die Granularität der Objekte und Subjekte ist ein sehr wichtiger Parameter bei der Konzeption eines diskreten Zugriffskontrollmodells mit weitreichenden Auswirkungen auf den späteren Betrieb. Werden zum Beispiel nur komplette Tabellen eines RDBMS als Objekte identifiziert, so ist es später nicht möglich den Zugriff auf Datensätze innerhalb einer Tabelle einzuschränken. Subjekte Objekte O 1 O... 2 S 1 R 11 R 12 O j R 1 j S 2 R 21 R 22 R 2 j... S i R i1 R i2 Abbildung 4: Zugriffskontrollmatrix Ein Beispiel für einen nicht autorisierten Informationsfluss soll folgende Problematik verdeutlichen: Subjekt S 1 ist Besitzer einer vertraulichen Tabelle O 1 und gewährt nur Subjekt S 2 Leserechte für diese Tabelle. Subjekt S 2 könnte nun eine neue Tabelle O 2 anlegen, die entsprechenden Rechte dafür vorausgesetzt, und den Inhalt von O 1 hineinkopieren. Danach könnte S 2 als Erzeuger und Eigentümer der Tabelle O 2 einem Dritten Leserechte auf O2 erteilen und so die vertraulichen Inhalte veröffentlichen obwohl S 1 dies eigentlich nicht zulassen wollte. Solches Fehlverhalten von Subjekten kann somit nur im Nachhinein durch Auditing-Maßnahmen erkannt werden. R ij 13

14 Kapitel 2. Grundlagen DAC Mechanismen sind für starke Systemsicherheit wenig oder nur sehr eingeschränkt geeignet, denn Zugriffsentscheidungen werden nur aufgrund von Identität und Eigentumsrechten getroffen und ignorieren dabei andere sicherheitsrelevante Informationen, so wie etwa die Rolle des Benutzers oder die Schutzbedürftigkeit eines Objekts Fähigkeitslisten Zugriffskontrollmatrizen eignen sich zwar sehr gut für eine übersichtliche, logische Darstellung, sind in der Praxis aufgrund ihrer Unflexibilität und schnell wachsenden Größe allerdings ungeeignet. Durch das zeilenweise Zerlegen der Zugriffskontrollmatrix entstehen Fähigkeitslisten (capability list, CL), die jedem Subjekt die erlaubten Zugriffsrechte bezüglich der einzelnen Objekte zuordnen und diese direkt beim Subjekt speichern. Subjekt 1 Objekt 1 Objekt 5 R 11 R 15 Subjekt 2 Objekt 3 R 23 Subjekt 3 Objekt 5 R Subjekt n Objekt 1 Objekt 2 Objekt 4 R n1 R n2 R n4 Abbildung 5: Fähigkeitsliste Vorteilhaft an dieser Art der Rechteverwaltung ist, dass nur noch relevante (nicht leere) Einträge gespeichert werden und dass die Frage, welche Rechte ein bestimmtes Subjekt hat, schnell entscheidbar ist. Nachteilhaft dagegen wirkt sich aus, dass es zu einer unkontrollierten Propagierung von Rechten (und daher auch zu Problemen beim Entzug (Revokation) dieser Rechte) kommen kann. Des weiteren können die einzelnen Fähigkeitslisten sehr lang werden, wenn die Zahl der Objekte in einem System die Zahl der Subjekte bei weitem übersteigt. Letztlich kann die Frage, wer auf ein bestimmtes Objekt zugreifen darf, aufgrund der gewählten Speicherungsstruktur für die administrierten Rechte nicht direkt beantwortet werden. Hierzu ist eine exhaustive Suche über die Fähigkeitslisten aller im System vorhandenen Subjekte erforderlich [Kaß95] Zugriffskontrolllisten Die alternative Darstellung ist die Zugriffskontrollliste (access control list, ACL). Hierbei erfolgt die Partitionierung der Zugriffskontrollmatrix spaltenweise. Jedes Element der Liste spezifiziert für ein Objekt, welche Subjekte welche Art von Zugriff haben. Objekt 1 Subjekt 1 R 11 Subjekt 4 R 41 Subjekt 2 R 21 Objekt 2 Subjekt 9 R Objekt n Subjekt 4 R 4n Subjekt 9 R 9n Abbildung 6: Zugriffskontrollliste 14

15 Kapitel 2. Grundlagen Ein Vorteil von Zugriffskontrolllisten besteht darin, dass die zu verwaltenden Listen recht kurz sind, sofern die Zahl der Subjekte in einem System kleiner als die Zahl der Objekte ist. Der Verwaltungsaufwand lässt sich sogar noch weiter reduzieren, wenn Subjekte in Gruppen angeordnet werden. Darüber hinaus lassen sich die für ein bestimmtes Objekt zugriffsberechtigten Subjekte schnell bestimmen, und es werden nur relevante Einträge verwaltet. Die gewählte Speicherungsstruktur wirkt sich insofern nachteilig aus, als dass die Fähigkeiten eines Subjektes nur durch die Traversierung der Zugriffskontrolllisten aller Objekte bestimmt werden können. Für benutzerbestimmbare Zugriffskontrolle ist es essentiell, dass bei der Erzeugung eines Objektes mindestens ein Subjekt in die Zugriffskontrollliste eingetragen wird (meist das erzeugende Subjekt). Im mobilen Datenbankszenario, so auch bei HERMES, ist die Anzahl der Subjekte häufig bedeutend größer als die Anzahl der Objekte, so dass der Einsatz einer Zugriffskontrollliste die günstigere Alternative darstellt, sofern man die Subjekte zusätzlich gruppiert. Für HERMES soll jedoch aus Gründen der Effizienz zu jedem Objekt keine Liste zugriffsberechtigter Subjekte (bzw. Gruppen) gespeichert werden, sondern nur ein Eintrag. Dies hat den Vorteil, dass die Zugriffsberechtigungen direkt am Objekt gespeichert werden können und keine aufwendige Traversierung durchgeführt werden muss. Die zugreifenden Subjekte sowie Art der Objekte, deren Granularität und die genaue Umsetzung finden sich im Abschnitt Weitergabe von Rechten Eine charakteristische Eigenschaft benutzerbestimmbarer Zugriffskontrolle in Abgrenzung zu regelbasierter Zugriffskontrolle (vergleiche Abschnitt ) ist die Möglichkeit der Subjekte, Rechte für den Zugriff auf eigene Objekte weiterzupropagieren oder erteilte Rechte zu entziehen. Grundsätzlich sind zwei Arten von Rechtepropagierungen zu unterscheiden [Kaß95]: Wird ein Recht mit Kopiererlaubnis (grant option) an ein Subjekt weiterpropagiert, so wird der Empfänger ermächtigt, dieses Recht seinerseits anderen Subjekten zu erteilen. Erfolgt die Delegierung ohne Kopiererlaubnis, so kann der Empfänger zwar die dadurch autorisierten Operationen auf Objekten durchführen, die Weitergabe dieser Rechte ist ihm jedoch untersagt. Ziel eines wohldefinierten Autorisierungssystems muss es sein, die Historie der Weitergaben genau zu verfolgen, um unkontrolliertes Propagieren zu vermeiden. Auf diese Weise soll erreicht werden, dass der Systemzustand nach dem Entzug eines Rechtes so ist, als ob dieses Recht nie erteilt worden wäre. Dabei können zwei Probleme auftreten [Kaß95]: i. Ein Subjekt (Empfänger) kann dasselbe Recht von verschiedenen anderen Subjekten (Absendern) erhalten haben. Ruft einer der Absender dieses Recht zurück, so darf dies nicht zu einer Entziehung der durch andere Subjekte gewährten Rechte führen. ii. Da das Empfängersubjekt nach dem Erhalt eines Rechtes mit Kopiererlaubnis berechtigt ist, dieses Recht seinerseits weiterzupropagieren, muss diese Möglichkeit der Weitergabe beim Rückruf eines Rechtes ebenfalls Berücksichtigung finden. Wurde dasselbe Recht auch von anderen Absendern erhalten (siehe i), so können, je nach zeitlicher Reihenfolge, die Weitergaben von Rechten an Dritte trotz des Rückrufs eines Absenders unbeeinflusst bleiben. Ein Propagierungs- und Revokationsalgorithmus, der diese Probleme löst und sich durchgesetzt hat, wird erstmals in System R [GW76] vorgestellt und soll hier nicht näher betrachtet werden. Gängige DBMSe (Oracle, DB2) machen sich die Prinzipien des Algorithmus zu Nutze und speichern in internen Tabellen (Systemtabellen) das folgende 4-Tupel (A,P,O,B) ab. Nutzer A (grantor) hat Privileg P (select, delete, update, insert) auf Objekt O (Tabelle, Sicht) an den Nutzer B (grantee) gewährt. Die SQL-Norm bietet für die Zugriffskontrolle und Rechtedelegierung GRANT und REVOKE an: GRANT privilege [,...] ON object [ ( column [,...] ) ] [,...] TO { PUBLIC username [,...] } [ WITH GRANT OPTION ] 15

16 Kapitel 2. Grundlagen GRANT erlaubt das Erteilen von Zugriffsrechten (Privileges) bis auf einzelne Spalten einer Tabelle und die Möglichkeit die eigenen Rechte an Dritte weiterzugeben (WITH GRANT OPTION). Objekte sind unter anderem Basisrelationen und Sichten. REVOKE [ GRANT OPTION FOR ] { SELECT INSERT UPDATE DELETE REFERENCES } ON object [ ( column [,...] ) ] FROM { PUBLIC username [,...] } { RESTRICT CASCADE } REVOKE, als inverse Operation zu GRANT, dient dem Entziehen von Zugriffsrechten. Dies wird dadurch kompliziert, dass ein Benutzer dasselbe Recht über unterschiedliche GRANT-Anweisungen erhalten haben kann (siehe Punkt i). Der die REVOKE-Operation auslösende Benutzer muss derjenige gewesen sein, der diese Rechte auch gewährt hat. Die optionale Angabe GRANT OPTION FOR in der REVOKE-Anweisung bedeutet, dass der Benutzer nicht versucht, die angegebenen Rechte per se zu löschen, sondern nur für diese Rechte die Berechtigung zur Rechtevergabe zu widerrufen. Bekommt Nutzer B ein spezielles Recht mit grant-option von Nutzer A und gibt es seinerseits weiter an Nutzer C, dann kann Nutzer A das Recht kaskadierend entziehen, mittels dem CASCADE-Schlüsselwort. Wenn hingegen RESTRICT spezifiziert wurde, kann Nutzer A das Recht nicht entziehen, wenn es Nutzer B bereits an andere Nutzer gewährt hat Systembestimmte Zugriffskontrolle Die Zugriffskontrolle in benutzerbestimmten Zugriffskontrollsystemen zeichnet sich durch ein hohes Maß an Flexibilität aus, da jeder Besitzer von Daten prinzipiell in der Lage ist, jedem Subjekt Zugriff auf diese Daten zu gewähren. Häufig fordert die Anwendungssemantik, insbesondere im militärischen Bereich, jedoch eine restriktivere Einschränkung des Zugriffs durch fest definierte Anwendungsregeln, die den Kreis der möglichen zugreifenden Objekte beschränkt. Die sachgerechte Benutzung diskreter Zugriffskontrolle allein reicht nicht aus, um diese Regeln einzuhalten, da nicht erzwungen werden kann, dass jedes Subjekt sie befolgt [Rup02]. Dies motiviert die Einführung systembestimmter oder mandatorischer Zugriffskontrolle, die den Gedanken verfolgt, im System einheitlich vorgegebene Sicherheitsrichtlinien (Policies) durchzusetzen. Die Policy wird dabei durch einen Administrator systemweit und fest vorgegeben, wobei Benutzern nicht erlaubt wird, diese zu ändern bzw. weiterzugeben. Die so festgelegten systemglobalen Eigenschaften dominieren über die benutzerspezische Rechtevergabe, das heißt, ein Zugriff auf ein Objekt wird auch dann verweigert, wenn es zwar eine explizite Benutzerfreigabe gibt, diese jedoch im Gegensatz zur durchzusetzenden systemweiten Vorgabe steht. Hieraus folgt insbesondere (im Gegensatz zu benutzerbestimmten Zugriffskontrolle), dass der Besitzer eines Objektes unter Umständen überhaupt keinen Zugriff mehr auf seine eigenen Objekte hat. Die Zugriffsentscheidung wird schließlich anhand von Attributen getroffen, welche den Objekten zugeordnet sind und eine Reihe von sicherheitsrelevanten Informationen beinhalten. Als nachteilig kann die Starrheit der anfangs festgelegten Richtlinien gesehen werden, die während der Laufzeit nicht änder- bzw. anpassbar sind und eine entsprechende vorausdenkende Anfangsimplementierung bedingen. Die häufigste Form dieser Art von Sicherheitspolicies stellt das Multilevel Security Konzept dar. Hierbei wird jeder Entität (Subjekt als auch Objekt) ein bestimmtes Sicherheitslevel mit dementsprechenden Rechten zugeordnet. Die detailliertere Beschreibung einer Umsetzung namens "Oracle Label Security", erfolgt im Abschnitt Rollenbasierte Zugriffskontrolle Neben dem traditionellen DAC und MAC kann die Vergabe von Zugriffsrechten auch rollenbasiert erfolgen (role-based access control, RBAC). Hierbei stehen nicht die Subjekte sondern die durch sie durchzuführenden Aufgaben im Vordergrund. Benutzer, die aufgrund ihrer Aufgaben und Verantwortlichkeiten, über die gleichen Rechte verfügen sollen, werden dann einer bestimmten Rolle (benannte Zusammenfassung von Rechten) zuge- 16

17 Kapitel 2. Grundlagen ordnet. Rollen sind eine Weiterentwicklung des Gruppenkonzeptes, bei dem lediglich Mengen von Benutzern nach verschiedenen Kriterien zusammengefasst werden. Zwischen Rollen und Benutzern sowie Rollen und Zugriffsrechten auf Objekte existiert eine n:m-beziehung. Ein Subjekt kann mehreren Rollen zugeordnet sein und eine Rolle kann viele Subjekte als Mitglieder besitzen. Ebenso kann eine Rolle die Zugriffsrechte auf mehrere Objekte repräsentieren und ein Objekt darf von mehreren Rollen bearbeitet werden [Rup02]. Rollen können durchaus hierarchisch strukturiert sein. Dabei muss darauf geachtet werden, dass keine Zyklen bei der Zuweisung entstehen. Subjekte Rolle 1... Rolle n Rolle 2 Rolle 3 Objekte Abbildung 7: Hierarchie einer rollenbasierten Zugriffskontrolle 2.4. Anforderungen an die Zugriffskontrolle von HERMES Das lokale Einfügen, Ändern und Löschen auf replizierten Daten ist eine wesentliche Forderung von HERMES, da, im Unterschied zu herkömmlichen Touristenführern, die mobilen Nutzer weitgehend selbst die Daten für das System erstellen und pflegen (Nutzeradministratoren) sollen. Dazu gehören Informationen über Hotels, Restaurants (z.b. Speisekarten) und Reiseberichte. Zur Realisierung dieser Funktionalität wird eine adäquate Nutzerverwaltung und Rechtevergabe benötigt. Die klassischen schemaorientierten Techniken in Datenbanksystemen sind in einer Umgebung mit vielen Tausend und wechselnden Nutzern, die vorwiegend Daten in dieselben wenigen Tabellen einfügen bzw. deren Inhalte modifizieren, nicht ausreichend. Vielmehr werden datenabhängige Verfahren und erweiterte Zugriffsmodi mit folgenden Zusicherungen benötigt: Jedes Objekt hat einen Besitzer (Eigentümer-Paradigma). Der Besitzer kann anderen Nutzern Rechte auf seine Objekte vergeben. Die Rechtevergabe auf Subjekte muss variierbar sein: Es müssen sowohl einzelne Subjekte als auch Gruppen von Subjekten autorisiert werden können. Der lesende Zugriff ist mit Ausnahme der privaten Bereiche uneingeschränkt möglich. Nutzer können nur auf autorisierte Objekte schreibend zugreifen Die Existenz von sogenannten Nutzeradministratoren, die als Datenkontrolleure mit erweiterten Rechten die von anderen Nutzern eingebrachte Daten prüfen (auf Korrektheit, Verstöße, usw.) und gegebenenfalls aktualisieren. Die Objekte von HERMES sind häufig langlebig. Zugriffsbeschränkungen auf diese Objekte können sich daher im Laufe der Zeit ändern. Die Durchführung dieser Änderungen oder die Vergabe neuer Zugriffsrechte muss somit dynamisch, das heißt im laufenden System, erfolgen können. Keineswegs sollte die Spezifikation neuer Autorisierungen nur am "stehenden" System vorgenommen werden können. Zugriffskontrollmechanismen sollen einen möglichst geringen Einfluss auf das Laufzeitverhalten und den Speicherplatzbedarf haben. Das Autorisierungssystem muss zu jedem Zeitpunkt logisch konsistent sein. Es hat die verfolgte Sicherheitspolitik korrekt abzubilden. Das System soll einfach handhabbar und auch unabhängig von einer RPS-Umgebung einsetzbar sein. 17

18 Kapitel 2. Grundlagen Das Ziel besteht deshalb darin, ein System zum Differenzieren und Verwalten der Objekte und der darauf basierenden Rechte zu schaffen. Die Granularität des Kontrollbereichs sollte grundsätzlich möglichst fein (idealerweise stellen die Objekte einzelne Tupel dar) sein, um auf die heterogenen Anforderungen im HERMES-Umfeld individuell reagieren zu können. Einschränkungen sind jedoch im Hinblick auf die Performance zu beachten. Je feiner die autorisierbaren Granularitäten für die Subjekt-, Objekt- und Zugriffstyp-Domänen sind, desto höhere Kosten fallen für die Evaluierung von Sicherheitsanfragen und die Administration von Rechten an Zugriffskontrolle in Datenbanksystemen Dieser Abschnitt beschäftigt sich mit den zur Verfügung stehenden Möglichkeiten der Zugriffskontrolle in relationalen Datenbanksystemen. Detaillierte produktspezifische Syntax-Betrachtungen werden nicht angestellt, vielmehr soll die Gesamtanalyse im Mittelpunkt stehen, die durch Einhaltung der SQL-Norm seitens der Datebank- Produkte ermöglicht wird. So bieten DBM-Systeme alle durchweg Mechanismen wie Sichten, Trigger, Prozeduren und die Umsetzung der benutzerbestimmten Zugriffskontrolle. Hauptaugenmerk wird auf die Verwirklichung feingranularer Zugriffsbeschränkung im Hinblick auf die Entwicklung eines Zugriffkontrollsystems für HERMES gelegt Nutzerverwaltung und Authentifizierung Grundsätzlich verfügt jedes Datenbanksystem über Nutzer und Gruppen, die auf die Datenbankobjekte zugreifen wollen. Ein einzelner Nutzer kann dabei mehreren Gruppen angehören und jede Gruppe kann beliebig viele Mitglieder besitzen. Oracle-Datenbanken unterstützen zudem das in Abschnitt beschriebene Rollenkonzept. Die Nutzer und Gruppen können entweder durch das Datenbanksystem selbst (z.b. Sybase Adaptive Server Enterprise oder Oracle9i) oder implizit durch das zugrundeliegende Betriebssystems (z.b. DB2) definiert werden. Die Authentifizierung der Nutzer kann im DBMS selbst (Oracle9i, Sybase ASE), durch das Betriebssystem (DB2, Oracle9i, Sybase ASE) oder durch separate externe Produkte (z.b. Kerberos) erfolgen. Die grundlegende Autorisierung der Zugriffe auf Objektebene erfolgt in jedem Fall innerhalb des DBMS Schemabasierte Rechtevergabe Allen relationalen Datenbanksystemen ist die Rechtevergabe auf einzelne Objekte (z.b. Tabellen, Sichten) eines Schemas oder auf das Schema selbst gemein. Die Rechte lassen sich grundsätzlich in Objekt- und System-Rechte (sog. Authorities bei DB2, system privileges bei Oracle) einteilen. System-Rechte stellen eine Zusammenfassung von Rechten auf einer höheren als die Schema- bzw. Objekt-Ebene dar (bei DB2 z.b. Rechte auf Instanzenebene). Die Rechte auf einzelne Objekte realisieren die Umsetzung der DAC-Funktionalität. Jedes Objekt hat einen Besitzer (vornehmlich der Erzeuger desselben), der sämtliche Rechte auf dieses innehält und die Weitergabe (mittels GRANT) bzw. den Entzug (mittels REVOKE) von Rechten auf dieses Objekt an andere Nutzer bzw. Gruppen nach eigenem Ermessen regulieren kann. Bei Interaktion eines Nutzers mit den Objekten der Datenbank werden seine Rechte geprüft und bei nicht vorhandener Autorisierung entsprechende Fehler erzeugt. Diese elementare grobgranulare Rechtevergabe, sollte geschickt mit anderen Mechanismen kombiniert werden, um eine spezialisierte (werte- bzw. zeilenbasierte) Zugriffskontrolle zu ermöglichen Zugriffskontrolle durch Programmlogik Wird die Zugriffskontrolle in die Applikationslogik eingebettet, so autorisiert selbige an die Datenbank gerichtete SQL-Anfragen. Durch den zusätzlichen Anwendungscode kann der Zugriff auf einzelne Datensätze eingeschränkt und überwacht werden, dennoch kann diese zusätzliche Sicherheitsvorkehrung umgangen werden, indem ein Nutzer außerhalb der Anwendung, beispielsweise durch andere Anwendungen, Tools oder durch Di- 18

19 Kapitel 2. Grundlagen rektzugriff, auf die Datenbank zugreift. Will die Anwendung den Zugriff auf die Daten anhand deren Sensibilität 2 vornehmen, so sind in der Regel viele zusätzliche (Hilfs-)Tabellen nötig Physische Separation durch Nutzung mehrerer Datenbanken Eine alternative Methode, die Daten anhand ihrer Sensibilität zu trennen und nur befugten Subjekten Zugang zu gewähren, stellt die Verwendung eine separaten Datenbank für jede Sensibilitätsstufe dar. So erhält man beispielsweise eine extra Datenbank für alle streng vertraulichen Daten, eine weitere für geheime und eine letzte für allen zugängliche Informationen. Dieser Ansatz ist in der Praxis völlig unakzeptabel. Der Overhead in punkto Ressourcenverbrauch (Arbeitsspeicher, Plattenplatz) und die Kosten der Verwaltung bzw. Administration einer Datenbank multiplizieren sich mit der Anzahl der neuen Datenbanken. Weiterhin bedarf das Auslesen von Daten aus verschiedenen Datenbanken sogenannten Distributed Queries und spezieller Anwendungslogik Einsatz von Sichten Generell ist es vorteilhafter die Autorisierungslogik so nahe als möglich bei den Daten zu implementieren, so dass eine Umgehung unmöglich ist. Sichten realisieren die Vereinfachung komplexer Datenbankschemata auf konkret benötigte Teildaten (sogar auf feingranulare Tupel- und Spaltenebene) und liefern logische Datenunabhängigkeit, d.h. Anwendungen, die auf die Sichten zugreifen bleiben stabil gegenüber Schemaänderungen. Indem einzelnen Nutzern oder Gruppen die Rechte auf die zu Grunde liegenden Basistabellen entzogen werden und die entsprechende Zuordnung zu den einzelnen Sichten mit passenden Objekt-Rechten (INSERT, UPDATE, DELETE, SELECT) vorgenommen wird, erlaubt man den Subjekten bzw. Anwendungen den Zugriff auf schutzbedürftigen Daten ausschließlich über die Sichten. Auf diese Weise ist es möglich, sensible Tupel aus Datenschutzgründen zu verbergen bzw. auch um Daten in neuer Form zu präsentieren. Die optionale Spezifikation von WITH CHECK OPTION bei der Sichtenerzeugung respektiert die angestrebte Zugriffskotrolle insofern, als dass keine INSERT- oder UPDATE-Operationen erlaubt sind, die zum Verletzen der Sichtdefinition führen würden. In Verbindung mit dem Spezialwert USER (vorhanden in DB2, Oracle, ASE) und der Verwendung der Gruppe PUBLIC (gefordert von der SQL-Norm) bei der Rechtevergabe können benutzerspezifische, parametrisierte Sichten erzeugt werden, die für jeden Nutzer anders aussehen. USER liefert den aktuellen Nutzernamen, der einer Datenbanksession zugeordnet ist. PUBLIC ist eine symbolische Gruppe, der jeder Datenbanknutzer implizit angehört. Es folgt eine Veranschaulichung des Prinzips: create view EigeneAuftraege as select * from Auftraege where Name = USER with check option; revoke all privileges on Auftraege from PUBLIC; grant select, insert on EigeneAuftraege to PUBLIC; Durch die Erzeugung der Sicht, dem Entziehen sämtlicher Rechte auf die Basistabelle und anschließender Rechtezuweisung an sämtliche Nutzer kann jeder Benutzer (nur) seine persönlichen Aufträge (vorausgesetzt die Tupel verfügen über die Spalte "Name") sehen und neue einfügen, aber nicht löschen. Um Sichten zur Klassifikation von Tupeln nach Sensibilität zu ermöglichen, ist schon mehr Aufwand nötig: create view sensitive_employee as select * from employee where sensitivity='sensitive' or sensitivity = 'Confidential' or sensitivity = 'Public' create view confidential_employee as select * from employee where sensitivity = 'Confidential' or sensitivity = 'Public' 2 Schutzwürdigkeit 19

20 Kapitel 2. Grundlagen create view public_employee as select * from employee where sensitivity = 'Public' Wie an dem Beispiel deutlich wird, muss für jedes Sicherheitslevel eine separate Sicht und in den Basistabellen eine zusätzliche Spalte für die Klassifizierung der Tupel definiert werden. Im obigen Beispiel befähigt ein höheres Sicherheitslevel auch zum Zugriff auf weniger hoch eingestufte Tupel. Obige Technik ist nur für eine kleine Anzahl an Nutzern ratsam, da die vielen Sichten verwaltet und sämtlichen Nutzern adäquate Rechte zugewiesen werden müssen. Oft ist dieser Ansatz auch zu starr, wenn sich die zu Grunde gelegene Sicherheitspolitik ändert (z.b. bei Einführung neuer Sicherheitslevel). Nachteilig gestaltet sich die schlechte Performance bei der Definition großer Sichten (z.b. Mehrfachjoin von Tabellen mit vielen Tupeln), da Anfragen an die Sicht immer erst in entsprechende Anfragen an die Basistabellen umgewandelt werden müssen. Ebenfalls problematisch ist die eingeschränkte Update-Fähigkeit von Sichten. Unterschiedliche DBMS-Produkte haben zudem andere Bedingungen zur Gewährung des schreibenden Zugriff auf die Sicht (generell müssen die Attribute eindeutig den Basistabellen zugeordnet werden können) Trigger Ein Trigger ist ein Block von (PL)SQL-Anweisungen, die mit einer Tabelle oder einer Sicht assoziiert und für ein ereignisbedingtes Auslösen von Aktionen zuständig ist. Beim Entwurf von Triggern werden ein Ereignis (INSERT, DELETE, UPDATE (auch auf einzelne Spalten)), eine Bedingung (BEFORE, AFTER, INSTEAD OF) für die Aktivierung desselben spezifiziert und die Aktion(en) zur Ausführung, wenn der Trigger aktiviert wurde. Durch die normkonforme Angabe von for each row bzw. for each statement wird der Trigger für jede Einzeländerungen einer mengenwertigen Änderung bzw. nur einmal für die gesamte Änderung "gefeuert". Somit können Schreibrechte einzelner Tupel (in Verbindung mit dem Wert des aktuellen Nutzers, z.b. durch die USER- Variable) autorisiert werden. Wenn Anweisungen den Sicherheitsanforderungen der Triggerdefinition nicht genügen, kann ein Fehler signalisiert werden, um eine entsprechende Änderung an den Daten der Basistabelle zu verhindern. Trigger werden zwar auf eine Basistabelle (oder Sicht) definiert, können aber durchaus Aktionen auf anderen Tabellen derselben Datenbank ausführen, um so tabellenübergreifende Zugriffsrechte zu prüfen. Die sogenannten INSTEAD-OF-Trigger, die lediglich auf Sichten definiert werden können, ersetzen die den Trigger auslösende Operation komplett durch die Anweisungen im Rumpf und können so eigene Prüfungen oder Semantiken implementieren. Sogenannte INSTEAD-OF-VIEWS (Sichten mit INSTEAD-OF-Triggern) erlauben dann beispielsweise einem gewissen Personenkreis ein update auf mehrere Tabellen durch die Sicht, auf die sie normalerweise nur lesenden Zugriff hätten, sei es durch gewollte Schreibbeschränkungen oder durch die nicht mögliche Änderbarkeit der Sicht augrund der Einschränkungen des DBMS. Leserechte (SELECT) können durch Trigger jedoch nicht geprüft werden. Daher ist die Kombination von Triggern mit anderen in diesem Abschnitt. beschriebenen Techniken für eine vollständige Sicherheitspolitik notwendig. Trigger können zudem durch ihre Aktionen auch wieder (ungewollt) andere Trigger auslösen. Nicht nur muss man evtl. Kaskadierungen im Überblick behalten um Zyklen zu vermeiden, die Performance kann dadurch auch nachteilig beeinflusst werden Routinen (Prozeduren, Funktionen) Routinen können vielseitig programmiert (extern mit einer Hochsprache, Parameterübergabe, verschiedene Rückgabetypen, Zugriff auf externe Dateien, Verwendung von dynamischem SQL) und dementsprechend breitgefächert angewendet werden. Sie können den Code für die Zugriffsregeln beinhalten und sollten eingesetzt werden, wenn eine Kombination von Sichten zusammen mit den normalen DAC-Rechten auf Schemaobjekte unzureichend für die angestrebten Zwecke ist. So kann eine Prozedur oder Funktion von Triggern oder von der Applikation aufgerufen werden, um beispielsweise vor einem INSERT gegen eine Tabelle eine Reihe von Rechte- Prüfungen vorzunehmen. Der Nachteil wird dabei auch deutlich. Man muss "Hintertüren" zu den Rohdaten vermeiden, so dass z.b. kein Einfügen gegen die Basistablle mehr möglich ist. Des weiteren können Routinen alleine nicht wirksam werden. Es bedarf immer einer aufrufenden Komponente (Applikation, Trigger, oder andere Routinen). 20