Typographische Konventionen

In dieser Arbeit werden die folgenden typographischen Notationen verwendet.

Für Programm-Code wird eine dicktengleiche Schreibmaschinenschrift genutzt. class Role < ActiveRecord::Base

has_many :users

validates_presence_of :rolename

validates_uniqueness_of :rolename, :case_sensitive => false

def to_s

rolename end

end

Im laufenden Text wird für Klassen, Attribute und Befehle ebenfalls eine Schreibmaschinenschrift genutzt.

Englische Begriffe, für die es keine geeignete deutsche Entsprechung gibt, und bestimmte Eigennamen sind kursiv dargestellt.

Beim erstmaligen Auftreten einiger technischer Begriffe sind jeweils in einer Fußnote kurze Erklärungen gegeben. Verweise auf Seiten im Internet sind ebenfalls in Fußnoten vermerkt.

Zitate und Verweise in das Literaturverzeichnis (z. B. siehe (Thomas u. Heinemeier Hansson 2006, S. 158ff.)) genügen der DIN 1505 und haben die Form Verfasser (Jahr) oder (Verfasser Jahr, Seitenzahl).

Verwendete Abkürzen

API

bspw. bzw.

CRUD Create Read Update Delete

DRY DSL

HTML Hyper Text Markup Language MVC Model View Controller RBAC Role Based Access Control REST Representational State Transfer S. Seite

s. o. TZI usw. vgl. z. B.

iv

Danksagung

An dieser Stelle möchte ich einigen Menschen danken, die mich bei dieser Arbeit und während meines Studiums unterstützt haben.

Ich danke Herrn Prof. Dr. Ing. Carsten Bormann für die Möglichkeit diese Arbeit durchführen zu können und für die sehr lehrreichen und erbaulichen Seminare in der Vergangenheit. Seine zahlreichen Anmerkungen im Verlauf der Arbeit waren sehr hilfreich.

Herrn Dipl. Inf. Steffen Bartsch danke ich für die angenehme Zusammenarbeit und die Möglichkeit unter seiner Anleitung dieses Thema in Angriff zu nehmen. Er stand mir soweit möglich jederzeit für Fragen zur Verfügung und äußerte seinen fachlichen Rat stets ruhig und kritisch. Herrn Dr. Karsten Sohr danke ich für die schnell erteilte Zusage, das Zweitgutachten dieser Arbeit zu übernehmen.

Ein großer Dank gebührt auch Frau Alica Schulz für die großartige Unterstützung während der letzten Monate meines Studiums. Sie war stets für mich da und mir damit eine große Stütze.

Ebenso danke ich allen meinen Freunden für die nette Zeit und die Unterstützung während meines Studiums und insbesondere während der Anfertigung dieser Arbeit. Ein Dank gebührt ebenfalls meinen Kameraden bei der Freiwilligen Feuerwehr Etelsen, die Zeit meines Lebens für eine sinnvolle Freizeitbeschäftigung und Ausgleich sorgten.

Ich danke weiterhin Herrn Marcus Gagelmann und Herrn Marc Schröder für die kritische Auseinandersetzung mit der neuen Deutschen Rechtschreibung. Sie ermöglichten das Anfertigen eines weitestgehend fehlerfreien Textes. Noch vorhandene Fehler sind mir anzurechnen. Den Herren Andreas und Hans-Joachim Müller danke ich für die Beratung in Fragen der Typographie.

Ein großer abschließender Dank gilt meinen Eltern, Herrn Dipl. Ing. Manfred Kohlmann und Frau Renate Kohlmann, die mich während meines gesamten bisherigen Lebens jederzeit unterstützt und gefördert haben und mir damit ein Leben mit größter Selbstständigkeit ermöglichten. Dies hat mich sehr ge- prägt.

Inhaltsverzeichnis

1  Einleitung  1

1.1  Szenario  2

1.2  Zielsetzung und Anforderungen  3

1.3  Vorgehensweise  4

1.4  Gliederung der Arbeit  5

2  Grundlagen  7

2.1  Gängige Konzepte zur Umsetzung von Web-Anwendungen  8

2.2  Informationssicherheit im Umfeld des Internets  9

