Kompartmentalisierung in Web-Anwendungen am Beispiel eines Projektmanagement-Systems

Inhaltsverzeichnis

1 Einleitung
1.1 Szenario
1.2 Zielsetzung und Anforderungen
1.3 Vorgehensweise
1.4 Gliederung der Arbeit

2 Grundlagen
2.1 Gängige Konzepte zur Umsetzung von Web-Anwendungen
2.2 Informationssicherheit im Umfeld des Internets
2.2.1 Notwendigkeit von Informationssicherheit
2.2.2 Rollenbasierte Zugriffskontrolle und das Bell-LaPadula- Modell
2.2.3 Versteckte Kanäle
2.2.4 Mehrfache Instanziierung
2.3 Kompartmentalisierung
2.3.1 Die Umsetzung der Kompartmentalisierung in der An- wendung Plusquam
2.4 Fazit

3 Kompartmentalisierung für das Bugtracking
3.1 Projektmanagement und Bugtracking
3.1.1 Benutzerverwaltung
3.1.2 Projektverwaltung
3.1.3 Tickets
3.2 yats - Yet Another Ticketing System
3.2.1 Entwurf und Abbildung der Datenbank
3.2.1.1 Klassenübergreifende Attribute
3.2.1.2 Die Klasse Project
3.2.1.3 Die Klasse Issue
3.2.1.4 Die Klasse User und ihr beigeordnete Klassen .
3.2.1.5 Die Klasse Enumeration
3.2.1.6 Die Klasse Tracker
3.2.1.7 Die Klasse Role
3.2.2 Abbildung der Anwendungslogik
3.2.2.1 Allgemeines
3.2.2.2 Benutzerverwaltung
3.2.2.3 Projektverwaltung
3.2.2.4 Tickets
3.2.2.5 Umsetzung einer Suchfunktion
3.3 Integration der Kompartmentalisierung in den Bugtracker . . .
3.3.1 Vorbereitung des yats-Entwurfes zur Integration
3.3.1.1 Bereitstellung eines Mechanismus’ zur Authen- tifizierung
3.3.1.2 Bereitstellung eines Modells für Benutzerrollen
3.3.1.3 Anpassung der Modelle und Controller
3.3.1.4 Das Berechtigungsmodell für yats
3.3.2 Bestimmung der Modelle zur Formung eines Kompart- ments
3.3.3 Umsetzung der Kompartmentalisierung in yats
3.3.4 Entwicklung einer Policy zur Synchronisierung . .
3.4 Fazit

4 Evaluation
4.1 Vorgehen bei den automatisierten Tests
4.2 Entwicklung der Testdaten
4.2.1 Testdaten für Benutzer
4.2.2 Testdaten für Projekte und deren Mitglieder
4.2.3 Testdaten für Tickets
4.3 Hilfsmethoden für alle Testfälle
4.4 Testfälle für die Kompartmentalisierung in den Modellen .
4.5 Test der Anwendungslogik
4.6 Test des SynchronizationController
4.7 Test der Synchronisierung
4.8 Bewertung der Synchronisierungs-Funktion
4.8.1 Synchronisierung über Benutzer-Berechtigungen
4.8.2 Konfliktlösungsstrategien
4.9 Abgrenzung zu verwandten Arbeiten
4.10 Fazit

5 Ergebnis und Ausblick

A Installation von yats

A.1 Systemvoraussetzungen

A.2 Einrichten einer yats-Instanz

B Das Berechtigungsmodell für yats

Literaturverzeichnis

Abbildungsverzeichnis

1.1 Projektmanagement durch konkurrierende Dienstleister

2.1 Informationsfluss im Bell-LaPadula-Modell

2.2 Multilaterale Sicherheitsmodelle

2.3 Synchronisierung zwischen zwei Kompartments

3.1 Klassenentwurf: Gesamtsystem

3.2 Klassenentwurf: Project

3.3 Klassenentwurf: Issue

