Entwurf einer anwendungsunabhängigen Zugriffskontrolle mittels ...

Technische Universität Darmstadt
Fachbereich: Informatik
Informationstechnologie Transfer Office
Entwurf einer anwendungsunabhängigen
Zugriffskontrolle mittels AOP
am Beispiel eines Fahrtenbuch-Dienstes
Diplomarbeit
Andreas Blecher
Darmstadt, 15. Juli 2003
Eingereicht bei:
Prof. Alejandro Buchmann, Ph. D.
Fachgebiet für Datenbanken und Verteilte Systeme
Fachbereich Informatik
Technische Universität Darmstadt
Betreuung durch:
Dipl.-Inform. Andreas Görlach und
Dr. Mariano Cilia
Informationstechnologie Transfer Office
Technische Universität Darmstadt
Dr.-Ing. Sven Riedel
OnStar Europe
GM Europe GmbH, Rüsselsheim

Erklärung
Hiermit versichere ich, dass ich die vorliegende Arbeit selbständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Aschaffenburg, 15. Juli 2003
Andreas Blecher

Inhaltsverzeichnis
Inhaltsverzeichnis
ABBILDUNGSVERZEICHNIS .............................................................................................................III
TABELLENVERZEICHNIS....................................................................................................................V
ABKÜRZUNGSVERZEICHNIS ...........................................................................................................VI
1 EINLEITUNG .................................................................................................................................. 1
1.1 HINTERGRUND UND MOTIVATION ............................................................................................. 1
1.2 PROBLEMSTELLUNG .................................................................................................................. 2
1.3 ÜBERBLICK................................................................................................................................3
2 SICHERHEITSANALYSE: FAHRTENBUCH-SZENARIO ...................................................... 4
2.1 ÜBERBLICK: FAHRTENBUCH- SZENARIO ................................................................................... 4
2.2 INTERESSENGRUPPEN UND SCHUTZZIELE .................................................................................. 5
2.2.1 Sicht des Fahrers ................................................................................................................. 6
2.2.2 Sicht des Dienstbetreibers.................................................................................................... 8
2.2.3 Sicht des Herstellers ............................................................................................................ 8
2.2.4 Sicht des Finanzamts............................................................................................................9
2.3 SICHERHEITSKONZEPTE FÜR ELEKTRONISCHE FAHRTENBÜCHER............................................. 10
2.3.1 Sicherheitsanforderungen .................................................................................................. 10
2.3.2 Datenerhebung im Fahrzeug ............................................................................................. 11
2.3.3 Vertraulichkeit der Datenübertragung .............................................................................. 14
3 ZUGRIFFSKONTROLLVERFAHREN UND AOP................................................................... 17
3.1 ZUGRIFFSKONTROLLLÖSUNGEN FÜR DEN SCHUTZ VON FAHRTDATEN .................................... 17
3.1.1 Zugriff auf den Fahrtenbuch-Server .................................................................................. 17
3.1.2 Benutzerauthentifizierung .................................................................................................. 18
3.1.3 Zugriffskontrolle durch das Dateisystem bzw. die Datenbank........................................... 18
3.1.4 Rollenbasierte Zugriffskontrollverfahren........................................................................... 20
3.1.5 Policy-basierte Zugriffskontrollverfahren.......................................................................... 22
3.2 PROBLEME ÜBLICHER ZUGRIFFSKONTROLLVERFAHREN.......................................................... 25
3.2.1 Fahrtenbücher und Zugriffskontrollen............................................................................... 25
3.2.2 Vermischung von Quellcode und Zugriffskontrolle............................................................ 25
3.2.3 Abhängigkeit der Anwendung vom verwendeten Verfahren .............................................. 27
3.3 ANWENDUNGSUNABHÄNGIGKEIT DURCH ASPEKTORIENTIERTE PROGRAMMIERUNG (AOP)... 29
3.3.1 Motivation für AOP............................................................................................................ 29
3.3.2 Aspekte............................................................................................................................... 29
3.3.3 Dynamische und Statische Querverbindungen .................................................................. 30
3.3.4 Die Software AspectJ TM ...................................................................................................... 30
I

Inhaltsverzeichnis
4 ENTWURF: POLICY-BASIERTE ZUGRIFFSKONTROLLE................................................ 33
4.1 GRUNDLAGEN ......................................................................................................................... 33
4.1.1 Die Entwurfziele................................................................................................................. 33
4.1.2 Die Einteilung der Sicherheitsfunktionen in Pakete........................................................... 35
4.1.3 Das MIX-Datenmodell ....................................................................................................... 36
4.2 DIE ARCHITEKTUR DES ZUGRIFFSKONTROLLSYSTEMS ............................................................ 37
4.2.1 Der Sicherheitsproxy ......................................................................................................... 37
4.2.2 Die Verwaltung der Zugriffsregeln .................................................................................... 39
4.2.3 Die Benutzerschnittstelle für die Policy-Verwaltung ......................................................... 41
4.3 DIE ZUGRIFFSVERWALTUNG.................................................................................................... 42
4.3.1 Die Verwaltung der Policy-Dateien................................................................................... 43
4.3.2 Die Benutzerverwaltung..................................................................................................... 44
4.3.3 Die Objektverwaltung ........................................................................................................ 45
4.3.4 Die Aktionsverwaltung....................................................................................................... 46
4.4 DAS SEMANTISCHE DATENMODELL ZUR ZUGRIFFSVERWALTUNG ........................................... 47
4.4.1 Ontologien für die Zugriffsverwaltung............................................................................... 48
4.4.2 Ontologien für die Objektverwaltung................................................................................. 49
4.4.3 Ontologien für die Aktionsverwaltung ............................................................................... 50
5 IMPLEMENTIERUNG DER ZUGRIFFSKONTROLLE......................................................... 51
5.1 ASPEKTORIENTIERTE ZUGRIFFSKONTROLLE............................................................................ 51
5.1.1 Der anwendungsspezifische Autorisierungsaspekt ............................................................ 51
5.1.2 Der anwendungsunabhängige Autorisierungsaspekt......................................................... 53
5.2 IMPLEMENTIERUNG DER POLICY-BASIERTEN ZUGRIFFSKONTROLLE ....................................... 54
5.2.1 Speicherung von Policy Dateien in der XML Datenbank eXist ......................................... 54
5.2.2 Zugriff auf die Policies mittels XPath ................................................................................ 57
5.2.3 Darstellung der Zugriffsregeln als MIX-Ontologien.......................................................... 59
6 SCHNITTSTELLEN UND KONFIGURATIONEN................................................................... 63
6.1 DAS APPLICATION PROGRAMMING INTERFACE ....................................................................... 63
6.2 KONFIGURATION ..................................................................................................................... 66
6.2.1 Die Zusammenstellung der Sicherheitslösung ................................................................... 66
6.2.2 Die Konfiguration der Policy-basierten Zugriffskontrolle................................................. 67
6.3 VERGLEICH UND BEURTEILUNG .............................................................................................. 71
7 SCHLUSSBETRACHTUNGEN................................................................................................... 72
7.1 FAZIT....................................................................................................................................... 72
7.2 ZUSAMMENFASSUNG DER BEITRÄGE....................................................................................... 73
7.3 AUSBLICK................................................................................................................................73
LITERATURVERZEICHNIS...................................................................................................................I
II

Abbildungsverzeichnis
Abbildungsverzeichnis
ABBILDUNG 1: FAHRTENBUCH-SZENARIO (EIGENE DARSTELLUNG) ............................................................ 4
ABBILDUNG 2: MODELL FAHRTENBUCH SERVER (EIGENE ABBILDUNG) ...................................................... 5
ABBILDUNG 3: SICHERHEITSANFORDERUNGEN VON FAHRTENBÜCHERN (EIGENE DARSTELLUNG) ............ 11
ABBILDUNG 4: MÖGLICHE RISIKEN BEI DER DATENÜBERTRAGUNG (EIGENE DARSTELLUNG) ................... 15
ABBILDUNG 5: NIST CORE RBAC REFERENZMODELL (VGL. [FSG01] S. 232).......................................... 20
ABBILDUNG 6: BEISPIEL FÜR EINE XACML POLICY (VGL. [DBS02] S. 11) ............................................... 24
ABBILDUNG 7: ANWENDUNGSPROGRAMM INKLUSIVE RECHTEPRÜFUNG ................................................... 25
ABBILDUNG 8: BEISPIELANWENDUNG OHNE ZUGRIFFSFUNKTIONALITÄT................................................... 27
ABBILDUNG 9: VERTEILUNG DER ZUGRIFFSKONTROLLFUNKTIONALITÄT (IN ANLEHNUNG AN [HHI02] S. 5)
.......................................................................................................................................................... 27
ABBILDUNG 10: SICHERHEITSPAKETE (EIGENE DARSTELLUNG)................................................................. 35
ABBILDUNG 11: ARCHITEKTUR DER ZUGRIFFSKONTROLLE (EIGENE DARSTELLUNG) ................................ 36
ABBILDUNG 12: AUTORISIERUNG VON FAHRTENBUCH-ZUGRIFFEN (VGL. [BHH01] S. 323)...................... 38
ABBILDUNG 13 : DAS BUTTERFLY-MODELL (VGL. [NOR01] S. 6 F.).......................................................... 40
ABBILDUNG 14: „POLICYSET“ FENSTER (EIGENE DARSTELLUNG) ............................................................. 41
ABBILDUNG 15: „POLICY“ FENSTER (EIGENE DARSTELLUNG) ................................................................... 42
ABBILDUNG 16: SEQUENZDIAGRAMM „ZUGRIFFSKONTROLLPRÜFUNG“ (EIGENE DARSTELLUNG) ............. 43
ABBILDUNG 17: SICHERHEITSSTATUS ........................................................................................................ 45
ABBILDUNG 18: „ERZEUGUNG EINES NEUEN OBJEKTES“ (EIGENE DARSTELLUNG) .................................... 45
ABBILDUNG 19: KLASSENDIAGRAMM AKTIONSVERWALTUNG (EIGENE DARSTELLUNG) ........................... 47
ABBILDUNG 20: „POLICYSET“ DARGESTELLT ALS KLASSENDIAGRAMM (EIGENE DARSTELLUNG)............. 48
ABBILDUNG 21: „POLICYSET“ DARGESTELLT ALS MIX-ONTOLOGIE (EIGENE DARSTELLUNG).................. 48
ABBILDUNG 22: BEISPIELPOLICY IM MIX-FORMAT (EIGENE DARSTELLUNG) ........................................... 49
ABBILDUNG 23: KLASSENDIAGRAMM: „GESCHÜTZTE KLASSE“ (EIGENE DARSTELLUNG).......................... 50
ABBILDUNG 24: DIE ONTOLOGIE „GESCHÜTZTE AKTIONEN“ (EIGENE ABBILDUNG) .................................. 50
ABBILDUNG 25: DER FAHRTENBUCH SPEZIFISCHE AUTORISIERUNGS ASPEKT ........................................... 51
ABBILDUNG 26: DIE METHODE “GETUSERID” (EIGENE ABBILDUNG)......................................................... 52
ABBILDUNG 27: POINTCUT: „AUTHORIZATIONOPERATIONS“ (EIGENE DARSTELLUNG) ............................. 53
ABBILDUNG 28: POINTCUT „INITIALIZATION“ (EIGENE DARSTELLUNG)..................................................... 54
ABBILDUNG 29: POINTCUT „SECUREDOBJECTCONSTRUCTORS“ (EIGENE DARSTELLUNG)......................... 54
ABBILDUNG 30: ARCHITEKTUR VON EXIST (VGL. [MEI03] ABSCHNITT „FEATURES“) ............................... 55
ABBILDUNG 31: BEISPIEL FÜR EIN POLICYSET ........................................................................................... 56
ABBILDUNG 32: FUNKTION „QUERYASRESOURCESET“ ............................................................................. 58
ABBILDUNG 33: BEISPIELE FÜR SUCHANFRAGEN ....................................................................................... 58
ABBILDUNG 34: ONTOLOGIE „POLICYSET“................................................................................................ 59
ABBILDUNG 35: FABRIK-METHODE „CREATEPOLICYSET()“ ...................................................................... 60
III

Abbildungsverzeichnis
ABBILDUNG 36: ONTOLOGIE POLICY.......................................................................................................... 60
ABBILDUNG 37: BEISPIEL-POLICY AUS EINEM XML POLICYSET................................................................ 61
ABBILDUNG 38: ONTOLOGIE SECUREDOBJECTTYPE.................................................................................. 62
ABBILDUNG 39: ONTOLOGIE SECUREACTION ............................................................................................ 62
ABBILDUNG 40: KLASSENDIAGRAMM „SECURITY FACADE“ ...................................................................... 63
ABBILDUNG 41: METHODE „VIEWPOLICYSET“ DER KLASSE „SECURITY FACADE“.................................... 64
ABBILDUNG 42: KLASSENDIGRAMM „SECURITY PORTAL“......................................................................... 65
ABBILDUNG 43: KONFIGURATIONSDATEI „SECURITY.XML“....................................................................... 67
ABBILDUNG 44: KONFIGURATIONSDATEI „POLICYCONFIGURATION.XML“ ................................................ 68
ABBILDUNG 45: KONFIGURATIONSDATEI „OBJECTCONFIGURATION.XML“................................................ 69
ABBILDUNG 46: BEISPIEL FÜR EINE DTD ZUR ÜBERPRÜFUNG DER VALIDITÄT DER KONFIGURATION....... 70
ABBILDUNG 47: KONFIGURATIONSDATEI „ACTIONCONFIGURATION.XML“................................................ 70
ABBILDUNG 48: FUNKTION „ISACTION“..................................................................................................... 71
IV

Tabellenverzeichnis
Tabellenverzeichnis
TABELLE 1: PERSONENBEZOGENE DATEN IN EINEM FAHRTENBUCH ............................................................ 6
TABELLE 2: GEFAHREN FÜR FAHRTDATEN ................................................................................................... 7
TABELLE 3: SCHUTZANFORDERUNGEN DES DIENSTBETREIBERS .................................................................. 8
TABELLE 4: ANFORDERUNGEN AN FAHRTENBÜCHER SEITENS DES FINANZAMTS ....................................... 10
TABELLE 5: MÖGLICHKEITEN ZUR EINDEUTIGEN IDENTIFIKATION VON FAHRZEUGEN............................... 12
TABELLE 6: AUTHENTIFIZIERUNG DES FAHRERS ........................................................................................ 13
TABELLE 7: ELEMENTE DES CORE RBAC REFERENZMODELLS .................................................................. 21
TABELLE 8: ENTWURFSZIELE DIESER ARBEIT............................................................................................. 34
TABELLE 9: PAKETE FÜR EINE SICHERHEITSARCHITEKTUR FÜR EINEN FAHRTENBUCH-DIENST ................. 35
V

Abkürzungsverzeichnis
Abkürzungsverzeichnis
Abs.
Absatz
AOP Aspektorientierte Programmierung (engl. aspect oriented
programming)
API
bzw.
DAC
DTD
EHU
engl.
etc.
Application Programming Interface
Beziehungsweise
Discretionary Access Control
Document Type Definition
Entertainment Head Unit
englisch
et cetera
f. folgende
ff.
GM
GmbH
GPS
GUI
fortfolgende
General Motors
Gesellschaft mit beschränkter Haftung
Global Positioning System
Graphical User Interface
i. S. im Sinne
ITO
JAAS
MAC
MIX
IT Transfer Office
Java Authentication and Authorization Service
Mandatory Access Control
Metadata based Integration model for data X-change
VI

Abkürzungsverzeichnis
NIST
Nr.
o.J.
PDA
RBAC
National Institute for Standards and Technology
Nummer
ohne Jahr
Personal Digital Assistent
Role Based Access Control
S. Seite
SSL
StGB
TDDSG
TDSV
v.a.
vgl.
XML
XSL
z.B.
Secure Socket Layer
Strafgesetzbuch
Teledienste Datenschutz Gesetz
Telekommunikationsdienste-Datenschutz-Verordnung
vor allem
Vergleiche
Extensible Markup Language
Extensible Style Language
zum Beispiel
VII

Einleitung
1 Einleitung
Diese Diplomarbeit wurde im Rahmen einer Kooperation zwischen der GM Europe
GmbH und dem Forschungsinstitut IT Transfer Office (ITO) (vgl. [ITOoJ]) zum
Themenbereich „Telematikdienstleistungen und –infrastrukturen“ erstellt.
Im Folgenden wird der Themenbereich kurz vorgestellt und das Ziel der vorliegenden
Arbeit wird beschrieben. Anschließend folgt ein Überblick über die Arbeit.
1.1 Hintergrund und Motivation
Der Siegeszug der Informations- und Kommunikationstechnologien hat auch vor
heutigen Automobilen nicht Halt gemacht. Heute können Telematik-Anwendungen
Fahrer bei der Routenführung unterstützen und mit aktuellen Verkehrsinformationen
versorgen. Ermöglicht werden diese „location based services“ durch eine Kombination
von Informationstechnologien, Telekommunikation und GPS-Positionsermittlung.
Weitere Anwendungsbeispiele sind ein automatischer Notruf, das Tracking von
gestohlenen Fahrzeugen und elektronische Fahrtenbücher, deren Ziel es ist, die
Funktionalität des Fahrzeuges zu verbessern und Kosten für den Fahrer zu senken.
Diese Telematik-Dienste können im Auto mittels einer „Entertainment Head Unit“
(EHU) genutzt werden. Die EHU ist eine Unterhaltungselektronik, bestehend aus einem
Display, einem integrierten Mobiltelefon, Autoradio, CD Laufwerk und Internet-
Zugang. Alternativ kann auch ein im Fahrzeug integrierter PDA genutzt werden, um
Daten vom Mobilitätsportal abzurufen (siehe z.B. OnStar Car@Web [OhmoJ]). Auf
dem Mobilitätsportal (vgl. z.B. das OnStar Mobility Portal [OnSoJ]) kann der Fahrer
auf seinen Kalender zugreifen oder seine persönlichen Einstellungen für die
Übertragung von Verkehrs- und Städteinformationen und weiteren Diensten ändern.
Ergänzt werden diese personenbezogenen Mobilitätsdienste in Zukunft um
fahrzeugbezogene Dienste (vgl. [CHB02]). Diese speichern Informationen über das
Fahrzeug, wie zum Beispiel Statistiken zum Benzinverbrauch, die Termine für die
nächsten Inspektionen oder auch ein Fahrtenbuch. Ein elektronisches Fahrtenbuch
speichert analog zu einem Fahrtenbuch in Papierform alle privaten und geschäftlichen
Fahrten, damit der Fahrer beim Finanzamt die pauschal abgerechneten Fahrten
nachweisen kann, um die Kosten abzusetzen.
1

Einleitung
1.2 Problemstellung
Diese Diplomarbeit soll sich mit dem Themenkomplex der Sicherheit verteilter Dienste
in Fahrzeugen anhand des Beispiels eines Fahrtenbuchs auseinander setzen und eine
Zugriffskontrolle für einen Fahrtenbuch-Dienst entwickeln. Dabei sollen folgende
Aspekte untersucht werden:
• Aspekt „Vertraulichkeit“
Hier ist die Frage zu beantworten, ob nur diejenigen Personen die Daten
bekommen, die dazu autorisiert sind.
• Aspekt „Authentizität“
Der Aspekt „Authentizität“ untersucht, ob die Daten tatsächlich von dem
angegebenen Wagen bzw. Fahrer stammen. Da mehrere Fahrer gemeinsam einen
Wagen nutzen können (z.B. bei einer Car-Sharing Gesellschaft) muss sowohl
das Fahrzeug als auch der Fahrer eindeutig identifiziert werden.
• Aspekt „Integrität“
Hier soll erörtert werden, mit welchen Verfahren man sicherstellen kann, ob der
Inhalt der Daten nicht verfälscht worden ist.
Da das Fahrtenbuch unabhängig von der Zugriffskontrolllösung entwickelt wurde,
müssen Mechanismen gefunden werden, die eine Anpassung der Sicherheitslösung an
das Fahrtenbuch, ohne Änderungen am Programmcode des Fahrtenbuches ermöglichen.
Die Zugriffskontrolle soll außerdem auch von anderen Diensten eingesetzt werden
können. Es wird gezeigt, dass eine solche „anwendungsunabhängige Zugriffskontrolle“
mit Hilfe aspektorientierter Programmierung (AOP) realisiert werden kann.
Anhand des Fahrtenbuch-Szenarios wird erörtert, welche Arten von Schnittstellen und
Konfigurationsmöglichkeiten geeignet sind, um anwendungsspezifische Besonderheiten
einfach zu unterstützen. Die in einer weiteren Diplomarbeit erstellte gruppenbasierte
Fahrtenbuch-Anwendung (vgl. [Kor03]) wird dabei als Beispielanwendung zur
Darstellung von Sicherheitsrisiken und Einsatz einer Sicherheitslösung herangezogen.
2