2.2.1  Notwendigkeit von Informationssicherheit  9

2.2.2  Rollenbasierte Zugriffskontrolle und das Bell-LaPadula-  

Modell   10

2.2.3  Versteckte Kanäle  11

2.2.4  Mehrfache Instanziierung  12

2.3  Kompartmentalisierung  14

2.3.1  Die Umsetzung der Kompartmentalisierung in der An-  

wendung  Plusquam  15

2.4  Fazit  18

3  Kompartmentalisierung für das Bugtracking  19

3.1  Projektmanagement und Bugtracking  19

3.1.1  Benutzerverwaltung  21

3.1.2  Projektverwaltung  22

3.1.3  Tickets  22

3.2  yats - Yet Another Ticketing System  23

3.2.1  Entwurf und Abbildung der Datenbank  23

3.2.1.1  Klassenübergreifende Attribute  23

3.2.1.2  Die Klasse Project  25

3.2.1.3  Die Klasse Issue  25

3.2.1.4  Die Klasse User und ihr beigeordnete Klassen  26

3.2.1.5  Die Klasse Enumeration  28

3.2.1.6  Die Klasse Tracker  28

3.2.1.7  Die Klasse Role  29

3.2.2  Abbildung der Anwendungslogik  30

3.2.2.1  Allgemeines  30

3.2.2.2  Benutzerverwaltung  30

3.2.2.3  Projektverwaltung  32

3.2.2.4  Tickets  33

3.2.2.5  Umsetzung einer Suchfunktion  33

vi  Inhaltsverzeichnis  

3.3  Integration der Kompartmentalisierung in den Bugtracker  34

3.3.1  Vorbereitung des yats-Entwurfes zur Integration  34

3.3.1.1  Bereitstellung eines Mechanismus’ zur Authen-  

ti  fizierung  35

3.3.1.2  Bereitstellung eines Modells für Benutzerrollen  35

3.3.1.3  Anpassung der Modelle und Controller  35

3.3.1.4  Das Berechtigungsmodell für yats  36

3.3.2  Bestimmung der Modelle zur Formung eines Kompart-  

ments   37

3.3.3  Umsetzung der Kompartmentalisierung in yats  38

3.3.4  Entwicklung einer Policy zur Synchronisierung  40

3.4  Fazit  42

4  Evaluation  45

4.1  Vorgehen bei den automatisierten Tests  45

4.2  Entwicklung der Testdaten  46

4.2.1  Testdaten für Benutzer  47

4.2.2  Testdaten für Projekte und deren Mitglieder  48

4.2.3  Testdaten für Tickets  48

4.3  Hilfsmethoden für alle Testfälle  49

4.4  Testfälle für die Kompartmentalisierung in den Modellen  50

4.5  Test der Anwendungslogik  52

4.6  Test des SynchronizationController  54

4.7  Test der Synchronisierung  56

4.8  Bewertung der Synchronisierungs-Funktion  58

4.8.1  Synchronisierung über Benutzer-Berechtigungen  59

4.8.2  Konfliktlösungsstrategien  60

4.9  Abgrenzung zu verwandten Arbeiten  62

4.10  Fazit  65

5  Ergebnis und Ausblick  67

A  Installation von yats  71

A.1  Systemvoraussetzungen  71

A.2  Einrichten einer yats-Instanz  71

B  Das Berechtigungsmodell für yats  73

Literaturverzeichnis   75

Abbildungsverzeichnis   

1.1  Projektmanagement durch konkurrierende Dienstleister  3

2.1  Informationsfluss im Bell-LaPadula-Modell  10

2.2  Multilaterale Sicherheitsmodelle  14

2.3  Synchronisierung zwischen zwei Kompartments  16

3.1  Klassenentwurf: Gesamtsystem  24

3.2  Klassenentwurf: Project  25

3.3  Klassenentwurf: Issue  26

3.4  Klassenentwurf: User  27

3.5  Klassenentwurf: Enumeration  28

3.6  Klassenentwurf: Tracker  29

3.7  Klassenentwurf: Role  29

3.8  Anwendungsfälle: Benutzerverwaltung  30

3.9  Anwendungsfälle: Projektverwaltung  32

3.10  Anwendungsfälle: Ticketverwaltung  33