3.4 Klassenentwurf: User

3.5 Klassenentwurf: Enumeration

3.6 Klassenentwurf: Tracker

3.7 Klassenentwurf: Role

3.8 Anwendungsfälle: Benutzerverwaltung

3.9 Anwendungsfälle: Projektverwaltung

3.10 Anwendungsfälle: Ticketverwaltung

4.1 Testdaten: Benutzer

4.2 Testdaten: Projekte

4.3 Testdaten: Tickets

4.4 Verschmelzen von Datensätzen

Tabellenverzeichnis

2.1 Datensatzbezogene Polyinstanziierung

2.2 Attributbezogene Polyinstanziierung

2.3 Polyinstanziierung mit datensatzbezogener Freigabestufe

3.1 Berechtigungsmodell für yats

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 ge- meinsamen 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 Ein- richtungen 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. Oft- mals ist es auch notwendig, den Fluss von Daten auf einer Hierarchieebene zu unterbinden. Dies ist mit den genannten Ansätzen nicht möglich.

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 stam- mendes 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ön- nen. 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 Qualitätsstandards hin untersuchen lassen.

Auch Software-Produzenten betreiben selbstverständlich Qualitätssicherung an ihren Produkten. Dazu werden etablierte Werkzeuge des Projektmana- gements eingesetzt, welche auf Grund der fortschreitenden Entwicklung im Umfeld des Internets leicht über dieses betrieben werden können. Eine Vor- reiterrolle 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 erbrin- gen 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 beauftragen- den Unternehmen - jeder Dienstleister eigene Sicherheitsrichtlinien, die um- gesetzt werden sollten. Im Interesse des beauftragenden Unternehmens steht dabei allerdings die Durchsetzung der eigenen Vorgaben zur Informations- sicherheit.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1: Ein Software-Produzent stellt ein Projektmanagement-System bereit, mit dem mehrere Dienstleister (A - C) gemeinsam über das Internet arbei- ten können. Für den jeweiligen Dienstleister stellt sich das System dar, als hätte nur er allein Zugriff darauf.

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-Pr]oduzent die Möglichkeit besit- zen 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.

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 KompartmentalisierungsTechniken 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 ProjektmanagementSystems 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 Einsetz- barkeit des Gesamt-Systems für das in Abschnitt 1.1 dargestellte Szenario überprüft. Die Anwendungsfälle werden dabei mittels Unit - und Functional - Tests abgebildet.

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 Beschrei- bung der Kompartmentalisierungs-Funktion in der oben genannten Anwen- dung 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 gege- ben. 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 WebAnwendungen 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.

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 ² basie- renden Frameworks Ruby on Rails oder kurz Rails ³ entwickelt. Einen guten Einblick in Ruby bzw. Rails geben Thomas u. a. (2006) und Thomas u. Heine- meier Hansson (2006).

Der Entwurf jeder Anwendung wird auch durch die zum Einsatz kommende Programmiersprache und ganz besonders durch in dieser umgesetzte Para- digmen beeinflusst. Rails wird deshalb so häufig eingesetzt, weil die darin enthaltenen Konzepte eine agile Entwicklung und Umsetzung von Anwen- dungen 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 den typischen Lebenszyklus eines Datenbankobjektes und die auf diesem anwendbaren Methoden. Üblicherweise werden die entsprechenden Methoden in den jeweiligen Controllern implementiert (siehe dazu (Thomas u. Heinemeier Hansson 2006, S. 293ff.)).

Des Weiteren lässt sich eine Rails -Anwendung durch den Einsatz von Plugins einfach um Funktionalität erweitern. Dieses ist insbesondere in Hinblick auf die in Abschnitt 1.2 beschriebenen Ziele dieser Arbeit interessant, da das Mo- dul zur Kompartmentalisierung einfach als Plugin eingefügt werden kann.

2.2 Informationssicherheit im Umfeld des Internets