Einleitung
1.3 Überblick
Diese Arbeit setzt sich aus einer Einleitung und sechs weiteren Kapiteln zusammen:
In Kapitel 2 wird ein Sicherheitskonzept für ein Fahrtenbuch erstellt. Dieses umfasst
neben der Autorisierung von Benutzerzugriffen auch Empfehlungen für die authentische
Datenerhebung, die sichere Datenübertragung sowie den ordnungsgemäßen Betrieb des
Fahrtenbuch-Servers.
Kapitel 3 beschreibt, welche Zugriffskontrollverfahren in Fahrtenbüchern eingesetzt
werden, und diskutiert alternative Zugriffskontrollverfahren. Außerdem wird erklärt,
warum die Verwendung eines Application Programming Interfaces, wie es die meisten
derartiger Verfahren einsetzen, nicht geeignet ist, um eine anwendungsunabhängige
Sicherheitslösung zu realisieren. Stattdessen wird gezeigt, wie mit Hilfe von
aspektorientierter Programmierung eine Zugriffskontrolle entwickelt werden kann, die
in Verbindung mit beliebigen Anwendungen genutzt werden kann, ohne Anpassungen
am Programmcode der Anwendung vornehmen zu müssen.
Kapitel 4 beschreibt die Architektur der Sicherheitslösung und den Entwurf eines
policy-basierten Zugriffskontroll-Dienstes.
In Kapitel 5 wird der Prototyp der Zugriffskontrolle erläutert, der mit Hilfe von AspectJ
und der XML-Datenbank eXist implementiert wurde.
Kapitel 6 widmet sich der Konfigurierung der Zugriffskontrolle. Hier wird am Beispiel
einer Fahrtenbuch-Anwendung gezeigt, wie die Sicherheitslösung mittels XML-
Konfigurationsdateien an anwendungsspezifische Besonderheiten angepasst werden
kann.
3

Sicherheitsanalyse: Fahrtenbuch-Szenario
2 Sicherheitsanalyse: Fahrtenbuch-Szenario
In diesem Kapitel sollen fahrtenbuchspezifische Sicherheitsaspekte wie
„Vertraulichkeit“, „Authentizität“ und „Integrität“ untersucht werden.
2.1 Überblick: Fahrtenbuch- Szenario
Ein Fahrtenbuch hat den Zweck, alle Fahrten, die mit einem Fahrzeug durchgeführt
werden, ordnungsgemäß aufzuzeichnen, um anstelle eines Pauschalbetrags die
tatsächlich gefahrenen Kilometer steuerlich geltend machen zu können. Dazu muss in
den Aufzeichnungen eindeutig zwischen privaten Fahrten, Fahrten zur Arbeit und
geschäftlichen Fahrten unterschieden werden. Fahrtenbücher werden aber nicht nur für
die Vorlage beim Finanzamt geführt. Eine Firma kann ein Fahrtenbuch auch
verwenden, um sich einen Überblick über den Einsatz ihrer Firmenwagen zu
verschaffen. Und manchmal kommt es vor, dass notorische Verkehrsünder zur Führung
eines Fahrtenbuchs verkehrsgerichtlich verurteilt werden.
Fahrtenbücher gibt es heutzutage nicht mehr nur in Papierform, sondern auch als
elektronischer Dienst im Fahrzeug. Abbildung 1 zeigt die Infrastruktur, von der in
diesem Szenario ausgegangen wird.
Abbildung 1: Fahrtenbuch-Szenario (eigene Darstellung)
Im Fahrzeug gibt es ein Fahrzeugendgerät, das die Fahrtdaten sammelt und sie dem
Fahrer anzeigen kann. Um die Fahrtdaten vom Fahrzeug zum Server des
Dienstbetreibers zu übermitteln, wird ein Gateway benötigt, der die Daten über
Mobilfunk empfängt und sie über das Internet weiterleitet. Die Fahrtdaten werden auf
dem Server des Dienstbetreibers gespeichert, so dass auch andere autorisierte Personen
Zugriff auf die aktuellen Daten erhalten können und die Daten vor Verlust geschützt
sind. Zudem soll es möglich sein, auch externe Daten Dritter in das Szenario
4

Sicherheitsanalyse: Fahrtenbuch-Szenario
einzubinden, um z.B. dem Fahrer seine Kalendereinträge als Zielortauswahl zur
Verfügung zu stellen oder um Fahrtenbuch-Einträge in anderen Anwendungen zu
verwenden.
Das folgende Modell zeigt den Aufbau eines exemplarischen Fahrtenbuch Servers,
bestehend aus den Teilen Fahrtenbuch-Verwaltung inklusive einer Personalisierungs-
Komponente und einer Kundenverwaltung. Mit Hilfe der Personalisierungskomponente
lassen sich z.B. Aliase für Zielorte definieren. Die Kundenverwaltung sorgt für die
Verwaltung der Benutzer inklusive der notwendigen Sicherheitsfunktionen.
Abbildung 2: Modell Fahrtenbuch Server (eigene Abbildung)
2.2 Interessengruppen und Schutzziele
Ein Sicherheitskonzept für verteilte Dienste, wie das beschriebene Fahrtenbuch, muss
die speziellen Schutzanforderungen der beteiligten Personengruppen berücksichtigen.
Am Beispiel der Fahrtenbuch-Anwendung sollen einige Schutzziele erläutert werden,
die aus Sicht des Anbieters, der Benutzer (z.B. Fahrer) und Dritter (z.B. Finanzamt oder
Werkstätten) zu berücksichtigen sind. Andere Telematik-Anwendungen können
hingegen andere Schutzanforderungen aufweisen.
5

Sicherheitsanalyse: Fahrtenbuch-Szenario
2.2.1 Sicht des Fahrers
Personen, die ein Fahrtenbuch führen (im Folgenden nur noch Fahrer genannt) sind zum
Beispiel Mitarbeiter, die einen Firmenwagen haben, Fahrer in einer Fahrzeugflotte oder
auch Privatpersonen. Diese Fahrer sind primär am Schutz ihrer persönlichen Fahrtdaten
vor dem unbefugten Zugriff durch Dritte interessiert. Das deutsche Datenschutzgesetz
verbietet daher den Dienstbetreibern die unbefugte Speicherung und Nutzung
personenbezogener Daten (vgl. [Hob98] S. 50 f. und [Koc98] S. 358 f.). Die folgende
Tabelle erläutert mögliche personenbezogene Daten in einem Fahrtenbuch:
Daten
Inhaltsdaten
Nutzungsdaten
Fahrtenbuch spezifische Bedeutung
Zu den übertragenen Inhaltsdaten gehören vor allem die
Fahrtdaten, wie z.B. Abfahrts- und Zielort. Diese Daten sind
schützenswert, da sie zu Lasten des Fahrers verwendet werden
könnten.
Möchte ein Fahrer den Fahrtenbuchdienst nutzen, dann benötigt
der Fahrtenbuchdienstbetreiber von ihm Informationen über seine
Person, wie Fahrername, Fahrzeugidentifikation,
Nutzungszeitraum. Nach § 6 Abs. 2 TDDSG sind Nutzungsdaten
sofort nach Beendigung der Nutzung des Teledienstes zu löschen.
Abrechnungsdaten Werden Verbindungsdaten für Abrechnungszwecke verwendet,
dann handelt es sich gemäß § 6 Abs. 1 TDSV bzw. Nach § 6 Abs.
1 TDDSG um Abrechnungsdaten. Diese Daten dürfen nicht länger
gespeichert werden, als es für die Abrechnung erforderlich ist.
Bestandsdaten
Um den Fahrtenbuchdienst nutzen zu können, geht der Fahrer mit
dem Betreiber einen Vertrag ein. Dazu werden Vertragsdaten
(siehe § 4 Abs. 1 Satz 1 TDSV) für die Vertragserstellung benötigt.
Üblicherweise werden Vertragsdaten dauerhaft gespeichert und
bereitgehalten. Beispiele für Vertragsdaten sind der Fahrername
oder die IMSI der SIM-Karte.
Tabelle 1: Personenbezogene Daten in einem Fahrtenbuch
6

Sicherheitsanalyse: Fahrtenbuch-Szenario
Der Schutz durch das Datenschutzgesetz ist vor allem wichtig, da verschiedene
Personen in Kontakt mit den Fahrtdaten kommen, und da die Daten über das
Mobilfunknetz und das Internet übertragen werden müssen. Die folgende Auflistung
über Gefahren für personenbezogene Fahrtdaten soll dies verdeutlichen.
Gefahr
Erstellung von
Bewegungsprofilen
Erläuterung
Ein elektronisches Fahrtenbuch soll den Fahrer primär entlasten.
Um die Position des Autos zu bestimmen, wird in der Regel GPS
in Verbindung mit Dead Reckoning (vgl. [NEV01]) eingesetzt.
Ein datenschutzrechtliches Problem hierbei ist die Möglichkeit des
„Tracking’s“ der Fahrt.
Diese Daten könnten für Bewegungsprofile missbraucht werden,
die Rückschlüsse auf berufliche Aktivitäten und private Interessen
des Fahrers geben. Abhilfe bieten hier Verschlüsselungstechniken
und eine Zugriffskontrollfunktion.
Missbrauch von
Fahrtdaten
Manipulation von
Fahrtdaten
Der Fahrer geht davon aus, dass die Übertragung und Speicherung
der Fahrtdaten vertraulich ist. Das Recht auf informationelle
Selbstbestimmung und das Fernmeldegeheimnis schützt ihn aber
nur vor Eingriffen durch den Staat. Das Ausspähen von
elektronischen Nachrichten durch Privatpersonen ist dagegen nur
strafbar (§ 202a StGB), wenn die elektronische Übermittlung
gegen unberechtigten Zugriff gesichert ist (vgl. [Hob98] S. 156 ff.
und [Jae98] S. 168 ff.).
Personenbezogene Daten können manipuliert werden, um dem
Betroffenen zu schaden. Zum Beispiel könnte jemand versuchen,
Fahrtdaten im Auto oder auf der Webseite zu löschen oder zu
verändern. Aber auch der Fahrer selbst könnte versuchen,
Fahrtdaten zu manipulieren oder zusätzliche einzugeben.
Tabelle 2: Gefahren für Fahrtdaten
7

Sicherheitsanalyse: Fahrtenbuch-Szenario
2.2.2 Sicht des Dienstbetreibers
Unter Dienstbetreiber wird hier eine Firma verstanden, die einen Teledienst (das
elektronische Fahrtenbuch) auf einem Server anbietet. Auch der Dienstbetreiber stellt
Schutzanforderungen an die Führung eines elektronischen Fahrtenbuchs.
Gefahr
Schutz vor
unbefugtem
Zugriff
Hohe
Verfügbarkeit
Sicherung
Daten
der
Erläuterung
Der Zugriff auf Fahrtdaten darf nur nach erfolgreicher
Authentifikation des Nutzers erfolgen.
Da die Fahrtdaten mehrerer Fahrer und Fahrzeuge in einer
Datenbank gespeichert werden, muss sichergestellt sein, dass nur
auf die eigenen Daten zugegriffen werden darf. Ferner sollte der
Nutzer festlegen können, wer auf seine Daten Zugriff erhält und
diese Zugriffsberechtigungen auch wieder entziehen können. Es
sind geeignete Benutzerrollen oder Zugriffsrechte zu definieren.
Die Leistung des Fahrtenbuch-Servers muss einer mittleren bis
hohen Anzahl konkurrierend zugreifender Nutzer gerecht werden.
Der Zugriff beschränkt sich im Wesentlichen auf Abgleichung der
Fahrtdaten zwischen Fahrzeug und Server. Es muss jedoch damit
gerechnet werden, dass zu bestimmten Jahreszeiten eine erhöhte
Zugriffsrate aufgrund der betrieblichen und steuerlichen
Abrechnungszeiträume entstehen kann.
Zu sichern sind nicht nur die Fahrtbuchdaten, sondern auch die
Konfigurationsdaten, da diese wichtige Informationen, wie z.B.
Alias-Namen für Orte, enthalten. Ziel der Datensicherung ist es sie
gegen Unauffindbarkeit und Vernichtung zu sichern.
Tabelle 3: Schutzanforderungen des Dienstbetreibers
2.2.3 Sicht des Herstellers
Fahrzeughersteller und Hersteller von Fahrzeugendgeräten müssen dafür sorgen, dass
die Geräte im Fahrzeug jederzeit verfügbar sind. Ein Ausfall eines Gerätes würde die
zeitnahe Aufzeichnung von Fahrten verhindern. Ein weiteres Problem ist der begrenzte
8

Sicherheitsanalyse: Fahrtenbuch-Szenario
Speicher von Fahrzeugendgeräten, wodurch nur eine begrenzte Anzahl von Fahrten
aufgezeichnet werden kann.
Um die aufgezeichneten Fahrtdaten weiterzuverwerten, werden sie mittels eines
integrierten GSM-Telefons (in Zukunft UMTS) zu einem Fahrzeugportal übertragen.
Dabei ist die Vertraulichkeit der Übertragung ein Problem. Alternativ könnte man die
Fahrtdaten im Auto an einen PDA über RS232 oder Bluetooth übertragen.
Der Fahrzeughersteller benötigt zudem Fahrtdaten in aggregierter Form, um
Rückschlüsse auf Verwendung, aufgetretene Probleme etc. zu erhalten.
2.2.4 Sicht des Finanzamts
Ein elektronisches Fahrtenbuch wird vom Finanzamt anerkannt, wenn sich daraus
dieselben Erkenntnisse wie aus einem manuell geführten Fahrtenbuch gewinnen lassen.
Das Finanzamt will daher Zugriff auf die „Originaldaten“ erhalten. Von „Originaldaten“
zu sprechen, ist jedoch problematisch, da technisch gesehen, die Originaldaten im
Fahrzeug gespeichert sind. Gemeint sind hiermit aber, die Daten, deren Echtheit vom
Dienstbetreiber z.B. durch Verwendung von Signaturen gewährleistet werden kann. Die
Speicherung der Daten in originären digitalen Dokumenten muss gewährleisten, dass
eine nachträgliche Bearbeitung nicht möglich ist und dass die Dokumente in
angemessener Form archiviert werden (vgl. [BfF95]).
Die ordnungsgemäße Führung eines Fahrtenbuchs entspricht den Anforderungen, wie
sie an elektronische Aufzeichnungen in anderen Bereichen verlangt werden, wie bei der
Führung eines elektronischen Fristenbuches und bei den Grundsätzen ordnungsmäßiger
Buchführung. Die Fahrten eines Firmenwagens müssen sich in ihrer Entstehung und
Abwicklung nachvollziehen lassen.
Aus Sicht des Finanzamts ergeben sich die folgenden Anforderungen an ein
elektronisches Fahrtenbuch:
9

Sicherheitsanalyse: Fahrtenbuch-Szenario
Anforderung
Erfassung aller
Fahrten
Nachvollziehbare
Veränderungen
Chronologisch
und zeitnah
Erläuterung
Ein elektronisches Fahrtenbuch hat alle Fahrten, die mit einem
Fahrzeug durchgeführt werden, aufzuzeichnen. Ein Fahrtenbuch,
das z.B. nicht den Zweck einer geschäftlichen Reiseroute aufführt,
kann vom Finanzamt abgelehnt werden (vgl. [OatoJ]).
Ein elektronisches Fahrtenbuch ist nur dann ordnungsgemäß
geführt i. S. des § 6 Abs. 1 Nr. 4 Satz 2 EStG, wenn nachträgliche
Veränderungen der Aufzeichnungen technisch ausgeschlossen,
zumindest aber dokumentiert werden. Durch die Möglichkeit einer
(nicht überprüfbaren) nachträglichen Änderung hätte es der
Steuerpflichtige nämlich in der Hand, das Jahresergebnis seiner
PC-Eingaben — anders als bei einem z. B. handschriftlich
geführten Fahrtenbuch — nachträglich spurlos zu ändern, um so
ein für ihn „besseres Ergebnis“ zu erhalten.
Das Fahrtenbuch muss fortlaufend und zeitnah geführt werden,
damit es als ordnungsgemäß gelten kann. Der Zeitpunkt der
Eintragung sollte erkennbar sein. Außerdem sollten die Fahrten
chronologisch erfasst und aufgeführt werden (vgl. [DaB99]).
Tabelle 4: Anforderungen an Fahrtenbücher seitens des Finanzamts
2.3 Sicherheitskonzepte für elektronische Fahrtenbücher
2.3.1 Sicherheitsanforderungen
Aus den diskutierten Schutzzielen ergeben sich konkrete Sicherheitsanforderungen. Der
Dienstbetreiber und die Hersteller müssen dafür sorgen, dass das Fahrtenbuch jederzeit
verfügbar ist. Für die Fahrer ist nur eine Lösung geeignet, die ihnen eine vertrauliche
Verwendung der Daten erlaubt, und für das Finanzamt ist es wichtig, das die
Fahrtenbücher authentisch und unverfälscht sind.
10

Sicherheitsanalyse: Fahrtenbuch-Szenario
Abbildung 3: Sicherheitsanforderungen von Fahrtenbüchern (eigene Darstellung)
Die Sicherheitsanforderungen addieren sich, so dass eine einfache Sicherheitslösung
nicht ausreichen kann. Vielmehr bedarf es dem Zusammenspiel mehrerer Lösungen,
wie Verschlüsselungs-, Signatur- und Zugriffskontrollverfahren.
Im Folgenden werden primär Sicherheitslösungen für den Schutz der Daten im
Fahrzeug und auf dem Server erörtert. Es wird speziell der Punkt
Zugriffskontrollverfahren betrachtet. Zuvor wird jedoch erörtert, welche
Sicherheitsrisiken bei der Datenerhebung im Fahrzeug sowie bei der Datenübertragung
zum Server es gibt und welche Sicherheitslösungen sich anbieten.
2.3.2 Datenerhebung im Fahrzeug
Zur ordnungsgemäßen Fahrtenbuchführung sind Informationen über den Fahrer, die
gefahrene Strecke und das Fahrzeug notwendig. Die Frage ist nun, wie man
authentische Daten über das Fahrzeug, die Fahrtdaten und den Fahrer erhält, die nicht
vom Fahrer oder Dritten manipuliert werden können.
2.3.2.1 Eindeutige Identifikation des Fahrzeugs
Eine dieser Fragen lautet: „Wie kann man das Fahrzeug eindeutig identifizieren?“
Hierzu können folgende „Identifikationen“ verwendet werden:
11

Sicherheitsanalyse: Fahrtenbuch-Szenario
Möglichkeit
Fahrzeugspezifische
Identifikationen
Eingravierte
Seriennummer
Elektronische
Seriennummer
Digitale Signaturen
(vgl. [GoM02])
Erläuterung
Fahrzeugspezifische Merkmale wie Kennzeichen, Marke, Modell
oder Farbe können zur Identifikation eines Fahrzeugs verwendet
werden. Für die elektronische Identifikation reichen diese jedoch
nicht aus, da sie entweder nicht eindeutig sind (z.B. Marke,
Modell, Farbe) oder da sie einfach zu fälschen sind (z.B.
Kennzeichen).
Auch die eingravierte Seriennummer (engl. vehicle identification
number (VIN)) ist für Identifikation eines Fahrzeugs einer Flotte
untauglich, da sie nicht über große Entfernungen hinweg
abgefragt werden kann (Problem der Ortsgebundenheit). Zudem
könnte die Nummer bei der Übertragung verfälscht werden.
Die Seriennummer kann auch elektronisch bei Herstellung des
Fahrzeugs gespeichert werden, z.B. im Bordcomputer. Diese
elektronische Nummer kann für elektronische Dienste zur
eindeutigen Identifizierung des Fahrzeugs genutzt werden.
Eine weitere Möglichkeit zur Identifizierung von
Kraftfahrzeugen über drahtlose Netze in Kombination mit einer
GPS-Positionsermittlung sind digitale Signaturen. Jedes
Fahrzeug erhält ein Schlüsselpaar, das zum Signieren und
Verschlüsseln von Daten verwendet werden kann.
Tabelle 5: Möglichkeiten zur eindeutigen Identifikation von Fahrzeugen
Digitale Signaturen haben den Vorteil, dass sie auch für andere Anwendungen (wie z.B.
für die Lokalisierung eines Fahrzeuges) genutzt werden könnten (vgl. [GoM02]).
12

Sicherheitsanalyse: Fahrtenbuch-Szenario
2.3.2.2 Authentifizierung des Fahrers
Authentifizierung beweist, dass man tatsächlich die Person ist, die man vorgibt zu sein
(vgl. [BHH01] S. 147). Folgende Verfahren ermöglichen eine Authentifizierung des
Fahrers:
Verfahren
Manuelle Auswahl
des Fahrernamens
auf PDA
Identifikation
mittels Transponder
Identifikation
mittels Chipkarte
Identifikation
mittels SIM-Karte
Identifikation
mittels
Fingerabdruck
Erläuterung
Eine einfache Lösung ist, dass der Fahrer seine Namen auswählt
und hierzu einen Vorschlagswert erhält. Kombiniert werden kann
dies mit einer PDA gestützten Lösung (vgl. [IfT02a] und
[IfT02b]). Für eine Authentifikation des Fahrers ist aber auch die
Eingabe eines Passworts notwendig.
Eine andere sehr günstige Lösung ist der Einsatz von
Transpondern ([vgl. Mag01]), wobei diese keine echte
Authentifikation ermöglicht, da die Transponderdaten dupliziert
werden könnten.
Mehr Sicherheit verspricht der Einsatz von Chip-Karten (vgl.
[IbNoJ]). Sinnvoll ist eine solche Lösung wegen der damit
verbundenen höheren Kosten aber nur bei Flotten oder Car
Sharing Gesellschaften. Zudem könnten Fahrtdaten direkt auf der
Chipkarte sicher gespeichert werden.
Kostengünstiger als Chipkarten ist der Einsatz von Twin SIM-
Karten (vgl. [SysoJ]). Diese Lösung bietet sich an, wenn die
Fahrer mit ihrer Twin SIM-Karte im Auto auch telefonieren oder
andere Telematik-Dienste übers Internet nutzen möchten.
Eine weitere Alternative wäre die Authentifikation mittels
biometrischer Verfahren. Der Bordcomputer speichert dazu den
Fingerabdruck des Daumens oder Zeigefingers. Um sich zu
authentifizieren, muss sich der Fahrer mit diesem Finger auf dem
Sensor identifizieren (vgl. [Non00]). Solche Lösungen haben sich
bisher aber nicht durchsetzen können.
Tabelle 6: Authentifizierung des Fahrers
13