4.1  Testdaten: Benutzer  47

4.2  Testdaten: Projekte  48

4.3  Testdaten: Tickets  49

4.4  Verschmelzen von Datensätzen  61

Tabellenverzeichnis   

2.1  Datensatzbezogene Polyinstanziierung  13

2.2  Attributbezogene Polyinstanziierung  13

2.3  Polyinstanziierung mit datensatzbezogener Freigabestufe  13

3.1  Berechtigungsmodell für yats  37

1. Einleitung

In Zeiten des „Web 2.0“ ist es für Unternehmen und öffentlichen Einrichtungen immer einfacher geworden, große Mengen privater oder anderweitig sensibler Daten anzusammeln. Bekannte Beispiele für solche Datensammlungen sind die gerade enorm wachsenden sozialen Netzwerke wie facebook oder Dienstleistungsangebote wie Google Documents. Zusätzlich lagern viele Unternehmen ihre Daten in das Netz aus und beauftragen Dienstleister mit darauf aufbauenden Geschäftsprozessen.

Viele dieser zentral gespeicherten Daten sind also einem großen Personenkreis zugänglich. Der Schutz der Daten erhält daher einen immer höheren Stellenwert. Die Daten praktisch unter Verschluss zu halten ist allerdings keine Lösung. Ohne Zugriffsmöglichkeit sind Anwendungen (z. B. ein soziales Netzwerk) nicht umsetzbar. Der Zugriff muss also auf geregelte Art und Weise erfolgen können (siehe Anderson (2008) S. 275ff.).

Wie Anderson ausführt, ist eine zentrale Eigenschaft solcher Systeme die genau kontrollierte Zugriffsmöglichkeit der einzelnen Benutzer auf den gemeinsamen Datenbestand. Ein weit verbreiteter Ansatz ist hier die Nutzung eines rollenbasierten Systems, wie es z. B. in allen gängigen Foren oder Wikis zum Einsatz kommt (Role Based Access Control (RBAC)). In staatlichen Einrichtungen wird vielfach auch das Bell-LaPadula-Modell als Möglichkeit von aufeinander aufbauenden Freigabestufen eingesetzt (siehe Anderson (2008) S. 239ff.).

Die beiden genannten Ansätze verhindern den Fluss der Daten nach unten in der Hierarchie. Daher werden sie auch als multi level security bezeichnet. Oftmals ist es auch notwendig, den Fluss von Daten auf einer Hierarchieebene zu unterbinden. Dies ist mit den genannten Ansätzen nicht möglich.

2 1. Einleitung

Für eine horizontal ausgerichtete Zugriffskontrolle (multilaterale Sicherheit), welche den Fluss der Daten auch auf einer Hierarchieebene kontrolliert, sind mehrere Ansätze denkbar. Ein aus dem Bereich der Nachrichtendienste stammendes Konzept, welches dort seit Jahren zur Anwendung kommt, ist die Kompartmentalisierung der Daten. Auch für den Bereich des Internets sind Anwendungsfälle denkbar, die dieses Konzept nutzbringend einsetzen können. Ein mögliches Szenario wird im folgenden Abschnitt dargestellt.

1.1 Szenario

Es werden immer mehr Unternehmen dazu veranlasst, Geschäftsprozesse auszugliedern (Outsourcing ¹ ). Ein Unternehmenszweig, der immer häufiger an Dienstleister vergeben wird, ist die Qualitätssicherung. Bekannte Beispiele sind hier die Unternehmen der Automobil- oder Nahrungsmittelindustrie, die ihre Produkte von Fremdfirmen auf die Einhaltung eines hohen Qua-litätsstandards hin untersuchen lassen.

Auch Software-Produzenten betreiben selbstverständlich Qualitätssicherung an ihren Produkten. Dazu werden etablierte Werkzeuge des Projektmanagements eingesetzt, welche auf Grund der fortschreitenden Entwicklung im Umfeld des Internets leicht über dieses betrieben werden können. Eine Vorreiterrolle kommt hier sicherlich der Open-Source-Gemeinschaft zu, die seit Jahren erfolgreich solche Werkzeuge über das Internet einsetzt.