Mit fortschreitender Entwicklung im Internet und den sich daraus ergeben- den Möglichkeiten und Anwendungsfällen erhält die Informationssicherheit einen höheren Stellenwert. Insbesondere Unternehmen häufen schnell große Datenmengen an, die oftmals privater Natur oder geschäftsrelevant sind. Ein Merkmal dieser Datensammlungen ist, dass immer mehr Daten aggregiert und zentralisiert werden.

2.2.1 Notwendigkeit von Informationssicherheit

Als Beispiel solcher Datensammlungen können hier Dienstleistungsangebote wie Google Documents ⁴ oder mobile me ⁵ von Unternehmen wie Google oder Apple angeführt werden, welche grundsätzlich privater oder geschäftlicher Natur sind. Einen ebensolchen Stellenwert nehmen die gerade enorm wach- senden sozialen Netzwerke wie facebook ⁶ ein. Neben diesen privaten Dienst- leistern lagern auch immer mehr Unternehmen Teile ihrer Geschäftsprozesse oder Daten aus.

Insbesondere durch die Zentralisierung und zunehmende Verknüpfung der Daten wächst der potentielle Nutzerkreis stetig und es entstehen laufend neue Anwendungen. Es ist offensichtlich, dass der Schutz dieser Daten einen hohen Stellenwert einnehmen muss. Gerade in einem öffentlichen Netz wie dem Internet kommt dabei der Zugriffskontrolle eine zentrale Rolle zu.

Die Kontrolle des Zugriffes ist deshalb so zentral, weil Daten ohne Zugriffs- möglichkeit darauf wertlos sind. Dem notwendigen Schutz der Daten steht also gegenüber, dass zur Abwicklung von Geschäftsprozessen ein Zugriff auf diese notwendig ist. Es ist also nicht möglich, die Daten einfach hinter den sprichwörtlich geschlossenen Türen zu halten. Vielmehr muss ein Zugriff auf die Daten in geregelter Weise erfolgen können. Die gängigsten Konzepte dazu werden in den folgenden Abschnitten dargestellt und bewertet.

2.2.2 Rollenbasierte Zugriffskontrolle und das Bell-LaPadula-Modell

Der bei der Zugriffskontrolle im Umfeld des Internets meist verfolgte Ansatz ist die Umsetzung eines rollenbasierten Zugriffsmodells (Role Based Access Control (RBAC) - siehe Sandhu u. a. (1996)). Hierzu werden jedem Benutzer bestimmte Rollen und damit verbundene Berechtigungen innerhalb des Sys- tems zugeordnet. In Webforen und Wikis werden vielfach die Einteilungen nach „Administrator“, „Moderator“ und „Benutzer“ vorgenommen.

Dieser rollenbasierte Ansatz ist nah verwandt mit den aus dem UNIX-Umfeld bekannten Benutzergruppen. In Benutzergruppen werden allerdings nur die Benutzer zusammengefasst, während eine Rolle neben den ihr zugeordneten Benutzern auch immer eine Reihe von mit dieser Rolle assoziierten Berechti- gungen enthält.

Durch die Zuordnung von Berechtigungen zu den einzelnen Rollen lässt sich der Zugriff auf bestimmte Daten jeweils genau kontrollieren. Ein Nachteil dieses Modells ist, dass in komplexeren Szenarien eine Vielzahl von Rollen und Berechtigungen benötigt wird. Damit steigt der Organisationsaufwand schnell an.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Im Bell-LaPadula Modell werden Informationen in Stufen eingeteilt. Ein le- sender Zugriff auf diese Daten ist dabei immer nur nach unten möglich. Schreibender Zugriff ist nur in die andere Richtung erlaubt.