Sicherheitsanalyse: Fahrtenbuch-Szenario
2.3.2.3 Fahrtdaten Ermittlung
Nicht nur das Fahrzeug und der Fahrer müssen eindeutig identifiziert werden, sondern
auch Fahrtdaten, wie gefahrene Kilometer, müssen authentisch und unverfälschbar sein.
Folgende Daten sind laut Erlass des Bundesministerium für Finanzen für die Vorlage
beim Finanzamt notwendig (vgl. [BfF95]):
• Name des Fahrers (Alternativ könnte auch ein Pseudonym oder die
Mitarbeiternummer eingetragen werden),
• KFZ-Kennzeichen (oder Fahrzeugidentifikationsnummer),
• Kilometerstand,Datum/Uhrzeit bei Fahrtbeginn und bei Fahrtende (werden
automatisch vom Fahrzeug erfasst),
• Abfahrts- und Zielort (mittels GPS-Positionsermittlung) und
• Nutzungsart und Fahrtzweck (Der Fahrer muss auswählen, ob die Fahrt
geschäftlich, privat oder eine Fahrt zur Arbeit ist. Außerdem ist der Fahrtzweck
anzugeben, z.B. der aufgesuchte Geschäftspartner).
Wenn der Fahrer zur Gruppe der Berufsgeheimnisträger, wie z.B. Ärzte, Rechtsanwälte
und Steuerberater, gehört, dann muss er aufgrund des Auskunftsverweigerungsrechts
keine Angaben über den Namen und die Anschrift des Mandanten machen. Für den
Fahrtzweck reicht in diesem Fall die Eintragung „Mandantenbesuch“. Da aber das
Finanzamt im Falle begründeten Zweifels genauere Informationen über den Fahrtzweck
einfordern darf, müssen dennoch Angaben über den Mandanten gespeichert werden.
Diese Daten sind vor unberechtigter Einsicht durch Dritte zu schützen (vgl. [Oat00]).
2.3.3 Vertraulichkeit der Datenübertragung
Abbildung 4 zeigt ein Szenario für ein verteiltes Fahrtenbuch. Es wird ein PDA
verwendet, der Daten mit dem Bordcomputer im Fahrzeug abgleichen kann. Der
Bordrechner sowie der PDA können über ein Mobiltelefon über den Gateway mit dem
Internet verbunden werden. Ein Fahrtenbuch-Server kommuniziert mit dem Gateway
über das Internet, um die Fahrtdaten aus dem Auto abzurufen.
In der Kette vom PDA bis hin zum Fahrtenbuch-Server gibt es zahlreiche
Angriffspunkte. Angreifer könnten versuchen, die Datenübertragung zwischen PDA
und Fahrzeug, Fahrzeug und Gateway sowie zwischen dem Gateway und dem
14

Sicherheitsanalyse: Fahrtenbuch-Szenario
Fahrtenbuch-Server abzuhören. Zur Sicherung der Datenübertragung im Internet
können die üblichen Verfahren wie SSL eingesetzt werden, die für die Zwecke eines
Fahrtenbuches in den meisten Fällen ausreichen sollten.
Abbildung 4: Mögliche Risiken bei der Datenübertragung (eigene Darstellung)
2.3.3.1 Datenübertragung mittels mobiler Geräte und Speichermedien
Zum Datenabgleich können auch mobile Geräte wie PDAs (siehe [Mag01] und
[IfT02a]) oder Chipkarten (siehe [IbNoJ]) eingesetzt werden, die am Personal-
Computer die Daten sichern. In Zukunft könnten auch Datenabgleichstationen (z.B. an
einer Tankstelle) genutzt werden, um Daten zum Dienstbetreiber zu übertragen. Leider
verfügen die Betriebssysteme der meisten Geräte noch nicht über einen ausreichenden
Speicherschutz oder Verschlüsselungsbibliotheken (vgl. [BHH01] S. 150 ff.), so dass
bei Verlust des Gerätes jedermann auf die Fahrtdaten zugreifen könnte.
2.3.3.2 Datenübertragung mittels Mobilfunk und Internet
Die Fahrtdaten können auch mittels Mobilkommunikation und Internet zum Fahrzeug-
Portal übertragen werden (siehe [SysoJ]) und durch Protokolle wie WTLS und TLS
geschützt werden. Da die übertragenen Daten im Gateway entschlüsselt und wieder
verschlüsselt werden müssen, besteht allerdings keine Ende-zu-Ende Sicherheit (vgl.
[Myn00]), außer die Daten werden bereits von der Anwendung verschlüsselt und
entschlüsselt. Um zu verhindern, dass Angreifer die Kommunikation abhören, Daten
15

Sicherheitsanalyse: Fahrtenbuch-Szenario
ausspähen, Trojanische Pferde einspielen oder Denial-of-service Attacken starten
können, ist eine Ende-zu-Ende Verschlüsselung notwendig.
16

Zugriffskontrollverfahren und AOP
3 Zugriffskontrollverfahren und AOP
Zum Schutz der Fahrtenbuch-Daten können verschiedene Zugriffskontrollverfahren
eingesetzt werden. Das folgende Kapitel diskutiert die wichtigsten
Zugriffskontrollverfahren und erläutert warum diese nur bedingt für eine
anwendungsunabhängige Zugriffskontrolle geeignet sind. Anschließend wird gezeigt,
wie mittels aspektorientierter Programmierung diese Mängel behoben werden können.
3.1 Zugriffskontrolllösungen für den Schutz von Fahrtdaten
Im Folgenden wird davon ausgegangen, dass sich die Fahrtdaten auf dem Fahrtenbuch-
Server befinden und vor unberechtigten Zugriffen geschützt werden müssen.
3.1.1 Zugriff auf den Fahrtenbuch-Server
Der Fahrtenbuchdienst soll als Teil eines Fahrzeugportals realisiert werden, welches am
Fachgebiet Datenbanken und verteilte Systeme in Zusammenarbeit mit dem IT Transfer
Office entwickelt wurde (siehe [CiH02]).
Das Fahrzeugportal läuft auf einem J2EE Application Server und setzt Web-Services
ein. Außerdem verwendet es ein semantisches Datenmodell (siehe [Bor98]) und legt
Anwendungsdaten in einer XML Datenbank ab (siehe [CiH02]).
Ziel ist es, die bereits bestehende Architektur, um eine Sicherheitslösung zu erweitern.
Für deren Realisierung bietet sich eine aspektorientierte sowie auf einzelnen Diensten
basierende Architektur an. Die Sicherheitslösung soll in Form von mehreren einzelnen
Diensten realisiert werden (z.B. Zugriffskontrolle, Authentifikation und Auditing), so
dass man diese ohne umfangreiche Anpassungen durch andere Implementierungen
austauschen kann.
Im Folgenden wird am Beispiel des Fahrtenbuch-Dienstes diskutiert, wie Anwendungen
und Daten auf dem Portal vor unbefugten Zugriffen geschützt werden können.
17

Zugriffskontrollverfahren und AOP
3.1.2 Benutzerauthentifizierung
Um auf die Fahrtenbuch-Daten zugreifen zu können, muss sich der Anwender
authentisieren. Dabei können die in Kapitel 2.3.2.2 beschriebenen Verfahren
(Passwörter, Chipkarten oder biometrische Verfahren), die Authentifizierung
ermöglichen, in Verbindung mit Protokollen zur Verschlüsselung sowie dem Remote
Procedure Call-Konzept (vgl. [Eck01] S. 354f.) zum Einsatz kommen.
Die einfachste Form der Benutzerauthentifizierung ist eine Passwortabfrage. Das
System verlangt die Identifikation/Kennung des Benutzers, z.B. durch ein Login-
Prompt. Der Benutzer identifiziert sich durch seine Kennung und authentifiziert sich
durch ein Passwort. Das System vergleicht das eingegebene Passwort mit dem in der
Passwortdatei (vgl. [Eck01] S. 309). Passwortschutz wird häufig von kommerziellen
Systemen eingesetzt (siehe [IbNoJ] und [SysoJ]).
3.1.3 Zugriffskontrolle durch das Dateisystem bzw. die Datenbank
Die Fahrtenbuch-Daten können entweder im Dateisystem des Servers abgelegt werden
oder in einer eigenen Datenbank aufbewahrt werden.
In Unix werden Dateien und Verzeichnisse durch das Definieren so genannter
Zugriffsbits geschützt. Die ersten drei Bits legen die Rechte des Besitzers fest, d.h.
lesenden, schreibenden oder ausführenden Zugriff. Die nächsten drei Bits definieren die
Zugriffsrechte für Gruppenmitglieder der Gruppe des Besitzers (bzw. der Datei) und die
letzten drei Bits die Zugriffsrechte aller anderen Personen. Mittels des Kommandos
„chmod“ können Bits verändert werden (vgl. [Tan95] S. 339).
In der neuesten Version der XML-Datenbank eXist (siehe [Mei03]) wurde ein Unix
ähnlicher Zugriffschutz eingeführt, der ebenfalls Schutzbits für den Benutzer, die
Benutzergruppe und weitere definiert. Es werden wie in Unix drei Zugriffsrechte
(Lesen, Schreiben und Ändern) unterstützt.
Eine Zugriffskontrolle auf Dateisystem-Ebene ermöglicht jedoch keine anwendungsspezifischen
Anpassungen der Zugriffskontrolle. Es lässt sich nicht definieren, welche
Anwendungsmethoden geschützt werden sollen, und eine differenzierte Behandlung der
Daten eines Dokumentes ist ebenfalls nicht möglich. Die Einteilung der Benutzer in die
drei Gruppen Besitzer, Besitzergruppe und Sonstige spiegelt in der Regel nicht die
Benutzerverwaltung einer Anwendung wieder. Der Vorteil einer solchen Lösung ist
18

Zugriffskontrollverfahren und AOP
aber, dass sie von jedem Anwendungsprogramm sofort benutzt werden kann, unter der
Voraussetzung, dass das Programm mit der Situation eines abgelehnten Zugriffs
umgehen kann. Die XML-Datenbank eXist liefert beispielsweise eine
Zugriffsverweigerungsausnahme an den Aufrufer zurück. Daher müsste man alle darauf
basierenden Anwendungen um eine Fehlerbehandlung, die z.B. dem Benutzer eine
sinnvolle Fehlermeldung ausgibt, ergänzen.
Ferner ist ein Zugriffsschutz auf Dateisystem- bzw. Datenbank-Ebene wirkungslos
gegenüber Angriffen von Insidern, besonders wenn es sich um Administratoren handelt
(vgl. [BoP02]). Der Kunde hat dabei keine andere Möglichkeit, als dem Betreiber zu
vertrauen, dass seine Systeme sicher und dessen Mitarbeiter vertrauenswürdig sind.
Jedoch werden laut einer Untersuchung des FBI (siehe [CSI01]) 45% der Angriffe
durch Insider durchgeführt. Zudem ist die Ansammlung personenbezogener Daten, wie
sie in einer Fahrtenbuch-Datenbank vorhanden sind, immer ein interessantes Ziel für
Angreifer.
Um den Anwender auch vor Attacken zu schützen, kann Datenbankverschlüsselung
angewendet werden. Man kann die gesamte Datenbank auf dem Server verschlüsseln
oder auch nur kritische Teile. Dies schützt aber nur vor Angriffen externer
Eindringlinge, da Administratoren Zugriff auf die verwendeten Schlüssel haben.
Würden alle Fahrtenbuch-Daten aber mit einem privatem Fahrzeug- Schlüssel
verschlüsselt in der Datenbank abgelegt, wären zudem keine Auswertungen für die
gesamte Flotte mehr möglich. Dies kann aber für Anfragen zu Kundenterminen oder für
statistische Auswertungen nötig sein. Daher soll sich die Datenbank um die
Verschlüsselung der Daten kümmern und nur besonders kritische Daten könnten separat
verschlüsselt und in einer eigenen Datenbank gespeichert werden (vgl. [BoP02]).
Alternativ wäre es auch möglich, private Daten erst gar nicht an den Fahrtenbuch-
Server für die Flotte zu übermitteln, sondern auf einem PDA oder einer Chipkarte
abzulegen.
In Ergänzung zu diesen Technologien wird in dieser Arbeit versucht, eine
Sicherheitslösung zu entwerfen, die an die Besonderheiten eines Anwendungsprogramms
durch Konfiguration angepasst werden kann.
19

Zugriffskontrollverfahren und AOP
3.1.4 Rollenbasierte Zugriffskontrollverfahren
Rollenbasierte Zugriffskontrollen (engl. „role based access controll“ [RBAC]) werden
häufig für die Zugriffskontrolle in verteilten Mehrbenutzer-Systemen genutzt. Daher
eignen sie sich ideal für ein verteiltes Fahrtenbuch.
3.1.4.1 Das Core RBAC Referenzmodell
Das „National Institute for Standards and Technology“ (NIST) hat den Aufbau eines
RBAC Systems festgelegt. Im Folgenden wird nur auf das Grundmodell „Core RBAC“
(vgl. [FSG01] S. 232 ff.) eingegangen, das in der folgenden Abbildung dargestellt ist.
Abbildung 5: NIST Core RBAC Referenzmodell (vgl. [FSG01] S. 232)
Im Referenzmodell werden einer Menge von Benutzern (USERS) eine Menge von
Rollen (ROLES) zugeordnet. Diese Rollen werden wiederum einer Menge von
Berechtigungen (PRMS) zugewiesen, die Zugriffsrechte von Operationen (OPS) auf
Objekte (OBS) definieren.
Wählt ein Benutzer eine Rolle aus der Menge der Rollen aus (man sagt auch „er
aktiviert diese Rolle“), so erhält er die Berechtigungen dieser Rolle. Die Auswahl an
aktiven Rollen wird durch eine Sitzung (SESSION) dargestellt.
Die Pfeile in der Abbildung stellen die Art der Beziehung dar. Pfeile in beide
Richtungen stehen für eine „Many-to-Many-Relation“, während einfache Pfeile eine
„One-to-Many“ Beziehung darstellen. Ein Benutzer kann also mehreren Sitzungen
zugeordnet sein, aber eine Sitzung kann nur einem Benutzer zugewiesen werden. Bei
der Beziehung zwischen Benutzern und Rollen handelt es sich dagegen um „Many-to-
Many-Relationen“. Das heißt eine Rolle kann beliebig vielen Benutzern und ein
Benutzer kann beliebig vielen Rollen zugeordnet werden. Das gleiche gilt auch für
20