Sobald ein Software-Produzent die eigene Qualitätssicherung ausgliedert, hat er im Gegensatz zu der Open-Source-Gemeinschaft weitere Vorkehrungen zu treffen. Da er den beauftragten Dienstleistern unternehmensinterne Daten zur Verfügung stellt, muss er ein großes Augenmerk auf die Informationssicherheit und die Zugriffskontrolle richten.

Insbesondere sobald mehrere Unternehmen dieselbe Dienstleistung erbringen sollen, ist die Zugriffskontrolle nicht mehr trivial. Da es sich bei den beauftragten Unternehmen um Mitbewerber handelt, stehen diese in einer Konkurrenzsituation zueinander. Außerdem hat - neben dem beauftragenden Unternehmen - jeder Dienstleister eigene Sicherheitsrichtlinien, die umgesetzt werden sollten. Im Interesse des beauftragenden Unternehmens steht dabei allerdings die Durchsetzung der eigenen Vorgaben zur Informationssicherheit.

¹ Mit Outsourcing wird die Ausgliederung oder Abgabe von Unternehmensaufgaben an Dienstleister bezeichnet. Verträge legen dabei Dauer und Umfang der zu erbringenden Leis- tung fest.

1.2. Zielsetzung und Anforderungen 3

Abbildung 1.1: Ein Software-Produzent stellt ein Projektmanagement-System bereit, mit

Dessen ungeachtet sollen die Dienstleister auf einer gemeinsamen Plattform arbeiten. Dieses ermöglicht erst die kontrollierte Aggregation der Daten und somit eine Zusammenarbeit zwischen den Dienstleistern.

Es ist nun das folgende in Abbildung 1.1 gezeigte Szenario denkbar: Ein Software-Produzent beauftragt mehrere Dienstleister mit der Qualitätssicherung seiner Produkte. Diese erhalten dazu über das Internet Zugang zu einem Projektmanagement-System, welches der Software-Produzent betreibt. Die Grundlage dieses Systems bildet eine Datenbank, auf welcher die Dienstleister gemeinsam arbeiten sollen.

Hier ist nun zu beachten, dass der Software-Produzent die Möglichkeit besitzen muss die durch ihn vorgegebenen Sicherheitsrichtlinien durchzusetzen. Trotzdem muss eine Zusammenführung der Daten erfolgen können, damit eine Zusammenarbeit zwischen den einzelnen Beteiligten möglich ist.

1.2 Zielsetzung und Anforderungen

Wie im oben beschriebenen Szenario erwähnt, sind Anwendungsfälle für Web-Anwendungen denkbar, die ein solches Sicherheitskonzept umsetzen. Dieser Bachelor-Report soll aufzeigen, dass eine bestehende Web-Anwendung um Kompartmentalisierungs-Techniken erweitert werden kann und sich damit eine sinnvoll einsetzbare Anwendung ergibt. Die Grundlage dazu bildet das oben beschriebene Szenario, in welchem ein Projektmanagement-System ein- gesetzt wird.

4 1. Einleitung

Die in der Arbeitsgruppe Rechnernetze am Technologie-Zentrum Informatik (TZI) ² entwickelte Anwendung Plusquam verwendet bereits das Konzept der Kompartmentalisierung im Rahmen eines ähnlichen Anwendungsfalles. ³ Das entsprechende Modul soll aus dieser Anwendung herausgelöst und in ein Projektmanagement-System integriert werden.

Bei der Integration des Kompartmentalisierungs-Moduls wird Wert auf die Dokumentation der dafür notwendigen Schritte und Anpassungen des Projektmanagement-Systems gelegt. Bei diesem Schritt auftretende Schwierigkeiten sollen ebenfalls dokumentiert werden.

Nach erfolgter Integration soll anhand einiger beispielhafter Anwendungsfälle überprüft werden, ob in einer solchen Web-Anwendung das Konzept der Kompartmentalisierung sinnvoll eingesetzt werden kann. Die Grundlage für diese Testfälle bildet ebenfalls das oben dargestellte Szenario.

1.3 Vorgehensweise