Neben diesem Modell hat sich insbesondere im militärischen Bereich das Bell-LaPadula-Modell bewährt (siehe Rushby (1986)). Dabei werden die im System gespeicherten Daten in Sicherheitsstufen eingeteilt. Das Modell sieht vor, dass nur Informationen auf der eigenen oder einer darunter liegenden Stufe gelesen werden dürfen. Das Schreiben von Informationen darf nur in der eigenen oder einer höheren Sicherheitsstufe möglich sein. Die Abbildung Wie die Abbildung zeigt, liegen die Grenzen des Informationsflusses beim Bell-LaPadula-Modell horizontal. Die Zugriffskontrolle ist also vertikal orientiert. Aufgrund dieser Eigenschaft werden dieses oder ähnliche Modelle den Multi-Level-Sicherheitssystemen zugeordnet.

Beiden Modellen ist gemeinsam, dass sie den Informationsfluss innerhalb einer Benutzergruppe oder Hierarchieebene zulassen. So können Benutzer im Bell-LaPadula-Modell alle Informationen ihrer Schutzstufe einsehen. Diese Eigenschaft ist nicht immer gewollt und widerspricht auch dem in 1.1 beschriebenen Anwendungsfall.

2.2.3 Versteckte Kanäle

Eine weitere Schwachstelle der oben beschriebenen Sicherheitsmodelle sind die sogenannten versteckten Kanäle (covert channels - erstmals in Lampson (1973)). Bei einem versteckten Kanal handelt es sich um einen Kommunika- tionskanal, welcher bei der Konzeption des Sicherheitsmodells nicht für diese vorgesehen wurde, trotzdem aber den Zugriff auf geschützte Informationen gestattet.

Ein wichtiges Merkmal eines versteckten Kanals ist die Bandbreite, mit der Informationen durch diesen transportiert werden. Diese reicht von wenigen Bit pro Sekunde bis hin zu mehreren Megabyte pro Sekunde (Anderson 2008, S. 265). Wenige Bit pro Sekunde reichen sicherlich nicht aus, um große Daten- mengen zu transportieren, für die Preisgabe eines kryptographischen Schlüs- sels sind sie aber allemal ausreichend. Es muss also versucht werden das Auftreten solcher Kanäle zu verhindern oder zumindest ihre Bandbreite zu begrenzen. Umgesetzt würde sicherlich häufiger Letzteres, da: “The cost of enforcement may be high. A cheaper alternative [. . . ] is to bound the capa- city of the covert channels.” — „Der Aufwand hier mag sehr hoch sein. Eine günstigere Alternative [. . . ] ist die Begrenzung der Bandbreite der versteck- ten Kanäle.“ (Lampson 1973, S. 5)

In der Literatur finden sich viele Beispiele versteckter Kanäle, wie temporäre Dateien oder Interprozesskommunikation (Lampson 1973, S. 2) bis hin zur Positionierung von Festplattenköpfen in bestimmten Zyklen (Anderson 2008, S. 264). Die Betrachtung versteckter Kanäle und ihrer vielfachen Ausprä- gungsformen ist nicht Gegenstand dieser Arbeit. Lediglich ein Teilaspekt ist für die Betrachtung der Kompartmentalisierung in Web-Anwendungen wich- tig.

Im Regelfall tritt ein versteckter Kanal nämlich auch dort auf, wo bereits durch die Abwesenheit bestimmter Daten auf diese geschlossen werden kann. Dies ist insbesondere in Hinblick auf die oben beschriebenen Sicherheitsmo- delle interessant. Eine nähere Betrachtung genau dieses Falles findet sich im folgenden Abschnitt.

2.2.4 Mehrfache Instanziierung

In engem Zusammenhang mit den versteckten Kanälen steht der Ansatz der mehrfachen Instanzbildung von Daten oder Polyinstanziierung (Jajodia u. a. 1995, S. 493ff.) und (Anderson 2008, S. 266f.). In den beiden oben genannten Sicherheitsmodellen kann ein versteckter Kanal immer dann auftreten, wenn in einer Zugriffsstufe bereits ein Datensatz existiert und in einer niedrigeren Zugriffsstufe derselbe Datensatz erneut angelegt werden soll (z. B. eine Datei mit demselben Namen). In diesem Fall hat das Sicherheitssystem prinzipiell zwei Möglichkeiten:

Zum einen kann das System das Anlegen dieses Datensatzes verhindern. Damit hätte das System allerdings ungewollt geschützte Informationen (die Existenz dieser Daten) preisgegeben und somit einen versteckten Kanal geschaffen. Andererseits kann das System den Datensatz einfach anlegen. Dann existieren allerdings mehrere Instanzen davon.

Dieses Problem kann oftmals durch die Einführung festgelegter Namenskon- ventionen oder die Bereitstellung eigener Dateisysteme für jede Freigabe- stufe unterbunden werden. Diese Möglichkeit besteht nicht, sobald die Daten innerhalb einer Datenbank abgelegt werden (dies ist der Regelfall bei Web- Anwendungen), da diese per Definition nur einen einzigen Namensraum zur Verfügung stellt. Somit ist die mehrfache Instanzbildung nicht zu umgehen.

Formal handelt es sich um Polyinstanziierung, sobald mehrere Datensätze scheinbar denselben Primärschlüssel besitzen (Denning u. a. 1987, S. 225). Dabei werden zwei Arten von mehrfacher Instanzbildung unterschieden:

- Datensatzbezogene Polyinstanziierung
- Attributbezogene Polyinstanziierung

Als datensatzbezogene Polyinstanziierung wird die Tatsache bezeichnet, dass mehrere Datensätze mit demselben Primärschlüssel und bspw. unterschiedlichen Freigabestufen angelegt werden. Im hier gezeigten Beispiel (Tabelle 2.1) ist dabei der Schiffsname der Primärschlüssel. Die Buchstaben „Ö“ und „G“ bezeichnen dabei die Freigabestufen „Öffentlich“ bzw. „Geheim“.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Datensatzbezogene Polyinstanziierung

Bei der attributbezogene Polyinstanziierung hingegen ist zumindest der Primärschlüssel und eventuell weitere Attribute für alle Instanzen derselbe. Die restlichen Attribute hingegen unterscheiden sich in Inhalt und Freigabestufe (siehe Tabelle 2.2).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2: Attributbezogene Polyinstanziierung

Sobald eine Freigabestufe nicht für die einzelnen Attribute eines Datensatzes festgelegt, sondern nur auf den gesamten Datensatz bezogen wird (wie in Tabelle 2.3 gezeigt), kann nicht mehr zwischen den beiden Arten der mehrfachen Instanzbildung unterschieden werden.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.3: Polyinstanziierung mit datensatzbezogener Freigabestufe

Dieser letztgenannte Fall wird mit dem Begriff der „Deckgeschichte“ (cover story - (Jajodia u. a. 1995, S. 495)) umschrieben. Durch die Existenz dieser Deckgeschichten kann die Entstehung des oben beschriebenen verdeckten Kanals verhindert werden. Unterschieden werden zwei Arten der Anlage von Deckgeschichten:

1. Eine sichtbare Polyinstanziierung tritt auf, sobald ein privilegierter Be- nutzer versucht einen Datensatz einer geringeren Freigabestufe zu ver- ändern. Da bei der Änderung Informationen freigegeben würden, wird ein zweiter Datensatz in der höheren Freigabestufe angelegt.
2. Eine unsichtbare Polyinstanziierung wird im umgekehrten Fall ange- wendet. Sobald ein Benutzer versucht einen Datensatz einer höheren Freigabestufe zu ändern, muss diese Änderung zugelassen werden (s. o.). Daher wird der entsprechende Datensatz in der niedrigeren Freigabe- stufe erneut angelegt.

Die Benennungen „sichtbar“ bzw. „unsichtbar“ beschreiben also die Situation aus Sicht des jeweiligen Benutzers. Weitere Beispiele zu diesen Unterscheidungen können Jajodia u. a. (1995) entnommen werden.