Zugriffskontrollverfahren und AOP
Rollen und Berechtigungen, Rollen und Sitzungen sowie Operationen und Objekte (vgl.
[Fis02] S. 32 ff.).
Die Komponenten des Referenzmodells basieren auf folgender Terminologie:
Terminus
Benutzer (engl.
user)
Rollen (engl. roles)
Sitzungen (engl.
sessions)
Operationen (engl.
operations
Objekte (engl.
objects
Zugriffsrechte
(engl. permissions)
Erläuterung
Ein Benutzer kann ein Mensch oder auch ein Objekt (z.B. ein
“Mobile Agent”) sein.
Um den Administrationsaufwand gering zu halten, werden
Benutzern Rollen für gruppenspezifische Aufgabenbereiche
zugeordnet. Ein Benutzer kann mehrere Rollen haben und eine
Rolle kann mehreren Benutzern zugeordnet sein.
Eine Sitzung ist eine Abbildung eines Benutzers auf eine oder
mehrere Rollen. Dieses Konzept erlaubt somit die selektive
Aktivierung und Deaktivierung von Rollen.
Eine Operation ist eine ausführbare Aktion, wie z.B. Daten
hinzufügen, Daten invalidieren und Daten lesen.
Ein Objekt sind Instanzen einer Java-Klasse, wie z.B. eine
Instanz einer Klasse, die einen Fahrtenbuch-Eintrag darstellt.
Ein Zugriffsrecht ist die Genehmigung, eine Operation auf einem
Objekt auszuführen. Zugriffsrechte auf Objekte sind den
einzelnen Rollen zugeordnet. Ein Benutzer erhält somit ein
Zugriffsrecht, indem er einer Rolle zugeordnet ist.
Tabelle 7: Elemente des Core RBAC Referenzmodells
3.1.4.2 Rollen und Fahrtenbücher
Speziell für Flotten (n Fahrer mit m Fahrzeugen) sind rollenbasierte Zugriffskontrollen
sehr gut geeignet. Fahrer dürfen nur über eine Fahrerrolle auf eigene Fahrtdaten
zugreifen. Vertriebsleiter können über eine Rolle „Gebiet X“ auf alle Fahrtdaten ihres
Vertriebsgebietes zugreifen. Und das Management kann eine Rolle „Manager“ erhalten,
mit der man lesenden Zugriff auf alle Daten erhält.
21

Zugriffskontrollverfahren und AOP
Eine Weiterentwicklung zum „Core RBAC“ Modell ist das „Hierarchical RBAC“ (vgl.
[FSG01] S. 234 ff.). Es führt hierarchische Rollen ein, so dass eine Rolle die
Eigenschaften einer anderen Rolle erben kann. So kann man erreichen, dass die
Managerrolle alle Eigenschaften der Vertriebsleiterrolle erbt. Allerdings muss darauf
geachtet werden, dass nicht die Kombination zweier Rollen dazu führt, dass man Rechte
erhält, die außerhalb der Zuständigkeit der Rollen liegen. Beispielsweise darf die
Kombination der Rollen „Betriebsprüfer“ und „Sachgebiet 1“ nicht dazu führen, dass
man plötzlich schreibenden Zugriff auf das Sachgebiet 1 erhält. Um dies zu verhindern,
wurde das Modell zum „Constrained RBAC” Modell erweitert. Dieses erlaubt die
Modellierung von Zuständigkeiten, die nicht verletzt werden dürfen.
Ein solches rollenbasiertes Zugriffsmodell kann in Form eines Frameworks entworfen
werden, das ein „Application Programming Interface“ (API) anbietet. Mittels dieses
API kann man die Zugriffsfunktionalität im Anwendungsprogramm nutzen, indem man
die Funktionen zur Verwaltung der Rollen und für die Zugriffsprüfungen in das
Anwendungsprogramm programmiert (vgl. [Fis02] S. 139). Für eine anwendungsunabhängige
Sicherheitslösung ist die Nutzung eines solchen Frameworks aber nicht
geeignet, da Änderungen (oder der Austausch) an der Sicherheitslösung auch
Änderungen am Anwendungscode verursachen.
3.1.5 Policy-basierte Zugriffskontrollverfahren
3.1.5.1 Autorisierungs-Policies
Ein sehr flexibler Ansatz ist der Einsatz von Policies. Autorisierungs-Policies werden
verwendet, um zu festzulegen, auf welche Dienste oder Ressourcen ein Benutzer
zugreifen kann (vgl. [DBS02] S. 3). Sie entsprechen Zugriffsregeln, d.h. sie definieren
Aktivitäten die ein Subjekt mit einem Software Objekt durchführen darf oder auch
nicht. Solche Policies eignen sich sehr gut für den Zugriffsschutz in verteilten
Systemen, in denen die Zugriffskontrolle in einer Vielzahl von heterogenen
Komponenten implementiert ist (vgl. [DBS02] S. 1 ff.).
Anstelle des Benutzers kann auch eine Benutzerrolle definiert werden, so dass man
diesen Ansatz mit einem rollenbasiertem System kombinieren könnte.
22

Zugriffskontrollverfahren und AOP
Zusätzlich müssen aber noch Policies für den Fall einer Zugriffsverletzung (z.B.
mehrere fehlgeschlagene Login-Versuche) definiert werden. Diese beschreiben dann die
Aktionen, die in einem solchen Fall auszuführen sind.
3.1.5.2 Policy-basierte Ansätze
Man kann Policy-basierte Ansätze unterscheiden, je nachdem, ob sie dem Benutzer
einen „discretionary access control“ (DAC) oder einen „mandatory access control“
(MAC) Zugriff erlauben. DAC Policies beschränken den Zugriff auf Objekte auf
bestimmte Benutzer oder Benutzergruppen. Ferner gestatten sie einem Besitzer, Rechte
weiterzugeben. Realisiert werden kann eine solche Policy z.B. mittels einer
Zugriffskontrollmatrix bestehend aus Benutzer, Objekt und Aktion. Bei MAC Policies
darf hingegen nur eine zentrale Autorität die Regeln festlegen. Dies wird erreicht,
indem jedem Subjekt und jedem Objekt eine Sicherheitsklassifikation zugewiesen wird.
Für die Spezifikation von Policies gibt es zahlreiche Ansätze. Bei Logik-basierten
Sprachen, werden Policies mittels logischer Konstrukte wie Rekursion und Verneinung
konstruiert. Ereignis gesteuerte Sprachen wie z.B. die „security policy language“,
spezifizieren dagegen Ereignisse, die von einem „event monitor“ verarbeitet werden.
Manche Ansätze verwenden XML zur Definition der Zugriffsregeln (vgl. [LMY01] S.
4). Beispielsweise kann man XACML (siehe [OAS03]) einsetzen, um den Zugriff auf
XML Dokumente in Form von „(Subjekt, Ziel, Aktion)“ Regeln im XML Format zu
reglementieren. Ferner kann man in XACML konditionale Zugriffsregeln für XML
Dokumente definieren und externe Nachbedingungen zur Spezifikation von Aktionen,
die vor der Freigabe eines Zugriffes ausgeführt werden müssen, festlegen. Siehe dazu
das folgende Beispiel:
23

Zugriffskontrollverfahren und AOP
Abbildung 6: Beispiel für eine XACML Policy (vgl. [DBS02] S. 11)
XML hat den Vorteil, dass es ein weit verbreiteter Standard ist. Für den Benutzer ist
aber eine graphische Eingabemaske notwendig, da für ihn eine XML Policy kaum
lesbar ist. Da XACML nur XML Dokumentinhalte schützt und es keine Gruppierung
von Policies unterstützt, ist es für das Fahrzeug-Portal nur bedingt geeignet.
3.1.5.3 Policies und Fahrtenbücher
Große Systeme beinhalten Millionen von Benutzern und Ressourcen. Es ist unpraktisch,
Policies für jedes einzelne Individuum oder gar für jede einzelne Ressource zu
spezifizieren. Stattdessen muss es möglich sein, Policies auch bezüglich
(verschachtelten) Gruppen festzulegen. Bei einem Fahrtenbuch genügt z.B. eine
Vorgabe-Policy, die definiert, dass nur der Fahrer Änderungen vornehmen darf, nur
Gruppenmitglieder lesenden Zugriff auf nicht private Daten erhalten und das Löschen
von Fahrteinträgen generell nicht gestattet ist. Es muss dem Fahrer aber erlaubt sein, für
eine Gruppe von Fahrteinträgen (Ressourcen) in einem festgelegten Rahmen
Anpassungen vorzunehmen (z.B. weiteren Personen Lesezugriffe gewähren). Außerdem
ist es nützlich, Policies, die Rechte einer Rolle (z.B. eines Finanzprüfers) festlegen, zu
gruppieren (vgl. [DBS02] S. 3).
24

Zugriffskontrollverfahren und AOP
3.2 Probleme üblicher Zugriffskontrollverfahren
3.2.1 Fahrtenbücher und Zugriffskontrollen
Die untersuchten Fahrtenbücher weisen keine der oben aufgeführten Zugriffskontrollverfahren
auf. Die meisten Systeme verfügen nur über eine einfache
Passwortabfrage (siehe [IbNoJ] und [SysoJ]). Fortgeschrittene Zugriffskontrollen wie
etwa rollenbasierte Zugriffskontrollen werden hingegen nicht unterstützt.
Im Folgenden soll nicht weiter auf die Sicherheitsmängel üblicher Fahrtenbuch-
Software bzw. -Dienste eingegangen werden. Stattdessen wird erörtert, welche
Probleme auftreten, wenn man die Zugriffskontrolle einer (Telematik-)Anwendung mit
den oben beschriebenen Verfahren realisieren möchte.
3.2.2 Vermischung von Quellcode und Zugriffskontrolle
Das Hauptproblem üblicher Verfahren ist, dass die Zugriffskontrollaufrufe im
Anwendungsprogramm zu programmieren sind. Üblicherweise verfügt eine Zugriffskontrollfunktionalität
über eine Schnittstelle, die vom Anwendungsprogramm genutzt
wird. Die folgende Abbildung zeigt eine Beispielanwendung, die um Funktionen zur
Überprüfung der Autorisierung erweitert wurde.
package Logbook;
import Security.SecurityFacade;
public class Start
{
…
public static void main(String[] args) throws Exception {
SecurityFacade security = SecurityFacade.getInstance();
…
else if (action.equals(„setdate“)) {
if(security.checkAuthorization(user,”Entry”,”setdate”)
String date = JoptionPane.showInputDialog(…);
Entry e = (Entry) entries[actualNbr];
e.setdate(date);
else
System.out.println(“Access denied”);
…
}
}
Abbildung 7: Anwendungsprogramm inklusive Rechteprüfung
Wie man anhand der fett markierten Zugriffskontrollfunktionen deutlich sehen kann,
muss sich ein Großteil des Anwendungscodes mit der Zugriffskontrolle beschäftigen.
25

Zugriffskontrollverfahren und AOP
Bei Verwendung einer Sicherheits-Schnittstelle (hier SecurityFacade) sind folgende
Anpassungen notwendig.
• Benutzerzugriff entdecken und weiterleiten
Das Anwendungsprogramm muss sich selbst darum kümmern, Zugriff auf eine
geschützte Ressource zu entdecken (z.B. Abbildung 7 Zeile 10), um eine
Zugriffsbehandlung auslösen zu können.
Außerdem muss die jeweilige Anwendungsklasse den Benutzer, der auf die
geschützte Ressource zugreifen will, authentifizieren bzw. ein Sitzungsobjekt
mit den Benutzerdaten übergeben bekommen.
• Zugriffskontrollaufruf durchführen
Anschließend muss das Anwendungsprogramm die Zugriffskontrolle aufrufen
(siehe Abbildung 7 Zeile 11). Hierzu müssen jedoch alle erforderlichen Daten
wie die Identifikation des zugreifenden Benutzers, die gewünschte Aktion und
das geschützte Objekt ermittelt und dem Zugriffskontrollaufruf übergeben
werden. Jede geschützte Anwendungsklasse muss zudem die SecurityFacade
importieren und eine Instanz der Facade erzeugen (Abbildung 7 Zeile 2 und 8).
• Fehlerbehandlung bei Zugriffsverweigerung
Außerdem muss das Programm sich selbst um die Fehlerbehandlung im Falle
einer Zugriffsverweigerung kümmern (siehe Abbildung 7 Zeile 15-16).
Beispielsweise kann das Anwendungsprogramm eine Fehlermeldung ausgeben
oder eine Methode zur Fehlerbehandlung aufrufen. Da die Art der Ausgabe einer
Fehlermeldung von der graphischen Benutzeroberfläche des Anwendungsprogramms
abhängt, muss es dem Programm möglich sein, sich selbst um die
Fehlerbehandlung zu kümmern. Hierzu könnte es eine Ausnahme von der
Zugriffskontrolle erhalten, anhand der es entscheiden kann, welche weiteren
Schritte durchzuführen sind.
Soll dieses Sicherheitssystem durch ein anderes abgelöst werden, dann müssen alle
aufgezählten (in der Abbildung fett markierten) Code-Zeilen ausgetauscht werden.
Wenn alle Funktionen der Zugriffskontrolle in eine eigene Klasse ausgelagert werden
könnten, würde das Anwendungsprogramm wie folgt aussehen:
26

Zugriffskontrollverfahren und AOP
1. package Logbook;
2.
3. public class Start
4. {
5. …
6. public static void main(String[] args) throws Exception {
7. …
8. else if (action.equals(„setdate“)) {
9. String date = JoptionPane.showInputDialog(…);
10. Entry e = (Entry) entries[actualNbr];
11. e.setdate(date);
12. }
13.}
Abbildung 8: Beispielanwendung ohne Zugriffsfunktionalität
Auch bei Verwendung von standardisierten Sicherheitslösungen wie z.B. JAAS (vgl.
[SUN01] und [Lad03]) muss die Anwendungsklasse durch eine import-Anweisung für
den entsprechenden Sicherheits-Controller und einen Zugriffskontroll-Aufruf für jede
zu schützende Aktion erweitert werden.
3.2.3 Abhängigkeit der Anwendung vom verwendeten Verfahren
Durch Verwendung einer speziellen Sicherheitslösung macht sich die Anwendung
folglich abhängig von deren Realisierung. Mit zunehmendem Programmumfang wird
ein Wechsel oder eine Anpassung immer aufwendiger, da der Code der
Zugriffsfunktionalität quer über das gesamte Anwendungsprogramm verteilt ist.
Class 1 Class 2 Class 3 Class 4 Class 5 Class 6 Class 7 Class 8 Class 9 Class 10 Class 11 Class 12 Class 13 Class 14 Class 15 Class 16
Abbildung 9: Verteilung der Zugriffskontrollfunktionalität (in Anlehnung an
[HHI02] S. 5)
Die Vermischung von Zugriffskontrolle und Anwendungsprogramm führt außerdem zu
folgenden Problemen:
27

Zugriffskontrollverfahren und AOP
• Während der Anforderungsanalyse
Obwohl eine Trennung der Anforderungen von Zugriffskontrolle und
Anwendung möglich ist, ist der Austausch eines Verfahrens durch ein anderes
nicht ohne weiteres möglich. Ändern sich die Sicherheitsanforderungen zum
Zeitpunkt der Einführung, muss die komplette Anwendung überarbeitet werden.
• Während des Entwurfs
Ein getrennter Entwurf von Zugriffskontrolle und Anwendung ist nicht möglich,
da die Funktionen der Anwendung sehr eng mit den Sicherheitsfunktionen
verzahnt sind. Wenn ein spezielles Zugriffskontrollverfahren zum Einsatz
kommen soll, muss die komplette Anwendung entsprechend adaptiert oder neu
entwickelt werden, da der Zugriffsschutz sich nicht in das System
hineinkonfigurieren lässt.
• Während der Implementierung
Die Trennung der Programmierung von Zugriffskontrolle und Anwendung ist
kaum möglich, da die Zugriffskontrollaufrufe überall verwendet werden. Bei
Änderung der Zugriffskontrollschnittstelle müssen alle betroffenen Klassen
abgeändert werden. Das Testen der Anwendung ohne die Zugriffsfunktionalität
bedarf einer Auskommentierung aller Zugriffsfunktionen.
• Während der Nutzung
Die Zugriffskontrolle ist ein Engpass im System. Wenn sie ausfällt, dann steht
das ganze System still. Es ist in der Regel nicht möglich, das System ohne
Zugriffsfunktionalität bzw. mit einer alternativen Zugriffskontrollfunktionalität
auszuführen.
Wie diese Probleme zum Teil gelöst werden können, ist Gegenstand des nächsten
Abschnittes und der folgenden Kapitel.
28

Zugriffskontrollverfahren und AOP
3.3 Anwendungsunabhängigkeit durch Aspektorientierte
Programmierung (AOP)
3.3.1 Motivation für AOP
Das Problem, dass der Programmcode der Zugriffskontrolle quer über die gesamte
Anwendung verteilt ist, lässt sich mittels aspektorientierter Programmierung lösen.
Aspektorientierung soll helfen, eine Schwachstelle objektorientierter Programmierung
zu beheben. Querschnittsaspekte, die die ganze Anwendung betreffen, können nicht
durch hierarchische Modularisierung sinnvoll gelöst werden. Die Untergliederung der
Anwendung in Klassen und Unterklassen sowie Schnittstellen hilft kaum weiter, wenn
der Aspekt sich auf alle Teile einer Anwendung bezieht.
Aspektorientierte Programmierung ist eine Methode, mit der man die benötigte
Funktionalität automatisch zu einem Original-Programmcode hinzufügen kann. Das
besondere an AOP ist, dass es dem Programmierer die Arbeit abnimmt, den
Programmcode an mehreren Stellen im Programm abändern zu müssen. Stattdessen
muss nur definiert werden, wo Änderungen vorzunehmen sind und in welchen Fällen
diese Änderungen durchgeführt werden sollen. Ein Übersetzer webt anschließend die
Änderungen, die in den Aspekten definiert wurden, in den Code ein, ohne dass das
Originalprogramm geändert werden muss.
3.3.2 Aspekte
Ein Aspekt ist zum einen die Zusammenstellung aller Anforderungen eines Typs (z.B.
Sicherheit) an ein System. Wie eine Anforderung kann der Aspekt alle Teile des
Systems betreffen. Zum anderen ist der Aspekt ein Programmkonstrukt, wie z.B. eine
Java-Klasse, die alle Codeteile, die sich auf diese Anforderung beziehen, enthält.
Beispielsweise enthält der Aspekt „Zugriffskontrolle“ alle Programmteile der
Zugriffskontrollfunktionalität. Der Aspekt definiert außerdem, welche Anwendungsklassen
die Programmteile benötigen, so dass er die entsprechenden Teile zur
Übersetzungszeit zur jeweiligen Anwendungsklasse hinzufügen kann.
Durch diese Kapselung von Anforderungen in Aspekten ist es möglich, im
Gesamtsystem eine stärkere Trennung der Anforderungen bei Design und
29

Zugriffskontrollverfahren und AOP
Implementierung durchzuhalten, Redundanz und Inkonsistenzen zu verhindern sowie
die Verständlichkeit zu erhöhen.
Der Aspekt Zugriffskontrolle wird somit integraler Bestandteil aller Anwendungsklassen.
Dass dabei die Objektgrenzen aufgehoben werden, damit Aspekte unabhängig
von der öffentlichen Schnittstelle auf Objekte zugreifen können, stellt keine Verletzung
der Schnittstellen dar, da der Aspekt nun zu einem festen Bestandteil des Objektes
geworden ist (vgl. [Dom01]).
Aspekte können eingesetzt werden, wenn man mehrere Klassen hat, zu der eine
gemeinsame Funktionalität hinzugefügt werden soll. Des Weiteren ermöglichen
Aspekte das Hinzufügen und Entfernen von Features einer Klasse zur Übersetzungszeit.
Auf diese Weise können Benutzer wählen, welche Features sie wollen.
3.3.3 Dynamische und Statische Querverbindungen
Der Programmierer kann in Aspekten dynamische Querverbindungen (engl. dynamic
cross cutting) zu bestimmten Punkten im Ablauf eines Anwendungsprogramms
festlegen. An einem solchen Punkt (engl. join point) kann er dann den gewünschten
zusätzlichen Programmcode einfügen. Ein Join Point kann z.B. ein Punkt in einem
Objekt sein, an dem eine Methode aufgerufen oder ein Feld des Objektes referenziert
wird.
Zusätzlich ermöglicht aspektorientierte Programmierung auch die Definition von
statischen Querverbindungen. So lässt sich eine Klasse um zusätzliche Methoden und
Felder erweitern. Beispielsweise kann man hiermit ein Feld für die Identifikation des
Objektes einfügen, das von den dynamischen Querverbindungen genutzt werden kann.
Außerdem können auch Vererbungsbeziehungen zwischen Klassen verändert werden.
3.3.4 Die Software AspectJ TM
Für die Erstellung von AOP Software gibt es diverse Werkzeuge, wie AspectJ TM (vgl.
[Asp02]). AspectJ TM erweitert Java um einige neue Schlüsselwörter und um einen
Übersetzer „ajc“, der anhand der neuen Schlüsselwörter die Aspekte in die
Objektklassen einfügt. Hiermit lassen sich Aspekte in Form von Java-Klassen
realisieren (vgl. [Asp02] Anhang A).
Die wichtigsten Bestandteile von AspectJ TM (vgl. [KHH01] und [Asp02]) sind:
30

Zugriffskontrollverfahren und AOP
• Join Point
Ein Join Point ist ein von AspectJ vordefinierter Punkt während der Ausführung
eines Java Programms, an dem alternative Aktionen ausgeführt werden können.
AspectJ definiert folgende Join Points, die man verwenden kann:
- Methoden- und Konstruktorenaufrufe
- Methoden- und Konstruktorenausführungen
- lesende und schreibende Feldzugriffe
- Aufruf einer Ausnahmebehandlung
- Statische und dynamische Initialisierungen einer Klasse
Ein Methodenaufruf löst z.B. einen zugehörigen Join Point aus, wenn im
Anwendungsprogramm die entsprechende Methode aufgerufen wird.
• Pointcut
Ein neues Schlüsselwort in AspectJ TM ist Pointcut. Ein Pointcut definiert eine
Zusammenstellung von Join Points in einem Programm bei denen eine
bestimmte Aktion ausgeführt werden soll. Zusätzlich zu den festgelegten Join
Points können auch Werte dieser Join Points abgefragt und bei der Definition
des Pointcut mitverwendet werden. Eine Definition eines Pointcut in einem
Aspekt sieht beispielsweise wie folgt aus:
pointcut authorize(): call(void setField(int));
Auf der linken Seite des Doppelpunktes steht der Name des Pointcut. Auf der
rechten Seite stehen ein oder mehrere Join Points, auf die sich der Pointcut
bezieht.
• Advice
Zu einem Pointcut können ein oder mehrere Advices definiert werden, die
festlegen, was im Falle eines Pointcuts geschehen soll. Mit Hilfe eines
vorangestellten Schlüsselworts legt der Advice fest, wann die zusätzliche Aktion
ausgeführt werden soll. Mögliche Schlüsselwörter sind:
31

Zugriffskontrollverfahren und AOP
- before (zusätzliche Aktion wird vor dem Join Point ausgeführt)
- after (zusätzliche Aktion wird direkt nach dem Join Point
ausgeführt)
- around (zusätzliche Aktion wird anstelle des Join Points
ausgeführt)
So kann man erreichen, dass vor jedem Aufruf einer bestimmten Methode zum
Beispiel eine Logging Operation ausgeführt wird. Ebenso ist es möglich, den
Advice alternativ oder nach der Ausführung der eigentlichen Aktion
auszuführen.
Da AspectJ TM die zusätzlichen Methodenaufrufe in den eigentlichen Code einarbeitet,
verschlechtert sich pro Pointcut das Laufzeitverhalten des Anwendungsprogramms ein
wenig, da der zusätzliche Code nun mit ausgeführt werden muss. Dafür ist die
Verwendung von Aspekten aber flexibler als ein direkt eingebetteter Code.
32

Entwurf: Policy-basierte Zugriffskontrolle
4 Entwurf: Policy-basierte Zugriffskontrolle
4.1 Grundlagen
4.1.1 Die Entwurfziele
Im vorherigen Kapitel wurden die Hauptanforderungen an die Sicherheit verteilter und
personalisierbarer Dienste im Fahrzeug diskutiert. Die folgende Auflistung definiert,
welche dieser Anforderungen durch die vorliegende Arbeit erfüllt werden bzw. in
weiteren Schritten durchgeführt werden sollen.
Entwurfsziele
Zugriffskontrolle
Die in dieser Arbeit realisierte Zugriffskontrolle regelt den Zugriff
auf fahrzeugspezifische Dienste und Daten, wie Fahrtenbücher oder
Benutzerprofile. Sie verwendet dazu Sicherheitspolicies, in denen
der Eigentümer des Objektes festlegen kann, wer wie auf sein
Objekt zugreifen darf.
Der Aufbau einer Zugriffsregel ist fest vorgegeben. In einer
erweiterten Version wäre es denkbar, die Struktur flexibler zu
gestalten, so dass auch anwendungsspezifische Konstrukte in die
Regeln mitaufgenommen werden könnten.
Authentizität Die Zugriffskontrolle hängt von einer zuvor erfolgten
Authentifikation ab. Da sowohl das Anwendungsprogramm als
auch die Zugriffskontrolle Sitzungsinformationen wie aktueller
Benutzer, Gruppenzugehörigkeit und Authentifikationsstatus,
benötigt, muss die Authentifikation so realisiert werden, dass beide
Programme sie nutzen können.
Im Fall von Telematik-Anwendungen kommen zudem oft
verschiedene Authentifikationsmethoden zum Einsatz, z.B. eine für
die Anmeldung mittels PDA und eine für die Anmeldung mittels
Personal Computer.
33

Entwurf: Policy-basierte Zugriffskontrolle
Entwurfsziele
Vertraulichkeit
Integrität
Verfügbarkeit
Die Einhaltung der Vertraulichkeit von Daten wird durch die
Implementierung des Zugriffskontrollmechanismus gewährleistet.
Die Kommunikationssicherheit, die durch Einsatz von Verschlüsselungstechniken
(z.B. SSL) gesichert werden kann, liegt außerhalb
des Schwerpunktes dieser Arbeit.
Die Integrität der Fahrtenbuch-Daten beim Einsatz verteilter
Fahrzeugdienste kann mittels digitaler Signaturen realisiert werden.
Die Verfügbarkeit des Fahrtenbuches ist abhängig von der
Verfügbarkeit der einzelnen Dienste zu denen auch die
Zugriffskontrolle gehört. Wenn der Dienst „Zugriffskontrolle“
ausfällt, kann kein Benutzer mehr die Fahrtenbuch-Anwendung
nutzen. Um die Verfügbarkeit zu gewährleisten, sind andererseits
aber auch skalierbare Hardware und Software notwendig.
Die im Rahmen dieser Arbeit realisierte anwendungsunabhängige
Zugriffskontrolle ermöglicht aber auch beim Ausfall eines
Sicherheitsdienstes die Nutzung der Anwendungssoftware,
allerdings ohne Prüfung der Zugriffsberechtigung. Um eine solche
Situation zu vermeiden, wurde die Sicherheitslösung möglichst
modular aufgebaut, so dass man relativ einfach diese
Sicherheitslösung durch ein anderes Sicherheitssystem austauschen
kann.
Verbindlichkeit
Für die Verbindlichkeit wichtiger Aktionen (wie z.B. das Erstellen
von Fahrtbuch-Einträgen) ist es notwendig, alle Aktionen zu
protokollieren. Eine solche Funktionalität müsste daher noch
implementiert werden.
Tabelle 8: Entwurfsziele dieser Arbeit
34

Entwurf: Policy-basierte Zugriffskontrolle
4.1.2 Die Einteilung der Sicherheitsfunktionen in Pakete
Pakete sind ein Mechanismus, um Modellelemente (z.B. Java Klassen) zu Gruppen
zusammenzufassen (vgl. [Bal99] S. 267). In der Implementierungsphase werden die
Java-Klassen eines Paketes in Form von Unterverzeichnissen des Projektverzeichnisses
abgelegt. Folgende Pakete wurden definiert:
Pakete für eine Sicherheitsarchitektur für einen Fahrtenbuch-Dienst
Zugriffskontroll-
Dienste
Konfigurations-
Dienste
Das Paket „Zugriffskontroll-Dienste“ stellt Dienste für die
Autorisierung von Benutzerzugriffen bereit. Oft wird
Autorisierung auch durch eine „Authentifizierung“ und ein
„Auditing“ ergänzt.
Das Paket „Konfigurations-Dienste“ wird benötigt, um
Einstellungen für die Sicherheitslösung zu verwalten. Dies
umfasst zum einen die Zusammenstellung der Sicherheitslösung
wie auch die anwendungsspezifische Anpassung der
Sicherheitsdienste an ein Anwendungsprogramm.
Tabelle 9: Pakete für eine Sicherheitsarchitektur für einen Fahrtenbuch-Dienst
Ein weiteres vorgesehenes Paket „Kryptographie und Digitale Signaturen“ (siehe
Abbildung 10) für das Schlüsselmanagement (vgl. [Eck01] S. 265 ff.),
Verschlüsselungsmethoden (vgl. [Sch96]) und Funktionen für die Erstellung und
Verifizierung von digitalen Signaturen (vgl. [Eck01] S. 235 ff.), wurde aufgrund des
Umfangs und des beschränkten zeitlichen Rahmens nicht realisiert.
Abbildung 10: Sicherheitspakete (eigene Darstellung)
Die parallel zu dieser Arbeit entwickelte Fahrtenbuch-Anwendung enthält wichtige
Funktionen für den Betrieb von verteilten Fahrtenbüchern. Sie nutzt das Autorisierungs-
35

Entwurf: Policy-basierte Zugriffskontrolle
Paket zur Realisierung einer Zugriffskontrolle. Die folgende Abbildung gibt einen
groben Überblick über die Architektur der Zugriffskontrolle und der als
Beispielanwendung genutzten Fahrtenbuchanwendung.
Abbildung 11: Architektur der Zugriffskontrolle (eigene Darstellung)
Zum Einsatz kommen eine XML-Datenbank (vgl. [Mei02]) zur Speicherung der Daten
und Java Klassen zur Realisierung der Zugriffskontrollfunktionalität. Ergänzt werden
diese durch eine Benutzerschnittstelle für die Verwaltung der Zugriffskontrollregeln.
4.1.3 Das MIX-Datenmodell
Die Pakete „Zugriffskontroll-Dienst“ und „Konfigurations-Dienste“ verwenden
Datenelemente, wie z.B. eine Zugriffsregel oder ein Konfigurationseintrag. Diese
Datenelemente werden mit Hilfe des MIX-Datenmodells definiert und implementiert.
MIX (Metadata based Integration model for data X-change) ist ein sich selbst
beschreibendes Datenmodell (vgl. [Bor98] und [Bor99]). Jedes Element der
Zugriffskontrolle, das einen besonderen Bestandteil der Zugriffskontrolle repräsentiert,
wird durch MIX-Klassen (im Folgenden auch Ontologie genannt) realisiert. In den
Zugriffskontroll-Diensten werden anstelle einfacher oder komplexer Datentypen diese
Ontologien eingesetzt, wodurch eine bessere Nachvollziehbarkeit des Quellcodes
möglich wird.
An einem Beispiel soll dies kurz erläutert werden. Eine Zugriffsregel setzt sich
zusammen aus Benutzern mit einer Benutzeridentifikation, geschützten Objekten und
Zugriffsrechten. Modelliert man diese als Klassen und die Benutzeridentifikation als
Datentyp „String“, so kann es geschehen, dass die Benutzeridentifikation an einer Stelle
mit „String userId“ und an einer anderen Stelle mit „String id“ deklariert wird. Leichter
nachvollziehbar wird der Code wenn die Ontologie „UserIdentifikation“ verwendet
wird. Die Deklaration „UserIdentifikation userId“ wird somit eindeutig. Aus der
36

Entwurf: Policy-basierte Zugriffskontrolle
Ontologie „UserIdentifikation“ kann man außerdem erfahren, was der Zweck einer
Benutzeridentifikation ist und aus welchen Elementen eine Benutzeridentifikation
besteht.
Zur Modellierung einfacher Datenelemente bietet MIX „Simple Semantic Objects“ an.
Diese repräsentieren atomare Datenelemente in Form von Tripeln wobei C
einem Konzept aus der verwendeten Ontologie entspricht und v den aktuellen Wert
dieses Konzepts wiedergibt. Außerdem werden in $ Zusatzinformationen zur Verfügung
gestellt, so dass ein Mensch oder eine Maschine die Bedeutung des Datenelements
nachvollziehen kann. Ein „Simple Semantic Object“ wäre z.B.:
Um komplexe Ontologien darzustellen, verwendet MIX „Complex Semantic Objects“
(vgl. [Bor98] S. 28 ff.). Hiermit können komplexe Datenelemente, wie eine
Zusammenstellung von Zugriffsregeln, beschrieben werden. Ein „Compex Semantic
Object“ wird repräsentiert in Form eines Paares . C stellt wiederum ein Konzept
dar. A entspricht einer Menge von „Simple Semantic Objects“. Ein Beispiel für ein
„Complex Semantic Object“ ist z.B. ein Benutzer, der eine Benutzeridentifikation und
einen Namen hat.
Die unterstrichenen Elemente sind Pflicht-Elemente, d.h. sie müssen in dieser Ontologie
definiert werden.
4.2 Die Architektur des Zugriffskontrollsystems
4.2.1 Der Sicherheitsproxy
Um sich Fahrtenbuch-Einträge anzeigen zu lassen und um sie zu ändern, muss überprüft
werden, ob der Benutzer das Recht hat, die Daten zu lesen bzw. zu ändern. Zwar
verfügen heutige Server (und in Zukunft wohl auch Fahrzeugcomputer) über einen
umfangreichen Schutz durch das Betriebssystem, dieser reicht aber nicht aus, um
anwendungsspezifische Besonderheiten durch spezielle Schutzmaßnahmen zu sichern.
37

Entwurf: Policy-basierte Zugriffskontrolle
Abbildung 12: Autorisierung von Fahrtenbuch-Zugriffen (vgl. [BHH01] S. 323)
Der Zugriff auf den Fahrtenbuch-Dienst auf einem Server wird durch eine Art Mittler
zwischen mobilen Geräten bzw. Personal Computer geschützt. Dieser wird im
Folgenden auch „Proxy“ genannt, da er ähnlich einem Proxy Zugriffe auf die
Anwendung abfängt, überprüft und im Erfolgsfall weiterleitet. Wie diese Funktionalität
mit Hilfe aspektorientierter Programmierung realisiert wird, wird im Kapitel
„Implementierung“ erläutert.
In Anlehnung an einen Proxy verläuft ein Zugriff in folgenden Einzelschritten
1. Ein Benutzer ruft in der Fahrtenbuch-Anwendung eine Funktion auf oder greift auf
ein Anwendungsobjekt zu. Diese Benutzeraktionen werden vom Sicherheitsproxy
abgefangen und überprüft.
2. Mit Hilfe der Benutzerverwaltung des Anwendungsdienstes wird dazu ermittelt, ob
es eine existierende Benutzersitzung gibt. Der Sicherheitsproxy benötigt von der
Benutzersitzung zudem die aktuelle Benutzerkennung und weitere Daten, wie z.B.
Gruppenzugehörigkeiten.
3. Falls keine Sitzung vorhanden ist, da z.B. der Zeitrahmen der aktuellen Sitzung
überschritten ist, veranlasst der Proxy (oder das Anwendungsprogamm) eine
Benutzerauthentifizierung.
4. Der Anwendungsdienst prüft nun, ob der Benutzer authentifiziert ist. Um zu
verhindern, dass Benutzer jeden ihrer Zugriffe authentifizieren müssen, wird das
Konzept der Sitzung (engl. session) verwendet.
38

Entwurf: Policy-basierte Zugriffskontrolle
5. Nach erfolgreicher Anmeldung erzeugt der Anwendungsdienst eine neue Sitzung.
6. Nun könnte vom Sicherheitsproxy nochmals überprüft werden, ob der Benutzer sich
authentifiziert hat. Da sich das Anwendungsprogramm aber um die
Authentifizierung kümmert, wird dieser Schritt weggelassen.
7. Stattdessen wird nochmals der Status der Sitzung überprüft und die
Benutzerkennung ausgelesen. Diese wird im Folgenden für die Überprüfung der
Zugriffsrechte dieses Benutzers verwendet.
8. Nachdem der Proxy alle benötigten Daten (Benutzer, Informationen über die
ausgewählte Aktion und über die angefragten Anwendungsobjekte) für die
Zugriffskontrollprüfung gesammelt hat, ruft er den Zugriffskontrolldienst auf, der
sich um die Prüfung der Zugriffskontrollregeln und die Zugriffe auf die Datenbank
kümmert.
9. War die Zugriffskontrollprüfung erfolgreich, so wird die eigentliche
Anwendungsfunktion mit den benötigten Parametern aufgerufen. Andernfalls wird
eine Fehlermeldung ausgegeben oder eine bestimmte Ausnahmebehandlung
ausgelöst (die Fehlerbehandlung mittels Ausnahmebehandlung ist bisher aber nicht
realisiert worden).
10. Nachdem das Anwendungsprogramm die Aktion ausgeführt hat, gibt es die Daten
an den Aufrufer über die anwendungsspezifische Benutzerschnittstelle zurück, ohne
dass der Sicherheitsproxy als Mittler eingesetzt wird.
11. Tritt jedoch eine Zugriffsverweigerung ein, dann gibt der Sicherheitsproxy eine
entsprechende Fehlermeldung an den Aufrufer zurück.
4.2.2 Die Verwaltung der Zugriffsregeln
Die Zugriffsregeln dieser Sicherheitslösung werden in Form von „Policies“ (vgl.
[DBS02] S. 4 ff.) realisiert. Eine Policy repräsentiert in dieser Arbeit eine einzelne
Zugriffsregel, die ähnlich wie eine Event-Condition-Action Regel (vgl. [CiB02] S. 2 f.)
aus drei Teilen besteht:
1. einem Benutzer, der den Zugriff veranlasst hat,
2. einer Bedingung, die erfüllt sein muss, damit die aufgerufene Methode ausgeführt
werden kann
3. und einer Liste von Elementen, auf die der Aktion Zugriff gewährt wird.
39

Entwurf: Policy-basierte Zugriffskontrolle
Policies können zu so genannten „PolicySets“ kombiniert werden und als ein
„PolicySet“ einem zu schützenden Anwendungsobjekt zugewiesen werden. Greift nun
ein Benutzer auf dieses Objekt zu, so erhält er nur Zugriff, wenn die Kombination aus
dem Benutzer, dem angefragten Feld (bzw. dem ganzen Objekt) und dem benötigten
Zugriffsrecht in einer der Policies des „PolicySets“ definiert ist. Die Policy-Verwaltung
stellt somit den zentralen Dienst für die Steuerung der Zugriffskontrolle dar.
Unterstützt wird die Policy-Verwaltung durch drei weitere Dienste, die sich um die
Verwaltung der Benutzer und Benutzergruppen, um die Verwaltung der zu schützenden
Aktionen und um die Verwaltung der zu schützenden Klassen kümmern.
Der zentrale Policy-Dienst wird in Anlehnung an das „Butterfly Modell“ (vgl. [Nor01]
S. 6 f.) von drei weiteren Zusatzdiensten unterstützt. Das Butterfly-Modell ähnelt
rollenbasierten Systemen (vgl. [FBK99], [FSG01] und [Fis02]). Die grundlegenden
Objektarten im Butterfly Modell sind jedoch Benutzer, Ressourcen und Aktionen.
Beziehungen zwischen diesen Objekten werden mittels Rechten geregelt. Zudem
können Benutzer und Ressourcen zu Gruppen zusammengefasst werden. Der Name
„Butterfly-Modell“ kommt daher, dass das Modell aussieht wie ein Schmetterling mit
zwei großen Flügeln (die Benutzer und Ressourcen-Verwaltung, die beide Gruppen
unterstützen) sowie einem kürzeren Schwanz, der die Aktionsverwaltung darstellt.
Abbildung 13 : Das Butterfly-Modell (vgl. [Nor01] S. 6 f.)
40

Entwurf: Policy-basierte Zugriffskontrolle
Der Benutzerdienst verwaltet beispielsweise einen Baum aus Benutzern und
Benutzergruppen, die Ressourcenverwaltung einen Baum aus geschützten
Anwendungsklassen (und deren Felder und Objekte) und die Aktions-Verwaltung eine
Liste von Aktionen pro geschützter Anwendungsklasse. Da auch das
Benutzerprogramm eine Benutzer- und Benutzergruppenverwaltung benötigt, wird
diese verwendet. Idealerweise gibt es aber eine zentrale Benutzeradministration, die von
mehreren Anwendungsprogrammen genutzt werden kann und mit der ein Single-Sign-
On möglich ist. Auf diese Weise müsste sich der Anwender nur einmal bei der zentralen
Benutzerverwaltung anmelden, anstatt sich bei jedem Anwendungsprogramm einzeln
anmelden zu müssen.
Aus Zeitgründen wird in dieser Arbeit jedoch darauf verzichtet, hierarchische Benutzerund
Ressourcengruppen zu realisieren. Stattdessen können Benutzer und Ressourcen
nur in eine Benutzer- bzw. Objekttypklasse eingeteilt werden. Würde eine hierarchische
Gruppenbildung unterstützt, so müssten einerseits zyklenfreie Graphen verwaltet
werden, andererseits würde die Rechteprüfung einen Suchalgorithmus zum Auffinden
von Rechtekombinationen in den Graphen benötigen (vgl. [Nor01] S. 14).
4.2.3 Die Benutzerschnittstelle für die Policy-Verwaltung
Der Benutzer kann über eine Benutzerschnittstelle auf die Daten der Zugriffskontrolle
zugreifen. In einem ersten Fenster sieht er eine Liste von „PolicySets“, die eine
Zusammenstellung von Zugriffsregeln zu einem Anwendungsobjekt darstellen. Damit
mehrere Anwendungsobjekte durch ein PolicySet geschützt werden können, kann der
Benutzer diese mittels einer selbstdefinierbaren Kategorie, wie z.B. „alle meine
Privatfahrten“ gruppieren. Wie „PolicySets“ erzeugt werden, wird im nächsten Kapitel
erläutert.
Abbildung 14: „PolicySet“ Fenster (eigene Darstellung)
41

Entwurf: Policy-basierte Zugriffskontrolle
Selektiert der Benutzer in der Tabelle einen „PolicySet“ und drückt die Schaltfläche
„Change“, so gelangt er zu einem weiteren Fenster, in dem alle Zugriffsregeln, die im
ausgewählten „PolicySet“ definiert sind, aufgelistet werden.
Eine Zugriffsregel (hier auch „Policy“ genannt) besteht aus einer Liste von Benutzern,
einer Liste von Feldern und Objekten des geschützten Anwendungsobjektes und einer
Liste von Zugriffsrechten. Wenn alle Elemente (z.B. Objekte) zugelassen werden
sollen, kann stattdessen auch das Schlüsselwort „all“ verwendet werden.
Abbildung 15: „Policy“ Fenster (eigene Darstellung)
Wählt man nun eine „Policy“ aus der Tabelle, kann man diese in einem weiteren
Fenster editieren. Wie diese festgelegt werden können, wird im übernächsten Kapitel
unter Konfiguration erläutert.
4.3 Die Zugriffsverwaltung
Das Paket “Security” besteht aus den drei Teilpaketen „Security.Authorization“,
„Security.Configuration“ und „Security.UserInterface“.
Das Teilpaket “Security.Authorization” enthält die Klassen, die für die Realisierung des
Sicherheitsproxies benötigt werden (v.a. den Aspekt „AbstractAuthentifikationAspect“,
der im Kapitel Implementierung erläutert wird). Zusatzdienste für die Verwaltung der
Aktionen, Objekte und Zugriffsregeln, sind in den Teilpaketen
„Security.Authorization.ActionService“, „Security.Authorization.ObjectService” und
“Security.Authorization.PolicyService” definiert.
Alle Klassen für die Verwaltung der Konfiguration sind im Teilpaket
„Security.Configuration” gespeichert, alle Klassen der Benutzerschnittstelle der
Zugriffskontrolle sind im Paket „Security.UserInterface“ abgelegt.
42

Entwurf: Policy-basierte Zugriffskontrolle
4.3.1 Die Verwaltung der Policy-Dateien
Die Zugriffsverwaltung (hier auch PolicySet-Dienst genannt) kümmert sich um die
Verwaltung der Zugriffsrechte. Hierzu ordnet sie „Policies“ einem Objekt oder einer
Objektgruppe zu. Sie ist gemäß des Entwurfsmusters „Singelton“ konzipiert worden
(vgl. [Bal99] S. 287 ff.). Das bedeutet, dass es immer nur eine einzige Instanz
„PolicySetService“ gibt, die von allen Klassen im Paket „Security“ angesprochen
werden kann.
Die wichtigste Funktion der Zugriffsverwaltung ist die Überprüfung der Zugriffe auf
geschützte Objekte bzw. Methoden. Der Ablauf dieser Zugriffsprüfung ist im folgenden
Sequenzdiagramm in Abbildung 16 dargestellt.
Abbildung 16: Sequenzdiagramm „Zugriffskontrollprüfung“ (eigene Darstellung)
Folgende Schritte werden im Wesentlichen durchgeführt:
1. Ein Funktionsaufruf wird vom Sicherheitsproxy (die Klasse
„AbstractAuthorizationAspect“) abgefangen.
2. Der Sicherheitsproxy nutzt die Aktionsverwaltung, um zu überprüfen, ob die
Aktion zu den geschützten Aktionen gehört.
3. Der Proxy (bzw. der Aspekt) ruft eine Funktion der Klasse Policy-Verwaltung
(hier „PolicySetService“) auf, die die Zugriffsrechteprüfung bearbeitet.
4. Um an das zugehörige „PolicySet“ zu gelangen („getPid“), verwendet die
Policy-Verwaltung eine Klasse „oidPidMap“, die eine Tabelle für die
Zuordnung von PolicySet-Identifikationen zu Objekten verwaltet.
43

Entwurf: Policy-basierte Zugriffskontrolle
5. Anschließend durchsucht die Policy-Verwaltung alle vorhandenen
Zugriffsregeln des ausgewählten „PolicySets“ nach einer Übereinstimmung mit
den aktuellen Parametern für den Benutzer, das angefragte Objekt und die
verwendete Methode (mittels „queryAccessRights“).
6. Dazu verwendet sie die Funktion „queryAsResourceSet“, die die XML-
Datenbank mit den angegebenen Daten mittels einer XPath-Anfrage durchsucht.
7. Wenn die Bearbeitung erfolgreich war, dann kann die eigentliche Funktion
ausgeführt werden, andernfalls wird die Funktion „treatAccessDenied“
aufgerufen, die je nach Einstellung eine Fehlermeldung oder einen besonderen
Rückgabewert zurückgibt.
4.3.2 Die Benutzerverwaltung
Die Benutzerverwaltung kümmert sich um die Verwaltung der Benutzer, der
Benutzergruppen und um die Authentifizierung von Benutzern. Da das
Anwendungsprogramm in der Regel diese Daten selbst verwaltet, wird eine
Schnittstelle hierfür zum Anwendungsprogramm benötigt. Idealerweise wird die
Benutzerverwaltung aber als eigener Dienst realisiert, so dass mehrere
Anwendungsprogramme diesen nutzen können.
Zu jeder Benutzersitzung wird ein Sicherheitsstatus erstellt, mit dessen Hilfe die
Zugriffskontrolle abfragen kann, ob sich der Benutzer authentisiert hat, wie der
Benutzername ist und, wenn Rollen verwendet werden, welche aktiven Rollen er hat.
Des Weiteren könnten Angaben über die Art der Authentifikation hier festgehalten
werden, wie die Authentifikationsmethode (Passwort, Smartcard, etc.).
Der Sicherheitsstatus ist Teil der Sitzungsinformationen, d.h. es muss eine
standardisierte Schnittstelle geben, mit der die Sicherheitslösung den Status abfragen
bzw. setzen kann.
Um diese Werte zu setzen und abzufragen, sind die in Abbildung 17 dargestellten
Funktionen notwendig.
44

Entwurf: Policy-basierte Zugriffskontrolle
Sicherheitsstatus
-BenutzerID : int
-AuthStatus : int
+getUserID()
+getStatus()
+setStatus()
Sicherheitslösung
Abbildung 17: Sicherheitsstatus
Für ein Fahrtenbuch bietet sich die Authentifikation mittels Passwort an. Falls
Änderungen signiert werden sollen, ist es aber sinnvoll ein Smartcard orientiertes
Verfahren zu unterstützten.
In einer weiteren Ausbaustufe kann die Sicherheitsverwaltung um einen Rollen-Dienst
erweitert werden. Dieser müsste in die Benutzer- und Gruppenverwaltung integriert
werden.
4.3.3 Die Objektverwaltung
Die Objektverwaltung ist ebenfalls eine Singelton Klasse. Für jede zu schützende
Klasse speichert sie die spezifischen Schutzeinstellungen. Andere Dienste, wie der
Sicherheitsproxy und die Zugriffsverwaltung, benutzen die Objektverwaltung, um die
Schutzeinstellungen einer bestimmten Klasse abzufragen. Das folgende
Sequenzdiagramm zeigt beispielhaft den Einsatz der Objektverwaltung bei der
Zuweisung einer PolicySet-Identifikation zu einem neu erzeugtem Anwendungsobjekt.
Abbildung 18: „Erzeugung eines neuen Objektes“ (eigene Darstellung)
45

Entwurf: Policy-basierte Zugriffskontrolle
Wenn ein neues Anwendungsobjekt erzeugt wird, werden die folgenden Schritte
ausgeführt:
1. Wenn ein neues Anwendungsobjekt erzeugt wird, erkennt dies der
Sicherheitsproxy (die Klasse „AbstractAuthorizationAspect“).
2. Dieser prüft mit Hilfe der Objekt-Verwaltung, ob es sich bei dem Objekt um
eine zu schützende Anwendungsklasse handelt.
3. Wenn ja, dann muss die Policy-Verwaltung diesem Objekt eine Policy
zuweisen.
4. Wenn der Benutzer bereits ein „PolicySet“ für diese Klasse und die von ihm
gewählte Objekt-Klassifizierung (z.B. alle Fahrtenbucheinträge mit der
Klassifikation Privat) hat, dann wird dem Objekt dieses „PolicySet“ zugeordnet.
5. Andernfalls wird ein neues PolicySet erzeugt und dem Objekt zugewiesen.
Es wird hier jedoch auf verschachtelte Objektgruppen verzichtet. Das Konzept kann
aber entsprechend abgeändert werden. Dabei ist darauf zu achten, dass kein Zyklus im
Objektgruppengraph entsteht, da eine Gruppe nicht in sich selbst enthalten sein kann.
4.3.4 Die Aktionsverwaltung
Genauso wie die Policy-Verwaltung ist auch die Aktionsverwaltung eine Singelton
Klasse. Sie verwaltet die Einstellungen für alle zu schützenden Methoden. Die
Aktionsverwaltung wird beispielsweise in dem Sequenzdiagramm in Abbildung 16
verwendet.
Für jede zu schützende Methode erzeugt die Aktionsverwaltung eine Ontologie
„SecureAction“. Außerdem bietet sie Funktionen zum Erzeugen, Ändern, Einsehen und
Löschen von den Ontologien „ObjectType“ und „Permission“ an (siehe Abbildung 19).
Zugriffsrechte (engl. permissions) könnten z.B. wie folgt definiert sein:
• Für get-Methoden Leserechte,
• für set-Methoden Schreibrechte und
• für delete-Methoden Löschrechte.
46

Entwurf: Policy-basierte Zugriffskontrolle
Die nachträgliche Identifikation geeigneter Methoden ist relativ aufwendig und es kann
auch vorkommen, dass die Anwendungsklassen angepasst werden müssen, um einen
ausreichenden Schutz zu erzielen.
Die folgende Abbildung zeigt die Klasse „ActionService“ mit einigen ihrer Attribute
und Methoden. Auf diese soll hier nicht weiter eingegangen werden. Abgebildet sind
auch die zugeordneten Ontologien. Aus welchen weiteren Ontologien sich diese (und
die der anderen Dienste) im Einzelnen zusammensetzen, wird im nächsten Abschnitt
erläutert.
Abbildung 19: Klassendiagramm Aktionsverwaltung (eigene Darstellung)
4.4 Das semantische Datenmodell zur Zugriffsverwaltung
MIX-Ontologien wurden bereits im Kapitel 4.1.3 erläutert. Zum Paket „Ontology“ des
Fachgebietes „Datenbanken und verteilte Systeme“ wurden in dieser Arbeit folgende
Pakete hinzugefügt:
1. Ontology.Security.Authorization.ActionService
2. Ontology.Security.Authorization.ObjectService
3. Ontology.Security.Authorization.PolicyService
4. Ontology.Security.Configuration
Im Paket „Ontology.Security.Authorization“ sind Ontologien abgelegt, die für die
Realisierung der Zugriffskontrolle benötigt werden. Gemäß den verwendeten
Dienstklassen gibt es drei Teilpakete, deren Ontologien im Folgenden erläutert werden.
Zusätzlich gibt es noch das Paket “Ontology.Security.Configuration”, das Ontologien,
die für die Konfiguration benötigt werden, enthält.
47

Entwurf: Policy-basierte Zugriffskontrolle
4.4.1 Ontologien für die Zugriffsverwaltung
Ein „PolicySet“ ist eine Zusammenstellung von Policies. Da ein „PolicySet“ ein
komplexes Datenelement repräsentiert, beerbt sie die Ontologie
„ComplexSemanticObject“. Jedes „PolicySet“ verfügt über eine Identifikationsnummer
und über eine oder mehrere Eigentümer.
Abbildung 20: „PolicySet“ dargestellt als Klassendiagramm (eigene Darstellung)
„PolicySets“ können Anwendungsobjekten einer festgelegten Klasse zugeordnet
werden, wodurch alle Felder der Klasse geschützt werden. Die Felder der Klasse kann
man anschließend in den einzelnen Zugriffsregeln auswählen und eine
Zugriffsbedingung für einen oder mehrere Benutzer festlegen.
Dargestellt als MIX-Ontologie (vgl. [Bor99] S. 37) sehen „PolicySets“ wie folgt aus.
1.

Entwurf: Policy-basierte Zugriffskontrolle
Das Element „ObjectGroup“ ist optional. Wenn es definiert wird, dann bezieht sich das
„PolicySet“ nicht auf alle Instanzen einer Klasse, sondern nur auf die Instanzen dieser
Objektgruppe. Hiermit ist es beispielsweise möglich, alle privaten Fahrtenbucheinträge
eines Fahrers mit diesem „PolicySet“ zu erfassen.
In dieser Arbeit definieren „Policies“ Zugriffsrechte in Form von Tripeln aus
Benutzern, Feldern und Zugriffsbedingungen. Das erste Tripel-Element legt die
beteiligten Benutzer oder Benutzergruppen fest. Das zweite Element definiert die
Felder, so dass nicht für jedes Feld im geschützten Anwendungsobjekt ein eigenes
„PolicySet“ angelegt werden muss. Und das dritte Element bestimmt die
Zugriffsbedingungen, die erfüllt sein müssen, damit auf das Objekt mit der festgelegten
Aktion zugegriffen werden darf.
Zugriffsbedingung könnten z.B. eine bestimmte Benutzerrolle sein oder die
Zugehörigkeit zu einer Personengruppe. Diese Arbeit beschränkt sich aber auf die
Zuordnung zu einfachen Zugriffsrechten wie Lese-Recht, Schreib-Recht oder Lösch-
Recht.
Eine Policy eines PolicySets für ein Fahrtenbuch könnte dann wie folgt aussehen:
1.

Entwurf: Policy-basierte Zugriffskontrolle
Abbildung 23: Klassendiagramm: „geschützte Klasse“ (eigene Darstellung)
Außerdem enthält die Objektverwaltung Ontologien für die Abbildung von Feldern
einer Klasse. Hierzu werden für jedes geschützte Objekt eine Liste von Feldern und eine
eindeutige Feldidentifikation benötigt.
4.4.3 Ontologien für die Aktionsverwaltung
Nachdem die Rechteprüfung erfolgreich durchgeführt wurde, kann die gewünschte
Aktion ausgeführt werden. Wird der Zugriff jedoch verweigert, dann muss eventuell
eine alternative Aktion aufgerufen werden. Dabei kann es sich um eine Fehlermeldung
handeln oder auch um eine speziell dafür vorgesehene Funktion.
Mit Hilfe der Ontologie „SecureAction“ wird festgelegt, welche Aktion bzw.
Fehlermeldung ausgeführt werden soll (siehe Abbildung). Die alternative Methode kann
dann mittels des „Java Reflection“ Mechanismus durch „invoke“ aufgerufen werden.
1.
Abbildung 24: Die Ontologie „geschützte Aktionen“ (eigene Abbildung)
Zusätzlich werden Ontologien für die Definition von Methodenargumenten
(insbesondere zur Festlegung, ob und wie eine Benutzersitzung übergeben wird) und für
die Definition des benötigten Zugriffsrechtes (engl. permission) verwendet.
50

Implementierung der Zugriffskontrolle
5 Implementierung der Zugriffskontrolle
Das folgende Kapitel beschreibt die Implementierung der Zugriffskontrolllösung. Zuerst
wird erläutert, wie die aspektorientierte Zugriffskontrolle im Allgemeinen realisiert
wurde. Anschließend werden die verwendeten Technologien für die Speicherung, den
Zugriff und die Verarbeitung der Zugriffsregeln der policy-basierten Zugriffskontrolle
beschrieben.
5.1 Aspektorientierte Zugriffskontrolle
Ziel dieser Arbeit ist es, eine möglichst anwendungsunabhängige Zugriffskontrolle zu
realisieren. Dies soll mit Hilfe eines Aspektes „Autorisierung“ erreicht werden. Alle in
diesem definierten Zugriffskontrollaufrufe werden, ohne dass ein Anwendungsprogrammierer
dies programmieren muss, zur Übersetzungszeit automatisch in die
Anwendungsklassen hineinübersetzt.
5.1.1 Der anwendungsspezifische Autorisierungsaspekt
Die Beispielanwendung “Fahrtenbuch”, die in einer zweiten Diplomarbeit entwickelt
wurde, soll nun mit Hilfe dieser Zugriffskontrolle geschützt werden.
Um dies zu erreichen, ist ein Bindeglied in Form eines „Autorisierungs“-Aspektes
zwischen der Fahrtenbuch-Anwendung und der Sicherheitslösung notwendig. Die
folgende Abbildung stellt einen Ausschnitt aus diesem Aspekt dar.
1. public aspect AuthorizationAspect extends
AbstractAuthorizationAspect{
2. public pointcut Initialization()
3. : call(* *.main(..));
4.
5. declare parents: Logbook..* implements SecuredClasses;
6.
7. public pointcut SecuredObjectsConstructors()
8. : execution(Ontology.BasicObject.DataSet.new(..));
9.
10.public UserIdentification getUserId(Object object)…
11.public ObjectIdentification getObjectId(Object object)…
12.public ObjectGroupIdentification getObjectGroup(Object
object) …
Abbildung 25: Der Fahrtenbuch spezifische Autorisierungsaspekt
Soll anstelle der Fahrtenbuch-Anwendung eine andere Anwendung geschützt werden,
dann ist in der Datei in der Zeile 5 das Paket dieser Anwendung anzugeben. Die
Zeichen „..*“ hinter „Logbook“ bedeuten, dass auch alle Unterpakete des Paketes
51

Implementierung der Zugriffskontrolle
„Logbook“ berücksichtigt werden sollen. Alle eingebundenen Pakete bzw. Klassen
implementieren damit die Schnittstelle „SecuredClasses“, die als Stellvertreterobjekt für
diese Klassen fungiert.
Ideal wäre, wenn Anwendungsprogrammierer überhaupt keinen Code ändern müssten
und auf die Definition von neuen Paketen im Autorisierungsaspekt verzichten könnten.
Um dies zu erreichen, könnte man anstelle von Zeile 5 auch folgendes definieren:
declare parents: *..* implements SecuredClasses;
Hierdurch werden alle Pakete, die der Compiler findet, eingebunden. Aus
Leistungsgründen und aufgrund möglicher zirkulärer Beziehungen wird hierauf
verzichtet. Trotzdem ist mittels dieses Vorgehens eine schnellere Einbindung einer
Sicherheitslösung möglich, als wenn ein Sicherheits-Framework verwendet wird, da die
Einbindung der Zugriffskontrolle fast ohne Programmieren erfolgen kann. Anpassungen
können stattdessen durch einfaches Konfigurieren eingearbeitet werden.
Falls doch programmiersprachliche Anpassungen notwendig werden, so sollten sie in
dieser anwendungsspezifischen Aspektklasse erfolgen. Beim Fahrtenbuch waren
folgende Änderungen notwendig.
Das Fahrtenbuch kümmert sich selbst, um die Verwaltung seiner Benutzer und um die
Authentifizierung. Um an die aktuelle Benutzeridentifikation zu gelangen, bietet der
anwendungsspezifische Autorisierungsaspekt eine abstrakte Methode „getUserId“ an,
die zu implementieren ist. In der Fahrtenbuch-Anwendung wird beispielsweise eine
Sitzung bei jedem Methodenaufruf übergeben. Aus diesem Sitzungsobjekt wird mittels
der Methode „getUserId“ die aktuelle Benutzeridentifikation extrahiert.
1. public UserIdentification getUserId(Object object){
2. Session session = ((Session)object);
3. String id = session.getUserID();
4. return new UserIdentification(id);
5. }
Abbildung 26: Die Methode “getUserId” (eigene Abbildung)
Weitere Anpassungen waren notwendig für die Ermittlung der Objektidentifikation, da
die Objektidentifikation der Fahrtenbuch-Elemente verwendet werden sollte. Alternativ
könnten auch die Objektreferenz als Objektidentifikator oder die Identifikationen der
Ontologie „Complex Semantic Object“ verwendet werden. Des Weiteren wurde auch
52

Implementierung der Zugriffskontrolle
noch die Objektgruppe, zu der das Objekt gehört, mit der Funktion “getObjectGroup”
ermittelt.
5.1.2 Der anwendungsunabhängige Autorisierungsaspekt
Der anwendungsspezifische Autorisierungsaspekt erbt die eigentliche Funktionalität
von einem anwendungsunabhängigen Autorisierungsaspekt. Dieser definiert Pointcuts
(siehe Abschnitt 3.3.4) für Zugriffskontrollaufrufe und für die Zuweisung von Policy-
Dateien.
Der Pointcut „AuthorizationOperations“ webt in alle eingebundenen Methodenaufrufe
ein Zugriffskontrollaufruf ein (siehe Abbildung 27 Zeile 5). Es werden aber nicht alle
Methodenaufrufe überprüft, sondern nur solche, die durch die Konfiguration als
sicherheitsrelevant eingestuft sind.
1 public aspect AbstractAuthorizationAspect{
2 public interface SecuredClasses{String ID=““;};
3 …
4 protected pointcut AuthorizationOperations()
5 : call(* SecuredClasses+.*(..)) &&
6 if(isAction(thisJoinPointStaticPart.
getSignature().getName(),
thisJoinPointStaticPart.getSignature()
.getDeclaringType().getName()
7 ));
8 …
9 Object around() : AuthorizationOperations() {
10 …
11 }
Abbildung 27: Pointcut: „AuthorizationOperations“ (eigene Darstellung)
Damit die Funktion „isAction“ in der Konfiguration nachschauen kann, werden ihr alle
notwendigen Daten über die Methode mittels “thisJoinPointStaticpart.getSignature”
übergeben. Wenn die Prüfung erfolgreich war, dann werden alle zugehörigen Advices
ausgeführt. Auf diese Weise wird der Advice in Zeile 9 aufgerufen, der die Zugriffskontrollprüfung
durchführt, und der festlegt, was geschieht, wenn der Aufruf nicht
zugelassen wird.
Als weiteren Pointcut definiert der anwendungsunabhängige Autorisierungsaspekt den
Pointcut „Initialization“, der dafür zuständig ist, beim Start des Anwendungsprogramms
die Sicherheitsdienste, wie die Policy-Verwaltung (Abbildung 28 Zeile 7), die Objekt-
Verwaltung (Zeile 8) und die Aktions-Verwaltung (Zeile 9) zu starten.
53

Implementierung der Zugriffskontrolle
1. public abstract aspect AbstractAuthorizationAspect{
2. …
3. public abstract pointcut Initialization();
4. after(): Initialization() { // Read configuration
5. configuration = Configuration.getInstance();
6.
7. configuration.startService(„PolicyService“);
8. configuration.startService(„ObjectService“);
9. configuration.startService(„ActionService“);
10. }
11. …
12.}
13.
Abbildung 28: Pointcut „Initialization“ (eigene Darstellung)
Ein weiterer wichtiger Pointcut ist “SecuredObjectConstructors”. Dieser wird ausgelöst,
wenn ein Objekt einer Klasse, die „SecuredClasses“ implementiert, erzeugt wird.
Nachdem das Objekt erzeugt wurde, wird der Advice „after():
SecuredObjectsConstructor“ ausgeführt, der diesem ein PolicySet entsprechend der
Vorgaben der Konfigurationsdatei „ObjectConfiguration.xml“ zuweist.
1. public abstract aspect AbstractAuthorizationAspect{
2. …
3. public abstract pointcut SecuredObjectsConstructors()
4. …
5. after() returning: SecuredObjectsConstructors(){
6. if(isSecuredClass(thisJoinPointStaticPart.
getSignature().getDeclaringType().getName() ));
7. {
8. …
9. inialize.invoke(authService, new Object[]{userId,
thisObject});
10. …
11. } …
12.}
Abbildung 29: Pointcut „SecuredObjectConstructors“ (eigene Darstellung)
5.2 Implementierung der Policy-basierten Zugriffskontrolle
5.2.1 Speicherung von Policy Dateien in der XML Datenbank eXist
Zur Speicherung der Zugriffsrechte und der Konfigurationsdateien wird die Open-
Source-XML Datenbank eXist (vgl. [Mei03]) verwendet. Aus Effizienzgründen
speichert eXist XML Dateien nicht in einem relationalen Datenspeicher, sondern in
einem eigenen XML Datenspeicher (siehe Abbildung). Eine Schnittstelle zu
relationalen Datenbanken ist aber auch vorhanden. Ähnlich wie die Speicherung von
Dateien in Ordnerstrukturen, werden XML Dokumente in hierarchischen Kollektionen
54

Implementierung der Zugriffskontrolle
gespeichert. Ist ein XML Dokument mit einem Schema Dokument oder einer DTD
verknüpft, so wird beim Einfügen des Dokumentes dieses einer Validitäts-Prüfung
unterzogen.
Abbildung 30: Architektur von eXist (vgl. [Mei03] Abschnitt „Features“)
Die Datenbank, die in Java implementiert ist, kann auf drei verschiedene Arten
betrieben werden. Erstens als eigener Server Prozess, zweitens eingebettet in eine Java
Anwendung oder drittens in Verbindung mit einem Servlet Container wie z.B. Tomcat
(vgl. [ApaoJ]).
Die folgende Abbildung zeigt eine XML-Datei für die Festlegung von Zugriffsrechten,
die in der XML-Datenbank eXist im Verzeichnis „/db/policies“ gespeichert werden
kann. Eine XML-Datei hat ein Wurzelelement (hier „PolicySet“ in Zeile 2 mit dem
Attribut „id“ für die eindeutige Identifikation des PolicySets). Das Wurzelelement kann
mehrere Kind-Elemente haben. In diesem Fall gibt es eine Liste von Eigentümern (Zeile
3-5), eine Liste von Objekttypen (Zeile 7-9) und eine Liste von Policy-Einträgen (Zeile
11 ff.). Die Policy-Einträge werden in eigenen Dateien gespeichert und mit Hilfe von
XInclude (vgl. [Mei03] Abschnitt „XInclude“) in die zugehörigen PolicySets
eingebunden (siehe Abbildung 31 Zeile 12). Der Hauptgrund hierfür ist, dass eXist eine
statische Datenbank ist, d.h. um Änderungen an gespeicherten XML-Ressourcen
vorzunehmen, muss die komplette Datei ausgelagert, geändert und wieder gespeichert
werden. Daher ist es einfacher kleinere Dateien zu bearbeiten. Zum anderen kann
hierdurch eine Policy mehreren PolicySets zugeordnet werden.
55

Implementierung der Zugriffskontrolle
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Abbildung 31: Beispiel für ein PolicySet
In der neuesten Version unterstützt eXist eine UNIX ähnliche Zugriffskontrolle auf
gespeicherte XML-Dateien (vgl. [Mei03] Abschnitt „Security“). Es gibt drei Arten von
Zugriffsrechten:
Read
Write
Zugriffsrecht, um eine Datei zu lesen oder zu suchen oder um die Inhalte einer
Kollektion aufzulisten.
Zugriffsrecht, um eine Datei zu löschen oder zu verändern oder um eine neue
Datei oder eine neue Subkollektion zu einer Kollektion hinzuzufügen.
Update Zugriffsrecht, um eine existierende Datei zu verändern, Das Entfernen der
Datei ist nicht erlaubt, solange nicht das Write Recht gewährt wurde.
Es ist aber nicht möglich, den Zugriff auf einzelne Elemente in der XML-Datei zu
regeln, und auch die Definition von eigenen anwendungsspezifischen Zugriffsregeln ist
unmöglich. Z.B. kann man keine neuen Zugriffsrechte definieren und eine differenzierte
Zuordnung von Benutzern und Benutzergruppen zu einem Zugriffsrecht kann nicht
stattfinden. Außerdem bedarf die Nutzung der Datenbank-Zugriffsrechte einer
nachträglichen Anpassung der Anwendungsprogramme, da bei einem zurückgewiesenen
Zugriffsversuch auf die Datenbank eine Ausnahmebehandlung in der
Anwendung zu erfolgen hat. Insgesamt gesehen ist somit diese Lösung nicht geeignet
für eine anwendungsunabhängige Zugriffskontrolle.
56

Implementierung der Zugriffskontrolle
5.2.2 Zugriff auf die Policies mittels XPath
Auf die Datenbank kann über mehrere Schnittstellen zugegriffen werden (vgl. [Mei03]
Abschnitt „Server Deployment“). Unterstützt werden zum einen XPath Anfragen via
http und XML-RPC sowie direkte Zugriffe von Java aus über die XML:DB API. Um
effiziente XPath-Anfragen zu ermöglichen, nutzt eXist Index-Strukturen. Der
bevorzugte Weg, um eXist von Java Anwendung aus anzusprechen, ist jedoch die
Nutzung der XML:DB API. Diese stellt eine vereinheitlichte Schnittstelle für den
Zugriff auf XML Datenbanken dar. Die Basiskonzepte der XML:DB API sind Treiber
(engl. driver), Kollektionen (engl. collections), Ressourcen (engl. resources) und
Dienste (engl. services). Der Treiber für eXist umfasst die für ihn spezifische
Datenbankzugriffslogik. Eine Kollektion ist ein Container, der Ressourcen oder weitere
Subkollektionen enthält. Als Ressourcen werden im Augenblick nur XML-Ressourcen
unterstützt. Dienste schließlich können angefragt werden, um spezielle Aufgaben wie
XPath-Anfragen oder Benutzermanagement zu erfüllen.
XPath (vgl. [GaW02]) ist eine Sprache für die Adressierung von XML Strukturen, die
von mehreren anderen XML Standards wie XSLT, XPointer oder XQuery vewendet
wird. Mit ihr lassen sich Such-Ausdrücke definieren, die in einer Art Pfad-Beschreibung
festlegen, welche Elemente eines XML Dokumentes benötigt werden. Zum Beispiel
repräsentiert der vorwärtsgerichtete Slash (/) eine einfachen XPath Ausdruck, mit dem
man den Wurzelknoten eines XML Dokumentes erhält.
In eXist ist eine XPath Dienst eingebaut, der zwar noch nicht den vollen Sprachumfang
von XPath unterstützt, mit dem sich aber die wichtigsten Ausdrücke darstellen lassen
(vgl. [Mei03] Abschnitt „XPath HowTo“). Um die XML-Datenbank zu durchsuchen,
kann man diesen Dienst nutzen, indem man „service.query()“ aufruft
und eine XPath-Query definiert. Die Methode gibt ein ResourceSet zurück, was einer
Menge an gefundenen XML-Ressourcen entspricht.
Der Zugriff auf die XML-Datenbank ist in der Klasse „SecurityPortal“ gekapselt. Diese
enthält beispielsweise folgende Funktion zum Zugriff auf alle Elemente beliebiger
XML-Dokumente, die der angegebenen Suchanfrage entsprechen.
57

Implementierung der Zugriffskontrolle
1 public class SecurityPortal extends de.tud.ito.hp.portal.Portal
{
2 …
3 public ResourceSet queryAsResourceSet(String query) {
4 try {
5 XpathQueryService service = (XpathQueryService)
col.getService(„XpathQueryService“,
„1.0“);
6 service.setProperty(„pretty“, „true“);
7 service.setProperty(„encoding“, „ISO-8859-1“);
8
9 ResourceSet result = service.query(query);
10 return result;
11 } catch (Exception ex) {
12 System.err.println(„Not in database: „);
13 return null;
14 } …
15 }
Abbildung 32: Funktion „queryAsResourceSet“
Normalerweise werden nur die Dokumente der aktuellen Kollektion durchsucht. Mit
Hilfe der Funktionen „document“ und „collection“ ist es aber möglich, auch spezielle
Dokumente und Kollektionen auszuwählen (vgl. [Mei03] Abschnitt „Developer’s
Guide“). Mittels der Funktion „document()“ legt man beispielsweise fest, welche
Dokumente in welchem Dokumentenpfad zu berücksichtigen sind.
Die folgende Abbildung zeigt einige Beispiele für Suchanfragen.
1 query = „document(‚/db/config/PolicyConfiguration.xml’)“;
2 query = „document(‚/db/config/“+ moduleName +“’)/*“;
3 query = „document(‚/db/policies/“ + pid + „.xml’)/PolicySet
[Users/User/@id=’“ + userId + „’]“;
Abbildung 33: Beispiele für Suchanfragen
Die erste Suchanfrage in Abbildung 33 ermittelt, ob es ein Dokument
„PolicyConfiguration.xml“ im Verzeichnis „/db/config“ gibt. Die zweite Suchanfrage
liefert den Wurzelknoten einer Datei mit dem in „moduleName“ spezifizierten Namen
im Vezeichnis „/db/config“ zurück. Die dritte Suchanfrage ähnelt den ersten beiden. Sie
hat jedoch die zusätzlich Bedingung, dass der Benutzer die Identifikation hat, die in
„userId“ steht (siehe [Mei03] Abschnitt „XPath HowTo“).
58

Implementierung der Zugriffskontrolle
5.2.3 Darstellung der Zugriffsregeln als MIX-Ontologien
Zur Darstellung des Datenmodells der Zugriffskontrolle werden MIX-Ontologien
verwendet. Im Folgenden wird auf einige wichtige Ontologien aus den Paketen Policy-,
Objekt- und Aktionsverwaltung kurz eingegangen.
5.2.3.1 PolicySet und Policy
Die zentrale Ontologie im Paket Policy-Verwaltung ist das PolicySet. Dieses stellt eine
Menge von Policies dar, die in einer Datei zusammengefasst werden. Das gesamte
PolicySet kann Anwendungsobjekten zugewiesen werden.
1 public class PolicySet extends ComplexSemanticObject {
2 public static final String CONCEPTNAME =
PolicySet.class.getName();
3
4 public PolicySetIdentification identification;
5 public ClassName className;
6 public OwnerList ownerList;
7 public UsedByObjectGroupList usedByList;
8 public PolicyList policyList;
9 …
10 }
Abbildung 34: Ontologie „PolicySet“
Ein PolicySet verfügt über eine eindeutige Identifikation (Zeile 4), über eine
zugeordenete Klasse (Zeile 5) und über drei Listen. In der ersten Liste (Zeile 6) steht,
wer oder welche Personen Eigentümer des PolicySets sind. Dies ist notwendig, damit in
Zukunft nur Eigentümer das PolicySet verändern dürfen. Die zweite Liste (Zeile 7) legt
fest, welchem Objekttypen (z.B. „Privatfahrt“ bei Fahrteinträgen) das PolicySet
zugeordnet ist. Dieser Eintrag kann aber auch weggelassen werden. Die dritte Liste
(Zeile 8) enthält die Zugriffsregeln in Form von Policies. Auf diese wird bei der
Ontologie „Policy“ genauer eingegangen.
Die folgende Abbildung zeigt eine Fabrik-Methode, mit deren Hilfe man ein PolicySet
anlegen kann. Ein synchronisierter Zähler (Zeile 4) erzeugt eindeutige Ids, die für die
Erstellung der PolicySet-Identifikationen (Zeile 5) benötigt werden. In den Zeilen 8 bis
10 werden die drei angesprochenen Listen angelegt und in Zeile 12 wird ein PolicySet
aus den zuvor erzeugten Teilelementen erstellt.
59

Implementierung der Zugriffskontrolle
1 public class PolicySetService{
2 …
3 protected synchronized PolicySet createPolicySet() {
4 pidCounter++;
5 PolicySetIdentification identification =
6 new PolicySetIdentification(„PS“+Integer.toString(
pidCounter));
7 ClassName name = new ClassName(className);
8 OwnerList owners = new OwnerList(null, null);
9 UsedByObjectGroupList usedBy =
new UsedByObjectGroupList(null, null);
10 PolicyList list = new PolicyList(null, null);
11
12 PolicySet policySet = new PolicySet(identification,
name,
owners,
usedBy,
list, null, null);
13 return policySet; }
14 …
15 }
Abbildung 35: Fabrik-Methode „createPolicySet()“
Zugriffskontroll-Policies (siehe Abbildung 36) spezifizieren Zugriffskontroll-
Einstellungen und werden im PolicySet in der PolicyList gespeichert. Eine Policy
enthält eine Policy-Identifikation, eine Beschreibung und drei Listen. Benötigt werden
je eine Liste für die zu berücksichtigenden Benutzer, für die zu schützenden Felder und
Objekte der Klassen sowie für die Zugriffsbedingungen.
1 public class Policy extends ComplexSemanticObject {
2 public static final String CONCEPTNAME =
Policy.class.getName();
3
4 public PolicyIdentification identification;
5 public Description description;
6 public UserList userList;
7 public ElementList elementList;
8 public AccessConditionList accessConditionList; …
9 }
Abbildung 36: Ontologie Policy
Eine einzelne Policy im XML-Format ist in Abbildung 37 dargestellt. Wie beim
PolicySet wird auch hier Xinclude verwendet, um XML-Ressourcen wie Benutzer,
Elemente und Zugriffsbedingungen einer Policy zuzuordnen. D.h. alle XML-
Ressourcen, die im Attribut „assignedPolicies“ unter anderem die Identifikation dieser
Policy speichern, werden automatisch in die XML-Ressource Policy eingebunden.
60

Implementierung der Zugriffskontrolle
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Abbildung 37: Beispiel-Policy aus einem XML PolicySet.
Aus Zeitgründen war es aber nicht möglich, komplexere Zugriffsbedingungen zu
realisieren. Hiermit könnte man z.B. prüfen, ob ein Element des Objektes einen
vorgegeben Wert hat oder ob der Benutzer der Eigentümer des Anwendungsobjektes ist.
5.2.3.2 SecuredClass und SecuredObjectGroup
Im Fahrtenbuch-Aspekt wurde das zu schützendende Fahrtenbuch-Paket festgelegt.
Welche Klassen aber geschützt werden, wird mittels der Ontologie für geschützte
Klassen definiert (vgl. dazu auch 6.2.2.2). Jede geschützte Klasse verfügt über eine
eindeutige Identifikation, über einen Klassenpfad sowie eine Liste geschützter
Objektgruppen. Der Klassenname bzw. Klassenpfad (z.B. „Logbook.Dataset.Entry“)
wird bei der Ermittlung der gesicherten Aktionen zur Laufzeit benötigt. Die Klasse
ActionService greift z.B. in der Funktion „getSecureAction“ auf das ontologische
Konzept „classPath“ zu.
Die Liste “SecuredObjectGroupList” enthält semantische Konzepte mit dem Namen
“SecuredObjectGroup”. Dies ermöglicht die Gruppierung von Instanzen einer Klasse in
beliebige Kategorien, beispielsweise die Klasse Fahrteintrag in die Kategorien
„Privatfahrt“, „Geschäftsfahrt“ und „Fahrt zur Arbeit“. Eine solche Objektgruppe hat
eine eindeutige Identifikation, einen Eigentümer und eine initiale Policy Identifikation.
Wenn eine neue Objektgruppe erzeugt wird, dann wird dieser eine passende initiale
Policy-Id zugewiesen oder es wird zusätzlich eine neue initiale Policy erzeugt. Am
61

Implementierung der Zugriffskontrolle
Beispiel eines Fahrtenbucheintrages soll dies erläutert werden. Wenn man eine
Objektgruppe „Patientenfahrt“ einrichtet, dann erstellt man zusätzlich eine initiale
Policy, die vorgibt, dass nur der Eigentümer und befreundete Ärzte diesen Eintrag lesen
dürfen, das Finanzamt hingegen darf nur unkritische Daten wie Datum und
Kilometerzahl lesen.
5.2.3.3 SecuredObjectType und SecureAction
Die zwei wichtigsten Ontologien der Aktionsverwaltung sind „SecuredObjectType“ und
„SecureAction“. Das erstere repräsentiert eine Zusammenfassung von Anwendungsklassen
mit gleichen oder gleichartigen Methoden unter einem Typbegriff. Die folgende
Abbildung zeigt den Aufbau eines „SecuredObjectType“ bestehend aus einer
eindeutigen Identifikation, einer Liste von zugeordneten Klassen und einer Liste von
Aktionen, die bei der Zugriffskontrolle verwendet werden sollen.
1 public class SecuredObjectType extends ComplexSemanticObject
2 {
3 public ObjectTypeIdentification identification;
4 public SecuredClassesList classesList;
5 public ActionList actionList;
6 …
7 }
Abbildung 38: Ontologie SecuredObjectType
Eine „SecureAction“ ist ein Eintrag in der Aktionsliste eines „SecuredObjectType“. Er
enthält Informationen, die die Aktionsverwaltung über Methoden der Anwendungsklasse
wissen muss, um diese zu schützen. Jede geschützte Aktion hat einen eindeutigen
Bezeichner, ein Zielobjekt und ein Zugriffsrecht. Optional sind dagegen die
Spezifikation, welche Argumente der Methode für die Rechteprüfung berücksichtigt
werden sollen, ob eines der Argumente auf die aktuelle Sitzung verweist und welche
Fehlermeldung bei einer Zugriffsverweigerung auszugeben ist.
1 public class SecureAction extends ComplexSemanticObject {
2 public static final String CONCEPTNAME =
SecureAction.class.getName();
3 public ActionIdentification identification;
4 public Target target;
5 public Permission permission;
6 public ArgumentIdentification argumentID;
7 public SessionArgument sessionargument;
8 public ErrorMessage errormessage;
9 …}
Abbildung 39: Ontologie SecureAction
62

Schnittstellen und Konfigurationen
6 Schnittstellen und Konfigurationen
Um die Sicherheitslösung an die jeweilige Anwendung anzupassen, kann man entweder
ein Application Programming Interface oder Konfigurationsdateien verwenden. Die
realisierte Lösung kann sowohl über eine Schnittstellenklasse, die die wichtigsten
Funktionen anbietet, als auch über mehrere Konfigurationsdateien angepasst werden.
Dieses Kapitel erläutert und vergleicht die beiden Herangehensweisen anhand des
Fahrtenbuch-Beispiels.
6.1 Das Application Programming Interface
Eine API (Application Programming Interface) ist eine Zusammenfassung von
Methoden, die Anwendungsprogrammen zur Verfügung gestellt werden. Folgende
Klassen stehen seitens der in dieser Arbeit entwickelten Lösung zur Verfügung:
1. die Klasse „SecurityFacade“
2. die Klasse „SecurityPortal“
Die Klasse „SecurityFacade“
Das Sicherheitssystem besteht aus mehreren Diensten, die sich um die Verwaltung der
Policies, der geschützten Objekte und der geschützten Aktionen kümmern. Damit einem
Client diese Komplexität verborgen bleibt, wird ein Facade-Muster (vgl. [Bal99] S. 293
ff.) verwendet, das alle Funktionen, die der Client benötigt, in eine einfach zu
handhabende Schnittstelle kapselt. Bei dem Client kann es sich um das zu beschützende
Anwendungsprogramm oder um eine eigene Benutzerschnittstelle für die Konfiguration
der Zugriffskontrolle handeln.
SecurityFacade
-instance : SecurityFacade
PolicySetService
Client
+getInstance() : SecurityFacade
+createObjectGroup(String,String,String)
+deleteObjectGroup()
+defineSecuredAction(String,String)
+deleteSecuredAct ion()
+viewPolicySet(Object)
+changePolicy()
+storeConfiguration()
SecuredObjectsService
ActionService
Abbildung 40: Klassendiagramm „Security Facade“
63

Schnittstellen und Konfigurationen
Über die Funktion „getInstance()“ kann sich der Client eine Instanz der „Security
Facade“ holen. Hiermit erhält er Zugriff auf für ihn relevante Funktionen der Policy-
Verwaltung (wie „viewPolicySet“ oder „changePolicy“), der Objekt-Veraltung (wie
„createObjectGroup“, oder „deleteObjectGroup“) und der Aktions-Verwaltung (wie
„defineSecuredAction“ oder „deleteSecuredAction“).
1 public class SecurityFacade {
2 …
3 public void viewPolicySet(Object obj) {
4 PolicySetService pss = PolicySetService.getInstance();
5 pss.viewPolicySet(obj);
6 }
7 …
8 }
Abbildung 41: Methode „viewPolicySet“ der Klasse „Security Facade“
Als Beispiel der Methode „viewPolicySet“ sieht man, wie die Methoden der Klasse
„Security Facade“ Aufrufe an die entsprechenden Dienste (hier die Policy Verwaltung)
weiterleiten. Die Methode holt sich dazu die entsprechende Dienst-Instanz über die
Funktion „getInstance()“ und ruft anschließend die gewünschte Methode mit den
entsprechenden Eingabeparametern auf.
Da diese Sicherheitslösung kein Framework sein soll, soll hier nicht auf die einzelnen
Schnittstellenfunktionen eingegangen werden.
Die Klasse SecurityPortal
Zur Speicherung der Policies und der Daten für die Konfiguration der Zugriffskontrolle
wird XML verwendet. Die XML Dateien werden in der XML-Datenbank „eXist“
gespeichert. Die Klasse „SecurityPortal“ umfasst alle Funktionen für die Speicherung,
die Änderung und den Zugriff auf XML-Daten.
64

Schnittstellen und Konfigurationen
SecurityPortal
+Konstruktor()
+Konstruktor(String)
+Konstruktor(String,String)
+getAsSAX(String,SAXHandler)
+queryAsSAX(String,SAXHandler)
+queryAsResourceSet(String) : ResourceSet
+store(String,String)
+update(String,String,ComplexSemanticObject,String,int,...
+search(Element,Element) : Element
PolicySetService
Configuration
Abbildung 42: Klassendiagramm „Security Portal“
Mit Hilfe der Konstruktoren aus der Portal-Klasse kann man festlegen, welche
Kollektion (z.B. „/db/policies“ oder „/db/config“) verwendet werden soll.
Die Klasse „SecurityPortal“ erweitert die Klasse „de.tud.ito.hp.porta.Portal“ um
mehrere Such- und Änderungsfunktionen. Die Funktion „queryAsResourceSet“ (siehe
Abbildung 32) ermöglicht beispielsweise die Suche nach bestimmten Elementen und
Attribut-Werten mittels einer als Parameter übergebenen Suchanfrage. Die Anfrage, die
als XPath-Ausdruck definiert wird, liefert als Ergebnis eine Menge an XML-
Teilabschnitten, die der Anfrage entsprechen.
Die Klasse „SecurityPortal“ bietet außerdem folgende Methoden an:
getAsSAX(id, handler)
Zweck: greift auf ein bestimmtes Element mittels eines
SAX-Handlers zu.
Parameter: id
Identifikation des gesuchten Elementes
handler SAX-Handler
Ergebnis: -
Beispiel: SAXHandler handler = new SAXHandler();
SecurityPortal.getAsSAX(, handler);
queryAsResourceSet(query)
Zweck: sucht Ressourcen in der XML-Datenbank mittels einer
Xpath-Query.
Parameter: query Xpath-Query
Ergebnis: ResourceSet alle gefundenen Resourcen
Beispiel: SecurityPortal.getAsSAX();
queryAsSAX(query)
Zweck:
sucht Ressourcen in der XML-Datenbank mittels einer
Xpath-Query Anfrage.
Parameter: query Xpath-Query
hanlder
SAX-Handler
65

Schnittstellen und Konfigurationen
Ergebnis: -
Beispiel: SAXHandler handler = new SAXHandler();
SecurityPortal.getAsSAX();
store(id, value)
Zweck: speichert eine neue Ressourcen in der XML-Datenbank.
Parameter: id
Bezeichner der neuen Ressource
value Wert der Ressource
Ergebnis: -
Beispiel: SecurityPortal.store(, );
restore(id)
Zweck: holt ein Element wieder aus der der XML-Datenbank.
Parameter: id
Bezeichner der neuen Ressource
value Wert der Ressource
Ergebnis: -
Beispiel: SecurityPortal.store(, );
6.2 Konfiguration
Die Konfiguration der Zugriffskontrolle besteht aus zwei Teilen:
1. Die Konfiguration der Zusammenstellung der Sicherheitslösung wird in der
Datei „Security.xml“ im Verzeichnis „/Security/Configuration“ festgelegt.
2. Die Policy-Verwaltung (in „PolicyConfiguration.xml“) sowie die dafür
notwendige Objekt-Verwaltung (in „ObjectConfiguration.xml“) und die
Aktions-Verwaltung (in „ActionConfiguration.xml“) werden in den
angegebenen Konfigurationsdateien definiert.
Im Folgenden wird die Struktur der einzelnen Konfigurationsdateien erläutert:
6.2.1 Die Zusammenstellung der Sicherheitslösung
Die Konfigurationsdatei „Security.xml“ des Sicherheitssystems wird in XML
geschrieben, da man so die Konfiguration in einem einfachen Editor verändern kann
und da sich XML als Konfigurationssprache Bereich des Internet durchgesetzt hat.
Im Wurzel-Element „Security“ ist das Attribut „Port“ vorhanden, das die URI für die
XML-Datenbank eXist festlegt. In diesem Beispiel läuft die Datenbank in dem Servlet
Container „Tomcat“ (vgl. [ApaoJ]) auf dem lokalen Rechner und kann über die Adresse
„xmldb:exist://localhost:8080/exist/xmlrpc“ angesprochen werden. Wenn die
Datenbank als eigener Server Prozess betrieben wird, dann würde die Adresse
„xmldb:exist://localhost:8081“ lauten (vgl. [Mei03] Abschnitt „Deployment“).
66

Schnittstellen und Konfigurationen
1
2
3
4
5
6

Schnittstellen und Konfigurationen
aus einer Benutzerliste, einer Elementliste und einer Zugriffskontrollliste. Für den Fall,
dass alle Elemente oder Zugriffsrechte gewährt werden sollen, wurde das Schlüsselwort
„all“ definiert. Dieses legt fest, dass z.B. alle Elemente des Objektes, dem diese Policy
zugeordnet wird, die Zugriffsbedingung erfüllen.
Das folgende Beispiel zeigt eine Beispielkonfiguration mit einer initialen Policy mit der
Id 1. Diese legt fest, dass der Besitzer des Objektes und damit der Erzeuger der Policy
alle Elemente bzw. Teil-Objekte lesen darf.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 …
17
18
Abbildung 44: Konfigurationsdatei „PolicyConfiguration.xml“
6.2.2.2 Die Konfigurationsdatei ObjectConfiguration
Die Konfigurationsdatei “ObjectConfguration.xml” ist notwendig, um dem
ObjectService mitzuteilen, welche Klassen des Anwendungsprogramms wie geschützt
werden sollen. Unterhalb des Wurzelelements „SecuredClassesList“ können mehrere zu
schützende Klassen aufgeführt werden.
68

Schnittstellen und Konfigurationen
1
2
3
4
5
8
9
12
13
16
17
18
19
20 …
21
22
Abbildung 45: Konfigurationsdatei „ObjectConfiguration.xml“
Jede zu schützende Klasse kann mehrere Objektgruppen umfassen. Objektgruppen
werden verwendet, um Instanzen eines Typs zu gruppieren und um ihnen einen Policy-
Typ zuzuweisen. Eine Objektgruppe hat einen Identifikator, einen Besitzer und eine
initiale Policy Identifikation. Wenn ein neues Objekt erzeugt wird, dann wird eine neue
Policy erzeugt, gemäß den Angaben der zugehörigen initialen Policy. Die Bestimmung
der initialen Policy erfolgt entweder durch explizite Zuweisung durch den Benutzer
oder das System weist eine Standard-Policy zu. Bei der Zuordnung kann die Wahl der
Objektgruppe zur Bestimmung der initialen Policy herangezogen werden.
Im angegebenen Beispiel werden als Gruppeneinteilung für Fahrtenbuch-Einträge
Fahrtentyp-Kategorien verwendet.
Die Konfigurationen können manuell verändert werden. Um sicherzustellen, dass die
entstehenden XML Dokumente der vorgesehenen Struktur entsprechen, kann eine DTD
(Document Type Definition) oder eine Schema Definition verwendet werden. Die
folgende Abbildung zeigt eine DTD zur Überprüfung der Validität der obigen XML
Konfigurationsdatei.
69

Schnittstellen und Konfigurationen
1
4
5
6
8
11 ]>
Abbildung 46: Beispiel für eine DTD zur Überprüfung der Validität der
Konfiguration
6.2.2.3 Die Konfigurationsdatei ActionConfiguration
Die Konfigurationsdatei „ActionConfiguration.xml“ definiert, welche Aktionen durch
Zugriffskontrollprüfungen geschützt werden sollen. Aktionen werden Objekttypen
zugeordnet. Ein Objekttyp kann eine Java Klasse repräsentieren oder auch eine Menge
von Java Klassen. Er besteht aus einer Identifikation „id“, einer Klassenliste „classes“
und aus einer Aktionsliste „Actions“.
1
2 < ObjectTypesList >
3
4
5
6
7
8
14
15 …
16
17
18
Abbildung 47: Konfigurationsdatei „ActionConfiguration.xml“
Eine Aktion hat einen Namen („name“), ein Ziel-Objekt („target“), ein Zugriffsrecht
(„permission“) und eventuell ein Argument („argumentID“), eine Sitzung
(„sessionargument“) und eine Fehlermeldung („errormessage“). Zugriffsrechte können
70

Schnittstellen und Konfigurationen
beliebige Bezeichner sein wie Lesen, Schreiben, Ändern oder Löschen. Wenn in einem
Policy-Eintrag einem Benutzer ein entsprechendes Zugriffsrecht auf das hier als
„target“ deklarierte Element (oder auf alle Elemente) zugewiesen wurde, dann darf er
die Aktion ausführen, andernfalls nicht.
Anhand des Aktions- und des Klassennamens kann zur Laufzeit überprüft werden, ob
die Aktion einer Zugriffskontrollprüfung unterzogen werden soll. Dazu werden im
Aspekt „AbstractAuthorizationAspect“ (siehe Abbildung 27) alle Methodenaufrufe von
Methoden, die in den Klassen der geschützten Pakete definiert sind, mit der Aktion
„isAction(..)“ überprüft (Abbildung 48). Diese Aktion ermittelt mit Hilfe des Aktions-
Dienstes, ob eine entsprechende Aktion als geschützt definiert wurde. Falls dies der Fall
ist, wird die Zugriffsprüfung durchgeführt.
1 public aspect AbstractAuthorizationAspect{
2 …
3 protected static boolean isAction(String name,String typeName)
{
4 ActionService actionservice = ActionService.getInstance();
5 if(actionservice.isAction(name, typeName)) return true;
6 else return false;
7 } …
Abbildung 48: Funktion „isAction“
6.3 Vergleich und Beurteilung
Die Verwendung der Konfiguration ist relativ einfach im Gegensatz zu einem
Application Programming Interface. Die Zielrichtung ist aber eine andere. Während die
Konfiguration primär für die Zusammenstellung und die Definition von Elementen der
Zugriffsverwaltung gedacht ist, hat das Application Programming Interface den Vorteil,
dass man damit die Funktionen der Zugriffskontrolle in der Anwendung aufrufen kann.
Notwendig ist dies z.B., wenn die Benutzerschnittstelle der Zugriffskontrolle in die
Benutzerschnittstelle der Anwendung integriert werden soll. Man kann also sagen, dass
Konfiguration und API nicht als konkurrierende Alternativen, sondern als Ergänzungen
zueinander betrachtet werden müssen.
71

Schlussbetrachtungen
7 Schlussbetrachtungen
7.1 Fazit
In dieser Arbeit wird eine Zugriffskontrolllösung realisiert, die von verschiedenen
Anwendungen genutzt werden kann. Gleichzeitig ist es möglich, die Zugriffskontrolle
in einer Anwendung zu verwenden, ohne dass Änderungen im Programmcode der
Anwendung vorgenommen werden müssen. Die folgende Auflistung fasst die
wichtigsten Schlussfolgerungen zusammen:
1. Mit Hilfe von aspektorientierter Programmierung kann man eine
anwendungsneutrale Zugriffskontrollfunktionalität konzipieren, die von
verschiedenen Anwendungen genutzt werden kann.
2. Anwendungsspezifische Besonderheiten wie die eines Fahrtenbuches können
weitgehend mit Hilfe von Konfigurierung in der Zugriffskontrolle berücksichtigt
werden. Für die Konfiguration eignen sich insbesondere XML-Dokumente.
3. Für die Zugriffskontrollfunktionalität müssen Parameter wie der Benutzer, das
Objekt und die Methode übergeben werden. Diese Parameter können mittels
AOP und dynamischer Querverbindungen abgefragt werden.
4. Die Verwendung des semantischen Datenmodells MIX erleichtert die Übergabe
der für die Zugriffskontrolle benötigten Parameter. Da alle semantischen
Objekte eine Beschreibung, und eine Identifikation besitzen, kann man auf die
Objektidentifikation zugreifen, ohne umfangreiche Anpassungen vornehmen zu
müssen.
5. Dennoch kann es nicht ausgeschlossen werden, dass Anpassungen an der
Zugriffskontrolle vorgenommen werden müssen, da nicht alle Anwendungen
MIX und dieselbe Benutzerverwaltung verwenden. Durch Definition
vorgegebener Methodenrümpfe in der Aspektklasse kann auf die benötigten
Parameter (Benutzer, Methode, Objekte) zugegriffen werden.
6. Da die Prüfung aller Anwendungsklassen zu erheblichen Leistungseinbusen
führen kann, sollten die zu prüfenden Klassen explizit im Aspekt aufgeführt
werden.
72

Schlussbetrachtungen
7.2 Zusammenfassung der Beiträge
Im Rahmen dieser Arbeit wurde eine Zugriffskontrolle realisiert, die die erörterten Ziele
und die aufgeführten Schlussfolgerungen verdeutlichen soll. Im Einzelnen wurden
folgende Ergebnisse erzielt:
1. Es wurde eine Sicherheitsanalyse für Fahrtenbücher erstellt, die zeigt, welche
speziellen Sicherheitsanforderungen ein Fahrtenbuch aus Sicht der Benutzer, aus
Sicht der Hersteller und aus Sicht des Finanzamts erfüllen muss. Diese Analyse
dient zur Überprüfung, ob alle Anforderungen an eine Zugriffskontrolle mit
dieser Sicherheitslösung realisierbar sind.
2. Außerdem wurde ein Aspekt entwickelt, der die Anforderungen einer
Zugriffskontrolle zusammenfasst und der mit Hilfe einer Konfigurationsdatei
verschiedene Sicherheitslösungen einbinden kann.
3. Als Beispiel für eine Zugriffskontrolle wurde ein policy-basiertes
Zugriffskontrollsystem entwickelt, das Zugriffsregeln in einer XML-Datenbank
in Form von Policy-Dateien speichert und das das MIX Datenmodell verwendet.
7.3 Ausblick
Obwohl gezeigt wird, dass eine anwendungsunabhängige Zugriffskontrolle möglich ist,
bleiben dennoch einige Fragestellungen offen, die noch zu klären sind:
1. Zum einen ist zu erörtern, ob man den Autorisierungsaspekt so allgemein halten
kann, dass keine programmiersprachlichen Anpassungen mehr notwendig sind
und dennoch keine Leistungseinbusen entstehen. Hierzu wäre es in AspectJ
notwendig, „Type Patterns“, die in Aspekten zur Deklaration von Klassen und
Methoden verwendet werden, auch dynamisch anlegen zu können. Dies ist in
der aktuellen Version aber nur zur Übersetzungszeit möglich.
2. Eine weitere offene Problemstellung ist die Frage, wie man in einem
unbekannten Programmcode geeignete Methoden und Klassen für die
Zugriffskontrolle identifizieren kann. Ferner ist zu klären, ob es einem
Anwender, der diese Sicherheitslösung nutzen möchte, möglich ist, hiermit ein
Programm zu schützen.
3. Um eine praxistaugliche Sicherheitslösung für ein Fahrtenbuch zu erhalten,
müsste dieser Prototyp noch um Funktionen zur Verschlüsselung von Daten und
73

Schlussbetrachtungen
zum Signieren von Fahrtenbucheinträgen erweitert werden, was jedoch
außerhalb der Zielsetzung dieser Arbeit lag.
4. Außerdem müssten im Falle einer Zugriffsverweigerung Ausnahmen an das
Anwendungsprogramm zurückgegeben werden, so dass dieses selbst festlegen
kann, was im Falle einer Zugriffsverweigerung geschehen soll. Nur so ist es
möglich, eine Ausgabe der Fehlermeldung in einer für das Anwendungsprogramm
geeigneten Weise (z.B. in einfacher Shell oder im GUI der
Anwendung) zu erreichen.
5. Ferner wäre es möglich, diese Sicherheitslösung um zusätzliche Aspekte (im
Sinne der besprochenen Aspektorientierung) zu erweitern. Im Folgenden werden
die wichtigsten Sicherheitsfunktionen angesprochen, die man mittels Aspekten
realisieren könnte:
• Unter Auditing versteht man die Protokollierung aller Zugriffe. Da diese
über den gesamten Code verstreut sind und da man in der Regel vor allem
die geschützten Zugriffe protokolliert, würde sich eine kombinierte Lösung
zusammen mit dem Autorisierungsaspekt anbieten.
• Auch die Authentifizierung und das Sitzungsmanagement könnten in Form
eines Aspektes realisiert werden. Sitzungen werden in den meisten
Anwendungsmethoden verwendet, obwohl die Sitzungsverwaltung nicht die
Hauptaufgabe dieser Methoden ist.
74

Literaturverzeichnis
Literaturverzeichnis
[ApaoJ]
[Asp02]
[Bal99]
[BfF95]
The Apache Software Foundation (o.J.): Apache Tomcat.
Siehe http://jakarta.apache.org/tomcat/, letzter Zugriff 10.07.2003.
AspectJ TM (2002): AspectJ TM Documentation and Examples: Version
1.0.6 released on July 24, 2002. Siehe http://aspectj.org, letzter
Zugriff 07.07.2003.
Balzert, H. (1999): Lehrbuch der Objektmodellierung: Analyse und
Entwurf. Spektrum Akademischer Verlag, Heidelberg.
Bundesministerium für Finanzen (1995): Grundsätze
ordnungsmäßiger DV-gestützter Buchführungssysteme (GoBS). TOP
7 der Sitzung Bp II/95; mein Schreiben vom 28. Juli 1995 –IV A 8 –
S-0316 – 43/95 -.
[BHH01] Burkhardt, J., Henn, H., Hepper, S., Rindtorff, K. und Schäck, T.
(2001): Pervasive Computing: Technologien und Architektur mobiler
Internet-Anwendungen. Addison-Wesley Verlag, München.
[BoP02]
[Bor98]
[Bor99]
[CHB02]
[CiB02]
[CiH02]
Bouganim, L. und Pucheral, P. (2002): Chip Secured Data Access:
Confidential Data on Untrusted Servers. Proceedings of the 28 th
VLDB Conference, Hong Kong, China.
Bornhövd, C. (1998): MIX – A Representation Model for the
Integration of Web-based Data. Tech. Rep. DVS98-1, DVS1, Dep.
CS, Darmstadt University of Technology, Germany, Nov. 1998.
Bornhövd, C. (1999): Semantic Metadata for the Integration of Webbased
Data for Electronic Commerce. Proc. Of the International
Workshop on Advance Issues of Ecommerce and Web-based
Information System, Santa Clara, USA, 1999.
Cilia, M., Hasselmeyer, P. und Buchmann A. P. (2002): Profiling
and Internet Connectivity in Automotive Environments. In
Proceedings of the International Conference on Very Large Data
Bases (VLDB’02) (Hong-Kong, China, Aug. 2002), S. 1071–1074.
Morgan-Kaufmann.
Cilia, M. und Buchmann A. P. (2002): An Active Functionality
Service for E-Business Applictions. ACM SIGMOD Record 31, 1
(March), 24–30. Special Section on Data Management Issues in
Electronic Commerce.
Cilia, M. und Hasselmeyer, P. (2002): An Architecture for the
Delivery of Services in an Automotive Environment.
I

Literaturverzeichnis
[CSI01]
Computer Security Institut (CSI) (2001): CSI/FBI Survey.
www.gocsi.com/forms/fbi/pdf.html, letzter Zugriff 05.04.2003.
[DaB99] Datenschutz Berlin (1999): Jahresbericht 1999
des Berliner Beauftragten für Datenschutz und Akteneinsicht. Siehe
http://www.datenschutz-berlin.de/jahresbe/99/jb99-4_3.htm, letzter
Zugriff 24.05.2003.
[DBS02] Damianou, N., Bandara, A. K., Sloman, M. und Lupu, E. C. (2002):
A Survey of Policy Specification Approaches. Siehe
http://citeseer.nj.nec.com/damianou02survey.html, letzter Zugriff
10.07.2003.
[Dom01]
Dominick, L. (2001): Was bringen AOP und GP für die Industrie.
Siehe
http://net.objectdays.org/pdf/01/papers/ind_invited/dominick.pdf,
letzter Zugriff 10.07.2003.
[EbF00] Eberhardt, A. und Fischer, S. (2000): Java-Bausteine für E-
Commerce-Anwendungen: Verteilte Anwendungen mit Servlets,
CORBA und XML. Carl Hanser Verlag, München.
[Eck01]
[FBK99]
[Fin02]
[Fis02]
[FSG01]
[GaW02]
[Gol99]
[GoM02]
Eckert, C. (2001): IT-Sicherheit, Konzepte, Verfahren, Protokolle.
Oldenbourg Verlag, München.
Ferraiolo, D., Barkley, J. und Kuhn, R. (1999): A Role Based Access
Control Model and Reference Implementation within a Corporate
Intranet. ACM Trans. Inf. Syst. Sec. 2, 1.
Finanzgericht Baden-Württemberg (2002): Anerkennung eines
elektronischen Fahrtenbuchs. Siehe
http://www.profpopp.de/content/beratungsbrief/volltext/0601.htm#37
-02, letzter Zugriff 29.04.03.
Fischer, M. (2002): Konzeption und Implementierung eines
rollenbasierten Zugriffskontrollmodells für das Webrocat-System.
Diplomarbeit im Fachbereich Wirschaftswissenschaften der
Universität Gesamthochschule Essen.
Ferraiolo, Sandhu, Gavrila, Kuhn, Chandramouli (2001): Proposed
NIST Standard for Role-Based Access Control. ACM Transactions
on Information and System Security, Vol. 4, No. 3, August 2001, S.
224–274.
Gabrick, K. A. und Weiss, D. B. (2002): J2EE and XML
Development. Manning Publications Co., Greenwich (USA).
Gollmann, D. (1999): Computer Security. John Wiley & Sons, New
York.
Gollan, L. und Meinel C. (2002): Digitale Signaturen für
II

Literaturverzeichnis
Kraftfahrzeuge. Siehe http://www.ti.fhg.de/publikationen/technische
berichte/2002/prep0204.pdf, letzter Zugriff 24.04.2003.
[HHI02] Hilsdale, E., Hugunin, J., Isberg, W., Kiczales, G. und Kersten, M.
(2002): Aspect-Oriented Programming with AspectJ TM .” Siehe
http://aspectj.org, letzter Zugriff 07.07.2003.
[Hob98]
[IbNoJ]
[IfT02a]
[IfT02b]
[ITOoJ]
[Jae98]
[KHH01]
[Koc98]
[Kor03]
[Lad03]
Hobert, G. (1998): Datenschutz und Datensicherheit im Internet:
Interdependenzen und Korrelation von rechtlichen Grundlagen und
technischen Möglichkeiten. Dissertation, Frankfurt am Main: Lang.
Ingenieurbüro Nürnberg (o.J.): TravelControl: das automatisierte
elektronische Fahrtenbuch mit GPS-Ortung. Siehe http://www.ibnuernberg.de/,
letzter Zugriff 10.05.2003.
Institut für Telematik Trier (2002): GPS-unterstütztes Fahrtenbuch
für PalmOS–Handhelds. Siehe http://www.ti.fhg.de/
profil_und_kontakt/info-material/Fahrtenbuch.pdf, letzter Zugriff
10.05.2003.
Institut für Telematik Trier (2002): CeBIT: Lästige
Fahrtenbuchführung erledigt Handheld-Computer mit
Satellitendaten automatisch. Siehe “www.ti.fhg.de/
presse_und_medien/pressemitteilungen/2002/pm04_Cebit2002.html,
letzter Zugriff 10.05.2003.
IT Transfer Office (o.J.): Siehe http://www.ito.tu-darmstadt.de,
letzter Zugriff 07.07.2003.
Jaeger, S.(1998): Computerkriminalität. Augsburg: Interest Verlag,
1998, ISBN 3-8245-0700-5.
Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J. und
Griswold, W. G. (2001): An Overview of AspectJ. Lecture Notes in
Computer Science, Vol. 2072, S. 327-355. Siehe
http://citeseer.nj.nec.com/kiczales01overview.html, letzter Zugriff
10.07.2003.
Koch, F. A. (1998): Internet-Recht: Praxishandbuch; mit den neuen
Medien- und Teledienstrecht, Checklisten und Mustervertäge.
Oldenburg Verlag, München.
Korn, C. (2003): Entwurf und Implementierung eines anpassbaren
Fahrtenbuch-Dienstes für Gruppen. Diplomarbeit am IT Transfer
Office.
Laddad, R. (2003): AspectJ in Action: Practical Aspect-Oriented
Programming. Siehe
http://www.theserverside.com/resources/AspectJreview.jsp, letzter
Zugriff 15.06.2003.
III

Literaturverzeichnis
[LMY01]
[Mag01]
[Mei02]
[Mei03]
[Myn00]
[NEV01]
[Non00]
[Nor01]
[OAS01]
[OAS03]
[Oat00]
[OatoJ]
López, J., Maña, A. und Yagüe, M. I. (2001): XML-based Distributed
Access Control System. Siehe http://citeseer.nj.nec.com/530344.html,
letzter Zugriff 15.06.2003.
Magnatec (2001): Elektronisches Fahrtenbuch
Car Organizer 1, 1+ und Car Organizer 2. Siehe
http://www.magnatec.de/MDT_1%2B2d.html, letzter Zugriff
10.05.2003.
Meier, W. (2002): eXist: An Open Source Native XML Database.
Siehe http://citeseer.nj.nec.com/551828.html, letzter Zugriff
07.07.2003.
Meier, Wolfgang M. (2003): eXist: Open Source XML Database.
Siehe http://exist-db.org/index.xml, letzter Zugriff 07.07.2003.
Mynttinen, J. (2000): End-to-end security of mobile data in GSM.
Siehe www.citeseer.nj.nec.com/mynttinen00endtoend.html, letzter
Zugriff 29.04.2003.
NEVE Technologies (2001): “GPSi Dead Reckoning White Paper:
Product Overview” www.neve.com.au/downloads/GPSi-WhitePaper-
1-0.pdf, letzter Zugriff 04.02.03.
Nano online (2000): Freudiges Fahren per Fingerabdruck:
Fraunhofer-Institut entwickelt Sicherheitsstarten. Siehe
http://www.3sat.de/3sat.php?http://www.3sat.de/nano/tipps/13195/,
letzter Zugriff 10.05.2003.
NorCom (2001): Internet Resource Access Control: The Butterfly
Model. Siehe http://www.norcom.de/downloads/whitepaper/
WP_Butterfly_Model_010315.pdf, letzter Zugriff 15.06.2003.
OASIS (2001): Oasis Security Services Use Cases And
Requirements. Siehe http://unique.outlook.net/~evan/a2mluc/
usecases-strawman-2.html, letzter Zugriff 15.06.2003.
OASIS (2003): OASIS eXtensible Access Control Markup Language
TC. Siehe http://www.oasis-open.org/committees/
tc_home.php?wg_abbrev=xacml, letzter Zugriff 07.07.2003.
Ohne Autor (2000): Fahrtenbuch von Berufsgeheimnisträgern. Siehe
http://www.stb-web.de/fachartikel/steuerrecht/article.php/id/153,
letzter Zugriff 05.04.2003.
Ohne Autor (Ohne Jahr): Fragen rund um das Fahrtenbuch. Siehe
http://www.drivelog.com/faq.htm, letzter Zugriff 07.07.2003.
[OhmoJ] Autohaus Ohms (o.J.): Kurz und knapp, was ist OnStar C@rWeb ?
Siehe http://www.ohms.de/CarWeb/kurz_und_knapp.htm, letzter
Zugriff 07.07.2003.
IV

Literaturverzeichnis
[OnSoJ] OnStar (o.J.): http://www.onstar.de, letzter Zugriff 07.07.2003.
[Sch96]
[SUN01]
[SysoJ]
[Tan95]
[W3C99]
Schneier, B. (1996): Applied Crytography: Protocols, Algorithms,
and Source Code in C. John Wiley & Sons, Inc.
Sun (2001): JavaTM Authentication and Authorization Service
(JAAS) 1.0: Developer’s Guide. Siehe
http://java.sun.com/security/jaas/doc/api.html, letzter Zugriff
07.07.2003.
Systramatic (o.J.): MILLIONEN FAHRZEUGNUTZER ZAHLEN ZU
VIEL STEUERN. Siehe
http://www.oscar200.de/anwendungen/fahrtenbuch/index.html,
letzter Zugriff 07.07.2003.
Tanenbaum, A. S. (1995): Moderne Betriebssysteme. Carl Hanser
Verlag, München.
Worldwide Web Consortium (1999): XML Path Language (Xpath)
Version 1.0: W3C Recommendation 16. November 1999. Siehe
http://www.w3c.org/TR/xpath, letzter Zugriff 07.07.2003.
V