Zur Umsetzung der beschriebenen Ziele ist es zuerst einmal erforderlich, dass ein Projektmanagement-System zur Verfügung steht, welches um die entsprechende Funktionalität erweitert werden kann. Diese Arbeit soll nur exemplarisch aufzeigen, dass eine Integration von Kompartmentalisierungs-Techniken in eine bestehende Web-Anwendung möglich ist. Da bestehende Projektmanagement-Systeme ausnahmslos einen sehr großen Funktionsumfang und damit einhergehend eine hohe Komplexität besitzen (vgl. dazu das Produkt Redmine ⁴ ), wird in einem ersten Schritt eine eigene Anwendung mit eingeschränktem Funktionsumfang entwickelt.

Bedingt durch die einfach gehaltene Architektur dieses Projektmanagement-Systems wird eine schnelle Integration des Kompartmentalisierungs-Moduls angestrebt. Die zur Integration notwendigen Anpassungen an dem Projektmanagement-System werden dabei gesondert dokumentiert.

Nach erfolgter Integration wird anhand einiger Anwendungsfälle die Einsetzbarkeit des Gesamt-Systems für das in Abschnitt 1.1 dargestellte Szenario überprüft. Die Anwendungsfälle werden dabei mittels Unit- und Functional- Testsabgebildet.

² Die Internetpräsenz des TZI kann unter http://www.tzi.de eingesehen werden.

³ Siehe http://ag-ki.tzi.de/index.php?id=575&ids=825 für eine kurze Projektbeschreibung.

⁴ Siehe http://www.redmine.org

1.4. Gliederung der Arbeit 5

1.4 Gliederung der Arbeit

In Kapitel 2 werden die Grundlagen dieser Arbeit behandelt. Neben einer kurzen Einführung in die gängigen Konzepte bei der Umsetzung von Web-Anwendungen findet sich dort eine Abhandlung zur Informationssicherheit und Zugriffskontrolle im Umfeld des Internets. Insbesondere wird dort auch die Kompartmentalisierung von Daten behandelt und in einen Kontext mit den heute gängigen Ansätzen gesetzt. Dort findet sich ebenfalls eine Beschreibung der Kompartmentalisierungs-Funktion in der oben genannten Anwendung Plusquam.

Im daran anschließenden Kapitel 3 wird zunächst eine kurze Einführung in den Begriff des Projektmanagement gegeben und eine Abgrenzung gegenüber dem Begriff des Bugtracking vorgenommen. Daran anschließend wird das zur Umsetzung der in Abschnitt 1.2 beschriebenen Ziele eingesetzte Bugtracking-System erläutert. Darauf aufbauend werden im folgenden Abschnitt die zur Integration des Kompartmentalisierungs-Moduls notwendigen Erweiterungen in der Systemarchitektur dargestellt und erläutert.

Eine Evaluation des in Kapitel 3 entwickelten Systems im Hinblick auf die Umsetzbarkeit des oben beschriebenen Szenarios findet sich in Kapitel 4. Dort wird durch automatisierte Tests nachgewiesen und dokumentiert, dass eine Erweiterung von Projektmanagement-Systemen und insbesondere auch Bugtracking-Systemen durch Kompartmentalisierung sinnvoll sein kann.

Weiterhin wird dort das zum Einsatz kommende Kompartmentalisierungs-Modul bewertet und Anregungen für eine mögliche Weiterentwicklung gegeben. Abschließend findet in diesem Kapitel eine Abgrenzung zu verwandten Arbeiten statt.

In Kapitel 5 wird schließlich das Ergebnis dieser Arbeit zusammenfassend dargestellt. Daneben enthält dieses Kapitel auch einen Ausblick auf weitere denkbare Anwendungsfälle und Anregungen für weitere Untersuchungen.

In den Anhängen finden sich Systemvoraussetzungen für die Installation des in dieser Arbeit entwickelten Gesamtsystems und Bedienungshinweise für dieses.

2. Grundlagen

In diesem Kapitel werden die Grundlagen dieser Arbeit skizziert. Zunächst werden in Abschnitt 2.1 kurz einige zum Verständnis der folgenden Kapitel notwendigen Eigenheiten und Konzepte des für die Umsetzung des Szenarios verwendeten Frameworks ¹ Ruby on Rails dargestellt.