2.3 Kompartmentalisierung

Wie in Abschnitt 2.2 dargestellt, ist es nicht grundsätzlich ausreichend, den Informationsfluss nur zwischen den einzelnen Hierarchieebenen zu unterbin- den oder zu kontrollieren. Vielmehr ist es oftmals notwendig auch innerhalb einer Hierarchieebene (z. B. den Abteilungen eines Unternehmens) genaue Kontrollstrukturen zu etablieren. Diese Notwendigkeit trifft auf einen Groß- teil der informationsverarbeitenden Systeme zu, sofern sie personenbezogene oder firmeninterne Daten verarbeiten. (Anderson 2008, S. 275)

Wie die Abbildung 2.2 zeigt, können neben den oben beschriebenen horizontalen Grenzen diese zusätzlich vertikal angeordnet sein. Somit erfolgt der Informationsaustausch auf derselben Hierarchieebene ebenfalls kontrolliert oder wird gänzlich unterbunden. Systeme dieser Art werden daher multilaterale Sicherheitssysteme genannt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Die multilateralen Sicherheitsmodelle legen die Grenzen des Informations- flusses vertikal fest. Dadurch lässt sich der Datenaustausch im Gegensatz zum Bell-LaPadula-Modell auch auf einer Hierarchieebene kontrollieren.

Die Festlegung dieser vertikalen Grenzen ist dabei abhängig von der Art der zugrunde liegenden Daten. Sie kann dabei organisationsgebunden sein (ver- schiedene Abteilungen eines Unternehmens) oder fall- bzw. klientengebunden (z. B. in einer Kanzlei). Auch eine Mischung aus diesen oder anderen Kriteri- en ist denkbar.

Eine Art von multilateralen Sicherheitssystemen nutzt die sogenannte Kompartmentalisierung von Daten. Ihren Ursprung hat diese Technik bei den Nachrichtendiensten der Vereinigten Staaten und ihren Alliierten.

Dabei wird der Zugang zu Informationen dahingehend kontrolliert, dass den Informationen neben einer Freigabestufe (wie im Bell-LaPadula-Modell) zu- sätzlich Codewörter zugeordnet werden. Bekannte Codewörter sind z. B. „um- bra“ oder „crypto“. Dabei formen die Kombinationen aus Freigabestufen und Codewörtern die sogenannten Kompartments. Neben Codewörtern können auch andere Klassifikationsmerkmale für eine Zuordnung in unterschiedliche Kompartments herangezogen werden.

Da sich die Kompartments abhängig von den zugrunde liegenden Daten und damit z. B. abhängig von den zugrunde liegenden Berechtigungen und Klassifikationsmerkmalen formen, kann ihre Anzahl schnell anwachsen. So kann auf einen Text, der Material der Freigabestufen „Geheim“ und „Streng Geheim“ sowie den Codewörtern „umbra“ und „crypto“ enthält, nur zugegriffen werden, wenn der Benutzer alle diese Freigaben besitzt.

Die oben beschriebenen Multi-Level-Sicherheitssysteme können leicht in ein multilaterales Sicherheitssystem überführt werden. Dazu ist es lediglich not- wendig, die Daten mit unterschiedlichen Klassifikationsmerkmalen zu verse- hen und sie somit effektiv in unterschiedliche Kompartments zu unterteilen. Damit isoliert das Sicherheitssystem die Daten voneinander, anstelle einen Austausch dieser zu ermöglichen. Das eigentliche Problem ist also nicht so sehr das Abschotten der Daten sondern, vielmehr der kontrollierte Austausch dieser. (Anderson 2008, S. 280)

2.3.1 Die Umsetzung der Kompartmentalisierung in der Anwendung Plusquam

In der Anwendung Plusquam nimmt ein entsprechendes Modul die Kompartmentalisierung der Daten vor. Zunächst werden dabei die dafür vorgesehenen Daten in vollständig voneinander getrennten Kompartments abgelegt. Den Austausch der Daten zwischen den einzelnen Kompartments übernimmt in einem zweiten Schritt eine Synchronisierungsfunktion.

Die Aufteilung der Daten in einzelne Kompartments ist in diesem Modul über eine Policy geregelt und mit den jeweiligen Benutzer-Objekten verknüpft. In der Policy ist festgelegt, welche der Daten kompartmentalisiert werden sollen und wie bei einer Synchronisierung mit ihnen zu verfahren ist.

Dabei ist entscheidend, dass nicht alle vorhandenen Daten kompartmentalisiert werden müssen. Die Kompartmentalisierung kann dabei auf einzelne Modelle beschränkt werden. Für Modelle, die nur weitestgehend statische Informationen wie Übersetzungen oder andere Daten dieser Art abbilden, kann eine Kompartmentalisierung entfallen. Die Kompartmentalisierung geschieht aber immer bezogen auf ein vollständiges Modell.

Alle Modelle, welche kompartmentalisiert werden sollen, enthalten dabei ein Attribut compartment_id. Zu einem Kompartment gehörende Objekte enthalten hier jeweils denselben Wert und sind somit entsprechend zugeordnet. Weitere Eigenschaften besitzen die Kompartments nicht.

Dem Benutzermodell in der Anwendung kommt eine wichtige Rolle zu. Jeder Benutzer ist einem Kompartment zugeordnet. Alle Objekte, die dieser Be- nutzer anlegt, werden durch das Modul automatisch seinem Kompartment zugewiesen. Somit muss nicht extra in der Policy festgelegt werden, wie die Daten zuzuordnen sind; diese Zuordnung geschieht vielmehr automatisch.

Damit sind die Daten in den einzelnen Kompartments strikt voneinander getrennt. Um den Austausch der Daten zwischen den einzelnen Kompart- ments zu ermöglichen, nutzt das Modul den Ansatz der Synchronisierung. Dabei wird nicht fortlaufend synchronisiert, sondern jeweils in bestimmten Zeitabständen. Dadurch wird umgangen, dass sonst bei jedem schreibenden Zugriff auf die Datenbank alle Kompartments miteinander abgeglichen wer- den müssten.

Da nach der Synchronisierung die dafür vorgesehenen Daten in beiden syn- chronisierten Kompartments enthalten sein müssen, wird das oben einge- führte Konzept der mehrfachen Instanziierung angewendet (siehe Abschnitt 2.2.4). Die mehrfache Instanzbildung ist dabei datensatzbezogen. Die einzelnen Instanzen eines Datensatzes, die durchaus auch in einer Tabelle liegen können, werden dabei anhand ihrer compartment_id unterschieden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Die Synchronisierung zwischen zwei Kompartments erfolgt per pull im Na- men eines Benutzers im Quell-Kompartment. Es werden alle Daten abge- glichen, auf die dieser Benutzer Zugriff hat. Dabei wird das Konzept der mehrfachen Instanziierung angewandt (die synchronisierten Daten sind dann mehrfach vorhanden). Die Daten im Quell-Kompartment bleiben unverändert.

Auch bei der Synchronisierung zwischen den einzelnen Kompartments ist das Benutzermodell von zentraler Bedeutung. Die Synchronisierung findet dabei per pull in regelmäßigen Zeitabständen statt. Dazu muss das als Quelle dienende Kompartment einen Benutzer enthalten, in dessen Namen sich ein synchronisierender Benutzer dort anmelden kann. Beim Synchronisieren werden alle Daten abgeglichen, auf die der Quell-Benutzer Zugriff hat. Dieses Vorgehen ist in Abbildung 2.3 dargestellt.

Für die jeweiligen Benutzer erfolgt die notwendige mehrfache Instanziierung zunächst transparent. Neue Datensätze aus dem synchronisierten Kompartment werden einfach angelegt und existieren damit in beiden Kompartments. Ein eindeutiger Bezug zwischen den beiden Datensätzen wird dabei über die Klasse RemoteObjectMapping realisiert. Diese bildet die IDs der mehrfach instanziierten Datensätze im lokalen Kompartment auf die IDs der entsprechenden Datensätze im anderen Kompartment ab.