Darauf folgt in Abschnitt 2.2 ein Einführung in die Informationssicherheit und die Zugriffskontrolle im Umfeld des Internets. Es wird dort kurz die gängige Praxis zur Informationssicherheit im Internet anhand zweier gängiger Ansätze (die rollenbasierte Zugriffskontrolle und das Bell-LaPadula-Modell) erläutert. In diesem Abschnitt werden auch die Konzepte der „versteckten Kanäle“ und der Polyinstanziierung aufgegriffen und in einen Zusammenhang mit den erläuterten Sicherheitsmodellen gebracht.

Abschließend findet sich in Abschnitt 2.3 eine Einführung in das Konzept der Kompartmentalisierung. Hier werden die Charakteristika und Vorteile dieses Sicherheitsmodells besonders im Hinblick auf eine Nutzung in Web-Anwendungen beschrieben.

Dort wird ebenfalls das Kompartmentalisierungs-Modul, welches die Grundlage dieser Arbeit bildet, aus der Anwendung Plusquam erläutert. Dabei werden die Unterschiede zu der in (Anderson 2008, S. 277ff.) dargestellten Kompartmentalisierung herausgestellt und insbesondere die daraus resultierende Synchronisierung zwischen einzelnen Kompartments erläutert.

¹ Programmiergerüst, welches in der Softwareentwicklung Verwendung findet. Bietet Ent- wurfsmuster und Schnittstellen zur Anwendungsprogrammierung.

8 2. Grundlagen

2.1 Gängige Konzepte zur Umsetzung von Web-

Anwendungen

Eine der Grundlagen dieser Arbeit bildet die in der Einleitung genannte Web-Anwendung Plusquam. Diese ist mittels des auf der Sprache Ruby ² basierenden Frameworks Ruby on Rails oder kurz Rails ³ entwickelt. Einen guten Einblick in Ruby bzw. Rails geben Thomas u. a. (2006) und Thomas u. Heinemeier Hansson (2006).

Der Entwurf jeder Anwendung wird auch durch die zum Einsatz kommende Programmiersprache und ganz besonders durch in dieser umgesetzte Paradigmen beeinflusst. Rails wird deshalb so häufig eingesetzt, weil die darin enthaltenen Konzepte eine agile Entwicklung und Umsetzung von Anwendungen ermöglichen. Die Konzepte, welche unmittelbaren Einfluss auf den in Kapitel 3 dargestellten Anwendungsentwurf haben, werden an dieser Stelle erläutert.

Besonders kennzeichnend für Rails ist das sogenannte MVC-Konzept. MVC steht hierbei für Model-View-Controller. Dabei handelt es sich um eine aus den 1970 stammende Software-Architektur (näheres dazu siehe in Reenskaug (1979)). Die Motivation und die Eigenheiten dieses Konzeptes erfahren hier keine weitere Behandlung. In Ermangelung einprägsamer deutscher Begriffe werden die einzelnen Module des MVC-Konzeptes im Folgenden mittels ihrer englischsprachigen Entsprechungen benannt und jeweils kursiv dargestellt (Model, View, Controller).

Diesem Konzept folgend wird in Rails die zugrunde liegende Datenbank über die Models abgebildet. Die Präsentation der Daten und Systemmeldungen übernehmen die Views, die mittels Templates HTML-Quelltext oder andere Ausgabeformate generieren. Die Controller enthalten die Anwendungslogik.

Zwei weitere Konzepte von Rails sind für das Verständnis der folgenden Kapitel hilfreich. Der Idee der convention over configuration folgend stellt Rails bedingt durch die Struktur der zugrunde liegenden Datenbank und einiger Schlüsselwörter allen Klassen automatisch diverse Methoden und Attribute zur Verfügung. Auf diese wird in den Kapiteln 3 und 4 nicht näher eingegangen. Eine genaue Auflistung und Dokumentation ist Thomas u. Heinemeier Hansson (2006) zu entnehmen.

Das zweite Konzept nennt sich CRUD - Create, Read, Update und Delete, zu deutsch Anlegen, Lesen, Aktualisieren und Löschen - und beschreibt damit

² Siehe http://www.ruby-lang.org

³ Siehe http://www.rubyonrails.org