Diese Transparenz ist nicht mehr gegeben, sobald ein Datensatz, der bereits beiden Kompartments zugeordnet ist, in einem davon oder in beiden geändert wurde. Für die bei einer Synchronisierung dann notwendige Zusammenführung der Daten sind mehrere Herangehensweisen möglich.

Ein einfacher Fall liegt dann vor, sofern der entsprechende Datensatz nur in einem Kompartment Änderungen aufweist. Wurde der Datensatz nur in dem Kompartment geändert, aus dem heraus die Synchronisierung angestoßen wurde, so braucht er gar nicht angepasst werden. Wurde er dagegen nur im Quell-Kompartment geändert, so kann er einfach überschrieben werden.

Sofern in den beiden synchronisierten Kompartments eine Änderung vorgenommen wurde, ist eine differenziertere Herangehensweise erforderlich, um die jeweiligen Datensätze zusammenzuführen. In der Policy kann dazu eine entsprechende Strategie für jedes Modell gesondert festgelegt werden (dort conflict_resolution_policy genannt). Dabei sind grundsätzlich die drei folgenden Möglichkeiten gegeben: keep_local: Der lokal vorhandene Datensatz bleibt unverändert und die Änderungen aus dem Quell-Kompartment werden ignoriert. Dieses ist auch das Standard-Vorgehen, welches zur Anwendung kommt, sofern in der Policy keine Angaben gemacht werden.

overwrite: Das genaue Gegenteil von keep_local. Der lokale Datensatz wird überschrieben. Alle an diesem vorgenommenen Änderungen gehen dabei verloren.

manual: Bei dieser dritten Möglichkeit bleibt in der momentanen Implemen- tierung der Datensatz unverändert und es wird eine Warnung ausgege- ben. Denkbar wäre hier allerdings, dass der geänderte Datensatz aus dem entfernten Kompartment zwischengespeichert und anschließend durch einen Benutzer eine manuelle Konfliktlösung vorgenommen wird.

2.4 Fazit

In diesem Kapitel wurde das für den im folgenden Kapitel 3 dargestellten Systementwurf und dessen Umsetzung eingesetzte Framework Rails vorgestellt. Ein besonderes Augenmerk lag dabei auf den Besonderheiten, welche diesen Entwurf maßgeblich beeinflusst haben.

Anschließend wurden in diesem Kapitel die Grundlagen der Informations- sicherheit und Zugriffskontrolle im Umfeld des Internets erarbeitet. Dabei hat sich gezeigt, dass die Zugriffskontrolle auf Daten im Internet einen ho- hen Stellenwert besitzen muss. Anhand zweier Beispiele wurde die gängige Praxis hierzu dargestellt und die Einschränkungen der genannten Sicher- heitsmodelle aufgezeigt.

Mit der Kompartmentalisierung von Daten wurde abschließend ein weiteres Sicherheitsmodell eingeführt und der Bezug zu möglichen Anwendungsfällen hergestellt. Eine Erläuterung dieses Konzeptes für Web-Anwendungen hat anhand des Kompartmentalisierungs-Moduls aus der Anwendung Plusquam stattgefunden. Ein besonderes Augenmerk lag dabei auf der Erläuterung der Synchronisierung zwischen einzelnen Kompartments. Hierbei sind die Vorteile, welche dieses Konzept bietet, deutlich geworden.

[...]

---

¹ 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.

² 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 Projekt- beschreibung.

⁴ Siehe http://www.redmine.org

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

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

³ Siehe http://www.rubyonrails.org

⁴ Siehe http://docs.google.com/

⁵ Siehe http://www.apple.com/de/mobileme/

⁶ Siehe http://www.facebook.com