DER LUDWIG-MAXIMILIANS-UNIVERSITÄT MÜNCHEN
![\includegraphics [width=0.3\textwidth]{lmu_siegel}](img1.gif)
![$\textstyle \parbox{1cm}{
\begin{large}
\begin{tabbing}
\hspace{1cm} \=Dietmar Fackelmann\\ [2mm]
\end{tabbing}\end{large}}$](img2.gif)
![$\textstyle \parbox{1cm}{
\begin{large}
\begin{tabbing}
Bearbeiter: \hspace{1cm}...
...olle\\ [5mm]
Abgabetermin: \> 13. M\uml {a}rz 2001\\
\end{tabbing}\end{large}}$](img3.gif)
Hiermit versichere ich, daß ich die vorliegende Diplomarbeit selbständig verfaßt und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
München, den 13. März 2001
(Unterschrift des Kandidaten)
Mobile Agenten führen Tätigkeiten auf verschiedenen Systemen
flexibel und ortsungebunden aus.
Dazu werden die Agenten an die lokale Umgebung eines Systems gebunden.
Neben der Ausführung des
Agenten auf dem System sind oft auch Zugriffe auf Ressourcen des Systems notwendig.
Eine Agenteninstanz kann ebenso Ressourcen bereitstellen, auf die
ein Agentensystem oder weitere Agenteninstanzen zugreifen können.
Dabei müssen unautorisierte Zugriffe und der Missbrauch von Informationen
des Systems ausgeschlossen werden. Für die Akzeptanz einer
Agentensystemarchitektur spielt die Sicherheit eine große Rolle.
Diese Arbeit erstellt für das CORBA/Java basierte mobile Agentensystem MASA
ein Rechtekonzept.
Beginnend mit einer Einführung in die Grundlagen zur Sicherung der
Informationssicherheit werden die Anforderungen an eine
Agentensystemarchitektur analysiert. Eine konkrete Untersuchung
von MASA zeigt vorhandene Schwachstellen der momentanen
Implementierung auf.
Auf Basis der Sicherheitsanforderungen und den MASA
zugrundeliegenden Standards wird ein Rechtekonzept entwickelt,
welches eine geeignete Policy-Sprache bereitstellt, um
anwendungsspezifische Zugriffskontrollpolitiken zu formulieren.
Anhand eines Implementierungskonzepts wird die Integration des Rechtekonzepts in das mobile Agentensystem MASA beschrieben.
Durch den Einsatz Mobiler Agentensysteme sind generell alle
IT-Ressourcen gemeinsam benutzbar. Mobile Agenten können auf
Agentensysteme migrieren, auf Ressourcen von Agentensystemen
zugreifen, aber auch selbst Ressourcen bereitstellen.
Durch eine Agentensystemarchitektur besitzt eine Anwendung
eine höhere Flexibilität und Dynamik.
Agenten können dynamisch um neue Funktionalitäten erweitert
werden und diese durch Migration der Agenten auf den
unterschiedlichen Agentensystemen zur Verfügung stellen.
Eine Beispielanwendung ist die Verwendung einer Agentensystemarchitektur
als ein verteiltes Managementsystem. Die Vorteile liegen
hier in der durch das Agentensystem ermöglichten, dynamischen
Änderung der Managementfunktionalität. Beispielsweise kann so eine neu
hinzugefügte Ressource dynamisch in ein Endsystem eingebunden werden.
Die ansonsten nötige manuelle Konfiguration vor Ort entfällt.
Die Vorteile der Agentensystemarchitektur resultieren
aus der Mobilität der Agenten. Bezüglich
der Sicherheit birgt die Mobilität jedoch neue Risiken.
Aus der Perspektive eines Systems kann ein Agent
potenziell die Informationssicherheit des Systems gefährden.
Ein bösartiger Agent kann beispielsweise versuchen, unberechtigt auf
sensible Daten des Systems zuzugreifen.
Eine weitere Gefahr besteht in der Störung des Funktionsablaufs durch
einen Agenten.
Betrachtet man die Agenten, so können auch sie sensible Daten mit sich führen.
Auch diese Daten müssen vor unautorisierten Zugriffen und Missbrauch
geschützt werden.
Betrachtet man die möglichen Einsatzgebiete von
Agentensystemarchitekturen, wie z.B. den Einsatz als Managementsystem, werden
an das Agentensystem hohe Sicherheitsanforderungen gestellt.
Eine Hauptanforderung ist die Sicherstellung der Informationssicherheit, so dass
Informationen vor unautorisierten Zugriffen und Missbrauch geschützt sind.
Der Schutz der Informationssicherheit ist schon bei Einzelplatzsystemen und
verteilten Systemen keine leichte Aufgabe. Durch die Eigenschaften einer
Agentensystemarchitektur wird diese Aufgabe noch zusätzlich erschwert.
Hier gilt es, Ressourcen des Agentensystems vor Agenten und
Ressourcen der Agenten vor Agentensystemen zu schützen.
Der Hauptunterschied einer Agentensystemarchitektur gegenüber herkömmlichen
Architekturen ist die Ausführung von fremden Programmen auf dem System.
Dieser Fall tritt ein, sobald ein Agent auf einem Agentensystem
ausgeführt wird. Der Agent muss dynamisch in die Ausführungsumgebung
des Agentensystems eingebunden und ausgeführt werden.
Java-Applets, die von einem Rechner über das World Wide Web
heruntergeladen werden und auf dem System innerhalb eines
Browsers zur Ausführung gebracht werden,
können als Agenten, wenn auch mit eingeschränkter Funktionalität,
betrachtet werden.
Sicherheitshinweise, die vor der Ausführung von Java-Applets warnen,
lassen die Sicherheitsproblematiken, die durch die Ausführung von
fremden Programmen auf dem System entstehen, erahnen.
Ein Rechtekonzept eines Agentensystems hat die Aufgabe, die Anforderungen
bezüglich der Informationssicherheit zu erfüllen.
Dabei werden durch das Rechtekonzept die Rechtevergabe, Rechtedurchsetzung
und deren Verwaltung betrachtet.
Die Auswahl der eingesetzten Mechanismen und Techniken hat dabei
direkte Einflüsse auf die Eigenschaften und Funktionalität der
Agentensystemarchitektur.
Unterschiedliche Konzepte können sich unterschiedlich sowohl auf die
Migration, Autonomie und die Kommunikationsmöglichkeiten der Agenten
als auch auf die Effizienz und Performance auswirken.
Letztendlich wird ein Rechtekonzept benötigt, welches die positiven Eigenschaften einer Agentensystemarchitektur unterstützt, eine sichere Umgebung bereitstellt und die Anforderungen bezüglich der Performance und der Funktionalität erfüllt.
Um die Agentensystemarchitektur zu nutzen, wird
auf einem Endsystem jeweils ein Agentensystem zur Ausführung
gebracht. Ein Agentensystem stellt dabei die Ausführungsumgebung für
Agenten zur Verfügung. Für Agenten ist das
Agentensystem auch die Schnittstelle zum Endsystem.
Agenten sind in der Lage, über das Agentensystem auf Ressourcen
des Endsystems zuzugreifen.
MASA ist vollständig in der Programmiersprache Java implementiert [JAW 01].
Die Plattformunabhängigkeit des Agentensystems ist durch die
Java Virtual Machine, welche die Basis für das Agentensystem
darstellt, gegeben.
Als Kommunikationsinfrastruktur für die Agenten wird die
Common Object Request Broker Architecture (CORBA) eingesetzt.
Agenten können über die CORBA-Schnittstelle miteinander
kommunizieren. Die Mobilität der Agenten ist durch die Möglichkeit
der selbständigen Migration von Agenten gegeben.
Die graphische Bedienoberfläche wird durch einen Webbrowser dargestellt.
Durch den Browser kann der Webserver,
Bestandteil eines jeden Agentensystems, angesprochen werden.
Der Webserver wird zur Steuerung der Agenten und des
Agentensystems herangezogen. Der Benutzer greift über einen
Browser auf das Agentensystem zu. Der Zugriff auf einen Agenten
erfolgt durch ein Java-Applet des Agenten, welches vom
Webserver angefordert werden kann. Die weitere Kommunikation
mit dem Agenten über das Applet erfolgt über CORBA.
Die MASA Architektur und ihre Komponenten werden ausführlich
in [HGR 99] behandelt.
Die Authentisierung und Autorisationsanforderungen für MASA wurden in der Arbeit von Harald Rölle betrachtet [ROE 99]. Dabei wurde ein Sicherheitskonzept für MASA entwickelt, welches der Entwicklung des Rechtekonzepts zugute kommt.
Das Sicherheitskonzept realisiert grundlegende Sicherheitseigenschaften, auf die das Rechtekonzept aufbauen kann. Einzelne Entitäten können durch die Verwendung von Public-Key Verfahren und Zertifikate authentifiziert und identifiziert werden. Die Kommunikationskanäle werden gesichert und es werden getrennte Ausführungsumgebungen der Entitäten bereitgestellt. Statische und dynamische Informationen der Agenten können unterschieden werden, wobei die statischen Informationen eines Agenten geschützt sind.
In der Managementanwendung wird ein Händler über einen Provider mit
dem Automobilhersteller vernetzt. Der Händler hat so z.B. die
Möglichkeit, die Dienste des Bestell-Centers des Automobilherstellers zu
nutzen. Die Händler sind dabei über Wählleitungen an den Provider
angeschlossen, wobei die Verbindung als ein Virtuelles Privates Netzwerk (VPN)
realisiert ist.
Mit dem Provider werden in einem sogenannten Service Level Agreement (SLA)
Quality of Service (QoS) Parameter festgelegt. Ein QoS-Parameter stellt
z.B. der Netzdurchsatz vom Händler zum Bestell-Center des Automobilherstellers
dar.
Damit die Einhaltung der QoS-Parameter überprüft werden kann, sind Messungen der
relevanten QoS-Parameter nötig. Die Messung des Netzdurchsatzes vom
Händler zum Automobilhersteller erfolgt am Besten vom Händler aus.
Aufgrund der Möglichkeit von sich ändernden Gegebenheiten ist
zudem die Flexibilität des Management-Centers des Providers gefragt.
So können beispielsweise neue QoS-Parameter hinzu kommen oder geändert werden.
Der Einsatz von MASA eignet sich hier besonders gut.
Für die Durchsatzermittlung kann das Management-Center des Providers
einen mobilen Agenten zum Agentensystem des Händlers senden, wobei
dort die nötigen Messungen durch diesen mobilen Agenten vorgenommen
werden können. Ändern sich die QoS-Parameter oder kommen neue hinzu,
kann ein modifizierter mobiler Agent erstellt werden.
Für eine neue Aufgabe kann jeweils ein entsprechender Agent eingesetzt
werden, welcher die geforderte Funktionalität bereitstellt und
auf das entsprechende Agentensystem migriert, um dort die neue
Funktionalität zu integrieren. Die Möglichkeit der Aufgabenteilung ist
ein weiterer Vorteil von Agentensystemen. Ein Agent ist beispielsweise
in der Lage, weitere Agenten zu beauftragen, um die Aufgabe möglichst
effektiv zu bearbeiten.
Die Problematik bezüglich der Sicherheit liegt in den unterschiedlichen Administrationsbereichen
Ein Agent durchwandert u.U. unterschiedliche Administrationsbereiche.
Migriert beispielsweise der Agent des Providers auf das Agentensystem des
Händlers, um dort Messungen vorzunehmen, müssen die
Sicherheitspolitiken beider beteiligter Partner erfüllt werden.
Der Missbrauch von Informationen und unautorisierte Zugriffe auf Informationen
der Agentensysteme und der Agenten sind auszuschließen.
Anforderungen des Händlers
Die Sicherheitsanforderungen des Händlers bestehen darin,
dem Agenten des Providers nur die Zugriffe
zu gewähren, die er für die Messung des Netzdurchsatzes unbedingt benötigt.
Der Händler muss daher in der Lage sein, eine möglichst feingranulare
Sicherheitspolitik formulieren zu können.
Zugriffsrechte müssen an einzelne spezifische Entitäten, aber auch an
bestimmte Gruppen von Entitäten vergeben werden können.
Die Sicherheitspolitik kann unter Umständen sehr groß werden, wobei
sich die Eintragungen dynamisch ändern können.
Außerdem muss der Händler sicherstellen können, dass der Agent im Auftrag
des Providers handelt.
Bei der Entscheidungsfindung kann dabei auch die Vorgeschichte des Agenten
eine Rolle spielen.
Bezüglich des Schutzes der Informationssicherheit ist jeder Zugriff
einer Zugriffskontrolle zu unterziehen.
Die Zugriffskontrolle hat dabei die Aufgabe, die Sicherheitspolitik
des Agentensystems durchzusetzen.
Anforderungen des Providers
Die Sicherheitsanforderungen des Provider liegen im Schutz seines Agenten und
dessen Ressourcen.
Der Provider muss in der Lage sein, eine Sicherheitspolitik für spezifische Agenten erstellen zu können, welche ebenfalls die zugreifenden Entitäten spezifisch adressieren kann. Auch hier müssen feingranulare Zugriffsrechte vergeben werden können. Dabei ist wichtig, dass jeder Zugriff auf den Agenten einer Zugriffskontrolle unterzogen wird. Die Zugriffskontrolle muss dabei die Sicherheitspolitik des Providers durchsetzen. Gegebenenfalls sollte der Agent auch in der Lage sein, seine Aufgaben an weitere Agenten zu delegieren, wobei der Agent die Möglichkeit haben sollte, seine Zugriffsrechte an einen Agenten delegieren zu können, damit dieser die für die Bearbeitung der Aufgabe notwendige Berechtigung besitzt.
Die Zugriffskontrolle impliziert eine vorherige
Autorisation der Subjekte. Das Rechtekonzept muss daher ein
geeignetes Konzept der Authentisierung und Identifizierung vorweisen.
Erfolgt die Autorisation durch eine Zugriffskontrollpolitik,
sollte die eingesetzte Policy-Sprache einem formalen Modell zugrundeliegen.
Die Kriterien, die zur Entscheidungsfindung herangezogen
werden, müssen spezifiziert und klassifiziert werden.
Dabei ist darauf zu achten, dass die Kriterien den Anforderungen der
Mobile Agent System Architecture (MASA) entsprechen.
Damit Zugriffe anwendungsspezifisch autorisiert werden können, sollte eine möglichst feingranulare Zugriffskontrolle realisiert werden. Die Zugriffskontrollpolitik sollte handhabbar und benutzerfreundlich konfigurierbar sein. Die Sicherheitspolitiken müssen überschaubar und eindeutig interpretierbar sein.
Ein Agent soll weiter in der Lage sein, seine Rechte einem anderen
Agenten weiterzugeben. Die Rechtedelegation ist als eine erweiterte
Funktion des Rechtekonzepts anzusehen.
Sicherheitsrelevante Fragen sollten beantwortbar sein.
Dazu gehört z.B. die Frage, welches Subjekt ein spezifisches
Zugriffsrecht besitzt, oder wer in den letzten zwei Stunden
auf das Objekt ``XY'' zugegriffen hat.
Die Beantwortbarkeit dieser oder ähnlicher Fragen stellt die Basis
für ein sicheres System, auch in Bezug auf die Rückverfolgung
eventuell unautorisierter Zugriffe.
Es gilt, die Autorisation von der Rechtedurchsetzung und die Rechtedurchsetzung
von der Systemfunktionalität möglichst sauber zu trennen, wodurch
der Austausch einzelner Module ermöglicht wird.
Die Entwicklung eines Rechtekonzepts für MASA umfasst Thematiken der
unterschiedlichsten Gebiete der Informatik. So spielen neben einer
formalen Beschreibung einer Policy-Sprache,
Mechanismen und Techniken von softwarebasierten Schutzmechanismen
und unterschiedliche Architekturen eine Rolle.
Zusammenfassung der Zielsetzung:
Kapitel 2 beschäftigt sich mit Grundlagen, die für die Entwicklung des
Rechtekonzepts relevant sind. Es werden grundlegende Begriffe
eingeführt, die in der gesamten Arbeit verwendet werden.
Nach Betrachtung der Sicherheitsbedrohungen und Sicherheitsanforderungen,
werden bekannte Sicherheitsmodelle vorgestellt.
Hier werden unterschiedliche Konzepte und Mechanismen hinsichtlich ihrer Vor- und
Nachteile untersucht.
Ein weiteres Unterkapitel beschreibt Mechanismen, die zur Formulierung einer
Sicherheitspolitik eingesetzt werden. Das darauffolgende Unterkapitel konzentriert
sich auf die Komponenten, die zur Realisation der in der Sicherheitspolitik
formulierten Anforderungen benötigt werden. Auch hier existieren eine
Reihe von Konzepten und Mechanismen, die genauer betrachtet werden.
Nachdem unterschiedliche Anforderungen der unterschiedlichen Architekturen behandelt
worden sind, werden Modelle, die zur Bewertung und Prüfung der
Sicherheit herangezogen werden, analysiert.
Am Ende des Kapitels werden die in Java eingesetzten Mechanismen und
Techniken bezüglich der Sicherheit eingeführt.
Dazu gehört auch die Vorstellung von existierenden und bereits eingesetzten
Mechanismen.
Spezielle Anforderungen eines Rechtekonzepts für
eine Agentensystemarchitektur werden in Kapitel 3 betrachtet.
Die Schwerpunkte liegen hier auf der Rechtevergabe und Rechtedurchsetzung.
In Kapitel 4 wird die Mobile Agent Management Architecture (MASA) bezüglich der
in Kapitel 3 spezifizierten Anforderungen analysiert. Dabei werden sowohl
Stärken als auch Schwächen der momentanen Implementierung aufgezeigt.
Die Risikoanalyse aus Kapitel 4 verdeutlicht, inwieweit MASA
die Sicherheitsanforderungen erfüllt bzw. wo noch Schwachstellen
liegen.
Das Kapitel 5 betrachtet Standards bezüglich eines Rechtekonzepts.
Desweiteren liefert das Kapitel einen Überblick über Konzepte, die
zum Schutz der Agentensystemarchitektur eingesetzt werden können.
Außerdem wird der realisierte Schutz verschiedener Agentensystemarchitekturen
betrachtet.
Aus den in Kapitel 3 gewonnenen allgemeinen Anforderungen und den
in Kapitel 4 analysierten Anforderungen für MASA, wird in Kapitel 6 ein
Rechtekonzept für MASA entwickelt. Die einzelnen Komponenten des Rechtekonzepts
werden vorgestellt und deren Funktionsweise beschrieben.
Dazu gehört, neben der Einführung einer Politik-Sprache, das
Aussehen der Zugriffsrechte, die Realisation der Rechtevergabe und
deren Durchsetzung. Das Zusammenwirken der einzelnen Komponenten des
Rechtekonzepts wird am Ende anhand von Beispielszenarien verdeutlicht.
Das Implementierungskonzept von Kapitel 7 integriert das in Kapitel 6
entwickelte Rechtekonzept in die MASA Umgebung.
Mechanismen und Techniken, die für die Realisation des Rechtekonzepts
verwendet werden können, werden vorgestellt. Das Kapitel
beschreibt die notwendige Vorgehensweise, um das in Kapitel 6 vorgestellte
Rechtekonzept in MASA zu integrieren und zu nutzen.
Das Kapitel 8 enthält eine Zusammenfassung der Arbeit und einen Ausblicke auf Weiterentwicklungsmöglichkeiten.
Das folgende Kapitel behandelt Grundlagen, die für die Entwicklung eines Rechtekonzepts relevant sind. Nachdem im Kapitel 2.1 grundlegende Begriffe eingeführt werden, wird die Notwendigkeit eines Rechtekonzepts anhand von Sicherheitsbedrohungen und den daraus basierenden Sicherheitsanforderungen motiviert (Kapitel 2.2 und Kapitel 2.3). In Kapitel 2.4 werden anhand von existierenden Sicherheitsmodellen Sicherheitsanforderungen und deren Modellierung und Realisation erläutert. Dabei gibt das Unterkapitel über die Sicherheitspolitiken (Kapitel 2.5) einen Einblick in unterschiedliche Zugriffskontrollmodelle. Die Vorstellung der einzelnen Komponenten einer Zugriffssteuerung und deren Realisationsmodelle in Kapitel 2.6 geben einen Einblick in den Ablauf der Zugriffssteuerung. In Kapitel 2.7, wird anhand der unterschiedlichen Architekturen die jeweiligen Problematik der Realisation einer Zugriffskontrolle verdeutlicht. In Kapitel 2.8 werden Modelle, die zur Bewertung und Prüfung der Sicherheit eines Systems herangezogen werden können, vorgestellt. Abschließend wird in Kapitel 2.9 die Sicherheitsarchitektur von Java betrachtet. Dabei werden einzelne Konzepte und Mechanismen der Java 2 Security Architecture und ihre Grenzen vorgestellt.
Greift beispielsweise ein Benutzer auf eine Datei zu, um sie zu lesen,
so ist der Benutzer das Subjekt, die Datei das Objekt und der
lesende Zugriff die Aktion.
Darf nur ein von Person ``X'' signiertes Programm auf den Drucker zugreifen, so ist die Signatur ein Entscheidungskriterium, das bei der Entscheidungsfindung herangezogen werden muss.
Allgemein kann man drei Klassen von Bedrohungen unterscheiden [REI 97]:
Die Informationssicherheit wird in der Regel in allen drei Fällen verletzt. Die Zugriffskontrolle, welche eine geeignete Autorisation der zuvor authentifizierten Entitäten voraussetzt, hat die Aufgabe, unautorisierte Zugriffe zu unterbinden. Durch die Kenntnisnahme existierender Bedrohung können unter Umständen schon bei der Entwicklung eines Rechtekonzepts geeignete Maßnahmen getroffen werden, um den Bedrohungen entgegen zu wirken. Eine nachträgliche Integration von bestimmten Sicherheitsdiensten kann dann in der Regel entfallen.
Anhand der analysierten Bedrohungen können anwendungsspezifische Anforderungen analysiert und aufgestellt werden.
Die Sicherheitsanforderungen basieren hauptsächlich darauf, dass nur autorisierte Subjekte auf ein Objekt zugreifen können. Um Subjekte autorisieren zu können, müssen sie authentifizierbar sein, d.h. Subjekte müssen identifiziert und ihre Identität muss verifiziert werden können. Nur authentifizierbare Subjekte können so einer Zugriffskontrolle unterzogen werden.
Innerhalb der Zugriffssteuerung muss sichergestellt sein, dass alle
Subjekte und Objekte, die innerhalb der Sicherheitspolitik auftauchen,
von der Rechtevergabe erfasst werden können. Änderungen bzgl. der
Rechte dürfen nur von autorisierten Entitäten vorgenommen werden.
Eine Verletzung der Sicherheitspolitik muss entsprechend verarbeitet
werden. Desweiteren ist jeder Zugriffsversuch einer Zugriffskontrolle
zu unterwerfen. Es darf keine Möglichkeit geben, die Zugriffskontrolle
zu umgehen um unautorisiert auf Objekte zuzugreifen.
Wurde von einem Subjekt ein Zugriff auf eine Ressource getätigt, so sollte der
Zugriff dem Subjekt eindeutig zugeordnet werden können. Die eindeutige Zuordnung
ist eine Voraussetzung, um Zugriffe abrechnen zu können. Sind beispielsweise
Zugriffe mit Kosten verbunden, müssen sie geeignet abgerechnet werden können.
Die Abrechnungsmöglichkeit ist vor allem aber auch dann relevant, wenn Ressourcen
nur beschränkt vorhanden sind und eine gerechte Verteilung der Ressourcen
erfolgen muss.
Bei der Erstellung eines Rechtekonzepts müssen die Anforderungen des Systems an das Rechtekonzept detailliert beschrieben werden. In der Literatur [SAS 75,ECK 98,SUM 97] finden sich unterschiedliche Anforderungen die ein Sicherheitskonzept betreffen. Dabei handelt es sich oft um allgemeingültige Anforderungen, die erfüllt werden sollten, um hohen Sicherheitsanforderungen zu genügen. Folgend werden die relevanten Anforderungen stichpunktartig aufgezählt und erläutert. Die einzelnen Anforderungen nach [SUM 97] können als Basis für einen Kriterienkatalog herangezogen werden.
Unterschiedliche Sicherheitsmodelle versuchen dabei, einzelne Aspekte der Anforderungen zu erfüllen.
Das Modell der Zugriffsmatrix kommt aufgrund seiner Einfachheit und seiner Vielseitigkeit auch in vernetzten Systemen zum Einsatz. Dennoch besitzt das Modell auch einige Schwachstellen. Das Zugriffsmatrix-Modell im herkömmlichen Sinn hat Einschränkungen in Bezug auf die Darstellung besonderer Sicherheitspolitiken, die z.B. von zeitlichen Abläufen, sich dynamisch ändernden Eigenschaften oder mehreren Nutzerautorisationen abhängen.
In der Regel können jedoch alle Sicherheitspolitiken anhand des
Zugriffsmatrix-Modells modelliert werden. In der Praxis werden unterschiedliche
Mechanismen und Techniken eingesetzt, um das Zugriffsmatrix-Modell umzusetzen.
Das Konzept der Sicherheits- oder Zugriffsmatrix stützt sich
dabei unter anderem auf die Voruntersuchungen von Dennis, van Horn, Graham, Denning,
Jones und Lampson. Es wurde 1976 von Harrison, Ruzzo und
Ullmann umfassend begründet [SUM 97].
In der Abb. 2 werden den Subjekten (s. 1. Spalte)
Objekte (s. 1.Zeile) und die dazugehörigen Zugriffsrechte zugeordnet.
Objekte können dabei Daten oder auch Funktionen sein [WAE 93].
Das Zugriffsmatrix-Modell hat jedoch auch Schwächen. Folgende Problematiken sind zu berücksichtigen [SUM 97]:
Es existieren neben dem Zugriffsmatrix-Modell noch weitere Sicherheitsmodelle, die sich in der Erfüllung der unterschiedlichen Sicherheitsanforderungen unterscheiden.
Gegenüber dem Zugriffsmatrix-Modell wird z.B. durch das Bell-LaPadula-Modell die
Vertraulichkeit der Information besser geschützt, da hier der Informationsfluss
betrachtet wird [SUM 97]. Dabei werden oft Sicherheitsmodelle erweitert oder es
werden neue Mechanismen und Techniken eingesetzt. So besteht beispielsweise ein
weiterer Realisierungsansatz aus gerichteten Graphen. Ein Modell mit Einfluss der
Graphentheorie ist z.B. das Nehmen-Gewähren-Modell des Bell-LaPadula-Modells oder
das Gittermodell von Denning. Beide versuchen die Zugriffsmatrix mit den
Schutzringmechanismen bzw. den Trust-Level-Implementierungen zu verbinden, um die
bestehenden Mängel der Zugriffsmatrix zu reduzieren [BIS 90]. Ein Modell das
die Vertraulichkeit stärker behandelt als die Integrität ist das
Biba Integrity Model. Das Denning Information Flow Model betrachtet die
Fliesrichtung der Information und löst dadurch das Problem der
Sicherheitsklassifikationen, dadurch sind spezifischere Sicherheitsaussagen
möglich [CLS 94,SUM 97]. Das Rushby Separability Modell geht näher auf ein
Referenz Monitor Konzept ein, wobei eine Policy-Spezifikation des
Monitors nötig wird. Das Take-Grant Modell ist ein Capability basiertes Modell
indem ein Protection Graph eingesetzt wird.
Eine grundsätzliche Schwachstelle aller Modelle liegt jedoch in der einseitigen Berücksichtigung der Anforderungen [POW 93,VOS 95,SUM 97].
Letztendlich ermöglicht kein existierendes Sicherheitsmodell die Modellierung anwendungsspezifischer Sicherheitspolitiken. Eine anwendungsspezifische Politikspezifikation müsste differenzierte benutzerbestimmbare Festlegungen und anwendungsspezifische Informationsflussbeschränkungen enthalten. Desweiteren müssten noch weitere Eigenschaften, wie Authentifikation und Auditing festgelegt werden [ECK 98].
Formell stellt eine Zugriffskontrollpolitik (engl. Security Policy)
eine Menge an Ausführungen dar, welche definiert, was erlaubt ist oder was nicht.
Einfache Zugriffskontrollverfahren stellen die Zugriffskontrollpolitik durch
z.B. Zugriffskontrolllisten oder Zugriffsrechte dar.
Die Definition und Überprüfung der Policies wird durch die
Größe und Anzahl der eingesetzten Zugriffskontrollmechanismen
komplexer und schwieriger [FAL 00].
Die Zugriffskontrollpolitiken sollte von dem Durchsetzungsmechanismus
unabhängig und getrennt sein. Dadurch sind sie
nicht unnötig eingeschränkt. Zudem kann ein jeweils passender
Mechanismus ausgewählt und so auch leicht ausgetauscht werden.
Betrachtet man Zugriffskontrollpolitiken, unterscheiden sie sich oft dadurch,
wer die Zugriffskontrollpolitik bestimmt.
Zugriffskontrollpolitiken können vom System (MAC), von einem Benutzer (DAC) oder von
von beiden festgelegt sein.
Betrachtet man bestehende Sicherheitskonzepte, so kommt z.T. nur eine systemglobale Politik zum Einsatz. In diesem Fall können in der Regel jedoch die Sicherheitsanforderungen der spezifischen Anwendung und der vorhandenen Ausführungsumgebungen oft nicht erfüllt werden. Kommt nur eine systemglobale Sicherheitspolitik zum Einsatz, so wie beispielsweise in Java, stehen nur die Anforderungen der jeweiligen Ausführungsumgebung im Vordergrund [ECK 98].
Bei der benutzerbestimmbaren Zugriffskontrollpolitik (DAC) können Zugriffe beliebig autorisiert werden. Dabei ist durch Administrationsrechte festgelegt, wer welche Zugriffe autorisieren darf. In der Regel kann der Eigentümer des Objekts die Zugriffskontrollpolitiken seines Objekts bestimmen. Benutzerbestimmbare Zugriffskontrollpolitiken ermöglichen dem Eigentümer eines Objekts, Zugriffsrechte an dritte weiterzugeben. Wird ein Zugriffsrecht an eine dritte Entität weitergegeben, kann nicht kontrolliert werden, an wen die Informationen weitergeleitet werden.
Die benutzerbestimmbare Zugriffskontrollpolitik ist die gebräuchlichste Form der Zugriffskontrolle. Der Vorteil ist die feinere Granularität, die dadurch gegeben ist, dass jeder Eigentümer die gewünschten Zugriffsrechte auf seine Objekte selbst setzt.
Betrachtet man die systembestimmte Zugriffskontrolle, so stellt die benutzerbestimmbare
Zugriffskontrolle keinen Ersatz, sondern eine Ergänzung dar.
Eine systembestimmte Zugriffskontrolle wird so um feinere Einstellungen bezüglich
der Zugriffskontrolle erweitert.
Der Einsatz einer systembestimmten Zugriffskontrolle ist anzuraten, da eine alleinige
benutzerbestimmbare Zugriffskontrolle verletzbarer ist.
Definition: DAC (nach [GAL 87, 5. DEFINITIONS]):
``A means of restricting access to objects based on the identity of
subjects and/or groups to which they belong. The controls are
discretionary in the sense that a subject with a certain access permission
is capable of passing that permission (perhaps indirectly) on to any
other subject.''
Ein potentielles Problem der benutzerbestimmbaren Zugriffskontrolle stellt das löschen von Subjekten und Objekten dar. Nach dem Löschen muss sichergestellt werden, dass die Referenzen eines gelöschten Objekts keinen ungewollten Zugriff auf ein neu erzeugtes Objekt ermöglichen. Dabei kommt es auf den eingesetzten Mechanismus an. Wird ein subjektbasierter Mechanismus eingesetzt, so gestaltet sich das Löschen der Objekte schwierig, im Gegensatz dazu ist das Löschen von Subjekten bei einem objektbasierten Mechanismus problematisch.
Wird zum Beispiel die Zugriffskontrollliste (ACL) als subjektbasierter Mechanismus
verwendet, ist das Löschen von Objekten problemlos möglich, da die ACL mit dem
Objekt verbunden ist und damit ebenfalls gelöscht wird. Beim Löschen eines
Subjekts hingegen besitzen Zugriffskontrolllisten Einträge, die nicht mehr
gültig sind, bzw. bei der Erzeugung eines neuen Subjekts mit demselben Namen
z.B. dazu führen können, dass das Subjekt ungewollterweise autorisiert ist.
Die systembestimmte Zugriffskontrolle (MAC) regelt die systemglobalen Einstellungen.
Die Regeln der Zugriffskontrolle, die festlegen, welche Zugriffe zugelassen sind, sind
fest vorgegeben. Ein Implementierungsbeispiel ist z.B. das Multilevel Security Konzept.
Es stellt klassifizierte Umgebungen (Trust-Levels) bereit, die unterschiedliche
Sicherheitslevels darstellen. Eine Entität gehört jeweils einem Sicherheitslevel an.
Die Sicherheitslevels bilden dabei eine Hierarchie, die auch die Zugriffsrechte
regelt [GAL 87]. Es besteht eine zwingende, verbindliche Zugriffskontrolle
(Mandatory Access Control).
Ein weiteres Beispiel der Implementierung einer systembestimmten Zugriffskontrolle
ist das Konzept des Ringschutzes (Ring Structures) [SAL 74]
von MULTICS [SUM 97].
Die Sicherheitslevels können je nach Anwendungsart unterteilt sein, wobei sie
Arbeitsbereiche bzw. schutzbedürftige Umgebungen widerspiegeln.
Ein Beispiel einer systembestimmten Zugriffskontrollpolitik ist z.B. die
Festlegung von zwei Sicherheitslevels: [secure] und [default].
Jeder Entität wird nun ein Sicherheitslevel zugeteilt.
Beispielsweise könnte ein Benutzer A und die Datei ``ausgaben.txt'' dem
Sicherheitslevel [secure] angehören.
Auf die Datei können nun nur Benutzer des Sicherheitslevels [secure] zugreifen.
Jeder Zugriff von einem Benutzer des Sicherheitslevels [default] scheitert.
Betrachtet nun der Benutzer A die Datei, so kann er sie nicht an einen Benutzer
des Sicherheitslevels [default] weiterreichen. Auch nicht, wenn er der Eigentümer
der Datei ist.
Die systembestimmte Zugriffskontrolle bietet aus diesem Grund einen höheren Schutz. So schützen die systembestimmten Zugriffskontrollen z.B. auch vor Trojanischen Pferden. Hat z.B. ein Angreifer (Benutzer ``B''), der dem Sicherheitslevel [default] angehört, dem Benutzer ``A'' ein Programm zur Ausführung gegeben, das zusätzlich zu seiner eigentlichen Aufgabe noch die Datei ausgaben.txt an Benutzer ``B'' sendet, so scheitert dies aufgrund des unterschiedlichen Sicherheitslevels. Wird ein MAC Mechanismus implementiert, so sind die Subjekte und Objekte mit Sicherheitsmarken zu kennzeichnen, welche die Zugehörigkeit der Entität ausdrückt [OPP 97].
Andererseits kann es auch vorkommen, dass aufgrund unterschiedlich eingesetzter
Konzepte oder Mechanismen einzelne Teilpolitiken existieren, die jedoch von
einer Stelle aus verwaltet werden sollen. Die Schwierigkeit bei der Verwaltung
einzelner Teilpolitiken besteht in den oft unterschiedlich eingesetzten
Policysprachen, den unterschiedlichen Einträgen und dem fehlenden Gesamtüberblick.
So ist es beispielsweise nur sehr schwer möglich, Zusammenhänge der einzelnen Politiken
zu erkennen bzw. nachvollziehen zu können. Wünschenswert ist, eine Gesamtpolitik
über alle Teilpolitiken zu besitzen. Änderungen an dieser Gesamtpolitik wirken
sich dann jeweils auf die einzelnen Teilpolitiken aus. Betrachtet man eine
Gesamtpolitik, so ist es erforderlich, dass sich aus ihr einzelne Zugriffskontrollpolitiken
für die jeweils eingesetzten Zugriffskontrollmechanismen extrahieren lassen, die dann
an der richtigen Stelle durchgesetzt werden können.
Eine Möglichkeit, Teilpolitiken in eine Gesamtpolitik zu überführen, besteht in der Verknüpfung von Zugriffsrechtemengen [FAL 00]. Die Verknüpfung basiert dabei auf definierten Operatoren. Zugriffskontrollpolitiken können so konjunktiv und disjunktiv verknüpft werden. Die einzelnen Zugriffskontrollpolitiken können auf Teilmengen ihrer Attribute projiziert werden, wodurch nur die für die Entscheidungsfindung wichtigen Kriterien aus den beteiligten Zugriffskontrollpolitiken herausgefiltert werden.
Organisationsdomänen (Functional Domains) sind Gruppierungen von einzelnen Komponenten, die nach ihren funktionellen Aufgaben zusammengefasst werden. Betrachtet man einzelne Funktionsbereiche, so können auch hier wiederum Komponenten zusammengefasst werden, damit z.B. für diese Komponenten eine gemeinsame Sicherheitspolitik durchgesetzt werden kann.
Die Einteilung in Verwaltungsdomänen (Administrative Domains) wird vorgenommen,
um Domänen mit genau einer Verwaltungsautorität zu beschreiben [HAN 99].
Die einzelnen Domänen können dabei als Schutzdomänen aufgefasst werden. In verteilten Systemen können Administratortätigkeiten auch in zentrale und in lokale Schutzdomänen aufgeteilt werden. Zentrale Sicherheitspolitiken (systemspezifische Sicherheitspolitiken) können auf einer Unternehmens-Ebene getroffen werden, lokale (anwendungsspezifische Sicherheitspolitiken) jeweils auf der betreffenden lokalen Ebene.
Zentrale Sicherheitspolitiken und die jeweiligen dazugehörenden Operationen
müssen demnach zentral spezifiziert werden. So können hier z.B. spezifische
Rollen und ihre enthaltenen Zugriffsrechte definiert werden. Oder es können
Zugriffsrechte an bestimmte Subjektgruppen vergeben werden.
Die Gewährung bzw. Entziehung der Zugehörigkeit der spezifischen Rollen bzw.
die Zuteilung der Subjekte in Gruppen könnten dann von den Administratoren auf
der lokalen Seite vorgenommen werden.
Eine Sicherheitspolitik ist immer für einen bestimmten Bereich zuständig. Um Bereiche
abstecken zu können, eignet sich die Einteilung in unterschiedliche Domänen.
Finden domänenübergreifende Zugriffe statt, nimmt die Komplexität der
Zugriffskontrolle zu. Hier kann es vorkommen, dass Zugriffskontrollpolitiken von zwei bzw.
mehreren Parteien durchgesetzt werden sollen [FAL 00].
Müssen mehrere Sicherheitspolitiken durchgesetzt werden, kann es zu Unstimmigkeiten
und nicht auflösbaren Konflikten kommen. Diese Konflikte können z.B. durch eine
domänenübergreifende Sicherheitspolitik (Metapolicy), die die beteiligten Politiken
widerspiegeln, beseitigt werden. Dabei stellt die domänenübergreifende Politik
eine Politik der Teilpolitiken dar. Die Metapolicy muss dabei die jeweils in den
Teilpolitiken eingesetzten Policysprachen verstehen und umsetzen können.
Um mehrere Sicherheitspolitiken (Teilpolitiken) durchsetzen zu können, existieren unterschiedliche Verknüpfungsmöglichkeiten:
Die Verknüpfung der Sicherheitspolitiken kann entweder direkt definiert sein, wobei
die enthaltenen Zugriffsrechte definiert sind, oder es handelt sich um eine
Sicherheitspolitik, die aus verknüpften, bereits definierten Sicherheitspolitiken
besteht.
Betrachtet man die Einträge innerhalb der Sicherheitspolitiken, so besteht ein Eintrag zumeist aus [FAL 00]:
Betrachtet man nun die Verknüpfungsmöglichkeiten der einzelnen Sicherheitspolitiken, so existieren folgende Möglichkeiten:
Zwei Einträge der Sicherheitspolitiken, die sich nicht widersprechen, können so verknüpft werden, dass die resultierende Sicherheitspolitik die Zugriffe
Letztendlich gilt es einen Weg zu finden, die einzelnen Teilpolitiken zu verbinden ohne die Informationssicherheit zu gefährden.
In dem Modell müssen weitere Eigenschaften bzw. Bedingungen definiert werden, wie z.B.:
Wichtig ist hier, wie bestimmte Ausführungen beschrieben werden können,
um innerhalb der Sicherheitspolitik adressiert werden zu können.
Die Menge der Ausführungen wird in Regeln definiert.
Die Regeln bilden dabei eine Liste von Subjekten auf eine Liste
von Objekten auf eine bestimmte Anzahl von Aktionen ab.
Mithilfe dieser Regeln können dann z.B. Restriktionen der Aktionen
von Subjekten auf Objekte ausgedrückt werden.
Die Beschreibung der Sicherheitspolitik anhand individueller Subjekte und Objekte ist im Allgemeinen nicht praktikabel. Zumeist ist die Anzahl der beteiligten Entitäten zu groß bzw. noch unbestimmt und kann daher nicht erfasst werden. Andererseits ist dadurch auch der Verwaltungsaufwand zu hoch, da jedes spezifische Subjekt innerhalb der Sicherheitspolitik benannt werden muss. Durch Gruppierung und Zuordnung von Personen zu Aufgaben (Rollenverteilung) wird die Komplexität stark verringert.
Folgend soll der Ablauf eines Zugriffs erläutert werden. Anhand der vergebenen Zugriffsrechte werden während der Interaktion zwischen einem Subjekt und einem Objekt die getätigten Zugriffe auf ihre Berechtigung hin überprüft (Rechteprüfung (engl. Access Control)).
Betrachtet man die einzelnen Punkte, so sind der Zugriffssteuerung noch weitere
Aufgaben und Prozesse zuzuordnen (in Anlehnung an [CLS 94]).
Autorisation (Rechtevergabe)
Authentifikation
Die Identifizierung reicht alleine jedoch nicht aus. Da die Informationssicherheit von dieser Identifizierung abhängt, ist es erforderlich die ermittelte Identität zu verifizieren. Nachdem sichergestellt wurde, dass es sich wirklich um die angegebene Identität handelt, handelt es sich um eine authentifizierte Identität.
Die Authentifikation eines Benutzers oder eines Programms, welches einem Benutzer zugeordnet ist, erfolgt vor der ersten Interaktion mit dem System. Durch die eindeutige Identifikation und Verifikation des zugreifenden Subjekts kann die Berechtigung des Subjekts ermittelt werden.
Die Aufgabe der Identifikation und Authentifikation übernimmt dabei
die Zugangskontrolle. In Netzwerken kann dabei zwischen der zentralen
und der lokalen Zugangskontrolle unterschieden werden.
Die lokale Zugangskontrolle bezeichnet dabei den Zugang zu dem
Rechensystem. Die zentrale Zugriffskontrolle wird von i. Allg. von dem
Netzwerkbetriebssystem vorgenommen, wobei die Nutzung bestimmter
Netzdienste z.B. durch die Eingabe der Benutzerkennung und eines
Passworts ermöglicht wird [VOS 95,OPP 97].
In der Zugangskontrolle ist das Passwortkonzept am weitesten verbreitet. Sicherheitshardware, Memory- und Smart-Cards kommen nur in speziellen Anwendungsbereichen wie Home-Banking zum Einsatz. Zur Verifikation der Identität und der Integrität kommen klassische Techniken zum Einsatz. So z.B. digitale Signaturen und Zertifikate [ECK 98].
Es existieren verschiedene Formen von Zugriffsrechten. Die Wahl der zu verwendenden Zugriffsrechte hat einen großen Einfluss auf die Datenintegritätseigenschaften. Es gibt sowohl universelle Zugriffsrechte als auch objektspezifische Zugriffsrechte [ECK 98]. Typische universelle Zugriffsrechte sind Read (Lese-), Write (Schreibe-), Execute (Ausführ-) und Delete (Lösch-) Rechte. Universelle Zugriffsrechte beinhalten nur eine Aktion und nicht das Objekt auf das Zugegriffen wird. Sie können daher keine objektspezifische Operationen bezeichnen. Durch die Vergabe von universellen Zugriffsrechte werden den Subjekten große Freiheitsgrade gewährt.
Ein Pendant dazu stellen die spezifischen Zugriffsrechte dar.
Innerhalb der spezifischen Zugriffsrechte werden ebenso die Objekte
adressiert.
Durch objektspezifische Zugriffsrechte ist es möglich, Zugriffsrechte
zugeschnitten auf die spezifische Aufgabe des Subjekts zu vergeben.
Die Zugriffsrechte entsprechen den Operationen, die
Subjekte auf Objekte (allgemein oder spezifisch) ausführen.
Betrachtet man das Schreibrecht näher, so sind noch weitere feingranularere Zugriffsrechte denkbar. An diesem Beispiel wird auch deutlich, dass je feingranularer Zugriffsrechte sind, desto eher eine anwendungsspezifische Vergabe von Zugriffsrechten möglich ist [GAL 87].
Administrationsrechte
Ein besonderes Zugriffsrecht ist das Administrationsrecht. Administrationsrechte
existieren zumeist bei benutzerbestimmten Zugriffskontrollpolitiken (DAC), wobei
hier der Eigentümer des Objekts das Administrationsrecht auf sein Objekt
besitzt. Nur der Besitzer des Administrationsrechts auf das Objekt kann Zugriffe auf
das Objekt autorisieren bzw. widerrufen.
In einer rollenbasierten Zugriffskontrolle könnte das Administrationsrecht in einer Administrationsrolle wiedergespiegelt sein. Für unterschiedliche Administrationsaufgaben könnten auch unterschiedliche Administrationsrollen existieren, die jeweils die für die Erledigung der Aufgabe notwendigen Berechtigungen beinhalten. Dadurch ist eine feinere Einteilung in Administrationsumgebungen möglich. Eine eventuell vorhanden Rollenhierarchie integriert dabei die Vorteile einer systembestimmten Zugriffskontrolle (MAC).
Die Rechtevergabe (Autorisation) sollte ein semantisches Konzept darstellen, welches
von systemspezifischen Mechanismen getrennt ist. Zur Repräsentation eines
unabhängigen Konzepts wird eine Sprache benötigt, die den Autorisationsanforderungen
genügen. Die Sprache muss eine formale Semantik besitzen, so dass die Bedeutung einer
Autorisationsanforderung präzise festgelegt und überprüft werden kann [WOL 92].
Die Rechtevergabe hat enorme Auswirkungen auf die Sicherheit eines Systems. Um die Sicherheit nicht zu gefährden müssen bei der Autorisation folgende Punkte beachtet werden [FAL 00]:
In der Literatur finden sich noch weitere Anforderungen die erfüllt werden müssen, um bei den Autorisationsvorgänge die Informationssicherheit nicht zu gefährden [BRO 92]:
Je nach Anforderung können dabei auch unterschiedliche Strategien zum Einsatz kommen.
Die Vergabe von Zugriffsrechten kann entweder die Strategie des expliziten Verbietens
verfolgen, d.h. alle Zugriffsarten bis auf die verbotenen sind erlaubt
oder aber auch die Strategie des expliziten Erlaubens, d.h. alle Zugriffe
bis auf explizit erlaubten werden unterbunden [ECK 98].
Subjekt- ,objekt- und anwendungsspezifische Zugriffsrechte
Die Rechtevergabe vergibt Zugriffsrechte im Idealfall nach dem Least-Privilege
Konzept. Dies beinhaltet die objekt- und die subjektspezifische Rechtevergabe.
Unter einer subjektspezifischen Rechtevergabe versteht man dabei die Möglichkeit
der Vergabe von Zugriffsrechten an ein einzelnes spezifisches Subjekt.
Können einzelne Subjekte individuell autorisiert werden, wird durch den
Einsatz von objektspezifischen Zugriffsrechten (vgl. Kapitel 2.6.2)
eine anwendungsspezifische Autorisation
ermöglicht. Bei einer anwendungsspezifischen Autorisation werden den spezifischen
Subjekten nur die Zugriffsrechte zugeteilt, die sie für die Bearbeitung der
Aufgabe benötigen.
Diese Minimalzuweisung von Zugriffsrechten ist jedoch praktisch schwer zu
realisieren da sich die dafür notwendigen Informationen in der Regel dynamisch
ändern. Die meisten Konzepte sind jedoch statischer Art.
Autorisationsmethoden
Es existieren unterschiedliche Methoden der Autorisation. Subjekt- oder objektbasierte
Methoden sind vor allem bei Betriebssysteme verbreitet. Die sprachbasierte-Methode
ist eine Methode, welche die Autorisation von Subjekten über eine
Zugriffskontrollpolitik realisiert.
Bei den Protection Bits handelt es sich nicht um eine vollständige Implementierung der Zugriffsmatrix. Ein Zugriffsrecht kann nicht einem einzelnen Benutzer zugeteilt oder entzogen werden.
Einzelne Programme können Capabilities besitzen. Capabilities können aber auch
z.B. in einer Datei gespeichert sein. Sie werden dabei durch Hardware- oder
Softwaremechanismen bzw. durch Verschlüsselungsmechanismen geschützt.
Ein Capability kann unter Umständen auch weitergereicht werden und so anderen
Subjekten den Zugriff auf spezifische Objekte ermöglichen.
Die Delegation von Zugriffsrechten ist somit möglich.
Durch Capabilities kann das Least-Privilege Prinzip erfüllt werden, wobei
zudem eine sich dynamisch ändernde Umgebung unterstützt wird [SUM 97].
Durch die Möglichkeit, Capabilities weitergeben zu können, ist es jedoch sehr schwer bzw. unmöglich bestimmen zu können, wer gerade Zugriff auf ein spezifisches Objekt hat. Dies macht die Implementierung einer vollständig benutzerbestimmbaren Zugriffskontrollpolitik (DAC-Implementierung) nicht einfach. Untersuchungen zur Implementierung eines vollständigen DAC-Mechanismus mittels Capabilities finden sich in ``An augmented capability architecture to support lattice security and traceability of access'' [HEK 84]. Die Rücknahme von Zugriffsrechten ist ein weiteres Problem bei der Verwendung von Capabilities. Dennoch gibt es auch hier Lösungsansätze, so behandelt der Artikel von D. Redell ``Revokable Capabilities'' [RED 74]. Schwierigkeiten bestehen auch bei der präzisen Definition und Implementierung von Gruppen [GHW 86]. Eine reine Capability-basierte Methode ist aufgrund dieser Nachteile in der Regel ungeeignet.
Durch die große Anzahl von Objekten gestaltet sich jedoch die Passwortverwaltung schwierig, zudem muss für jedes spezifisches Objekt, auf das zugegriffen werden soll, ein neues Passwort verwendet werden, womit ein geeignetes Konzept der Passwortverwaltung benötigt wird.
SECURE, eine für IBM-Betriebssysteme entwickelte Software, implementiert ebenso einen Passwortschutz für jede Datei in sogenannten Dateiprofilen. Dabei sind für jede Datei mehrere Passwörter zulässig, an denen jeweils abgestufte Zugriffsrechte geknüpft werden können [WAE 93]. Passwörter müssen hier nicht per Hand eingegeben werden und sind dem Benutzer sogar unbekannt. Sie werden aus Elementen der Ordnungsmerkmale der Anwendung bzw. des Jobs, wie Auftragsnummer, Programm-, Programmier- und Dateiname vom Sicherungssystem selbst gebildet. Trojaner haben hier keine Chance mehr.
Die durch existierende PKI (z.B. PGP, MISSI, PEM, etc.) authentifizierten Entitäten übertragen ihre Autorität durch ein mit ihrem privaten Schlüssel signierten, speziell designten Attribut Zertifikat. Das Attribut Zertifikat enthält kein Schlüsselmaterial, also beispielsweise keinen öffentlichen Schlüssel (public key), sondern einen Fingerabdruck (Message Digest) der Anwendung, der Privilegien und der Sicherheitspolitik. ANSI X9 und die IETF haben hier Versuche zur Standardisierung gestartet.
Wie drückt man die Privilegien und die Policies im Zertifikat aus? Die Syntax muss durch Maschinen verarbeitbar sein, gut genug um reale Welt Privilegien und Policies aufnehmen zu können, jedoch benutzerfreundlich. Privilegien können z.B. durch privilege= attribute set notiert werden. Sicherheitspolitiken sind hingegen schwieriger zu notieren, da der Schutz, den eine Anwendung bei der Ausübung ihrer Aktivitäten besitzen soll, ausgedrückt werden muss.
Nachfolgend werden Vor- bzw. Nachteile der subjekt- bzw. objektbasierten Methoden
betrachtet. Die Aussagen sind als Diskussionsgrundlage gedacht, da je nach
Betrachtungsweise ein Nachteil auch ein Vorteil sein kann.
Die Vorteile der subjektbasierten Methoden liegt in der feineren Adressierungsmöglichkeit
der Subjekte. So kann hier z.B. explizit einer spezifischen Person ein
Zugriffsrecht erteilt werden. Auch bei einer sich ständig dynamisch änderten
Anzahl von Subjekten ist die subjektbasierte Methode vorzuziehen.
Bei einem Zugriff auf ein Objekt ist in der Regel auch die Kontrollzeit geringer, da
i. Allg. die Zugriffsrechte eines Subjekte stark begrenzt sind und somit keine
große Liste oder ähnliches durchsucht werden muss. Durch subjektbasierte
Methoden können weiter auch dynamische Domains unterstützt werden, so dass
Zugriffsrechte nur für bestimmte Domänen gültig sind.
Betrachtet man die Umgebung, so unterstützen subjektbasierte Methoden
eine sich dynamisch ändernde Umgebung. Dadurch dass die Zugriffsrechte an den
Subjekten haften, ist in der Regel auch eine Delegation der Zugriffsrechte
leichter zu realisieren.
Die Nachteile einer subjektbasierten Methode liegen in der Problematik der
Rücknahme von Zugriffsrechten. Desweiteren müssen auch die Objektnamen
eindeutig sein. Nach einer Änderungen der Objektnamen müssen so
Subjekte oft neu autorisiert werden. Sind außerdem sehr viele Objekte
vorhanden, sind subjektbasierte Methoden oft unhandlich.
Ein Defizit stellt auch die Vergabe von Zugriffsrechten an Gruppen dar.
Aus der Administrationssicht sind subjektbasierte Methoden weniger überschaubar.
Aussagen wie ``wer hat auf das Objekt X Zugriff'', sind nahezu unmöglich.
Die Vergabe, das Löschen und das Ändern von Zugriffsrechten ist
ebenso schwierig.
Betrachtet man z.B. Capability basierte Systeme, so existieren noch
der Kritikpunkt des teuren Aufrufs.
Die Systemperformance und das Einsperren der Privilegien sind problematisch. Entweder
muss die Hardware Tagged Memory bereitstellen, oder der Aufruf läuft über einen
Umweg zwischen dem Prozess und den Capabilities.
Betrachtet man objektbasierte Methoden, so liegen die Vorteile in der feingranularen
Adressierungsmöglichkeit der Objekte. Da die Zugriffsrechte direkt an den
Objekten haften, ist so die Vergabe der Zugriffsrechte für einzelne Objekte möglich.
Ändert sich die Anzahl der Objekte bzw. ändern sich die Objekte häufig, so ist eine
objektbasierte Methode gegenüber einer subjektbasierten Methode vorzuziehen.
Auch die Rücknahme der Zugriffsrechte gestaltet sich hier einfacher.
Die Vergabe von Zugriffsrechten an Gruppen von Subjekten ist leicht möglich,
zudem können jederzeit Aussagen gemacht werden, wer gerade Zugriffsrechte auf dieses
Objekt besitzt. Sollen Zugriffsrechte vergeben, geändert oder gelöscht werden,
stellt dies bei einer objektbasierten Methode in der Regel kein Problem dar, da die
Zugriffsrechte zentral zugänglich sind.
Nachteilig wirkt sich eine objektbasierte Methode oft bei der Granularität der Adressierung der Subjekte aus. So kann hier in der Regel nicht explizit nur eine Person berechtigt werden. Findet ein Zugriff statt, so sind die Kontrollzeiten oft sehr groß, da viele Subjekte Zugriff auf ein Objekt haben und somit eine große Anzahl von Subjekteinträgen durchsucht werden muss. Zudem können bei der objektbasierten Methode durch komplexe Wechselwirkungen zwischen den Objekten Widersprüche bezüglich der Rechtevergabe entstehen.
Der Vorteil der Autorisation anhand einer Policy liegt darin, dass Zugriffskontrollentscheidungen anhand vorhandener Kriterien getroffen werden können. Werden Entscheidungen anhand vorhandener Kriterien getroffen, müssen keine neue Kriterien (wie z.B. Protection Bits, ...) eingeführt werden.
Erfolgt die Spezifizierung anhand einer geeigneten Policysprache, gestaltet sich die Rechtevergabe flexibler, unabhängiger und ausdrucksstärker. Subjekte und Objekte können je nach Policysprache feingranular adressiert werden.
Mischformen der Autorisation durch einen sprachbasierten Ansatz und einer subjekt- bzw. objektbasierten Methode vereinen die Vorteile beider Seiten. So könnte ein Kriterium einer Policy ein Capability oder ein Eintrag in einer Zugriffskontrollliste (ACL) sein.
Die Delegation kann erfolgen durch [FAL 00]:
Administration der Rechtevergabe
Die Notwendigkeit der Administration der einzelnen Modell führte zu unterschiedlichen
Kontroll Modellen [GAL 87].
Eine Gruppe besteht aus einzelnen Subjekten, die etwas gemeinsam haben (z.B. das Arbeiten am gleiche Projekt). Problematisch ist die Vergabe von Zugriffsrechte an Gruppen dann, wenn ein Benutzer in mehreren Gruppen vertreten ist und sich dadurch die einzelnen Zugriffsrechte aufaddieren. Eine anwendungsspezifische Vergabe von Zugriffsrechten ist dann nicht mehr möglich [ECK 98].
Ein Rolle hingegen drückt die Beziehung Subjekt-Auftrag aus. Je nach Auftrag sind
unter Umständen unterschiedliche Rechte notwendig. Verschiedene Subjekte
können einer Rolle zugewiesen bekommen.
Bei Systemen, welche Role Based Access Control und Domain and Type Enforcement unterstützen, können Policies einfacher durch gruppierte Subjekte oder Objekte ausgedrückt werden.
Eine Rolle modelliert dabei die Aktion, die das Subjekt ausführen muss und die Information, auf die ein Subjekt zugreifen darf [ECK 98]. Es stehen also nicht die Objekte und Informationen im Mittelpunkt.
Wird ein rollenbasierter Mechanismus eingesetzt, muss z.B. nicht mehr für jedes Subjekt eine eigene Zugriffskontrollliste (ACL) angelegt werden. Dadurch wird die Komplexität und die damit anfallenden Kosten der Sicherheitsadministration in großen Netzwerken erheblich reduziert. Die Administration und das Management der Privilegien ist vereinfacht: Rollen können erneuert werden, ohne die Privilegien jedes einzelnen Nutzers auf einer individuellen Basis zu erneuern.
Werden Zugriffsrechte an Rollen vergeben, bleibt die Rechtevergabe unberührt von einer eventuell vorhandenen starken Dynamik der Subjekt-Erzeugung und -Terminierung [ECK 98].
RBAC ist eine Alternative zu den traditionellen DAC- und MAC-Policies. Sicherheitspolitiken werden anhand der natürlichen Organisationsstruktur spezifiziert und durchgesetzt. Jeder Nutzer wird einer oder mehreren Rollen zugeteilt und jeder Rolle werden eine Menge von Privilegien zugeteilt. Die Realisation einer rollenbasierten Autorisation besteht i. Allg. aus:
Die Analyse, wie eine Organisation operiert, gibt Auskunft über die bestmöglichste Definition der Rollen. Durch die Rollen-Hierarchie können gemeinsame Attribute zusammengefasst werden. Der Vorteil des Rollenkonzepts liegt in der geringeren Veränderung der Zugriffsrechte, die eine Rolle zugeteilt bekommt. Die Änderung der Zugriffsrechte von einzelnen Benutzern ist hier weitaus dynamischer.
Die Verwendung von Rollen kann sich u.U. jedoch nachteilig auf die Flexibilität in Bezug auf die Differenzierung der Rechtevergabe auswirken [ECK 98].
Subjektbasierte Methoden haben die Problematik, Objekte möglichst feingranular
adressieren zu können. Betrachtet man die objektbasierten Methoden so liegt die
Problematik in der feingranularen Adressierung der Subjekte.
Die sprachbasierte Methode ist i. Allg. ausdrucksstärker und flexibler. Durch die
sprachbasierte Methode lassen sich i. Allg. alle Entitäten feingranular adressieren.
Die Problematik liegt hier in der Suche nach einem geeigneten Mechanismus, der die
Zugriffskontrollpolitik durchsetzen kann.
Um Vorteile von subjekt-, objekt- und sprachbasierten Methoden zu vereinen, sind auch Mischformen denkbar.
Der Schutz der Information sollte auf der Ebene der Funktionen ansetzen, die für den Zugriff und die Bearbeitung der Informationen genutzt werden. Nach Lieb [LIE 90] lassen sich fünf Schutzebenen unterscheiden. Das Wirkungsfeld wird mit absteigender Ebene tendenziell begrenzter und spezifischer.
Hat ein Subjekt die ersten zwei Sicherheitsebenen passiert, ist sicherzustellen,
dass der Zugriff auf Daten und Funktionen im erwünschten Umfang begrenzt bleibt.
Relevant dafür ist die Datenzugriffs- und Funktionsberechtigung, welche sich durch
spezifische Schutzkonzepte, wie z.B. das Konzept der
Zugriffsmatrix (vgl. Kapitel 2.4.1),
realisieren lassen. Jeder Zugriff ist
somit einer Zugriffskontrolle zu unterziehen. Zu beachten ist dabei, dass die
Rechtsicherheit eines Systems von der Fähigkeit der Zugriffskontrolle abhängt,
sicher zu stellen, dass die Zugriffskontrolle nicht umgangen werden kann.
Die Zugriffskontrolle ist die Durchsetzungsinstanz der Zugriffskontrollpolitik.
Sie beantwortet Fragen über die geltende Zugriffskontrollpolitik und sucht,
falls nötig, nach einer Entscheidung. Was gespeichert wird und wie die Suche
abläuft, hängt dabei von der spezifisch definierten Abstraktion des Systems ab.
Aus Performancegründen kann die Zugriffskontrolle in der Regel
Zugriffskontrollentscheidungen zwischenspeichern.
Am Beispiel UNIX sind die Zugriffsrechte (Protection Bits) der Directories und der Dateien die Entscheidungskriterien. Sie sind auf der Festplatte oder Diskette gespeichert. Die Rolle der Zugriffskontrolle übernimmt der Kernelcode, der anhand der Protection Bits die Entscheidung trifft, ob der Zugriff zulässig ist oder nicht.
Ein Referenz Monitor besitzt folgende Eigenschaften:
Um diese Prinzip durchzusetzen und so die Zugriffskontrolle durchzuführen können hardwar- und softwarebasierte Schutzmechanismen verwendet werden. Die hardwarbasierten Mechanismen werden jedoch zunehmend von softwarebasierten Mechanismen verdrängt. Softwarebasierte Mechanismen sind in der Regel flexibler, leichter zu realisieren, haben Performance Vorteile und eignen sich vor allem zur Implementierung einer plattformunabhängigen Zugriffskontrolle. Hardwarebasierte Kontrollen beschränken sich zumeist auf grobgranulare und unflexible Speicherschutzmaßnahmen und sollen daher nicht weiter betrachtet werden [BAF 00]. Die Abb. 6 gibt einen Überblick über bestehende Schutzmechanismen.
Der Hauptvorteil eines softwarebasierten Schutzes ist die Portabilität.
Würde ein hardwarebasierter Schutz angewandt, müssten die Systeme
Zugriff auf die Page Tables und Systemaufrufe unterstützen. Diese
Mechanismen sind jedoch nicht einheitlich auf allen Plattformen vorhanden.
Der softwarebasierte Schutz kann in zwei Teile aufgeteilt werden [BAF 00]:
Der Speicherschutz verhindert unautorisierte Zugriffe auf den Speicher oder auf den ausführbaren Code. Dies reicht jedoch nicht immer aus. Müssen auch andere Ressourcen (z.B. Files, Displays, ...) geschützt werden, werden weitere Sicherheitsdienste benötigt. Die Sicherheitsdienste ergänzen dann den Speicherschutz.
Während z.B. der Speicherschutz das unberechtigte Lesen der als private deklarierten Methoden verhindert, überprüft ein Sicherheitsdienst aktiv, ob das Subjekt hinreichend autorisiert ist.
Zumeist werden Ausnahmebehandlungen verwendet, um die Zugriffskontrolle durchzusetzen. Durch die Verwendung von Ausnahmebehandlungen kann während der Laufzeit eine Einhaltung von aufgestellten Regeln durchgesetzt werden. Ein Programmierer ist z.B. in der Lage, gezielt Zugriffe auf Kontrollkomponenten umzulenken.
Die am häufigsten antreffenden Modelle sind Name Space Management, Capabilities
und Extended Stack Introspection. Es gibt jedoch auch noch andere Modelle bzw.
Mischformen. So z.B. die Verwendung von Proxy-Objekten oder die Verwendung von
Prozessen zur Durchsetzung der Zugriffskontrollpolitik.
![\includegraphics [totalheight=0.15\textheight]{ja-sec.eps}](img10.gif)
Capabilities
Grundsätzlich ist eine Capability ein fälschungssicherer Zeiger auf eine zu
kontrollierende System Ressource. Eine Capability muss explizit erteilt werden.
Dies kann bei der Initialisierung oder beim Aufruf einer anderen Capability
geschehen. Hat ein Programm einmal eine Capability, kann dieses Programm die
Capability einmal oder mehrmals nutzen und unter Umständen an andere Programme
weiterreichen. Besitzt ein Programm ein Capability, so muss es ihm vorher zugewiesen
worden sein [BAF 00]
Extended Stack Introspection
Das Prinzip ist denkbar einfach. Bevor ein Zugriff erlaubt wird, wird überprüft,
ob der Programmcode innerhalb des Aufrufstacks die notwendige Berechtigung besitzt,
die Operation auszuführen [BAF 00].
Da oftmals auch unautorisierte Programme Zugriffe auf geschützte Informationen ausführen müssen, um ihre Aufgabe zu erfüllen, besteht die Möglichkeit den Programmcode kurzzeitig durch einen expliziten Aufruf zu autorisieren.
Ein Problem ist jedoch, dass ein Prozess Zugriff auf verschiedene Ressourcen hat.
Jemand, der diesen Prozess ausführt, sollte nicht auf alle Ressourcen
Zugriff haben.
Dieses Problem ist unter dem Namen Confused-Deputy Problem bekannt und es
gab diese Problematik auch schon innerhalb von Betriebssystemen.
Nicht ausreichend gesicherte Funktionen ermöglichten den Zugriff auf
Ressourcen und stellten somit eine Sicherheitslücke dar. In UNIX sind hier
z.B. die S(ecure)-Bit Programme [HER 99] zu nennen, die oftmals eine
Schwachstelle darstellen und des öfteren dazu führten, dass unberechtigte
Nutzer den Root Status erlangten [ANO 99].
Name Space Management
Dieser Mechanismus wird benutzt, um Klassen zu verstecken oder auszutauschen.
Durch die Verwendung des Name Space Managements kann eine Zugriffskontrollpolitik
durchgesetzt werden, indem kontrolliert wird, wie die
Klassennamen eines Programms aufgelöst werden. Dabei kann eine Klasse aus
der Name Space Umgebung entfernt werden (Klassenaufruf misslingt), oder der
Name referenziert eine zur Original Klasse kompatiblen Klasse [BAF 00].
Diese Technik wird z.B. in Safe-Tcl [BOR 94] und in Plan 9 [PTP 96] verwendet. Bei Safe-Tcl werden beispielsweise Kommandos vor einem nicht vertrauenswürdigen Interpreter versteckt.
In einer objektorientierten Programmiersprache repräsentieren Klassen Informationen, die geschützt werden müssen. So repräsentiert die File-Klasse das Dateisystem und die Socket-Klasse die Netzwerkoperationen. Ist die File-Klasse und alle andere Klassen, die das Dateisystem beanspruchen für den Aufrufer (Subjekt) nicht sichtbar, so steht das Dateisystem dem Programm nicht zur Verfügung und kann somit auch nicht angegriffen werden. Ein Zugriff auf diese Klasse ist gleichzusetzten mit einem Zugriffsversuch auf eine nicht existente Klasse.
Um nun komplexere Zugriffskontrollpolitiken durchzusetzen, kann man Umgebungen erstellen, die die zu beschützenden Klassen durch kompatible stellvertretende Klassen ersetzen. Die stellvertretende Klasse kann einen Aufruf beispielsweise überprüfen und gegebenenfalls die Original Klasse aufrufen. Damit die Funktionalität erhalten bleibt, muss die stellvertretende Klasse kompatibel zu der Klasse sein, die sie vertritt.
Für ein flexibles und generelles Zugriffskontrollschema ist ein kontrollierbarer Einsatz der stellvertretenden Klassen notwendig. Die Kontrolle bezieht sich dabei z.B. auf privilegierte Nutzer oder Gruppen.
Entscheidungen sind hier statisch und werden vor der Ausführung
des Codes getroffen. Ist in einem Name Space eine Klasse versteckt bzw.
ausgetauscht worden, so gibt es keine Möglichkeit mehr, den
ursprünglichen Zustand wieder herzustellen.
Prozessbasiert Methode
Ein Sicherheitsdienst, welcher die Zugriffskontrollpolitik durchzusetzen hat,
kann auch basierend auf Prozesse realisiert werden.
Jede Anwendung läuft in einer separaten Instanz einer virtuellen Maschine.
Um die Prozess noch weiter aufzuteilen, kann eine separate physikalische
Maschine reserviert werden, um nicht vertrauenswürdigen Code auszuführen.
Der Vorteil eines Prozessmodells, welches auch oft bei Betriebssystemen zum Einsatz kommt, ist die Möglichkeit, jede einzelne Anwendung exakt aufzeichnen zu können. Wird eine Anwendung beendet, so können seine Threads unverzüglich beendet und der Speicherplatz freigegeben werden. Zwei virtuelle Maschinen haben keine direkten Referenzen auf die jeweiligen Daten, stattdessen werden indirekte Referenzen, wie bei Aufrufen von physikalisch getrennten Systemen, verwendet.
Wird eine potentiell gefährliche Operation aufgerufen, so wird eine Nachricht
von der nichtvertrauenswürdigen virtuellen Maschine zu einer
vertrauenswürdigen virtuellen Maschine gesendet, die daraufhin den Zugriff
überprüfen kann. Nachteilig wirkt sich hierbei der große Overhead aus.
Verwendung von Proxy-Objekten
Die Durchsetzung der Zugriffskontrollpolitik kann auch durch den Einsatz
von Proxy-Objekten realisiert werden.
Bei einer Anfrage einer Anwendung wird ein Proxy-Objekt unter
Berücksichtigung der Zugriffskontrollpolitik erzeugt.
Das erzeugte Proxy-Objekt besitzt abgesicherte Schnittstellen zu den einzelnen
Ressourcen.
Proxy-Objekte haben die Nachteile, dass für jede Agenten Instanz, die auf Ressourcen
zugreift, jeweils ein Proxy-Objekt erstellt werden muss.
Dadurch unterstützen sie jedoch auch die Möglichkeit, spezifisch für jede
Subjekt Entscheidungen zu treffen. Zudem können sie dynamisch für jedes
Subjekt erzeugt werden. Wird für einen Agenten ein Proxy-Objekt erstmals
erstellt, so ist die Zugriffskontrolle an sich mit wenig Rechenaufwand
verbunden.
Wrapper-Objekte
Das Subjekt, welches auf ein Objekt zugreifen will, besitzt nur eine
Referenz auf ein Wrapper-Objekt und kann nicht direkt auf das Objekt
zugreifen. Der Wrapper besitzt eine Zugriffskontrollliste, um erkennen zu
können, ob es sich um einen erlaubten Zugriff handelt.
Diese Technik ist, da sie auf einer Zugriffskontrollliste basiert,
nur für eine begrenzte Anzahl von Subjekten geeignet [KAT 98].
Wrapper-Objekte sind zwar leicht zu implementieren und sind auch
transparent gegenüber dem Implementierer, zudem existiert für jede
Ressource ein Wrapper-Objekt, jedoch ist dieser Mechanismus unflexibel.
Jeder Agent muß zum gleichen Zugriffskontrollmechanismus zeigen, der
bei jedem Zugriff durchgeführt wird.
Hybrid-Systeme
Haben die genannte Methoden verschieden Vor- und Nachteile, so wird durch den
Einsatz von Mischformen versucht, die Vorteile einzelner Methoden zu vereinen.
Name Space Management und Capabilities
Name Space Management ist hervorragend für das Verstecken von Klassen geeignet
und könnte deshalb eine gute Basis für eine Implementierung eines starken
Capability basierten Systems dienen. Nur die Klassen, welche die Capabilities
implementieren, können die Original System Klassen sehen.
Stack Inspection und Capabilities
Stack Inspection kann teuer sein hat jedoch hervorragende
Sicherheitseigenschaften. Capability Systeme sind schnell, erfordern
jedoch einen besonderen Programmierstil. Die Kombination bringt die
Vorteile beider Seiten zur Geltung.
Stack Inspection schützt wichtige Aufrufe, so z.B. das Öffnen von Dateien
oder Netzwerkverbindungen, während die Objekte, welche die Capabilities
zur Nutzung bestimmter Targets darstellen, zurückgegeben werden.
Sicherheit ist jedoch nur dann gegeben, wenn Capabilities nicht gestohlen
oder anderweitig in unautorisierte Hände gelangen.
Für ein strenges Capability basiertes System, wobei die einzige Möglichkeit zum Öffnen einer Datei darin besteht, ein Capability zu besitzen, könnte Stack Inspection genutzt werden, um alle bis vom System aufgerufene Datei Interfaces zu blockieren, während den Capability-Klassen der Zugriff gewährt wird. Die Vorteile im Vergleich zu einer rein Capability-basierten Methode liegen darin, dass jeder Zugriff auf jedes Objekt überprüft wird, in der Authentifikation der Subjekte und der Abrechenbarkeit der Zugriffe.
Unterscheidungen der Zugriffssteuerung können anhand der Nutzerverwaltung getroffen
werden. Es existieren Betriebssysteme, die nur einen Nutzer kennen (Windows, DOS) oder
eine Multiuser-Umgebung unterstützen (Windows NT, Unix, Linux), wobei eine
Zugriffskontrolle zumeist nur auf Multiuser Betriebssystemen realisiert
wurde [SUM 97].
Multiuser Betriebssysteme unterstützen den Nutzer im Hinblick auf die Sicherung der Daten und der Programme während der Ausführung. Dabei stützt sich das Betriebssystem auf unterschiedliche Funktionen ab [SUM 97,OPP 97,ECK 98,BRO 92,VOS 95,POW 93]:
Betriebssystemschutz wird i. Allg. durch strikte hierarchische Strukturen
und Privilegien von Systemprogrammen gewährleistet.
Sicherheitskonzepte mit strikter Trennung sowohl
der Anwenderprogramme untereinander, als auch der Daten und der Trennung
der Anwenderprogramme von den Betriebssystemkomponenten gelten
als sicherer [WAE 93].
In der Abb. 7 wird der Zugriffschutz
der einzelnen Anwendungen eines Betriebssystems verdeutlicht. Den Schutz übernimmt dabei
die Ein- und Ausgabe des Betriebssystems. Eine weitere Aufgabe, die das
Betriebssystem hier erfüllt, ist unter anderem die Verwaltung der
Identifikations- und Autorisationstabellen [WAE 93].
Unautorisierter Zugriff auf Anwendungsprogramme sowie auf Daten sind
aufgrund des Schutzes durch das Betriebssystem nicht möglich. Dabei
verwaltet das Betriebssystem die Identifikations- und
Autorisationstabellen, zudem auch das Logging und die Kommunikation mit
dem Nutzer bzw. dem Sicherheitsbeauftragten.
Prozessebasierte Zugriffskontrolle
Bei Betriebssystemen kommt dabei zumeist der prozessbasierte Zugriffskontrollmechanismus
zum Einsatz. In einem Prozess-Strukturiertem System setzt der Kernel die
Zugriffskontrollpolitiken durch. Der Kernel überprüft die Argumente bei jedem
Kernel-Aufruf und trifft die Entscheidung, ob der Aufruf erlaubt ist. Dabei kann ein
Prozess nur durch einen Shared Memory Buffer oder mithilfe eines System Aufrufs mit der
Außenwelt kommunizieren, welche unter der Kontrolle des Kernels stehen.
Beispielsweise besitzen Betriebssysteme für IBM Mainframes Systemprogramme mit einem Supervisor-Status, die sie von den Anwendungsprogrammen abgrenzt. Unterschiedliche Prozessmodi existieren auch z.B. bei dem Betriebssystem VAX-11 (Systemkernmodus, Ausführungsmodus, Überwachungsmodus, und Benutzermodus). Hier wurde jedem Modus eine genau definierte Teilmenge an Befehlsvorraten zugewiesen [WAE 93].
In der UNIX-Systemarchitektur besitzt jedes Objekt (z.B. die Datei
passwort.txt) Zugriffsrechte. Diese werden durch einen Autorisationsvorgang
erteilt. Jeder Prozess besitzt eine User ID und eine Gruppen ID. Mithilfe dieser
IDs wertet der Kernel aus, ob der Prozess genügend Privilegien besitzt, um auf
die Ressource zugreifen zu können.
Beim traditionellen UNIX System wird die Autorisation mittels Permission Bits
realisiert. Diese (Neun) Bits geben Auskunft über Lese-, Schreib- und
Ausführungsrechte [SUM 97].
Durch die Integration von Zugriffskontrolllisten wurden dabei eine erhöhte
Granularität bei der Autorisation ermöglicht. Zugriffskontrolllisten werden
z.B. von neueren UNIX-Systemen, MULTICS und Microsoft Windows NT
eingesetzt [SUM 97].
Ringschutz
Um die hohen Sicherheitsanforderung bezüglich des Informationsflusses zu erfüllen,
wurden weitere Mechanismen wie z.B. der Ringschutz zur Realisation einer
systembestimmten Zugriffskontrollpolitik entwickelt. Der Ringschutz realisiert dabei
eine systembestimmte Zugriffskontrollpolitik (MAC). Die Struktur ähnelt den
Baumringen. Je näher ein Code in der Mitte plaziert ist, desto mehr Privilegien
besitzt er. Aufrufe an weiter innen liegenden Informationen sind eingeschränkt.
Der Ringschutz kann auch mit den UNIX-Systemaufrufen verglichen werden [HER 99].
MULTICS besitzt diesen Ringschutz und unterstützt den Zugriffschutz auch bei der Anwendung von Formen der gestreuten Adressierung, also bei der Arbeit mit Segment- und Seitentabellen beim virtuellen Speicher [WAE 93].
Die Ringe 0,1 und 2 bei MULTICS bleiben dem Betriebssystem vorbehalten.
Die Ringe 3 bis 32 sind für Nutzerdaten angedacht. Ein zugreifender
Prozess weist sich beim Zugriff durch eine Operandenadresse aus, die
unter anderem die Schutzringnummern enthält [WAE 93].
Stimmt die Schutzringnummer überein, erhält der Prozess Zugriff laut
Zugriffsattribut. Stimmen die Schutzringnummern nicht überein,
überprüft eine Unterbrechungsroutine, ob die Schutzringnummer
größer oder kleiner ist, und erlaubt bzw. verweigert den Zugriff.
Capability Systeme
Hardware- oder softwarebasierte Capabilities wurden in traditionellen Maschinen in
einem markierten Speicher (Tagged Memories) gespeichert, wobei die Hardware das
Verändern des Wertes des Zeigers durch nicht vertrauenswürdige Prozesse schützt.
Eine andere Möglichkeit bestand in der Unterstützung von Handles oder Descriptors
des Kernels, was einem nicht vertrauenswürdigen Prozess erlaubte, seine Capabilities
zu verwenden [LEV 84]. Ein Benutzerprogramm konnte Capabilities laden, speichern
und ausführen, jedoch konnte nur der Kernel Capabilities erstellen [LEV 84].
Durch die Verteilung der einzelnen Komponenten, welche über ein
spezifisches Transportsystem verbunden werden, entstehen durch neue Techniken neue
Problematiken bezüglich der Zugriffssteuerung.
Beispiel neuer Techniken:
Die möglichen Bedrohungsarten steigen durch die Möglichkeit auch entfernter
unautorisierter Zugriffe auf Informationen und Serverdienste. Auch hier
gilt es jedoch die Informationssicherheit zu verwirklichen. Neue Konzepte hatten so
neue Mechanismen hervorgebracht, welche die Zugriffskontrollpolitiken systemweit
durchsetzen. Dazu gehört z.B. das Network File System (NFS) [STE 95], der
Network Information Service (NIS) [STE 95] und das Andrew File System
(AFS) [SUM 97]. NIS beispielsweise setzt auf eine verteilte Datenbank auf, welche
z.B. die Verwaltung der Kennwortdateien erleichtert [STE 95,SUM 97].
Aus Sicht der Zugriffsteuerung müssen die verteilten Objekte allgemein adressiert werden können. Nur so können spezifische Zugriffsrechte auf Objekte, die sich auch auf einem anderen System befinden können, vergeben und auch durchgesetzt werden. Etwas problematischer wirkt sich jedoch auch das Vorhandensein unterschiedlicher Zugriffskontrollpolitiken der unterschiedlichen Systeme aus, die sich zudem in unterschiedlichen Organisationen und somit Administrationsbereichen befinden können. Hier ist zumindest eine Unterscheidung der Abstraktionsebenen von internen und externen Zugriffsmöglichkeiten notwendig. So finden beispielsweise Zugriffskontrollentscheidungen nicht nur anhand des authentifizierten Subjekts und des Objekts statt, sondern auch anhand weiteren spezifischen Eigenschaften wie beispielsweise der Zielort des Zugriffs oder eines Passworts.
Betrachtet man typische Anwendungen von verteilten Systemen (Telnet, FTP, WWW), basiert
der Zugriffsschutz auf der Authentifikation eines Benutzers anhand eines Passworts.
Zudem kann der Zugriff auf Basis der Herkunft der Anfrage eingeschränkt sein.
Ein System innerhalb eines Verbundes kann dabei Bereiche freigeben, auf die alle
zugreifen dürfen, Einzelbereiche können z.B. durch eine Passwortabfrage geschützt werden
oder die Berechtigung richtet sich u.a. nach der Identität des Kommunikationspartners.
Durch ein heterogenes Umfeld wird die Realisation einer Zugriffssteuerung zusätzlich erschwert. Hier ist eine geeignete Abstraktionsebene gefragt, die sich nicht auf spezifische Sicherheitsmechanismen abstützt. Letztendlich muss in der Regel die Zusammenarbeit unterschiedlicher Sicherheitsinfrastruktur und Sicherheitsdienste gewährleistet werden.
In [WOL 92] wird auf die Zugriffskontrolle auf verteilte Objekte in heterogenen Netzwerkmanagementsystemen eingegangen. Das Sandhu`s Typed Access Matrix (TAM) Modell [ASA 92,SAN 92] dient als Rahmenwerk, um die Zugriffskontrollpolitiken in der oben genannten Umgebung zu untersuchen und zu erstellen. Ein TAM-Modell besteht dabei aus einer Zugriffmatrix kombiniert mit einer begrenzten Anzahl von Kommandos, welche die Erneuerung der Matrix kontrollieren. Dieses Modell erzeugt eine Sprache mit einer Semantik, welche unabhängig von einem spezifischem Implementierungsmechanismus ist, und erlaubt eine einfache Aussage von unterschiedlichen Zugriffskontrollpolitiken. Das TAM-Modell definiert eine Anzahl von Operationen, um die gemeinsame Zugriffskontroll-Informationen und die Funktionen für die Zugriffskontroll-Entscheidung festzulegen.
Die Zugriffskontrollschemata von CMIP und SNMPv2 setzten ein Identitäts-basierendes ACL Schema mit Objektgruppen ein. Durch das gegensätzliche Design ist die Integration der Objekte, die durch diese Zugriffskontrollpolitiken geschützt werden, schwierig.
Letztendlich soll das TAM-Modell als Basis dienen, um die unterschiedlichen Konzepte
der Zugriffskontrollinformationen in ein gemeinsames Konzept unterzubringen.
Desweiteren lockern die erweiterten Definitionen der Zugriffskontroll-Policies
im TAM-Modell die Aufgabe des Sicherheitsmanagement. Die TAM-Spezifikationen
unterstützen den Systemadministrator durch die allgemeine Sicht der zu managenden
Ressourcen, und das unabhängig von dem eingesetzten Management Protokoll.
Die Problematik der globalen Authentifikation von Entitäten bei
verteilten Systemen innerhalb einer Domäne können durch z.B. Authentifikations-
und Autorisations-Server realisiert werden.
Im Vordergrund steht hier vor allem die Trennung der Authentifikation von den eingesetzten
Durchsetzungsmechanismen. Zugriffskontrollentscheidungen werden in vernetzten Systemen
auch von Netzelementen, wie z.B. von Routern getroffen.
Konzepte, die die Zugriffskontrollpolitiken der einzelnen Domänen verteilter Systeme
durchsetzen, sind z.B. Firewalls bzw. Paketfilter.
Firewalls
Der einfachste Weg ein Cluster, also einen begrenzten Teilbereich des Netzes zu
schützen, ist den Zugriff auf das Cluster durch eine Firewall zu schützen. Dies
ist momentan auch der weitverbreiteste Schutz von Rechnernetzen. Eine Firewall lässt
auf Grundlage einer Filterpolitik Anfragen bestimmter Nachrichten nicht durch. Dabei
richtet sich die Sicherheitspolitik in der Regel nach der Herkunft des zugreifenden Subjekts.
Verteilte Capabilities
Capabilities erstrecken sich auch über Netzwerke hinweg. Bestehen entfernte
Objektreferenzen aus Bits, die nicht erraten werden können, so hat eine
entfernte Capability-Referenz alle Sicherheitseigenschaften einer lokalen
Capability [GON 89]. Es erschwert sich jedoch die ohnehin schon problematische
Rücknahme der Capabilities. Zudem ist das Risiko, dass eine dritte Partei
unberechtigt an eine Capability gelangt, weitaus höher [SUM 97].
Verteilte ACLs
Zugriffskontrollentscheidungen können auch auf der Basis der Identität eines Aufrufers
gefällt werden. Zwei Maschinen können eine verschlüsselte Verbindung aufbauen, wobei
auch ein Handshake stattfinden kann, um die Teilnehmer zu identifizieren.
Viele Architekturen die die Kommunikationsinfrastruktur für verteilte Objekte
zur Verfügung stellen (z.B. CORBA und DCE),
erlauben bei einem Objekt Aufruf die Befragung einer Access Control List.
Proxy Objekte
Auch Proxy Objekte könne zur Autorisation und Accounting Zwecken eingesetzt
werden [NEU 93].
Betrachtet man die herkömmlichen Schutzkonzepte, so reichen diese nicht aus.
Ist der Einsatz von Firewalls beispielsweise bei einem Cluster ausreichend, um bestimmte
Kommunikationsverbindungen zu unterbinden, um so z.B. nur mit vertrauenswürdigen
Rechnern kommunizieren zu können, bieten Firewalls keinen Schutz
gegenüber mobilen Code.
Passiert ein Mobiler Agent die Firewall, so entspricht dies einer Textdatei. Diese
Datei wird erst bei ihrer Ausführung gefährlich, falls es sich um einen bösartigen
Agenten handelt. Zur Zeit der Ausführung hat eine Firewall jedoch keinen Einfluß
mehr auf den Mobilen Agenten. Eine Firewall verhindert den Zugriff von außerhalb auf
das geschützte Cluster, der Zugriff von innerhalb des Cluster nach außen ist in der
Regel jedoch gestattet. Ein bösartiger mobiler Agent kann vom Internet heruntergeladen
werden, durchdringt ungehindert die Firewall, und kann bei der Ausführung sein Unwesen
treiben, falls keine geeigneten Sicherheitsvorkehrungen vorhanden sind.
Aufgrund der Mobilität von Objekten müssen Zugriffskontrollpolitiken dieser Objekte
auch auf anderen, z.T. fremden Systemen durchgesetzt werden können. Unautorisierte
Zugriffe und der Missbrauch sind hier ebenfalls zu verhindern.
Folgende Sicherheitsfragen fallen in den Zuständigkeitsbereich der Zugriffskontrolle bei Agentensystemen:
Agenten, die auf einem Agentensystem ausgeführt werden, müssen vor unbefugten Zugriffen
geschützt sein. Der Schutz eines Agenten vor böswilligen Agentensystemen gestaltet
sich äußerst schwierig, da der Agent dem Agentensystem in erster Linie vollkommen
ausgeliefert ist. Jedoch existieren auch hier Überlegungen, die den Agenten vor
böswilligen Agentensystemen schützen sollen [VIG 98,SAT 98a,HOH 98]
Betrachtet man die Kontrolle des Informationsflusses, so ist sie ebenfalls von
besonderer Bedeutung für die Informationssicherheit. Beispielsweise
kann durch die Informationsflusskontrolle sichergestellt werden, dass spezifische
sicherheitskritische Informationen das Agentensystem nicht verlassen können.
Zugriffe auf Objekte wie z.B. Dateien, sollten nach Möglichkeit ebenso nachvollziehbar und einer Person zuordenbar sein. Dies erfordert eine globale Authentifikationsmöglichkeit der einzelnen Subjekte.
Auch das Auditing sicherheitskritischer Zugriffe ist für ein Agentensystem
unerlässlich.
Bei Agentensystemen werden in der Regel
Zugriffskontrollpolitiken durch Überprüfungsmechanismen der Programmiersprache
oder der Laufzeitumgebung durchgesetzt. Die Zugriffskontrolle erfolgt dabei generell
über Kommunikations-Sicherheitsmechanismen wie z.B. einer Zugriffskontrollliste, oder
durch die Agenten-Programmiersprache. Policies, Credentials,
Zugriffskontrolllisten (ACLs) bis hin zu Tickets und Capabilities werden in
vorhandenen Agentensystemen eingesetzt.
Solange nur einige Services des Systems genutzt werden (z.B. Java Applets im
Sandbox Modell), reicht es aus, den Zugriffsschutz durch Isolation der unterschiedlichen
Codes untereinander und durch Zugriffskontrollen, die die Ausführungsumgebung
schützen zu realisieren. Dies entspricht dem Sandbox-Modell. Für Applikationen
im Allgemeinen aber werden jedoch mehr Services des Systems benötigt.
Betrachtung der Agenteninstanz History
Jede Migration von einem Agentensystem zu einem anderen Agentensystem wird Hop genannt.
Agenten, die mehrere Agentensysteme besuchen, sind Multi-Hop Agenten. Ein One-Hop Agent
migriert nur auf ein Agentensystem und reist dann nicht mehr weiter. Ein Beispiel für einen
One-Hop Agenten ist ein Applets. Ein Two-Hop Boomerang Agent migriert von seinem
Home-Agentensystem auf ein weiteres Agentensystem und dann wieder zurück. Involviert ist
also nur ein weiteres Agentensystem [ORD 98].
Bei One-Hop Agenten setzt sich das sendende Agentensystem keiner Gefahr aus. Bei einem Two-Hop Boomerang Agenten besteht die Gefahr eines modifizierten Agenten nur durch ein Agentensystem. Die Herstellung einer Vertrauensbeziehung zu einem Agentensystem kann durch ein Public-Key Verfahren erfolgen. Hier können die beiden Agentensysteme jeweils die Daten des Agenten verschlüsseln. Durch die Verschlüsselung mit jeweils dem öffentlichen Schlüssel des Partners. Bei Multi-Hop Agenten ist die Herstellung der Sicherheitsanforderungen erschwert, da mehrere Agentensysteme involviert sein können, wodurch die Gefahr eines Angriffs steigt.
Allgemein betrachtet ist es schwer, die Sicherheit eines Systems
einzustufen. Unterschiedliche Modelle, wie z.B. das Orange Book,
zeigen Richtlinien auf, nach denen Systeme auf ihre Sicherheit hin
eingestuft werden können. Dieser Abschnitt geht allerdings nur auf
das formale Modell des Orange Book ein.
Die Betrachtung der formellen Prüfung (formal proofs) oder formelle
Spezifikationssprachen würden den Rahmen dieser Arbeit sprengen.
Standards wurden erstmals für Einzelsysteme entwickelt.
Durch die Architekturen vernetzter Rechner wurden diese
Standards unter Einbeziehung der Eigenschaften der verteilten Systeme
erweitert und angepasst.
Standards, die die Eigenschaften mobiler Agentensysteme berücksichtigen,
existieren noch nicht.
"Die Sicherheit eines Rechensystems ist seine Fähigkeit, eine festgelegte Sicherheitspolitik zu realisieren. Die Frage nach der Sicherheit eines Systems ist also relativ zu den für das System (oder einer spezifischen Anwendung) festgelegten Sicherheitsanforderungen zu beantworten'' [ECK 98]
Das Orange Book beschreibt dabei Eigenschaften, die der Einstufung
bezüglich der Sicherheit eines Systems dienen. Die Eigenschaften
beziehen sich auch auf den jeweiligen Zugriffsschutz.
Eine Einstufung kann beispielsweise anhand der unterschiedlichen
MAC- und DAC-Zugriffskontrollpolitiken, die im Kapitel 2.5.1
vorgestellt wurden, erfolgen.
Diese Eigenschaften werden nachfolgend aufgezeigt,
da sie für die weiteren Abschnitte dieser Arbeit relevant sind.
Die Bewertung der Betriebssicherheit wird anhand sechs Hauptkriterien geregelt:
1. Security Policy
2. Marketing
3. Identifikation
4. Accountability
5. Assurance
6. Continuous Protection
Alle für die Betriebssicherheit wichtigen Komponenten müssen permanent und zuverlässig vor unautorisierten Zugriffen geschützt sein. Zur Handhabung des Kriterienkataloges werden sieben Sicherheitsklassen definiert [WAE 93,SUM 97,CLS 94]:
D : Minimaler Schutz
C1 : Benutzergesteuerter Zugriffsschutz
C2 : Kontrollierter Zugriffsschutz
B1 : Schutz durch Kennzeichnung
B2 : Schutz durch Strukturierung
B3 : Sicherheitsbereiche
A1 : Verifizierter Entwurf
Systeme der Gruppe C gestatten dem Nutzer die Vorgabe der Schutzgrade für Objekte und der Zugriffsrechte der Subjekte auf diese Objekte. Systeme der Gruppe B sind durch festgelegte, unveränderliche Schutzgrade und Zugriffsrechte gekennzeichnet, die jeweils bis zu einer bestimmten Sicherheitsstufe innerhalb eines hierarchisch strukturierten System reichen und die Rechte der darunter liegenden Sicherheitsstufen einschließen. Für Systeme der Gruppe A muss der Nachweis erbracht werden, dass keine Lücken im System enthalten sind.
Die Beispielanalyse von Sicherheitsschwachstellen des Betriebssystems UNIX anhand des Orange Book findet sich ebenfalls in [LIE 90].
Ein weiterer Beitrag leistet ECMA mit dem Standard Security in Open
Systems - A Security Framework (TC32/TG9). Er definiert Anforderungen
an den Security Service. Diese sollen dem Anwender OSI-gerechter
Anwendungen in der Schicht 7 bei der Erfüllung von
Sicherheitsanforderungen auf der logischen Ebene seiner Subjekte und
seiner Objekte unterstützen.
Der Vollständigkeit halber, sei noch das Bell-LaPadula-Modell
erwähnt, wobei das Problem der Kontrolle des Zugriffs beschrieben
ist. Das Orange Book ist eng mit diesem Modell
verbunden. [CLS 94,SUM 97].
Sicherheitsprinzipien werden hier formal beschrieben.
Es wird versucht, die Regeln der Informationsflusskontrolle
bei eingestuften Informationen formal zu erfassen [POW 93,SUM 97].
Es existieren unterschiedliche Standards, die untereinander jedoch nicht schlüssig sind, da Rücksicht auf die Ausdruckskraft genommen wird [KAR 95].
Die Anzahl der Sicherheitsstandards für Sicherheitspolitiken wachsen stetig an.
Soll eine Klasse geladen werden, so muss sie den Bytecode Verifier passieren. Dabei kann
es sich um lokale Klassen des Systems, entfernte Klassen von anderen Systemen, und um
signierte Klassen handeln. Der ClassLoader ist für das Laden der Klassen zuständig.
Der SecurityManager bildet die Schnittstelle zwischen der Core API und dem
Betriebssystem. Der SecurityManager verwaltet dabei die gesamten Zugriffe auf die
Ressourcen des Endsystems. In Java 2 werden Zugriffskontrollentscheidungen zumeist an den
AccessController weitergeleitet. Die SecurityPackages bilden die Basis für die
Authentifikation signierter Java Klassen. Die benötigten Daten für die
Verifikation können in einer Datenbank abgelegt werden [OAK 00,GON 00].
Die Java Virtual Machine (JVM) stellt eine Umgebung für Java-Programme dar und
führt den Bytecode aus [YEL 96b]. Dabei kommen die in der JVM implementierten (Low-Level)
Schutzmechanismen zum Einsatz. Vom Betriebssystem aus betrachtet ist die JVM ein
einzelner Prozess und alle Systemaufrufe der JVM laufen unter der Autorität des
Eigentümers der JVM ab.
Die Möglichkeit fremde Programme auf ein System herunterzuladen und auszuführen
stellt dabei besondere Anforderungen an die Sicherheitskonzepte.
Die in Java eingesetzten Sicherheitskonzepte basieren auf Sicherheitsvorkehrungen
der Sprache an sich und des Compilers. Durch den Einsatz des ClassLoaders
und dem SecurityManager werden Sicherheitsvorkehrungen auf der Applikationsebene
bereitgestellt. Das Java Sicherheitsmodell basiert hauptsächlich auf dem
Bytecode Verifier, dem ClassLoader, dem SecurityManager und seit Java 2 auch
auf dem AccessController [MOM 99].
Die vier Sicherheitskomponenten sind voneinander abhängig [IBM 99b].
Bei einer Sicherheitslücke eines dieser Elemente ist demnach das
ganze System bedroht:
Der SecurityManager und der AccessController müssen sich auf den ClassLoader verlassen. Er kann entfernte von lokal geladenen Klassen unterscheiden und die den Klassen zugeordneten ProtectionDomains zuordnen. Die Trennung der Klassen in Namensräumen verhindert Namenskomplikationen, und die Trennung in spezifisch geschützten Domains helfen die lokalen vertrauenswürdigen Klassen vor einem Überschreiben durch andere Klassen zu verhindern.
Der ClassLoader muss sich allerdings auch auf den SecurityManager verlassen, da dieser zum Beispiel verhindert, dass ein Programm einen eigenen ClassLoader ausführt. Wäre dies möglich, so könnten die durch den ClassLoader realisierten Schutzkonzepte umgangen werden.
Die Basis der Vertrauensbeziehungen bildet der ClassFile Verifier. Er
stellt sicher, dass die innerhalb eines Programms getroffenen
Schutzvorkehrungen auch durchgesetzt werden.
Low-Level Security (Sprache und Compiler)
Wird ein Java Programm ausgeführt, so kommen zuerst die
Low-Level Sicherheitsmechanismen von Java zum tragen. Bevor ein Code ausgeführt
wird, wird er überprüft und verifiziert. Dadurch wird sichergestellt, dass der
Code den Spezifikationen der virtuellen Maschine entspricht. Unzulässige Operationen
(Stack Overflow, etc.) werden erkannt und verhindert [YEL 96a].
Die Programmiersprache Java und ihre Ausführungsumgebung bietet Sicherheit durch die Überprüfung der Typ Einhaltung (Strong Type Safety). Das Static Byte Checking in Form von Byte Code Verification überprüft den Code vor der Ausführung. Unterstützt wird zudem eine Überprüfung zur Laufzeit (Dynamic Checking).
Einem nicht vertrauenswürdiger Code steht ein distinkter Namensraum zur Verfügung.
Referenzen zwischen einzelnen Modulen von verschiedenen Namensräumen sind nur
bei Methoden die als public deklariert worden sind möglich [OAK 00].
Folgend werden die Sicherheitseigenschaften von Java erläutert:
Die Sicherheitskonzepte wurden in den einzelnen Java-Versionen weiterentwickelt (vgl. Abb. 11, 12 und 13), und für bestimmte Sicherheitsanforderungen optimiert. Stand bei JDK 1.0 das Sandbox-Security Modell im Vordergrund, so kam bei JDK 1.1 das Konzept des Trusted Code zum Tragen. In JDK 1.2 (Java 2) ermöglicht das Sicherheitsmodell in Java eine feingranulare Zugriffskontrolle anhand von als trusted oder untrusted eingestuften Code ohne großen Implementierungsaufwand. Die Java 2 Security Architecture erlaubt die Umsetzung der Sicherheitsanforderungen durch z.B. Zuweisung einer spezifischen Schutzumgebung an einen fremden Code. Durch diese Zuweisung kann eine Zugriffskontrolle des fremden Codes auf Systemressourcen durchgesetzt werden [OAK 00,GON 98,GON 00,IBM 99b].
ClassLoader
Der ClassLoader lädt den Bytecode, der den Bytecode Verifier passiert hat, als Klasse in
die Java Virtual Machine (JVM) und übernimmt damit die Funktion des Binders.
Er ist verantwortlich für das Zusammenfügen der verschiedenen Klassen, so dass das
Programm ausgeführt werden kann. Weitere Aufgaben des ClassLoader bezüglich
Sicherheitsaspekte sind [OAK 00,IBM 99b,GON 98]:
Der ClassLoader ist zudem in der Lage, Klassen dynamisch zu laden, d.h. Programme können zur Laufzeit eingebunden werden. Identifiziert werden kann eine Klasse anhand des Namens und des ClassLoaders, der die Klasse geladen hat. Bezieht sich eine geladene Klasse auf eine noch nicht geladene Klasse, ruft die JVM dieselbe ClassLoader-Instanz auf, die die Klasse geladen hat, um die neue Klasse zu laden. Alle Klassen, die in einer Applikation genutzt werden, werden daher von ein und demselben ClassLoader geladen. Auf Basis dieser Technik kann jeder Applikation ein eindeutiger Namensraum zugeordnet werden. Dadurch kann es nicht zu Namensüberschneidungen der Klassen unterschiedlicher Applikationen kommen [OAK 00].
Durch die Verwendung des ClassLoaders sind Programme mit gleichlautendem
Klassennamen ausführbar, und die Programme sind untereinander
abgeschottet, wobei Zugriffe auf Klassen von fremden Programmen
verhindert werden.
Applets nutzen diese Technik, indem jedes heruntergeladene Applet
eine eigene ClassLoader-Instanz bekommt. Der dem Applet zur
Verfügung gestellte Namensraum dient der Sicherheit des
Systems, aber auch des Applets [OAK 00,GON 98].
Die Möglichkeit des dynamischen Ladens von Klassen ist jedoch schwer in Einklang zu bringen mit den Sicherheitsanforderungen der Type-Safety. Wie kann man wissen, dass der Code Typ-sicher ist, wenn er noch gar nicht vorhanden ist? Dieser Frage geht D. Dean in seiner Dissertation nach [DEA 98]. Letztendlich führt eine unkontrollierte dynamische Auflösung offener Referenzen zu Sicherheitsproblemen. Der Binder ist daher eine sicherheitskritische Komponente. Beispielsweise enthielten alte Java Versionen Sicherheitsmängel im ClassLoader, wodurch Schutzkonzepte umgangen werden konnten [ECK 98].
Der ClassLoader ist ein wichtiger Bestandteil des Sicherheitmodells. Er arbeitet
eng mit dem SecurityManager und AccessController zusammen. Der ClassLoader
besitzt als einziger bestimmte Informationen über die Klassen, welche in die
JVM geladen worden sind. Nur der ClassLoader kann erkennen, ob eine Klasse lokal
oder von einem entfernten Rechner geladen worden ist, und ob es sich um eine
signierte Klasse handelt [IBM 99b].
Der in Java 2 vorhandene SecureClassLoader dient als Basis zur Entwicklung
eines ClassLoaders mit dem Unterschied, dass der SecureClassLoader
mit jeder geladenen Klasse eine ProtectionDomain verbindet.
ProtectionDomains dienen dabei als Basis zum Einsatz des AccessControllers.
Wird der AccessController verwendet, um die System Security Policy durchzusetzen,
so ist die Verwendung des SecureClassLoaders unabdingbar [OAK 00,IBM 99b,GON 00].
Der Einsatz eines SecureClassLoader sieht dann wie folgt aus:
SecurityManager
Die Aufgabe des SecurityManager besteht darin, Operationen zur Laufzeit einer
Zugriffskontrolle zu unterziehen. Der SecurityManager agiert als zentrale Instanz,
wobei er die für die Kontrolle benötigten sicherheitsrelevanten Informationen und
Mechanismen bereitstellt und die Zugangskontrolle durchführt.
Die Zugriffskontrolle wird durch die Verwendung von Ausnahmebehandlungen
realisiert.
Der SecurityManager entscheidet z.B., ob eine Datei gelesen werden darf oder nicht,
ob sich der Zustand eines Threads ändern darf, ob der Zugriff auf ein Package erlaubt
ist bzw. ob eine Verbindung zu einem anderen Rechner erlaubt wird.
Der SecurityManager kann zur Entscheidungsfindung auch den ClassLoader heranziehen.
So kann er beispielsweise den ClassLoader fragen, von woher die Klasse stammte.
Daher kann eine differenzierte Zugriffskontrolle anhand dem Wissen, dass der
ClassLoader besitzt, erfolgen. Hierfür muss der SecurityManager nur über die
speziell implementierte Schnittstelle des ClassLoaders informiert sein [OAK 00].
Die Voraussetzung damit der SecurityManagers hinzugezogen wird ist die explizite Umlenkung eines zu schützenden Aufrufs auf den SecurityManager [OAK 00].
Die von dem SecurityManager verwendete Zugriffskontrollpolitik ist hart codiert. Durch einen entsprechenden Aufruf einer geschützten Funktion wird der SecurityManager angesprungen, der daraufhin die innerhalb des SecurityManagers codierte Zugriffskontrollpolitik durchsetzt [OAK 00].
In der Abb. 14 ist der Ablauf der Zugriffskontrolle durch den SecurityManager ersichtlich [IBM 99b].
Existiert eine nicht vertrauenswürdige Klasse auf dem Stack, erfolgt
eine Ausnahmebehandlung, welche den Zugriff auf das Objekt verhindert.
Betrachtet man die Vorgehensweise des SecurityManagers, wird das Konzept
eines Referenz Monitors implementiert,
da jeder, als sicherheitskritisch eingestufter Aufruf, die zentrale
Kontrollinstanz durchlaufen muss. Ist der Zugriff nicht zulässig,
erfolgt eine Ausnahmebehandlung (Exception).
Ist der Zugriff zulässig, ist die Zugriffskontrolle für den Nutzer transparent.
Kommt der Security Manager in einer unmodifizierten Form zum Einsatz, so gibt es folgende Nachteile:
Seit Java 2 kann jedoch auch zusätzlich der AccessController zur Entscheidungsfindung
herangezogen werden, der im Gegensatz zum SecurityManager eine klare Trennung der
Zugriffskontrollpolitik von dem Durchsetzungsmechanismus besitzt.
Die Zugriffskontrolle erfolgt aus Kompatibilitätsgründen durch den SecurityManager,
jedoch leitet der SecurityManager die Zugriffskontrolle an den AccessController weiter.
Access Controller
Der AccessController existiert erst ab Version 1.2 und ersetzt
einige Funktionalitäten des SecurityManagers [OAK 00].
Der Vorteil des AccessController besteht darin, dass für die Änderung der
Sicherheitspolitik nicht mehr der Programm Code modifiziert werden muss [OAK 00].
Die Änderungen können nun benutzerfreundlich durch Einträge in einer Policy-Datei
vorgenommen werden, welche von dem AccessController durchgesetzt wird [MOM 99].
Dabei sind die zu vergebenden Zugriffsrechte weitaus flexibler und feingranularer.
Lokale Klassen können nun auch einer Beschränkungen unterworfen werden.
Der AccessController basiert auf Konzepten, die durch spezielle Klassen implementiert werden und folgend vorgestellt werden:
Der AccessController verwendet Stack Inspection, kontrolliert also ebenfalls
den Stackinhalt. Im Gegensatz zum SecurityManager ist hier jedoch nicht mehr die
Klassen-Tiefe (Class-Depth), sondern die in den sich auf dem Stack befindlichen
ProtectionDomains enthaltenen Permissions-Objekte relevant.
Da die ProtectionDomains, die für die jeweilige Klasse zugeteilten
Berechtigungen enthalten, kann entschieden werden, ob alle Klassen des
aktuellen Aufrufstacks, die für den Zugriff notwendige Berechtigungen besitzen.
1) CodeSource
Die Code Herkunft wird durch ein java.net.URL-Objekt repräsentiert.
Die Liste der Signierer wird durch ein Array von
java.security.cert.Certificates-Objekte repräsentiert. Der Konstruktor
der CodeSource-Klasse sind folgendermassen aus:
CodeSource(URL url, Certificate[] certs)
Die URL-Herkunft bekommt man durch die getLocation()-Methode und die
Zertifikat durch die getCertificates()-Methode.
2) Permissions
Die Permission-Klassen repräsentieren den Zugriff zu den System
Ressourcen. Das java.security-Package stellt die abstrakte
Permission-Klasse bereit, um die spezifischen Zugriffe zu
repräsentieren. Es sind einige Subklassen in der Java Core API
vorhanden. Man kann auch seine eigene Permission-Klassen spezifizieren,
indem man eine Subklasse der betreffenden Klasse erstellt oder
vorhandene Subklassen (z.B. java.security.BasicPermission)
nutzt [OAK 00].
Spezifische Zugriffe werden von Permission-Klassen repräsentiert, die
zumeist im dafür zuständigen Package enthalten sind. So ist die
Permission-Klasse FilePermission ein Teil des java.io-Package.
Die vorhanden Permission-Klassen im
java.security-Package sind [OAK 00]:
AllPermission, BasicPermission, SecurityPermission, UnresolvedPermission
Desweiteren gibt es noch abstrakte Klassen:
java.security.PermissionCollection
(Repräsentation einer Sammlung homogener Berechtigungen)
und java.security.Permissions
(Sammlung heterogener Permission-Objekte)
3) System Security Policy
Die in der Java 2 Security Architecture eingesetzte Policy-Klasse spezifiziert,
welche Zugriffsrechte einer CodeSource zugesprochen werden soll.
Das java.security-Package enthält die abstrakte Policy-Klasse, die die Sicherheitspolitik der Java Applikationsumgebung (System Security Policy) repräsentiert. Das Ziel dieser Klasse ist zu erkennen, welche Berechtigungen (Permissions) einer CodeSource in der Policy-Datei zugeteilt worden sind.
Die Sicherheitspolitik wird durch eine Subklassen-Policy repräsentiert,
die eine Implementierung einer abstrakten Methode in der Policy-Klasse
enthält.
Die Herkunft der Policy-Informationen, um das Policy-Objekt zu
generieren, hängt von der Implementierung ab. So kann die Policy-Konfiguration
in einer ASCII-Datei, in einer serialisierten Binary-Datei der
Policy-Klasse oder in einer Datenbank enthalten sein [POL 00].
Die Standardimplementierung der java.security.Policy-Klasse wertet
die Zugriffskontroll-Policies, die aus einer Menge an Policy-Einträgen
besteht, aus.
Die Standardkonfiguration wertet eine systemspezifische und eine
benutzerbestimmten Zugriffskontrollpolitik aus. In einer Umgebung
mit mehreren Rechnern und Nutzern, kann bzw. muss für jeden Rechner und jeden
Nutzer eine Zugriffskontroll-Policy definiert werden.
Zur Vereinfachung kann die Definition der Zugriffskontroll-Policy
nicht als Einheit spezifiziert werden, sondern als eine Einheit
zusammengesetzter Teil-Policies [FAL 00].
Die Default Policy-Klasse wird durch die PolicyFile-Klasse von Sun implementiert.
![\includegraphics [totalheight=0.4\textheight]{beispielszenario-einl.eps}](img4.gif)
![\includegraphics [totalheight=0.25\textheight]{ac-matrix-fol.eps}](img5.gif)
![\includegraphics [totalheight=0.15\textheight]{grund-modelle.eps}](img6.gif)
![\includegraphics [totalheight=0.25\textheight]{grund-zu-ablauf.eps}](img7.gif)
![\includegraphics [totalheight=0.35\textheight]{schutzebene.eps}](img8.gif)
![\includegraphics [totalheight=0.4\textheight]{schutz.eps}](img9.gif)
![\includegraphics [totalheight=0.3\textheight]{grund-softwarebasis.eps}](img11.gif)
![\includegraphics [totalheight=0.3\textheight]{multics.eps}](img12.gif)
![\includegraphics [totalheight=0.4\textheight]{orange.eps}](img13.gif)
![\includegraphics [totalheight=0.3\textheight]{grund-javaapplikation.eps}](img14.gif)
![\includegraphics [totalheight=0.2\textheight]{java-sondbox.eps}](img15.gif)
![\includegraphics [totalheight=0.2\textheight]{java-trust-untrust.eps}](img16.gif)
![\includegraphics [totalheight=0.2\textheight]{java-ac-mech.eps}](img17.gif)
![\includegraphics [totalheight=0.15\textheight]{sm.eps}](img18.gif)
policy.provider= sun.security.provider.PolicyFlile
Die Permissions werden auf Basis einer Policy-Datei erstellt, wodurch die
PolicyFile-Klasse die Policy-Datei zuvor parst.
Anhand der Policy-Klasse wird letztendlich dem CodeSource Berechtigungen zugeteilt.
Per Default Einstellung werden zwei Policies durchgesetzt. Dies wird durch
die System Security-Datei (Security Property File) festgelegt und kann auch geändert
werden. Hier werden einige Eigenschaften bezüglich der Sicherheit festgelegt.
Innerhalb der System Security-Datei werden für die JVM global gültige Eigenschaften und Parameter definiert. Die Datei enthält in der Default Einstellung unter anderem den Eintrag: policy.provider=security.provider.PolicyFile. Hier wird die Klasse spezifiziert, welche als System-Policy instanziiert wird. Der Default Eintrag ist die Klasse PolicyFile im Package sun.security.provider. Diese Klasse definiert daher die default Java 2 SDK Policy Implementierung, welche die Policy-Dateien zur Sicherheitskonfiguration der JVM verwendet.
Durch den Eintrag policy.url.nummer kann der Ort der Policy-Datei
festgelegt werden. Die Datei kann sich auch auf einem entfernten
System befinden, wodurch sich z.B. auch Systemweite Policy-Dateien
auf einem Policy-Server befinden können [IBM 99b,OAK 00,GON 00].
4) Protection Domain
Eine ProtectionDomain wird verwendet, um einer CodeSource mit der ihr
zugewiesenen Berechtigungen zu gruppieren [OAK 00].
Die ProtectionDomain-Klasse repräsentiert eine Schutzeinheit innerhalb einer Java-Applikationsumgebung. Die Argumente des Konstruktors sind CodeSource-Objekte und PermissionCollection-Objekte. Die PermissionCollection-Objekte stellten die Berechtigungen dar, die dem CodeSource-Objekt angehören.
ProtectionDomain(CodeSource codesource, PermissionCollection permissions)
Jede Klasse, die in die JVM geladen wird, wird einer einzigen ProtectionDomain
zugeordnet. Diese Zuordnung basiert auf den CodeSource der Klasse.
Mehrere Klassen können einer ProtectionDomain zugeordnet sein.
Eine ProtectionDomain kann eine oder mehrere Berechtigungen beinhalten, wobei
die einzelnen Berechtigungen in jeder ProtectionDomain enthalten sein können.
Weitere Sicherheitsdienste (JCA, JSSE, JAAS)
Folgende Funktionalitäten runden die Sicherheitskonzepte in Java ab.
Java Cryptography Architecture (JCA) ist eine
Architektur, die Java Cryptography Extension 1.2 (JCE) in JDK 1.2 implementiert.
Um eine sichere Kommunikation zu bewerkstelligen, gibt es die
Java Secure Socket Extension (JSSE). Außerdem existiert noch
ein Rahmenwerk, das Java Authentication and Authorization Service
(JAAS) [SUN 00a], welches
Authentifikation des Users und eine Zugriffskontrolle realisiert.
Zuletzt können die Applikationen selbst eigene spezifizierte
Sicherheitsmechanismen implementieren, wobei die Sicherheitfeatures der
Java Plattform verwendet werden können.
Java Authentication and Authorization Service (JAAS)
JavaTM Authentication and Authorization Service (JAAS)erlaubt die Authentifikation und Durchsetzung der Zugriffskontrolle
anhand von Benutzern. JAAS implementiert dabei das Standard Pluggable
Authentication Module (PAM), welches ein Rahmenwerk darstellt und die
Zugriffskontrollarchitektur der Java 2 Security Architecture um die
benutzerbasierte Rechtevergabe erweitert [SUN 00b].
Durch JAAS ist eine Zugriffskontrolle auf Basis der CodeSource und der
Entität (Principal), die das Programm ausführt möglich [SUN 00c].
Hierfür muss die Authentifikation des Benutzers erfolgen und eine Entscheidung,
anhand der Identität des Benutzers, getroffen und durchgesetzt werden.
Ein Principal in Java repräsentiert
dabei eine Entität (z.B. einen individuellen Benutzer).
Um JAAS nutzen zu können wird die Standard Edition Version 1.3 benötigt.
Die Politik-Sprache wurde in JAAS wie folgt erweitert:
grant CodeBase ["URL"],
Signedby ["signers"],
Principal [Principal_Class] ["Principal_Name"],
Principal ... {
permission Permission_Class ["Target_Name"]
[, "Permission_Actions"]
[, signedBy "SignerName"];
...
};
Dadurch sind folgende Beispieleinträge innerhalb der Policy-Datei möglich:
Beispiel 1: JAAS Benutzer basierte Policy
grant Codebase "http://www.haendler.de, Signedby "Haendler",
Principal bar.Principal "Messe" {
permission java.io.FilePermission "/temp", "read";
}
Beispiel 2: Der Rolle Administrator werden Rechte zugeteilt
grant Principal provider.Role "administrator" {
permission java.io.FilePermission "/results/-", "read, write";
}
Beispiel 3: Einem Entwicklungsgruppe (Group) werden Rechte zugeteilt
grant Principal hersteller.Team "Messen" {
permission java.io.FilePermission "/team/-", "read";
}
Die JAAS Policy-Datei erlaubt auch, dass die Principal-Klasse ein PrincipalComparator ist. (Die Klasse implementiert das PrincipalComparator Interface). Die Berechtigung wird jedem Subjekt erteilt, welches der PrincipalComparator impliziert, wodurch Gruppierungen von Benutzern unterstützt werden.
public interface PrincipalComparator {
boolean implies(Subject subject);
}
Beispiel 4: Benutzer ``user'' können auf das Temp-Verzeichnis lesend und schreibend
zugreifen.
grant Principal bar.Role "user" {
permission java.io.FilePermission "/temp/-", "read, write";
}
Finden Überprüfungen während der Ausführung statt, durchquert
der Java 2 SecurityManager die JAAS-Politik, und erneuert daraufhin den
momentanen AccessControlContext mit den zusätzlichen Berechtigungen,
die dem Subjekt und dem CodeSource gewährt wurden. Wurde die
Aktion beendet, wird das Subjekt von dem aktuellen AccessControlContext
entfernt und das Ergebnis wird dem Aufrufer übergeben [SUN 00c].
Um die Verbindung des Subjekts mit dem aktuellen AccessControlContext
zu realisieren, wird eine interne JAAS Implementierung des
java.security.DomainCombiner Interfaces verwendet.
Zusätzliche Sicherheitsfunktionen in Java 2
In Java 2 stehen noch weitere Sicherheitsfunktionen zur Verfügung.
So werden in Java 2 multiple Signaturen unterstützt.
Die SignedObject-Klasse ermöglicht die Erstellung authentischer Objekte die sich
in Ausführung befinden und deren Integrität sichergestellt ist. Ein SignedObject
enthält ein serialisierbares Objekt und seine Signatur.
Es kamen zwei neue Subpackages zum java.security.package hinzu ( java.security.cert und java.security.spec). Diese Pakete dienen der Handhabung der X.509 Zertifikate (Certificate Revocation Lists (CRLs) und Certificate Signing Requests (CSRs)). Es werden nun auch X.509-Zertifikate V3 unterstützt. Ein zusätzliches Zertifikat Interface, das X509 Extension Interface, ermöglicht zusätzliche Attribute mit privaten oder öffentlichen Schlüssel, um die Zertifikathierarchie und die CRL Verteilung zu managen.
Sicherheitskritische Zugriffe können in der Java 2 Security Architecture aufgezeichnet werden, indem die java.security.debug Systemeigenschaft gesetzt wird.
Anstatt die Klassentiefe auf dem Stack (Class-Depth) einer Klasse angeben zu müssen, um privilegierten Code ausführen zu können, kann die doPrivileged()-Methode eingesetzt werden, wodurch sensitiver Programmcode an einem bestimmten Platz abgelegt und unter einem privilegiertem Modus ablaufen (Namen Lexical Scoping of Privilege Modification) kann. Damit wird unter anderem eine flexible Zugriffskontrolle zur Laufzeit ermöglicht [IBM 99b, S.91: Run-Time Access Controls].
Java bietet auch Konzepte, welche zur Adressierung von Subjekten herangezogen werden können. Ein Principal in Java repräsentiert eine Entität (z.B. einen individuellen Nutzer). Um dies zu ermöglichen, definiert das java.security-Package ein Principal-Interface. Eine Gruppe von Principals wird durch ein Group-Interface repräsentiert (vgl. java.security.acl-Package).
Das Guard Interface wird zur Erzeugung eines Objekts benötigt, welches eine
bestimmte Ressource schützt. Derjenige, der eine Ressource zur Verfügung stellt,
kann ein Objekt erstellen, welches diese Ressource repräsentiert und in ein
GuardedObject, also einem beschützten Objekt, einkapselt.
Der Zugriff auf eine so geschützte Ressource ist nur möglich, wenn die
Sicherheitsüberprüfungen im Guard-Objekt erfolgreich abgeschlossen sind.
Es gibt unterschiedliche Sicherheits-Tools, die den Umgang mit spezifischen Mechanismen erleichtern.
Die Autorisation erfolgt nach dem Fail-Safe Defaults Prinzip
(vgl. Kapitel 2.3), wobei
jeder, nicht explizit autorisierte Zugriff, unterbunden wird.
Jedoch muss ein sicherheitskritischer Zugriff explizit durch den Implementierer
als solchen deklariert und einer Zugriffkontrolle unterworfen werden.
In Java 2 sind vertrauenswürdige Klassen nur noch die des Boot Class Paths, welcher
intern in der JVM spezifiziert ist ( sun.boot.class.path Property). Alle anderen
Klassen müssen in der Regel den Verifier und die Sicherheitspolitik passieren.
Wird die Sicherheitspolitik nur durch den SecurityManager implementiert,
ist das sogenannte Seperation of Policy and Mechanism Prinzip
(vgl. Kapitel 2.3) verletzt.
Die fehlende Trennung zwischen dem Entscheidungs- und Durchsetzungsmechanismus und
der Zugriffskontrollpolitik führt zu einer unflexiblen
Zugriffskontrolle [ECK 98].
Hier ist die Verwendung der Policy-Klasse von Java 2 vorzuziehen.
Applikationen können ihre eigene Policy-Subklassen unter der
Verwendung der abstrakte Methode der java.security.Policy-Klasse implementieren.
Es können mehrere Instanzen
dieser Klasse vorhanden sein, wobei jedoch immer nur eine Policy durchgesetzt werden kann.
Das gegenwärtig installierte Policy-Objekt kann durch die getPolicy()-Methode
erhalten werden. Programme mit der nötigen Berechtigung können das gegenwärtig
installierte Policy-Objekt durch den Aufruf der setPolicy()-Methode, ändern.
Bei einem Multiuser-System kann der Systemadministrator eines Systems eine systemweite
Default Policy-Datei festlegen, wobei jeder einzelne Nutzer diese um eine eigene
Policy-Datei erweitern kann.
Die Autorisationen erfolgen auf Basis spezifischer Zugriffsrechte
(vgl. Kapitel 2.6.2), die neben
der Aktion auch das Objekt adressieren. Es existieren spezifische Zugriffsrechte,
die um weitere anwendungsspezifische Zugriffsrechte erweitert werden können.
Beispiel: Zugriffsrecht-Eintrag in die Policy-Datei
grant Codebase "http://foo.com", Signedby "foo" {
permission java.io.FilePermission "/temp/-", "read";
}
Die Beispiel Zugriffskontrollpolitik erlaubt dem von http://foo.com
heruntergeladenen und von foo signiertem Code, alle Dateien
unterhalb des Temp-Ordners zu lesen.
Durch die Erweiterung mit JAAS (vgl. Kapitel 2.9.1) ist es
möglich zusätzlich noch das Kriterium des Ausführers des Codes hinzuzuziehen.
Beispiel: Zugriffsrecht-Eintrag JAAS
grant Codebase "http://www.mnm.com, Signedby "mnm",
Principal foo.Principal "hanisch" {
permission java.io.FilePermission "/temp/hanisch/-", "read";
}
Dieser Eintrag, der durch JAAS ermöglicht wird, erlaubt nur
den von ``mnm'' signierten Code von der Web-Seite ``www.mnm.com'' den Lesezugriff auf
das Verzeichnis /temp/hanisch/ und allen weiteren Unterverzeichnissen.
Der Nutzer kann also in seinen Sicherheitspolitiken exakt definieren,
auf welche Ressource ein bestimmter Code, einer bestimmten URL und
(oder) einer bestimmten Signatur zugreifen darf.
Durch die Verwendung spezieller Überprüfungsmechanismen kann zudem die Benutzung
von nicht autorisierten Methoden, die jedoch zur Aufgabenerfüllung spezifischer
Methoden benötigt werden, erlaubt werden. So kann durch die Methode
AccessController.doPrivileged() eine Klasse auf dem Stack als privilegiert
markiert werden. Dies hat zur Folge, dass ab dieser Klasse keine weiteren ProtectionDomains
kontrolliert werden. Zusätzlich besteht auch noch die Möglichkeit einen
Snapshot eines Aufrufkontextes zur Entscheidungsfindung heranzuziehen. Dies ist dann
notwendig, wenn die Überprüfung auf Basis eines speziellen Aufrufkontextes erfolgen
muss.
Betrachtet man die Standardimplementierung der Java 2 Security Policy als Matrix-Modell, so erfolgt die Speicherung der Sicherheitsmatrix zeilenweise. Die zeilenweise Abspeicherung ist bei Mobilen Agenten Architekturen vorzuziehen, da sich die Subjekte häufiger ändern. Desweiteren wird durch die Standardimplementierung ein DAC-Kontrollmechansimus realisert.
Der SecurityManager ist verantwortlich für die Rechtedurchsetzung.
In Java 2 werden die grundsätzlichen Überprüfungen der Zugriffe auf Ressourcen des
Endsystems von dem SecurityManager an den AccessController weitergeleitet.
Der AccessController ist in diesem
Fall für die Rechtedurchsetzung verantwortlich. Der SecurityManager, als auch der
AccessController betrachten den Stack, bzw. den Stack Context, um eine Entscheidung bzgl.
des Zugriffs treffen zu können.
In Java 2 sieht die Überprüfung durch den AccessController wie folgt aus:
Um Zugriffskontrollentscheidungen zu treffen, wird die Methode
getPermissions(codesource) einer konkreten Implementierung der abstrakten
Klasse java.security.Policy aufgerufen.
Die Methode bestimmt auf Basis der durchgesetzten Policy die Menge der
Berechtigungen (Permissions), die die aufrufende Klasse besitzen soll.
Die konkrete Implementierung der Policy-Klasse parst die Policy-Datei und erstellt
auf Basis der Einträge ein Permissions-Objekt.
Die Policy enthält die durchzusetzenden Zugriffskontrollregeln
in Form von Grant-Einträgen. Die Policy Einträge werden der Reihe nach ausgewertet.
Für einen erfolgreichen Zugriff muss jede ProtectionDomain einer Klasse des überprüften AccessControllContexts, der die ProtectionDomains des Stacks enthält, die notwendigen Berechtigungen in Form von Permission-Objekten beinhalten.
In Java sind daher keine Mechanismen vorhanden um Systemressourcen bezüglich der
Nutzungsdauer und Nutzungslast zu limitieren. Dies rührt auch daher, weil die
traditionellen Java Scheduler einfache Round Robin Systeme darstellen.
Können zum Beispiel noch einzelne Netzwerkverbindungen anhand
der Anzahl von Netzwerkverbindungen beschränkt werden, ist die
Übertragung von Datenmengen nicht limitierbar.
Es gibt jedoch auch Entwicklungen, die sich auf die Limitierung der Ressourcen konzentrieren. Das Java Betriebssystem, welches von dem Flux Projekt in Utah erstellt wurde, ist momentan eines der seltenen Systeme, welches Ressourcen Limitierung in Java realisiert. Dabei arbeitet man mit traditionellen Prozess-Modellen.
Wie bei jeder Software ist jedoch auch Java nicht 100% sicher! So wurde beispielsweise der Java 2 Bytecode Verifier erfolgreich attackiert. Unter bestimmten Umständen untersucht die Java Virtual Machine nicht den gesamten Bytecode, der geladen wird. So kann ein Angreifer Anweisungen einschmuggeln, welche die für Java typischen Sicherheitsmechanismen unterlaufen. Karsten Sohr ist es gelungen zu zeigen, dass sich tatsächlich auf diese Weise über das Internet in einen fremden Computer eindringen lässt. (Das Problem ist relativ einfach durch Hinzufügen einer einzigen Programmierzeile zu lösen [SOM 00]).
Capabilities
In Java stellen Capabilities eine simple Referenz auf ein Objekt dar.
Java Type Safety bewahrt dabei die Objektreferenzen vor Missbrauch.
Dabei werden Zugriffe auf Methoden oder Variablen blockiert, die nicht
als public deklariert worden sind [BAF 00].
Die momentanen Java Class Libraries benutzen bereits ein Capability
basiertes Interface, um offene Dateien und Netzwerkverbindungen zu
repräsentieren. Mithilfe statischer Methodenaufrufe werden die
entsprechenden Capabilities erworben. In einem weiter ausgebauten
Capability-basiertem System werden alle System Ressourcen (auch um eine
Datei erst zu öffnen) mithilfe Capabilities repräsentiert. In einem
solchen System wird einem Applet ein Array mit Capabilities bei der
Initialisierung übergeben.
Bei einem flexiblen Sicherheitsmodell wird das System die
Sicherheitspolitiken (Security Policies) vor dem Appletstart auswerten
und dem Applet daraufhin die Capabilities überreichen, die dem
Applet die in der Security Policy autorisierten Zugriffe ermöglicht.
Alternativ kann auch ein sogenannter Broker einer
authentifizierten Identität Capabilities übergeben.
Die Java Capabilities stellen einen Vermittler als exklusives Interface zu den System Ressourcen dar. Ein Programm muss z.B. die File System Capabilities, die es bei der Initialisierung oder durch einen Broker erworben hat benutzen, um auf Dateien zugreifen zu können. Die herkömmliche File-Klasse oder der Public Konstruktor FileInputStream darf somit nicht mehr genutzt werden. Damit die Sicherheit gewährt ist, sollte der Zugriff nur stattfinden können, falls ein Aufrufer das entsprechende Capability erhalten hat.
Die Schwierigkeit besteht darin, keine
andere Zugriffe zu ermöglichen, die die Sicherheitsvorkehrungen umgehen.
Da eine Capability nur eine Referenz auf ein Java-Objekt darstellt, kann
das referenzierte Objekt seine eigene Sicherheitspolitik (Security Policy) implementieren
und gegebenenfalls die Argumente, bevor sie an privaten,
internen Methoden übergeben werden, überprüfen.
Letztendlich kann eine Capability eine Referenz auf eine weitere
Capability beinhalten. Solange beide Objekte dasselbe Java Interface
implementieren, können die Capabilities voneinander unterschieden
werden.
Mit den momentanen Java Class Libraries kann ein Programm zum Öffnen einer Datei
seinen eigenen FileInputStream konstruieren. Um dies zu verhindern, darf
der FileInputStream keinen public-deklarierten Konstruktor haben oder
die FileInputStream-Klasse muss vor Programmen versteckt werden. Diese
Restriktionen betreffen natürlich auch andere Datei-relevante Java-Klassen,
wie z.B. die RandomAccessFile-Klasse. Während Java die Capabilities unterstützt,
sind signifikante Änderungen der Java Runtime Libraries und der, von den Libraries
abhängigen, Programme notwendig, um sicherstellen zu können, das der
Schutzmechanismus nicht mehr umgangen werden kann.
Extended Stack Introspection in Java
Variationen dieser Mechanismen finden sich in NS4.0, MSIE4.0 und Sun JDK1.2.
Ein vereinfachtes Modell des Stack Inspection kommt im NS3.0 zum
Einsatz [NET 00,DFW 84,ROS 00,BAF 00].
Extended Stack Introspection in den ersten Versionen von Java besaß ebenfalls die in Kapitel 2.6.6 aufgezeigte Confused Deputy-Problematik:
Das einfache Stack Inspection Modell erlaubte dem System Code
optional die Privilegien freizugeben. Bevor eine Datei geöffnet
oder eine andere Operation ausgeführt wird, überprüfte das System, ob diese
Privilegien freigegeben worden sind. Wurde vom System Code ein Privileg freigegeben
und danach ein nicht vertrauenswürdiges Applet ausgeführt, konnte das Applet
unautorisiert auf eine Ressource zugreifen.
Diese Attacke ist auch unter dem Namen ``Luring Attack'' bekannt.
Netscape löste dieses Problem, indem die Privilegien aller Stack Frames
bei der Suche berücksichtigt werden. Findet sich in einem Stack Frame ein
nicht vertrauenswürdiger Code, so wird das Privileg verweigert.
Der momentan in Java eingesetzte Stack Inspection Algorithmus betrachtet nicht
nur den nicht vertrauenswürdigen Code und den vertrauenswürdigen Systemcode.
Das System unterstützt Code einer unbegrenzten Anzahl von Principals, wobei
jedem Principal verschiedene Levels des Vertrauens ausgesprochen werden kann.
Es können Targets definiert werden, die verschiedene spezifische Privilegien
darstellen.
Extended Stack Introspection (vgl. Abb. 15) kommt z.B. bei den Browsern von Netscape und Microsoft zum Einsatz. JavaSoft arbeitet auch am Einsatz von Extended Stack Introspection. Für den Einsatz benötigt man die Operationen:
Netscape und Explorer bieten eine Reihe vordefinierter Targets, die
Ressourcen repräsentieren, an. Microsoft erlaubt nur voll
vertrauenswürdigen Codes neue Targets zu definieren, während
Netscape jedem erlaubt, ein Target zu erstellen. Somit können
Entwickler von Libraries ihre eigenen geschützten Ressourcen definieren.
Name Space Management in Java
Beim Name Space Management handelt es sich um eine Modifikation des Java`s
Dynamic Linking Mechanismus. Dieser Mechanismus wird benutzt, um für Applets
sichtbare Klassen zu verstecken oder auszutauschen. Name Space Management in
Java wird realisiert, indem der Java ClassLoader modifiziert wird.
Klassen von vertrauenswürdigen Subsystemen, die in nicht-vertrauenswürdigen
Codes enthalten sind, haben unterschiedliche Principals. Sie können somit
Klassen, die nur für vertrauenswürdigen Code sichtbar sind, einsehen [BAF 00].
Schwierig ist der Einsatz von Name Spaces bei geteilten Klassen. So nutzt das
Dateisystem und das Netzwerksystem die Klassen InputStream und
OutputStream. Diese können nicht einfach umbenannt bzw. ersetzt werden.
Zudem können neue Java Features, wie z.B. das Reflection API [GRE 00],
den Einsatz von Name Space Management unmöglich machen. Reflection und Klassen
Libraries könnten jedoch neu designed werden, damit der Einsatz von Name Space
Management möglich ist.
Beispielimplementierungen existieren als Zusatz für den Microsoft Explorer 3.0, wobei die JVM nicht modifiziert worden ist, jedoch Klassen in der Java Libraries geändert worden sind [BAF 00].
Ein Hauptanteil der Entwicklung von Sicherheitskonzepten und -mechanismen wurde auf der Suche nach einem sicheren Betriebssystem geleistet. Durch die Möglichkeit der Vernetzung von Komponenten und deren Zusammenarbeit mussten neue Konzepte und Mechanismen zum Schutz der Informationssicherheit gefunden werden.
Betrachtet man traditionelle Sicherheitskonzepte bezüglich Agentensystemarchitekturen, so kann man sagen, dass sie weder in der Lage sind den Sicherheitskontext einer Anfrage geeignet einzufangen, noch geeignete, ausdrucksfähige Politiken, zur Bestimmung ob die Anfrage zulässig ist, besitzen.
Eine Agentensystemarchitektur stellt neue Anforderungen an die Schutzkonzepte, wobei auch hier eine anwendungsspezifische, feingranulare Zugriffskontrollpolitik benötigt wird [REV 00]. Durch die Mobilität der Agenten wird ein kompletter Schutz der Informationssicherheit nicht nur erheblich erschwert, sondern deren Verwaltung wird zunehmend komplexer. Ebenso gilt es die Informationen eines Agenten zu sichern.
Die Realisation des Informationsschutzes der Agentensysteme ist ebenso eine schwierige
und komplizierte Aufgabe. Agenten müssen authentifiziert werden und einer geeigneten
Zugriffskontrolle unterworfen werden. Es müssen spezifische Eigenschaften der
Agenten beachtet werden, die sich im Laufe der Lebenszeit eines Agenten dynamisch ändern
können.
Betrachtet man die vorhandenen Konzepte und Mechanismen, die z.B. die Programmiersprache Java bereitstellt, so sind auch hier enorme Fortschritte zu verzeichnen. In Java wird softwarebasierter Schutz durch die Verwendung von Ausnahmebehandlungen (Exceptions) realisiert.
Java realisiert unterschiedliche Schutzmechanismen, welche beim Laden des Programms
zum Einsatz kommen (Übersetzer und Binder). Der Schutz vor direkten
Speicherzugriffen erhöht die Sicherheit. Durch die Java 2 Security Architecture
werden so grundlegende Sicherheitsanforderungen eines Sicherheitskonzepts erfüllt.
Beispielsweise ist die Zugriffskontrollpolitik von ihrem Durchsetzungsmechanismus
getrennt worden.
Dem Einsatz der Java 2 Security Architecture in unterschiedlichen Anwendungsgebieten sind jedoch auch Grenzen bezüglich der Sicherheit gesetzt. Dies ist hauptsächlich darauf zurückzuführen, dass die Sicherheitskonzepte größtenteils zur Lösung der durch die Applets verursachten Risiken konzipiert worden sind. Betrachtet man die Sicherheitsanforderungen von Agentensystemarchitekturen, sind grundlegende Sicherheitsanforderungen nicht erfüllbar.
Beispielsweise kann in Java zur selben Zeit nur eine systemglobale Sicherheitspolitik zum Einsatz kommen. Dabei steht vor allem der Schutz der Ausführungsumgebung im Vordergrund. Dynamische Änderungen der Politiken sind ebenso wenig vorgesehen, wie dynamische Änderungen von Zugriffsrechten aufgrund von sich dynamisch ändernden Eigenschaften der Subjekte. Anwendungsspezifische Sicherheitspolitiken die eine feingranulare Adressierung der Subjekte, Objekte und der Zugriffsrechte erfordern, können in der Standard Implementierung der Policy-Klasse nicht formuliert bzw. durchgesetzt werden. Desweiteren können Zugriffe auf Ressourcen nicht limitiert werden.
Das Modell besteht lediglich aus vier Komponenten: dem Agenten, dem Agentensystem, dem Endsystem und einer Person. Der Agent ist ein mobiler Agent (MA), der sich von Agentensystem zu Agentensystem bewegen kann. Ein Agentensystem (AS) stellt eine Umgebung zur Ausführung des Agenten bereit. Ein Agent besitzt immer ein Home-Agentensystem. Das Home-Agentensystem ist dabei dasjenige Agentensystem, auf dem der Agent erstmals gestartet wurde. Das Agentensystem wird auf einem Endsystem (ES) zur Ausführung gebracht. Zugriffe auf Informationen des Endsystems sind lediglich über das Agentensystem möglich. Die Kommunikation der einzelnen Entitäten erfolgt über Kanäle.
Das Endsystem, das Agentensystem und die Agenten
stellen spezifische Schnittstellen bereit, die über
wohldefinierte Kanäle angesprochen werden können.
Die Kommunikationsmöglichkeiten werden in der Abb. 16
als Pfeile dargestellt.
Die in dem Modell vorkommenden Komponenten können anhand der in Kapitel 2.1 definierten Begriffe zugeordnet werden:
Betrachtet man die einzelnen Subjekte, so sind verschiedene Zugriffe
möglich.
Bei Zugriffen von einem Agent auf einen Agenten,
von einem Agent auf ein Agentensystem und von einem
Agentensystem auf ein Agentensystem kann unterschieden werden,
ob es sich um einen lokalen oder einen entfernten Zugriff handelt.
Ausschlaggebend ist, wo sich das Subjekt und das Objekt zum Zeitpunkt
des Zugriffs befinden. Befinden sich das
Subjekt und das Objekt auf demselben Agentensystem, so handelt es sich
um einen lokalen Zugriff. Handelt es sich um einen entfernten Zugriff,
so befinden sich das Subjekt und das Objekt nicht auf demselben Agentensystem.
Eine Person kann auf folgende Objekte zugreifen:
(1.1) Agenten-Objekt
(1.2) Agentensystem-Objekt
(1.3) Endsystem-Objekt
Ein Agent kann auf folgende Objekte zugreifen:
(2.1) Agenten-Objekt lokal
(2.2) Agenten-Objekt entfernt
(2.3) Agentensystem-Objekt lokal
(2.4) Endsystem-Objekt lokal
Ein Agentensystem kann auf folgende Objekte zugreifen:
(3.1) Agenten-Objekt lokal
(3.2) Agenten-Objekt entfernt
(3.3) Agentensystem-Objekt lokal
(3.4) Agentensystem-Objekt entfernt
(3.5) Endsystem-Objekt lokal
Betrachtet man die Objekte, auf die zugegriffen werden kann, so
handelt es sich um Objekte von Agenten, Objekte von Agentensystemen
und um Objekte des Endsystems.
Betrachtet man die Agenten, Agentensysteme und Endsysteme, so müssen alle drei in der Lage sein, Zugriffe auf ihre Objekte zu beschränken. Hierfür müssen sie jeweils die Möglichkeit haben, ausdrücken zu können, wer auf Objekte zugreifen darf und wer nicht. Somit sind Zugriffskontrollpolitiken der Endsysteme, der Agentensysteme und der Agenten erforderlich.
Dabei ist darauf zu achten, dass die Durchsetzung der Zugriffskontrollpolitiken
nicht die Informationssicherheit der einzelnen Objekte gefährdet.
Betrachtet man mobile Agenten im Speziellen, so ist es erforderlich, dass
ein Agent jeweils an die lokale Umgebung gebunden, autorisiert und
einer Zugriffskontrolle unterzogen werden muss. Dabei ist zu
regeln, wer für Zugriffe, die dieser Agent durchführt, verantwortlich
ist.
Soll einem Subjekt ein Zugriff erlaubt werden oder explizit verboten werden, so müssen zur Durchsetzung dieser Forderung diese Subjekte authentifiziert werden können.
Die in MASA vorkommenden Subjekte (Personen, Agenten, Agentensysteme)
müssen demnach eindeutig authentifiziert werden können.
Die Identifikation der Subjekte muss nach wohldefinierten Eigenschaften
der Subjekte erfolgen. Die Eigenschaften sind dabei so zu wählen, dass
sie über Systemgrenzen hinaus ein Subjekt eindeutig identifizieren.
Da ein Agentensystem in einer verteilten Umgebung eingesetzt wird,
wird ein geeignetes Konzept benötigt, welches
die Authentifikation in einer verteilten Umgebung unterstützt.
Anhand der authentifizierten Identität können die Zugriffsrechte ermittelt werden, welche dem Subjekt durch eine Zugriffskontrollpolitik zugeteilt worden sind.
Hier sind spezifische Zugriffsrechte den
universellen Zugriffsrechten vorzuziehen (vgl. Def. in Kapitel 2.1).
Durch die Verwendung von spezifischen Zugriffsrechten wird die
Einschränkung der Zugriffe auf einzelne Informationen eines Objekts ermöglicht.
Ein spezifisches Zugriffsrecht steht eng in Verbindung mit der
Funktionalität des Objekts.
Die Zugriffsrechte sollten desweiteren eindeutig und daher aussagekräftig benannt sein, damit bei der Vergabe der Zugriffsrechte Fehler aufgrund falscher Interpretation ausgeschlossen sind. Durch die Namenvergabe muss eindeutig die Berechtigung erkennbar sein, die das Zugriffsrecht beinhaltet.
Autorisationsvorgänge müssen benutzerfreundlich, übersichtlich
und möglichst einfach und intuitiv erfolgen können.
Dabei ist die Eindeutigkeit und Widerspruchsfreiheit der Rechtevergabe
sicherzustellen.
Subjekte sollten nur Zugriffsrechte zugeteilt bekommen,
die sie unbedingt für die Erledigung der Aufgabe benötigen (Least-Privilege Prinzip).
Dazu gehört auch die Limitierung der
Systemressourcen.
Greifen räumlich verteilte Subjekte auf räumlich verteilte Objekte zu,
was in MASA der Fall ist, wird eine Rechtevergabe benötigt, die die
große Anzahl der Subjekte und Objekte ebenso handhaben kann, wie
auch die dynamische Erzeugung und Terminierung der Subjekte.
Da Zugriffsrechte unter Umständen wieder zurückgenommen werden müssen,
sollte das Rechtekonzept auch die Rechterücknahme berücksichtigen.
Durch das Vorhandensein unterschiedlicher Administrationsdomänen sind Zugriffskontrollpolitiken unterschiedlicher Interessengemeinschaften vorhanden. Sie machen ein Zusammenwirken der Zugriffskontrollpolitiken notwendig, welche die systematische Integration unterschiedlicher Zugriffskontrollpolitiken unterstützen muss.
Es müssen Zugriffskontrollpolitiken unterschiedlicher Administrationsbereiche
durchgesetzt werden, dazu gehören auch die benutzerspezifischen
Zugriffskontrollpolitiken der einzelnen Agenten.
Werden innerhalb der verschiedenen Zugriffskontrollpolitiken unterschiedliche
Zugriffsrechte auf z.T. ein und demselben Objekt vergeben, müssen bei der
Durchsetzung der beteiligten Zugriffskontrollpolitiken die
Autonomie-Anforderungender unterschiedlich beteiligten Objekte erfüllt werden.
Setzt ein Agentensystem beispielsweise zusätzlich zu seiner Zugriffskontrollpolitik
die Zugriffskontrollpolitik eines Agenten durch,
sollte durch die Zugriffskontrollpolitik des Agenten die Zugriffskontrollpolitik
des Agentensystems nicht verletzt werden.
D.h. Zugriffe, die nach der Zugriffskontrollpolitik des Agentensystems
erlaubt sind, müssen weiterhin erlaubt sein. Die Autonomie des Agentensystems
muss also gewährt bleiben. Zusätzlich darf die Informationssicherheit nicht verletzt
werden, d.h. Zugriffe die explizit durch die Zugriffskontrollpolitik des
Agentensystems verboten sind, müssen nach der Komposition mit der
Agenten-Zugriffskontrollpolitik immer noch verboten sein.
Um eine anwendungsspezifische Vergabe von Zugriffsrechten zu ermöglichen,
müssen Objekte beliebig feingranular adressiert werden können.
Die Granularität der adressierbaren Objekte ist dabei so zu wählen,
dass die Vergabe von Berechtigungen nach dem Least-Privilege Prinzip
(vgl Kapitel 2.3) ermöglicht wird.
Um auch benutzerspezifische Zugriffsrechte vergeben zu können, ist
ebenso eine feingranulare Adressierung der Subjekte notwendig.
Einfache Zugriffsbeschränkungen, d.h. Zugriffsbeschränkungen gebunden
an ein Subjekt, reichen für eine objektspezifische Vergabe von
Zugriffsrechten z.T. nicht aus.
Es müssen auch komplexe Zugriffsbeschränkungen, das sind
Zugriffsrechte geknüpft an Bedingungen, ermöglicht werden (vgl. [ECK 98]).
So muss innerhalb von MASA ermöglicht werden, dass Zugriffsrechte an einen
Agenten in Abhängigkeit seiner Vergangenheit (History) vergeben werden können.
Dabei müssen Bedingungen ausgedrückt werden können, die z.B.
die von dem Agenten zuvor besuchten Agentensysteme berücksichtigen.
Damit Agenten ihre Aufgabe an andere Agenten verteilen und diese Agenten die Aufgabe auch erledigen können, ist es notwendig, dass Agenten ihre Zugriffsrechte an weitere Agenten delegieren können. Die Weitergabe der Zugriffsrechte ist dabei zu kontrollieren, um die Informationssicherheit nicht zu gefährden.
Die Delegation der Zugriffsrechte darf jedoch nicht die Informationssicherheit gefährden.
Der gekennzeichnete Agent der Abb. 17 besitzt zuerst
als einziger das Zugriffsrecht, um auf das Objekt zuzugreifen. Nach der
Anforderung der Rechtedelegation sollte er jedoch in der Lage sein, das
Zugriffsrecht auch an einen weiteren Agenten delegieren zu können. Dabei kann
sich der zweite Agent auf dem gleichen Agentensystem, aber auch auf einem
entfernten Agentensystem, befinden.
Betrachtet man dieses Beispiel, so müssen folgende Anforderungen bezüglich der Rechtedelegation erfüllt werden, um die Informationssicherheit nicht zu gefährden:
Jeglicher Missbrauch der zur Rechtedelegation eingesetzten Mechanismen und Techniken muss ausgeschlossen werden. Dabei muss sichergestellt sein, dass kein Agent unberechtigterweise an ein Zugriffsrecht gelangen kann. So ist auch ein Konzept gefragt, welches ausschließt, dass ein bösartiges Agentensystem und ein bösartiger Agent durch Kooperation erreichen, dass der Agent unautorisierten Zugriff auf ein Objekt erlangt.
Es ist notwendig, die Delegation der Zugriffsrechte durch einen
geeigneten Mechanismus kontrollieren zu können. Beispielsweise
sollten Zugriffsrechte nur dann weitergegeben werden können,
wenn ein dafür notwendiges Zugriffsrecht vorhanden ist.
Auch hier ist darauf zu achten, dass die Zugriffskontrollpolitik des Eigentümers
nicht verletzt wird. Zugriffe, die nach der Zugriffskontrollpolitik
des Eigentümers erlaubt sind, müssen weiterhin erlaubt bleiben.
Die Informationssicherheit sollte ebenso nicht verletzt werden,
d.h. Zugriffe, die explizit durch die Zugriffskontrollpolitik des
Eigentümers verboten sind, dürfen nicht gewährt werden.
Dient die Rechtevergabe als Beschreibungsmittel für zulässige und unzulässige Zugriffe, ist die vollständige Durchsetzung der Rechtevergabe letztendlich für die Informationssicherheit verantwortlich.
Folgende Anforderungen müssen beachtet und realisiert werden:
Es darf keine Möglichkeit geben, die Rechtedurchsetzung zu umgehen.
Es ist erforderlich, dass alle Zugriffe der Subjekte auf Objekte
überprüft werden (Complete-Mediation Prinzip). Die Informationen, welche zur
Entscheidungsfindung herangezogen werden, müssen ebenfalls vor
unautorisierten Zugriffen geschützt werden. Manipulationen dieser
Informationen sind auszuschließen.
Bei einem Zugriff auf ein Objekt eines Agentensystems muss die Zugriffskontrollpolitik des Agentensystems durchgesetzt werden. Nur so kann die Informationssicherheit des Agentensystems sichergestellt werden. Bei einem Zugriff auf ein Objekt eines Agenten muss die Zugriffskontrollpolitik des Agenten durchgesetzt werden. Dabei ist die Zusammenarbeit mit der Zugriffskontrolle des Agentensystems notwendig. Die Zugriffskontrollpolitik des Endsystems ist bei Zugriffen auf die Informationen des Endsystems durchzusetzen.
Die Abb. 18 soll verdeutlichen, welche
Entität in MASA bei einem Zugriff jeweils eine Zugriffskontrolle durchführen muss.
Ein Pfeil bedeutet hier jeweils einen Zugriff auf ein Objekt. Das Subjekt ist
aus dem Pfeilursprung ersichtlich und das Ende des Pfeils
bezeichnet das Subjekt, auf welchem sich das Objekt, auf das
zugegriffen wird, befindet.
Die Zugriffskontrolle muss kontrollieren, ob das Subjekt das notwendige Zugriffsrecht besitzt, um auf das jeweilige Objekt zuzugreifen. Dabei sollte jeder nicht explizit autorisierte Zugriff verboten werden (Fail-Safe Defaults Prinzip).
Bei der Wahl des Konzepts und dessen Mechanismen zur Rechtedurchsetzung spielt die Funktionalität und Robustheit ebenso eine Rolle, wie die Effizienz (Performance), wobei auf Kompatibilitätseigenschaften (Compatibility) geachtet werden sollte. Die Sicherheit der eingesetzten Mechanismen und Techniken sollte dabei nicht von der Geheimhaltung der Verfahren abhängig sein (Open-Design Prinzip).
Jedes Objekt, auf das zugegriffen wird, muss in der Lage sein,
seine Sicherheitspolitik durchzusetzen. Nur so kann die Informationssicherheit
garantiert werden.
Mobile Agenten müssen an die lokale Umgebung gebunden,
autorisiert und einer Zugriffskontrolle unterzogen werden.
Wie bei jedem Zugriff muss auch hier der Zugriff einer
bestimmten Person zugeordnet werden.
Ein mobiler Agent handelt dabei als ein Abgesandter des Eigentümers
des Agenten und besitzt die Ausführungsrechte des Anwenders des Agenten.
Je nach Anwendungsgebiet von MASA ist eine Klassifizierung der
Anforderungen unterschiedlich. Dabei sollte MASA in der Lage
sein, auch Anforderungen einer hohen Integritätsstufe und einer
hohen Vertraulichkeitsstufe zu erfüllen.
Die einzelnen Sicherheitspolitiken der Endsysteme, Agentensysteme
und Agenten müssen durchgesetzt werden. Dabei darf die
Informationssicherheit der einzelnen Entitäten nicht gefährdet werden.
Die Sicherheitspolitik muss weiter durch eine Kontrollinstanz
verwaltet werden (Administrator), welche die Rechtevergabe
kontrolliert.
Betrachtet man die Beschränkung der Zugriffe näher, so sind
auch Zugriffe auf Systemressourcen zu limitieren.
Beispielsweise sollte der CPU-Verbrauch kontrolliert werden und nicht
unbeschränkt genutzt werden können.
Die folgende Zusammenfassung gibt nochmals einen Überblick über die
Sicherheitsanforderungen bezüglich des Rechtekonzepts:
Anforderungen der Authentifikation:
Bezüglich der Zugriffsrechte sind folgende Anforderungen zu erfüllen:
Die Rechtevergabe sollte unter anderem die Prinzipien aus Kapitel 2.3 berücksichtigen. Die folgenden Prinzipien müssen ebenfalls erfüllt werden:
Die Anforderungen der Rechtedurchsetzung in MASA sind:
In dieser Arbeit gilt es nun ein für MASA passendes Rechtekonzept zu entwickeln, dass diese Anforderungen erfüllt. Um herauszufinden, inwieweit die oben genannten Anforderungen schon erfüllt bzw. beachtet werden, wird im nächsten Kapitel MASA bezüglich dieser Anforderungen genauer untersucht und analysiert.
Analysiert werden die Authentifikation, die Rechtevergabe, die eingesetzten Zugriffsrechte und die eingesetzten Zugriffskontrollmechanismen.
Agentengattung - Agenteninstanz
Betrachtet man Agenten in MASA, so zerfällt der Begriff Agent
einerseits in die Agentengattung und andererseits in die
Agenteninstanz (vgl. [ROE 99] Kapitel 3.1).
Die Agentengattung entspricht dem statischen Teil eines Agenten.
Der statische Teil beinhaltet dabei alle Teile, welche alle
Agenten derselben Gattung besitzen, wie z.B. der
Programmcode der Agentengattung.
Die Agenteninstanz stellt den dynamisch Teil eines Agenten dar. Um einen Agenten auf einem Agentensystem auszuführen, wird der Programmcode (Agentengattung) instanziiert, d.h. auf dem Agentensystem zur Ausführung gebracht. Sobald der Programmcode auf dem Agentensystem ausgeführt wird, spricht man von einer Agenteninstanz. Die Agenteninstanz besitzt daher, im Gegensatz zur Agentengattung, dynamische Teile, die sich von Agent zu Agent derselben Gattung unterscheiden können. Beispiele dynamischer Teile sind die aktuelle Belegung der Attribute.
Die Abb. 19 zeigt folgende Entitäten:
Agentengattungen, Applets, Agenteninstanzen, Agentensysteme,
Endsysteme, Client-Systeme mit einem Browser, Benutzer von Agentensystemen,
Benutzer von Agenteninstanzen und Implementierer von Agentengattungen.
Eine von einem Benutzer implementierte Agentengattung kann instanziiert
werden. Bei einer instanziierten Agentengattung handelt es sich dann
um eine Agenteninstanz.
Die einzelnen Entitäten kommunizieren über Java-, CORBA- und
HTTP-Kanäle (vgl. [ROE 99] Kapitel 3.1).
Da die Agentengattung u.a. den Programmcode des Agenten darstellt, kann ihr der Implementierer zugeordnet werden. Der Implementierer ist die Person, die die Agentengattung implementiert hat.
Eine Agenteninstanz kann einerseits dem Eigentümer, die Entität,
die die Agenteninstanz gestartet hat und andererseits dem Anwender,
die Person, die den Agenten verwendet, zugeordnet werden.
Ein Agentensystem hat ebenso einen Eigentümer. Das ist die Person, die
das Agentensystem gestartet hat. Entitäten, die das Agentensystem benutzen, sind die
Anwender des Agentensystems.
Hier wird jeweils die Funktionalität eines Benutzers betrachtet. In MASA existieren demnach die unten genannten Benutzer, deren Oberklasse folgend als Person bezeichnet wird (vgl. [ROE 99] Kapitel 5.1.1).
Betrachtet man die Aufgaben der Personen, so ist der Eigentümer einer Agenteninstanz nur für die jeweilige Agenteninstanz verantwortlich.
Der Eigentümer eines Agentensystems ist verantwortlich
für das Agentensystem und übernimmt zusätzlich noch
administrative Aufgaben.
Die administrativen Aufgaben können sich dabei auch
auf die Agenteninstanzen beziehen, die auf dem Agentensystem
ausgeführt werden bzw. zur Ausführung gebracht werden sollen.
Eine weitere Unterscheidung, die man vornehmen kann, ist die Unterscheidung,
ob eine Entität ein Subjekt oder ein Objekt ist (vgl. Kapitel 2).
In MASA können Applets, Agenteninstanzen, Agentensysteme, Client-Systeme
und Benutzer Subjekte darstellen, die auf Objekte zugreifen.
Objekte in MASA können Agentengattungen, Agenteninstanzen,
Agentensysteme und Endsysteme sein. Auf diese Objekte kann zugegriffen werden.
Agentensysteme und Agenteninstanzen können demnach die Stellung eines
Subjekts und die Stellung eines Objekts einnehmen.
Die Subjekte können jeweils Aktionen an den von den Objekten
bereitgestellten Schnittstellen ausführen.
Ein Benutzer kann beispielsweise durch ein Applet, welches auf seinem Browser zur Ausführung gebracht wird, auf eine Agenteninstanz zugreifen und Aktionen ausführen (vgl. Abb. 19). Die durch den Benutzer getätigten Aktionswünsche werden von den Applets über CORBA-Kanäle an die Agenteninstanzen weitergeleitet. Die Agenteninstanzen kommunizieren über einen Java-Kanal und einen CORBA-Kanal mit dem Agentensystem, auf dem sie ausgeführt werden. Agenteninstanzen können durch Java-API Aufrufe auch Aktionen auf dem Endsystem ausführen. Agenteninstanzen sind auch in der Lage über einen CORBA-Kanal andere Agenteninstanzen zur Ausführung bestimmter Aktionen zu veranlassen. Die Agentensysteme untereinander verständigen sich über CORBA-Kanäle (vgl. [ROE 99] Kapitel 3.1).
Ausgangsbasis des Sicherheitmodells von MASA ist die Annahme, dass für
alle Entitäten eine getrennte Ausführungsumgebung bereitgestellt wird.
Dies gilt für die Trennung zwischen Agentensystemen, zwischen
Agentensystem und Agenteninstanzen und zwischen
Agenteninstanzen (vgl. [ROE 99] Kapitel 5.3).
Realisiert wird die Trennung durch die Verwendung von Thread-Groups für
Agenteninstanzen und durch die Trennung der Namensräume der
Entitäten durch den Java ClassLoader (vgl. [ROE 99] Kapitel 6.3.2-3).
So bekommt jede Agenteninstanz, bevor die Hauptklasse der Agenteninstanz
geladen wird, eine eigene ClassLoader-Instanz, die dann den Programmcode
der Hauptklasse aus dem Code Repository lädt.
Die Trennung der Namensräume bleibt auch dann bestehen, wenn eine
Agenteninstanz weitere Klassen nutzt, da hier derselbe
ClassLoader verwendet wird.
Architektonisch bedingt gilt aufgrund der Einbettungsbeziehung,
dass ein Agentensystem seinem Endsystem und ein
Agent seinem Home-Agentensystem vertrauen muss (vgl. [ROE 99] Kapitel 5.2).
Sicherungsmaßnahmen werden durch das Agentensystem überwacht und
durchgesetzt. Dabei wird eine negativistische Grundannahme durchgesetzt, d.h.
dass alles verboten wird, was nicht explizit erlaubt ist.
Da das Agentensystem die Sicherungsmaßnahmen überwacht und durchsetzt,
kann es auch die Sicherung zwischen den Agenteninstanzen übernehmen, wodurch die
Agenteninstanzen u.a. voreinander geschützt werden können.
Die Endsysteme und die Agenteninstanzen müssen sich daher aber auch
auf das Agentensystem verlassen können (vgl. [ROE 99] Kapitel 3.7).
Durch die Verwendung des plattformunabhängigen Agentensystems als Kontrollinstanz,
steht eine vereinheitlichte Schnittstelle für das Management
der Sicherheit zur Verfügung.
Der Einsatz des Code Repositories in MASA trägt zum Schutz der Informationssicherheit bei. Bei einem Zugriff einer Agenteninstanz können zwei Vertrauensbeziehungen unterschieden werden:
Auch hier trifft das Agentensystem die Entscheidung bezüglich des
zu verwendendem Code Repository, von dem die Agentengattung
geladen werden soll. Zusätzlich entscheidet das
Agentensystem noch, ob es sich bei einem Zertifikat eines
Subjekts um ein vertrauenswürdiges Zertifikat handelt.
(Die Entscheidung, ob ein Zertifikat vertrauenswürdig ist,
muss ebenso eine Agenteninstanz treffen können.)
Die Kommunikationskanäle werden durch geeignete
Mechanismen geschützt.
Dabei wird das Secure Socket Layer (SSL) Protokoll V3.0 für die
in MASA eingesetzten CORBA/IIOP- und HTTP-Kanäle verwendet.
Das SSL-Protokoll unterstützt dabei zusätzlich die Authentisierung
durch den sicheren Austausch von Zertifikaten (vgl. [ROE 99] Kapitel 6.1.2).
Der HTTP-Kanal verwendet das unter dem Namen HTTPS bekannte
SSL-Verfahren. Der CORBA-Kanal wird ebenfalls durch das SSL-Protokoll
geschützt. In MASA kommt hierfür ein SSL-fähiger ORB zum Einsatz.
Eine Agenteninstanz kann nur über den CORBA-Kanal mit einer weiteren Agenteninstanz oder dem Agentensystem kommunizieren. Dadurch kann in diesem Fall die Sicherung des Java-Kanals entfallen.
Betrachtet man das Sicherheitsmodell, so sind alle handelnden Entitäten (Personen, Agenteninstanzen, Agentensysteme) in der Lage, über gesicherte Kanäle zu kommunizieren, womit eine Basis eines sicheren Agentensystems gegeben ist. Bezüglich der Informationssicherheit muss desweiteren die Authentifikation der Entitäten möglich sein.
Die eindeutige Identifizierung der Entitäten ist in MASA sichergestellt.
Jede Entität (Principal) ist mit einem eindeutigen Identifikator
versehen, der eine verteilte Umgebung unterstützt (vgl. [ROE 99] Kapitel 5.5).
Die Agentengattung wird beispielsweise über eine Kombination des Namens und
eine organisatorische Klassifizierung identifiziert.
Der eindeutige Identifikator einer Agentengattung
FOO-Agent wird durch den Namen der Hauptklasse erzeugt:
[ de.unimuenchen.informatik.mnm.FOO.FOOMobileAgent]
Der Name wird aus dem DNS-Namen informatik.uni-muenchen.de,
der Organisation MNM, der Gattung FOO und dem Typen mobiler Agent gebildet.
Ausgehend davon, dass jede Organisation, die einen Agenten implementiert,
im DNS-Namensraum vertreten ist, ist die Bildung des Gattungsnamen ausreichend
für die eindeutige Identifizierung.
Zudem wird jedem Agentensystem über den NamingWebServer beim Start eine
in der Region eindeutige ID-Nummer zugewiesen.
Beim Erzeugen einer
Agenteninstanz auf einem Agentensystem bekommt die Agenteninstanz eine
vom Agentensystem erzeugte, fortlaufende Nummer zugewiesen.
Dadurch können Agenteninstanzen derselben Gattung auf einem
Agentensystem unterschieden werden.
Agenteninstanzen und Agentensysteme können eindeutig über die
Datenstrukturen, die in MASA eingesetzt werden, identifiziert werden.
Die Identifizierung der Endsysteme können über den Identifikator
des Agentensystems eindeutig identifiziert werden (auch hier wird
für die Identifizierung der DNS-Namensraum herangezogen).
Die Client Systeme werden im Namensraum der IP-Adressen identifiziert.
Personen können über ihre Zertifikate identifiziert werden.
Die Eindeutigkeit wird hier über die Kombination von Namen und
einer organisatorischen Klassifizierung erreicht.
Betrachtet man die Entitäten als Klassen, existiert die Oberklasse Principal und eine Unterklasse für die spezifischen Entitäten. Neben einem gemeinsamen Attribut (Identifikator) aller Entitäten (Principals) werden die Subtypen Agentensystem und Agenteninstanz mit weiteren Attributen versehen, damit eine Beziehung zu den Personen des Modells hergestellt werden kann. Die Abb. 20 zeigt das Klassendiagramm.
Für Agenteninstanzen und Agentensysteme werden jeweils die Authority
(Eigentümer) und der Implementierer betrachtet.
Unterscheidungen bezüglich des Implementierers und des Eigentümers sind
damit möglich.
Die Authority, also der Eigentümer einer Agenteninstanz, kann eine Agenteninstanz, ein Agentensystem oder eine weitere Entität (Principal) sein. Der Eigentümer (Authority) eines Agentensystems kann nur eine Person sein. Ein Implementierer einer Agentengattung oder eines Agentensystems kann ebenfalls nur eine Person sein.
Entitäten können somit anhand von wohldefinierten Eigenschaften identifiziert werden (vgl. [ROE 99] Tabelle 5.2):
Werden die Identitäten der Entitäten verifiziert, sind sie gegenüber
des Agentensystems authentifiziert.
Die Verifikation der Identität eines Principals
erfolgt in MASA durch ein Public-Key-Verfahren.
Ein Principal ist mit einem Schlüsselpaar ausgestattet.
Jedes Principal kann eindeutig identifiziert werden und ist
Eigentümer eines Schlüsselpaars, wodurch die Erstellung
eines Zertifikats ermöglicht wird. Hierfür
unterzeichnet die Entität ihren Identifikator mit dem
geheimen Schlüssel, woraus eine Signatur entsteht.
Das 3er-Tupel: Identifikator, Signatur und öffentlicher Schlüssel
stellen das Zertifikat der Entität dar.
Durch die Zertifikate lassen sich unmittelbar handelnde
Entitäten (Principals) authentisieren (vgl. [ROE 99] Kapitel 5.5.2).
Damit auch die Zugehörigkeit des Schlüsselpaares zu dem jeweiligen Principal überprüft werden kann, werden Zertifikatketten eingesetzt.
Ein Zertifikat kann von einem weiteren Principal signiert werden, der für die Echtheit des Zertifikats bürgt. Dieses Principal kann gegebenenfalls wiederum von einem Principal signiert worden sein (usw.). Anhand der Überprüfung der Zertifikatkette, kann festgestellt werden, ob ein Zertifikat als vertrauenswürdig eingestuft werden kann. Ist dies der Fall, kann das Schlüsselpaar eindeutig dem Principal zugeordnet werden und das Principal kann als authentifiziert betrachtet werden.
Um alle Principals authentisieren zu können, ist:
Das Zertifikat für die Authority eines Agentensystems wird out of band erteilt, also nicht durch eine Entität die dem Agentensystem angehört. Die Erteilung eines Zertifikats kann z.B. durch eine vorhandene Zertifizierungshierarchie erstellt werden.
Das Zertifikat für ein Agentensystem kann mit dem Zertifikat für die Authority eines Agentensystems erstellt werden.
Ablauf der Zertifikaterstellung eines Agentensystems (aus [ROE 99] Kapitel 5.5.4):
Aufgrund dieser Vorgehensweise wird die Authority eines Agentensystems
immer durch das vorletzte Zertifikat in der Zertifikatkette definiert
(Das vorletzte Zertifikat steht in der Abb. 21
an zweiter Stelle von oben).
Ein Sitzungszertifikat für Agenteninstanzen wird jeweils bei der Erzeugung einer Agenteninstanz von einem Agentensystem erstellt (aus [ROE 99] Kapitel 5.5.4):
Aus diesem Sitzungszertifikat der Agenteninstanz lassen sich folgende Identitäten ableiten:
Die Zertifikate für Implementierer und Anwender von Agenten
werden in der Regel ebenfalls out of band von unabhängigen
Instanzen generiert.
Folgend eine Übersicht der Eigentümer eigener Zertifikate (vgl. [ROE 99] Tabelle 5.2):
Die Authentifikation aller Attribute einer Agenteninstanz kann
auf eine Signatur des erzeugenden Agentensystems zurückgeführt werden.
Dies betrifft z.B. auch die History der Agenteninstanz.
Realisiert wird die Verwendung von Zertifikaten und Schlüsseln durch die Verwendung der Java Cryptography Extension (JCE). Ein Zertifikat Manager (CertificateManager) erstellt und speichert das Agentensystemzertifikat und die Sitzungszertifikate der Agenteninstanzen. Außerdem überprüft er die Integrität der Zertifikatketten und kann anhand einer Authentication-Policy die Vertrauenswürdigkeit der Zertifikate bestimmen (vgl. [ROE 99] Kapitel 6.6.1).
Durch die Verwendung von Code Repositories, die die Gattungsdaten
einer Agentengattung bereitstellen, ist es möglich, die
Agentengattung und die Agenteninstanz unabhängig voneinander
zu autorisieren.
Die in einem Code Repository befindliche Agentengattung ist dort
als JAR-Datei ([OAK 00]) abgelegt.
Die Zuordnung der Agentengattung zu einem Implementierer sowie
die Sicherstellung der Integrität
wird durch die digitale Signatur des Implementierers realisiert.
Hierfür legt der Implementierer sein Zertifikat innerhalb der
JAR-Datei ab und signiert daraufhin die
JAR-Datei (vgl. [ROE 99] Kapitel 6.5.1).
Die für die Authentisierung eingeführten Methoden
werden zudem zur Sicherstellung der Integrität von
Informationen und zur gesicherten Kenntlichmachung des Erstellers der
Information herangezogen.
Fazit
In MASA können somit alle handelnden Entitäten authentifiziert werden
und auch mit einer Person in Verbindung gebracht werden, die
für die handelnde Entität verantwortlich ist.
Zudem ist durch die Verwendung von Zertifikaten und der
Wahl der eindeutigen Namen auch die globale Authentifikation sichergestellt.
Die Authentisierungsanforderungen aus Kapitel 3
werden somit erfüllt.
Durch den Authentifikationsmechanismus ist die Grundlage vorhanden,
Zugriffsrechte an Subjekte innerhalb einer Zugriffskontrollpolitik
gezielt vergeben zu können.
Die Sicherungsmaßnahmen betreffen hier nur Objekte des Endsystems.
Die in der Zugriffskontrollpolitik des Endsystems vorgenommenen
Autorisationen sind über die gesamte Dauer der Ausführung eines
Agentensystems gültig. Der Schutz durch die Zugriffskontrollpolitik
des Endsystems wird daher dann eingesetzt, wenn auf Informationen des Endsystems
nie oder immer von einem Agentensystem bzw. einer Agenteninstanz aus
zugegriffen werden soll.
Die Zugriffskontrollpolitik des Endsystems ist von dem Betriebssystem abhängig, auf dem das Agentensystem zur Ausführung gebracht wird.
Wird ein Multiuser Betriebssystem eingesetzt, kann ein Endsystem
zwischen verschiedenen Eigentümern eines Agentensystems unterscheiden.
Unterschiedliche Personen könnten so Agentensysteme auf dem
Endsystem, mit jeweils unterschiedlichen Zugriffskontrollpolitiken ausführen.
Zugriffe durch ein Agentensystem auf das Endsystem können so individuell
vom Endsystem autorisiert werden.
Die Autorisation ist dabei von dem Administrator des Endsystems vorzunehmen.
Wird MASA beispielsweise verwendet, nur um statistische Daten eines
Endsystems auszulesen und zu verwerten, wobei keine Schreibberechtigung
benötigt wird, reicht es aus, dass die Personen, welche die Agentensysteme
starten, nur Leseberechtigungen besitzen. Durch die Zugriffskontrollpolitik
des Endsystems kann nun der schreibende
Zugriff eines Agentensystems (und der Agenteninstanzen, die auf
dem Agentensystem ausgeführt werden) auf das Endsystem gänzlich
unterbunden werden.
Im Normallfall soll das Agentensystem jedoch das darunterliegende Endsystem vollständig nutzen können. Nur so kann die volle Funktionalität eines Agentensystems genutzt werden. Dabei ist davon auszugehen, dass der Benutzer, der das Agentensystem startet, eine Berechtigung besitzt, die einem Administrator des Endsystems gleichkommen. Die Sicherheitsanforderungen, die von dem Agentensystem erfüllt werden müssen, sind dann dementsprechend hoch.
In der Abb. 22 sind die Zugriffe ersichtlich, die durch die Zugriffskontrolle des Endsystems beschränkt werden können. Dabei wird die Autorisation durch die Zugriffskontrollpolitik des Endsystems vorgenommen. Zu beachten ist jedoch, dass die in der Zugriffskontrollpolitik beschränkten Zugriffe über die ganze Lebenszeit eines Agentensystems bestehen bleiben und nicht geändert werden können. Zudem können die Zugriffsbeschränkungen nicht anwendungsspezifisch erfolgen. Aus diesem Grund sind, auch um die Funktionalität des Agentensystems nicht einzuschränken, die Zugriffsbeschränkungen der angegebenen Zugriffe möglichst nur vom Agentensystem aus vorzunehmen.
Das Agentensystem muss Zugriffe auf seine Schnittstellen und die Schnittstellen des Endsystems autorisieren. Zusätzlich müssen evtl. noch Zugriffe auf Schnittstellen der Agenteninstanzen autorisiert werden.
Dies ist dann notwendig, falls Agenteninstanzen eine
von der Agenteninstanz nicht autorisierte Schnittstelle anbieten,
die auf dem Agentensystem oder dem Endsystem kritische Aktionen ausführt.
Durch die Autorisationsmöglichkeit des Agentensystems müssen hier
kritische Aktionen, die durch die Agenteninstanz auf dem Agentensystem oder
auf dem Endsystem ausgeführt werden, beschränkt werden.
Das Agentensystem autorisiert in diesem Fall die Benutzung der von der
Agenteninstanz angebotenen Schnittstelle.
In MASA können momentan Agenteninstanzen durch die Vergabe von Zugriffsrechten in der Java System Policy autorisiert werden. Die innerhalb der Java System Policy vergebenen Zugriffsrechte werden einer Agenteninstanz beim Ladevorgang zugeteilt. Es handelt sich daher nur um statische Zugriffsrechte, wobei die Autorisation auf der CodeSource der jeweiligen Agenteninstanz basiert.
Desweiteren existiert auf jedem Agentensystem eine MASA Policy-Datei
( masa.boot.policy). Innerhalb dieser Datei werden für die
Ausführung des Agentensystems relevante, spezifische Zugriffsrechte vergeben.
Zusätzlich werden in der masa.boot.policy-Datei noch Zugriffsrechte
für Agenteninstanzen vergeben. Dabei handelt es sich um rudimentäre
Zugriffsrechte, die zur Ausführung einer Agenteninstanz benötigt werden.
Zudem werden hier Zugriffsrechte vergeben, anhand derer bestimmt werden
kann, ob eine Agenteninstanz berechtigt ist, Klassen zu definieren
bzw. Klassen zu benutzen (vgl. [ROE 99] Kapitel 7.7.1).
Adressierung der zugreifenden Subjekte
Momentan können nur Agenteninstanzen autorisiert werden.
Die Autorisation einer Agenteninstanz erfolgt auf Basis der Agentengattung.
Dies ist darauf zurückzuführen, dass innerhalb der Standardpolicy
zugreifende Subjekte nur anhand des Herkunftorts (URL) und einer
Signatur adressiert werden können (vgl. Kapitel 2.9).
Eine Agentengattung wird in MASA in ein Code Repository in Form einer
JAR-Datei abgelegt. Dabei entspricht der Name der JAR-Datei dem
Namen der Agentengattung. Dadurch ist durch den Herkunftsort der
Agentengattung die Agentengattung erkennbar.
Durch die zusätzliche Möglichkeit, die JAR-Datei signieren zu können,
kann hier die Signatur herangezogen werden, um den Implementierer der
Agentengattung zu bestimmen. Der Implementierer einer Agentengattung
legt sein Zertifikat innerhalb der JAR-Datei ab und signiert daraufhin
die JAR-Datei.
Autorisationen innerhalb der Standard Java Policy auf Basis einer Signatur
repräsentieren daher den Implementierer der Agentengattung.
Betrachtet man den folgenden Eintrag der System Java Policy, wird der Agentengattung [messe], welche vom Implementierer [Lorenz] implementiert worden ist, erlaubt, den Namen des Betriebssystems auszulesen:
![\includegraphics [totalheight=0.25\textheight]{introspection.eps}](img19.gif)
![\includegraphics [totalheight=0.30\textheight]{anf-agentmodell.eps}](img20.gif)
![\includegraphics [totalheight=0.17\textheight]{anf-ma-re-de.eps}](img21.gif)
![\includegraphics [totalheight=0.23\textheight]{anf-ma-komm.eps}](img22.gif)
![\includegraphics [totalheight=0.35\textheight]{agentenmodel-masa.eps}](img23.gif)
![\includegraphics [totalheight=0.2\textheight]{klassendiagramm-auth.eps}](img24.gif)
![\includegraphics [totalheight=0.25\textheight]{risiko-zertifikat.eps}](img25.gif)
![\includegraphics [totalheight=0.25\textheight]{anf-ac-es.eps}](img26.gif)
grant signedBy "Lorenz",
codeBase "systemresource://de/unimuenchen/informatik/mnm/masa/agent/messe"
{
permission java.util.PropertyPermission "os.name", "read";
}
Zugriffsrechte
Bei den in der Standard Java Policy eingesetzten Zugriffsrechten handelt es sich
um spezifische Zugriffsrechte (vgl. Kapitel 2.6.2).
D.h., dass das Zugriffsrecht die Berechtigung und das spezifische Objekt adressiert.
Das Zugriffsrecht hängt somit eng mit der Funktionalität des Objekts
zusammen.
Adressierung der Objekte
Die Adressierung der Objekte erfolgt demnach innerhalb des Zugriffsrechts.
Dabei existieren für die Objekte des Endsystems, auf die zugegriffen werden
kann, standardisierte Permission-Objekte. Ein Zugriff auf ein
Endsystem Objekt erfolgt durch einen Java-API Aufruf. Innerhalb der
Java-API existieren spezifische Permission Objekte, die verwendet
werden können.
Diese Permission Objekte können in der Java Policy
zugeteilt werden. Die Granularität der Objekte des Endsystems sind
vorgegeben, i.Allg. jedoch ausreichend.
In MASA können innerhalb der Standard Java Policy jedoch keine Zugriffsrechte für Objekte der Agentensysteme und Agenteninstanzen vergeben werden, da hier keine Permission Objekte zur Verfügung gestellt werden.
Die Möglichkeit, spezifische Permission Objekte zu erstellen, ist zwar gegeben,
jedoch fehlt hier eine Spezifikation.
Werden solche Permission Objekte erzeugt, müsste ein
quasi Standard für MASA existieren, der die Struktur der
Permission Objekte festlegt. Nur so könnte sichergestellt werden,
dass jeder Administrator die zu vergebenden Permission Objekte kennt,
eindeutig interpretieren und vergeben kann.
Eine Beispielimplementierung von MASA spezifischen Permission Objekten
findet sich in [ROE 99] Kapitel 7.7.1.
In der Abb. 23 werden alle
Zugriffsmöglichkeiten aufgezeigt, die durch die
Zugriffskontrolle des Agentensystems kontrolliert werden müssen.
In MASA können momentan nur Zugriffe von Agenteninstanzen auf Objekte
des Endsystems und Zugriffe bezüglich der Definition und der
Nutzung von Klassen autorisiert werden.
Bewertung
Betrachtet man die Autorisationsmöglichkeit des Agentensystems, so sind
hier keine anwendungsspezifischen Autorisationen möglich, da keine
subjektspezifische Vergabe von Zugriffsrechten möglich ist.
Erst durch eine subjekt- und objektspezifische Autorisation ist es möglich,
ein Subjekt nur für eine spezielle Aufgabe und damit anwendungsspezifisch
zu autorisieren.
Agenteninstanzen können nur auf Basis ihrer Agentengattung autorisiert werden.
Die Autorisation einer Agenteninstanz auf Basis der Agentengattung ist jedoch
unzureichend.
Zugriffe von Agentensystemen auf Agentensysteme und Agenteninstanzen
können überhaupt nicht autorisiert werden.
Letztendlich können innerhalb der Java System Policy nur Zugriffe
von Agenteninstanzen auf Informationen des Endsystems autorisiert werden und
das nur auf Basis der Agentengattung der Agenteninstanz.
Zudem ist die Autorisation nur statisch. D.h. die Autorisation kann nicht
von bestimmten Bedingungen abhängig gemacht werden.
Durch die Verwendung von spezifischen Zugriffsrechten können Zugriffsrechte für Objekte anwendungsspezifisch erzeugt werden. Eine objektspezifische Autorisation ist durch die Möglichkeit der Erzeugung eigener spezifischer Zugriffsrechte gegeben. Jedoch wird kein spezielles Konzept zur Erzeugung und Benennung von MASA spezifischen Permission-Objekten vorgegeben. Daher ist die Eindeutigkeit und Verwechslungsfreiheit der Zugriffsrechte nicht gegeben. Zugriffe von Agenteninstanzen auf Objekte des Agentensystems bzw. einer weiteren Agenteninstanz können somit ebenfalls nicht geeignet autorisiert werden.
Eine Agenteninstanz ist momentan in MASA nicht in der Lage, Zugriffe auf ihre Informationen zu beschränken. Die Informationssicherheit der Agenteninstanzen ist daher nicht sichergestellt.
Jede Agenteninstanz wird von einem eigenen ClassLoader geladen,
der jeweils seinen eigenen separaten Namensraum definiert. Dieser
ClassLoader ist für die Lokalisierung und das Laden von Klassen
verantwortlich, die die Agenteninstanz bei der Ausführung benötigt.
Durch den ClassLoader Mechanismus wird der Agenteninstanz zudem eine spezifische
Protection Domain zugewiesen. Eine Protection Domain beinhaltet dabei die
Zugriffsrechte, die der Agenteninstanz auf Basis ihrer Agentengattung
innerhalb der Java Policy Datei zugeteilt worden sind.
Genau diese Zugriffsrechte werden nun von dem Agentensystem durch
die Verwendung des SecurityManagers bzw. des AccessControllers durchgesetzt.
Greift nun eine Agenteninstanz auf Informationen des Endsystems zu,
wird dieser Zugriff von dem SecurityManager des Agentensystems kontrolliert.
Die Durchsetzung der Zugriffskontrollpolitik des Endsystems erfolgt betriebssystemspezifisch. Da Agenteninstanzen keine Zugriffskontrollpolitik haben, ist deren Durchsetzung auch nicht möglich.
Die Unterscheidung zwischen Agentengattungen und Agenteninstanzen ermöglicht eine differenzierte Autorisation anhand einerseits der Agentengattung und deren Implementierer und andererseits der Attribute einer Agenteninstanz.
Die Kanäle, welche zur Kommunikation der Entitäten genutzt werden, sind gänzlich durch die Verwendung von Public-Key-Verfahren gesichert.
Durch die Bereitstellung von abgeschotteten Ausführungsumgebungen
sind Agenteninstanzen voreinander geschützt. Die Bereitstellung
der abgeschotteten Ausführungsumgebungen durch das Agentensystem
schützt zudem das Agentensystem vor Agenteninstanzen.
Betrachtet man den Schutz der Daten einer Agenteninstanz oder
eines Agentensystems, so kommen zuerst die Visibilitätsmodifikatoren
und noch einige weitere Modifikatoren (z.B. der final Modifikator)
von Java zum Einsatz (vgl. Kapitel 2.9).
In MASA werden die von Java bereitgestellten Schutzmechanismen konsequent
eingesetzt und dienen der Implementierung statischer Zugriffstrukturen,
wodurch Klassen, Attribute und Methoden geschützt werden.
Zum Schutz der Endsystemschnittstelle verwendet MASA die Java Platform 2 Security Architecture (vgl. Kapitel 2.9). Dabei kommt der Mechanismus der ProtectionDomain und des SecurityManagers in Kombination mit dem AccessController zum Einsatz.
Durch die Verwendung der Security Policy wird einer
Agenteninstanz eine spezifische Protection Domain zugewiesen, die
die innerhalb der Policy zugeteilten Zugriffsrechte
in Form von Permission Objekten enthält.
Die Permission Objekte sind für Aktionen, welche auf
dem Endsystem ausgeführt werden können, durch die
Java Sicherheitsarchitektur vorgegeben.
Die zur Sicherung der Informationssicherheit eingesetzten Mechanismen
erfüllen jedoch nicht die Anforderungen aus Kapitel 3.
So wird nicht jeder Zugriff auf ein Objekt kontrolliert (complete mediation).
Damit kann auch nicht garantiert werden, dass jeder Zugriff, der nicht
explizit erlaubt ist, verboten ist (fail-safe defaults).
Zugriffe von Agentensystemen können innerhalb der Policy Datei
nicht autorisiert werden. Agenteninstanzen können Zugriffe auf
ihre Schnittstellen überhaupt nicht autorisieren.
Nur der statische Code einer Agentengattung ist durch die
vorhandene Signatur der JAR-Datei vor unautorisierten Modifikationen
durch die Signatur geschützt.
Dynamische Informationen, die eine
Agenteninstanz während der Lebenszeit besitzt, sind ebenfalls nicht
vor unautorisierten Zugriffen geschützt.
Es kann demnach nur das Agentensystem Zugriffe auf seine Schnittstellen und auf Schnittstellen von Agenteninstanzen beschränken. Betrachtet man die Autorisation der Zugriffe der Agenteninstanzen, so sind jedoch auch hier nicht alle Anforderungen erfüllt.
Die Adressierung der Agenteninstanzen in der Java Policy Datei kann nicht benutzerspezifisch erfolgen. Die Vergabe von Berechtigungen nur auf Basis der Gattung und des Implementierers der Gattung ist als unzureichend anzusehen. Hier wird eine benutzerspezifische Vergabe von Zugriffsrechten benötigt.
Desweiteren kann die Autorisation von Agenteninstanzen auch nicht von bestimmten
Bedingungen abhängig gemacht werden. So ist eine Autorisation von
Agenteninstanzen, die von der Vergangenheit (History) der Agenteninstanz
abhängt, nicht möglich.
Betrachtet man explizit die Zugriffsrechte, so handelt es sich um spezifische Zugriffsrechte. Diese Zugriffsrechte adressieren somit auch die Objekte und nicht nur die Aktion. Die objektspezifische Adressierung ist hier möglich, jedoch fehlt eine Standardisierung, um die Eindeutigkeit der Zugriffsrechte zu garantieren.
Sind die durch die Java-API standardisierten Zugriffsrechte für
Objekte des Endsystems i.Allg. ausreichend, fehlen MASA spezifische Zugriffsrechte.
Dadurch können Zugriffe auf das Agentensystem bzw. auf Agenteninstanzen
nicht autorisiert und daher auch nicht durchgesetzt werden.
Die Limitierung von Systemressourcen ist in MASA nicht möglich.
Ist ein Zugriff auf eine Systemressource erlaubt, kann diese
unbeschränkt genutzt werden. Hier besteht die Gefahr von Denial-Of-Service
Attacken.
Es können keine Entscheidungen anhand dynamischer Attribute
getroffen werden.
Dadurch ist die Autorisation der Zugriffe auf statische Eigenschaften
eingeschränkt.
Eine Agenteninstanz bekommt beim Ausführungsbeginn
Zugriffsrechte zugeteilt, die sich während der Ausführungszeit
nicht mehr ändern können, d.h. es können keine neuen
Zugriffsrechte hinzukommen und es können auch keine Zugriffsrechte
entfernt werden.
Die in MASA als Politik-Sprache eingesetzte Standard Politik Syntax von Java 2
stellt sich als ungeeignet heraus.
Um die zugreifenden Subjekte in MASA individuell adressieren zu können,
fehlt eine Spezifikation einer geeigneten Politik-Sprache.
Betrachtet man die Abb. 25, so sind hier einerseits Zugriffe erkenntlich, welche in MASA autorisiert und durchgesetzt werden können und andererseits Zugriffe, weder autorisiert noch durchgesetzt werden. Die Zugriffskontrollen des Endsystems wurden dabei vernachlässigt.
Nachdem kurz auf die Standardisierungsvorgänge eingegangen wird, werden Konzepte vorgestellt, die zum Schutz der Agentensysteme und der Agenten herangezogen werden können. Abschließend werden Agentensysteme bezüglich der realisierten Schutzmechanismen und Techniken betrachtet.
Der Mobile Agent System Interoperability (MASIF) Standard der Object
Management Group (OMG) hingegen macht eine klare Aussage über das Thema Sicherheit.
Diese stützt sich auf die CORBA Security Services Architektur ab. Leider
betrachten die Security Services beim CORBA Modell nur die Sicherheitsfragen
der Agenten Plattform hinreichend. Die unabhängigen Sicherheits Services, die
ein Agent benötigt, werden ignoriert [WAK 00].
Schwerpunkt bei der Foundation for Intelligent Physical Agents (FIPA) ist die Standardisierung der Agenten Kommunikations Sprachen, die kooperierende Agenten nutzen. Viele Details, die die Architektur der Agenten Plattform betreffen, benötigen noch Entwicklungszeit, bevor man sich dem Thema der Sicherheit widmen kann [WAK 00].
Der Schutz einer Agentensystemarchitektur kann
in den Schutz des Agentensystems, den Schutz der Agenten und den Schutz
eines Verbundes von Agentensystemen aufgeteilt werden.
Die Autorisation der Agenten wird über verschiedene Mechanismen realisiert. Es kommen Sicherheitspolitiken, Credentials, Zugriffskontrolllisten (ACLs),Tickets und Capabilities zum Einsatz.
Dadurch ergibt sich der folgende Ablauf:
Die Zugriffskontrolle basiert zumeist auf dem Referenz-Monitoring Prinzip, so dass jeder Zugriff der Zugriffskontrolle unterworfen wird. Die Realisation des Monitoring-Konzepts basiert auf konventionellen Mechanismen und Techniken wie zum Beispiel dem Einsatz von:
Folgend werden Konzepte vorgestellt, die für den Schutz der Agentensysteme eingesetzt werden können [WAK 00].
Die wohl meistbenützte Interpreter Sprache ist Java. Die
Programmiersprache Java und ihre Ausführungsumgebung bietet
Sicherheit aufgrund von Strong-Type Safety.
Java folgt dabei dem Sandbox-Modell, das wie oben beschrieben
den Speicher und die Zugriffsmethoden isoliert und zur Ausführung
eine exklusive Ausführungsumgebung bereitstellt.
Innerhalb von Java wird z.B. das Static-Byte-Checking in
Form von Byte-Code-Verification angewendet,
um die Sicherheit des Programms zu kontrollieren.
Dabei wird auch teils Dynamic-Checking während der
Ausführungszeit unterstützt. Ein separater Namensraum steht dem
nicht vertrauenswürdigen Code zur Verfügung. Referenzen zwischen
Modulen in verschiedenen Namensräumen ist nur bei als public
deklarierten Methoden möglich.
Durch die Signatur eines Agenten kann so z.B. der Auftraggeber, unter
dessen Namen der Agent unterwegs ist, bestimmt werden.
Denkbar ist somit auch, den Agenten die Rechte, die der Auftraggeber
besitzt, einzuräumen (Attribute Certificate).
Ein Objekt kann je nach Modell auch multiple Signaturen besitzen,
wobei es dann mehreren Principals angehören kann.
Beim Signieren kommt die Public Key Kryptographie zum Einsatz.
Eingesetzt wird ein Schlüsselpaar, ein privater und ein öffentlicher
Schlüssel. Die weite Verbreitung und der Einsatz der
Public Key Infrastruktur (PKI) spielt eine große Rolle,
um diesen Sicherheitsmechanismus geeignet nutzen zu können.
Durch eine digitale Unterschrift kann das Agentensystem die Herkunft des Agenten eindeutig bestimmen. Durch Überprüfen der digitalen Signatur des Programmcodes kann außerdem festgestellt werden, ob der Agent von anderen Agentensystemen manipuliert worden ist. Der Status bzw. die mehrfach zu verändernden Daten eines Agenten können nicht signiert werden und stellen deshalb ein Risiko dar. In diesem Fall könnte der Programmcode des Agenten eine Routine enthalten, die den Status überprüfen kann, wodurch das Agentensystem sicherstellen kann, dass nur Agenten mit einwandfreiem Status gestartet werden [WAK 00].
Während Gegenmaßnahmen zum Schutz des Agentensystems
zum Teil mit traditionellen Schutzmechanismen getroffen werden können, basieren
Gegenmaßnahmen zum Schutz der Agenten in der Regel auf der Erkennung eines
Angriffs.
Folgend sollen Mechanismen vorgestellt werden, die zum Schutz eines Agenten bzw. dessen Information eingesetzt werden können:
In ``Towards Mobile Cryptography'' [SAT 98b] wird versucht, die Sicherheitsproblematik durch den Einsatz der Kryptographie zu lösen. Dabei wird auch der Fall, dass sich der Agent in einer nicht vertrauenswürdigen Ausführungsumgebung befindet, betrachtet.
Probleme beim Signieren eines Agenten auf dem Home-Agentensystem entstehen, sobald der Agent von einem zweiten auf einen dritten Agentensystem reist (multi-hop Agent). Es kann nur der Teil des Agenten durch die Signatur kontrolliert werden, der der Home-Agentensystem Signatur entspricht. Änderungen der Daten oder des Status des zweiten Agentensystems können natürlich nicht mit dieser Signatur kontrolliert werden. Durch eine Verständigung mit dem Home-Agentensystem nach jedem besuchten Agentensystem kann gegebenenfalls der Schaden verringert werden. Dies bedeutet aber auch eine höhere Belastung des Systems. (Das Jumping Beans Agentensystem implementiert z.B. eine Client/Server Architektur, wobei ein Agent jedesmal zu einem sicheren zentralen Agentensystem zurückkehrt, bevor er ein neues Agentensystem besucht.). Der Vorteil ist, dass es sich hier nur um Two-Hop Boomerang Agenten handelt. Nachteilig wirkt sich hier der große Overhead aus.
Die eingekapselte Information hängt dabei von der Implementierung des Agenten ab, wobei es drei alternative Wege gibt die Ergebnisse einzukapseln:
Keiner dieser Mechanismen verhindert bösartiges Handeln des
Agentensystems, jedoch kann bösartiges Handeln erkannt werden.
Eine weitere Methode zum Einkapseln der Informationen ist der Gebrauch des
Partial Result Authentication Codes (PARC). Hierbei handelt es sich um kryptographische Prüfsummen,
erstellt mithilfe der Secret Key-Kryptographie
(ähnlich dem message authentication code).
Anfangs existieren mehrere Schüssel. Verwendet ein Agent nun einen
dieser Schlüssel, so wird dieser aus der Liste des Agenten gelöscht,
bevor er zum nächsten Agentensystem zieht.
Der Vorteil ist, dass die Authentifikation der Ergebnisse auf jedem
besuchten Agentensystem möglich ist, und das mit vorwärts Integrität.
Werden jedoch von einem Agentensystem Kopien der noch nicht genutzten Schlüssel gemacht bzw. ist die Schlüsselgenerierungsfunktion eines Agenten bekannt, sind diese beim erneuten Besuch des Agenten bzw. auch auf dem Agentensystem die unter Umständen mit diesem Agentensystem kooperieren, wertlos. Schon verschlüsselte Daten können so modifiziert werden, indem man Daten mit den bekannten Schlüsseln verschlüsselt. Um die Vorwärtsintegrität zu bewahren, besteht die Möglichkeit, Agenten, nachdem sie ein unbekanntes Agentensystem besucht hatten, wieder auf ein vertrauenswürdiges Agentensystem migrieren zu lassen, bei dem der Agent einen digitalen Zeitstempel bekommt. Auch hier ist der zusätzliche Overhead als Nachteil zu nennen.
Dieses Schema kann erweitert werden, indem es z.B. mehr als zwei kooperierende Agenten gibt. Es besteht aber auch die Möglichkeit einen Agenten statisch auf dem Home-Agentensystem zu belassen.
Ähnlichkeit hat diese Technik z.B. mit der Passwortabfrage, wobei das Passwort verschlüsselt vorliegt und verglichen wird. Die Sicherheitslücke besteht aber wieder darin, dass das Agentensystem den Agenten komplett kontrolliert und den Agenten z.B. dazu bringen kann, den Code auszudrucken und nicht auszuführen, nachdem die erwartete Umgebungsbedingung eingetroffen ist.
Das Agentensystem, das eine verschlüsselte Funktion enthält, führt ein Programm aus, ohne die Möglichkeit zu haben, die original Funktion zu erkennen. Dieser Ansatz erfordert die Unterscheidung zwischen einer Funktion und dem Programm, das diese Funktion implementiert.
Die Strategie ist simpel:
Zerstückle den Code, so dass es niemandem möglich ist, die
komplette Funktion zu verstehen (auch der Daten und der Spezifikationen)
oder den resultierenden Code unerkannt modifizieren zu können.
Leider ist noch kein Algorithmus bekannt, der diesen Blackbox Schutz
möglich macht. Die verschlüsselten Funktionen sind jedoch Beispiele
einer Annäherung an die Blackbox Kategorie.
Hat ein bösartiges Agentensystem jedoch ein solches Zertifikat erhalten bzw. ist es erst nach diesem Erhalt bösartig geworden, gefährdet dies das ganze System.
Der Vorteil ist hier, dass der Agentencode vertrauenswürdig ist.
Wurde die Aufgabenstellung erfüllt, kann dieser auf das
anfragende Agentensystem migrieren und die Ergebnisse kundtun.
Da der mobile Agent vertrauenswürdig ist und nur ein
One-Hop Agenten darstellt, sind ebenfalls die möglicherweise
sensiblen Informationen besser geschützt.
Vorteile gegenüber der Methode der Verschlüsselung mit dem Privat
Key des Agentensystems liegen in dem Erkennen der Fehlerstelle, falls
nicht alle Informationen eintreffen. Die sensible Information durchwandert
auch nicht unterschiedlichste Agentensysteme und ist somit weniger
Angriffen ausgesetzt. Der mobile Agent, der letztendlich die Aufgabe
ausführt, ist vom eigenen Agentensystem. Somit sind Angriffe durch
modifizierte mobile Agenten anderer Agentensysteme ausgeschlossen. Die
Gefahren von Trojanischen Pferden und Back Door Angriffen wird somit
ausgeschlossen. Durch den Einsatz eigener, vertrauenswürdiger
Agenten ist die Notwendigkeit der Zugriffskontrolle entschärft.
Nachteilig ist die Notwendigkeit, dass das Agentensystem einen
Agenten, welcher die Aufgabe bearbeiten kann, benötigt. Hier
sind somit Einbußen in der Flexibilität und Dynamik vorhanden.
Ein weiterer Nachteil besteht darin, dass das anfragende Agentensystem eine linear zu den befragten Agentensystemen ansteigende Anzahl von ankommenden mobilen Agenten verarbeiten muss. Da diese mobilen Agenten jedoch nur die resultierenden Ergebnisse mit sich tragen, ist dieser Aufwand i.Allg. gering einzuschätzen. Zusätzlich muss auf jedem Agentensystem ein eigener mobiler Agent gestartet werden, und das anfragende Agentensystem bekommt pro Anfrage an ein Agentensystem jeweils einen Agenten als Antwort, wodurch auch hier eine größere Belastung entsteht.
Ein Agent kann sehr viele Ressourcen verbrauchen, indem er z.B. bei vielen Agentensystemen so viele Ressourcen wie möglich beansprucht. Dies kann auch der Fall sein, falls ein Agent unendlich lange lebt und immer weitere Ressourcen auf verschiedenen Agentensystemen beansprucht, oder dass ein Agent neue Agenten erzeugt, die wiederum neue Agenten erzeugen. Hier besteht die Gefahr eines Denial-of-Service Angriffs. Kann z.B. verhindert werden, dass unzählige Agenten auf dem Agentensystem ausgeführt werden, ist eine große Auslastung eines bösartigen Agenten, welcher auf jedem Agentensystem möglichst viele Agenten startet, nur schwer zu kontrollieren. Ebenso schwer ist die Kontrollmöglichkeit der Benutzung anhand der Ressourcenauslastungen.
ASDK 1.1 beta 1 realisiert eine feine granulare Zugriffskontrolle durch
den Einsatz der Java 2 Security Architecture.
Jedes Aglet wird durch einen eigenen ClassLoader geladen.
Die Transaktion von Bytecode und die Zugriffe auf Ressourcen des Endsystems eines Aglets
werden durch den SecurityManager auf die Zulässigkeit hin überprüft.
Empfängt ein Aglet Bytecode, wird beispielsweise kontrolliert, ob
das Aglet die Berechtigung besitzt, die Klasse zu definieren.
Es wird eine benutzerbestimmte Zugriffskontrolle (DAC) implementiert, so dass
jedes individuelle Aglet seinen eigenen Schutz gegen Nachrichten anderer Aglets
selbst bestimmen kann.
Das Rechtekonzept basiert auf Domains, wobei Agentensysteme innerhalb einer Domain
als vertrauenswürdig angesehen werden.
Authentifikation:
In Aglets ist eine Serverauthentifikation implementiert.
Es können Aglets und Domänen authentifiziert werden.
Alle Server einer Domain teilen sich einen geheimen Schlüssel, mit dem
sie sich gegenseitig authentifizieren können. Agentensysteme innerhalb
derselben Domain gelten als vertrauenswürdig.
Nach erfolgreicher Authentifikation wird ein Credential des Aglets
mit samt dem Aglet an das Ziel-Agentensystem gesendet.
Ist das Aglet angekommen, so kann anhand des Credentials bestimmt
werden, inwieweit man diesem Aglet vertraut.
Migriert ein Aglet auf ein anderes Agentensystem, so wird dem
Aglet ein Credential mitgegeben, womit das Ziel-Agentensystem
die Vertrauenswürdigkeit des Aglets einstufen kann. So kann
anhand des Credentials z.B. durch die Verwendung des geheimen Schlüssels
festgestellt werden, ob das Aglet von
einem Agentensystem derselben Domain stammt.
Innerhalb einer Domain benötigt jeder User bzw. die Administratoren
der Agentensysteme dieser Domain den geheimen Schlüssel.
Fällt der geheime Schlüssel in falsche Hände, kann keinem
mehr vertraut werden.
Autorisation:
Die Autorisation erfolgt ähnlich nach den Mechanismen der Java 2 Security
Architecture. Es werden Permission-Klassen verwendet, wobei auch ein
Zugriffschutz der Aglets realisiert wird.
Ein Domain-basierte Policy wird nicht unterstützt.
Der Implementierer kann einfach durch die Signatur des Codes ermittelt werden.
Ein User wird über Credentials autorisiert, wobei
einem Aglets auf Basis des Owners und der Codebase Zugriffsrechte zugeteilt werden.
Durch Einträge in eine Policy-Datenbank oder mithilfe eines GUI-Interfaces können Berechtigungen erteilt werden. Es können unter anderem die in JDK1.2 vorkommenden Berechtigungen (Permissions) spezifiziert werden.
java.io.FilePermission : File read/write/execute java.net.SocketPermission : Socket resolve/connect/listen/accept java.awt.AWTPermission : showWindowWithoutWarningBanner, accessClipboard java.util.PropertyPermission : Java property java.lang.RuntimePermission : queuePrintJob, load library java.security.SecurityPermission : getPolicy, setSystemScope java.security.AllPermission : all other permissions com.ibm.aglets.security.ContextPermission : context property, start, shutdown com.ibm.aglets.security.AgletPermission : dispatch, deactivate, etc. com.ibm.aglets.security.MessagePermission : messaging
ContextPermission ist die Berechtigung, auf die Kontext-Properties
zugreifen zu können. Mögliche Parameter sind
z.B. shutdown (Herunterfahren), start, retract,
create.codebas@classname, listener.add, listener.remove oder
property.-key- sein.
Die AgletPermission-Klasse repräsentiert den Zugriff auf ein Aglet.
Ein AgletPermission besteht aus einem Principal-Name eines
Ziel-Aglets und den verschiedenen Operationsnamen für dieses
Aglet. Der Principal-Name ist der User-Name des Ziel-Aglets
(z.B. Guenter, anonymous, ...), und
die Operationsnamen sind die Methodennamen der Aglet-Klasse
(deactivate, activate, clone, retract, dispatch, dispose).
Die MessagePermission-Klasse repräsentiert die Berechtigung,
Nachrichten an ein Aglet zu senden. Ein MessagePermission enthält
den Principal-Name des Ziel-Aglets und die Art der Nachricht.
Beispielnamen sind z.B. message.show und message.getResult.
Rechteüberprüfung:
Die Rechteüberprüfung basiert auf den der Aglets zugeteilten
ProtectionDomains und den der ProtectionDomain zugeordneten
Zugriffsrechten.
Rechtedurchsetzung:
Die Rechtedurchsetzung erfolgt entsprechend der Java 2 Security Architecture.
Weitere Sicherheitsmerkmale:
Die Kommunikationspfade werden zwischen Servern innerhalb einer Domain
durch Integritätschecks gesichert.
Der Integritätscheck erfolgt mithilfe des geheimen Schlüssels.
Schutz des Aglets In Aglet wird ein Schutz der Aglets gegenüber anderen Aglets realisiert. Aglets können nicht vor bösartigen Agentensystemen geschützt werden.
Ajanta erlaubt durch sein Sicherheitskonzept einen sicheren Zugriff
auf Server-Ressourcen. Zudem kann ein Agent einen tamper-proof
Container, um Daten unterschiedlicher Places, die verschlüsselt werden
können, mit sich tragen.
Besitzer eines Agenten besitzen eine sichere entfernte Kontrolle. Ein
Agent kann mit Exceptions umgehen und ein sicherer Name-Service
unterstützt standortunabhängige Namen.
Zur Realisation der Zugriffskontrolle von Agenten auf
Server-Ressourcen und zur Erstellung geschützter Domains wird der
ClassLoader und der SecurityManager eingesetzt.
Authentifikation:
Wird ein Mobiler Agent auf einem System ausgeführt, so wird anhand
des Credentials der Mobile Agent authentifiziert.
Autorisation:
Der Server verwendet ACLs.
Autorisiert werden Agenten durch Credentials, die sie mit sich tragen.
Jeder Agent besitzt unterschiedliche Credentials, welche die Agenten
Identität mit dem Owner und dem Creator in Verbindung bringt. Das
Credential beinhaltet dabei auch das Public Key Zertifikat des
Owner. Der Creator kann dem Agenten unterschiedliche aber auch nur
begrenzte Privilegien zuteilen. Damit befinden sich also
Zugriffsrestriktionen in den Credentials.
Restriktionen können auch vom Erschaffer des Agenten erteilt
werden. Hierbei handelt es sich um negative Privilegien. So mag ein
Owner eines Agenten z.B. nicht, dass sein Agent einen bestimmten Server
aufsucht oder nichts einkaufen darf etc. .
Credentials können mit einer Verfallszeit ausgestattet werden, um den
Missbrauch bei einem Diebstahl einzuschränken.
Auf Basis einer Erweiterung können Zugriffs-Privilegien selektiv zurückgenommen werden.
Desweiteren besteht bei Ajanta die Möglichkeit, Zugriffsrechte zu delegieren.
Rechteüberprüfung:
Der Agenten Server enthält eine Domain Datenbank. In dieser steht
für jeden Agenten unter anderem die Thread Gruppe, der Owner, der
Creator und die URL der Herkunftsseite.
Hier befinden sich auch die Autorisation der Zugriffe, Limitierungen und
momentaner Gebrauch unterschiedlicher
Ressourcen des Servers.
Hat ein Agent momentan Zugriff, so stehen noch zusätzliche
Informationen in der Datenbank zur Verfügung.
Die Datenbank kann nur von einem Thread, der von der Server
ProtectionDomain ausgeführt wird, upgedatet werden.
Rechtedurchsetzung:
Der Server verwendet zur Rechtedurchsetzung einen Proxy Mechanismus.
Die Sicherheit des Proxy-Mechanismus basiert
dabei auf dem Java Sicherheitsmodell [KAT 98].
Der Proxy basierte Mechanismus erlaubt
einzelnen Ressourcen eine eigene Policy zu
implementieren [TNK 99]. Durch den Proxy Mechanismus ist eine
Inaktivierung einer oder mehrerer Interface Methoden möglich. Diese
Inaktivierung basiert bei Ajanta auf der Grundlage der Security
Policy und den Credentials des Client Agenten.
Der Ajanta SecurityManager wird durch einen erweiterten RMI Security
Manager implementiert, welcher die Zugriffe auf Ressourcen schützt. Der
SecurityManager verwendet dafür eine ACL um Agenten den Zugriff auf
lokale Dateien und Ressourcen zu gewähren. Diese ACLs Definitionen
basieren auf URNs und daher auf Basis der Identität
des Agenten Owners.
Eine mögliche Erweiterung erlaubt das Accounting des Ressourcenverbrauchs.
Schutz der Agenteninstanz
Ein Agent ist in der Lage, Daten von verschiedenen Hosts in einem
manipulationssicheren Logfile, wobei Daten nur jeweils angehängt werden
können, zu sammeln.
Es ist auch möglich, verschlüsselte Daten für einen
bestimmten Host zu einem spezifischen
Host weiterzuleiten [KAT 00].
Privilegien und Restriktionen
Die Privilegien und Restriktionen von Agenten werden für
folgende Operationen definiert:
Privilegien und die Delegation von Privilegien
Der Erzeuger eines Agenten bei Ajanta vergibt Agenten Privilegien
und Agenten Restriktionen. Die folgende Abbildung zeigt die Verbindung
der Privilegien und Restriktionen mit den Credentials des Agenten.
Hier sind nicht alle Felder des Credentials dargestellt. Bevor ein
Agent fertiggestellt wird, wird er noch vom Owner des Agenten
signiert. Jede Manipulation des Objekts, also auch der Privilegien
und der Restriktionen, kann erkannt werden, indem man die Hash Werte
und die Signatur des Credentials Objekts verifiziert.
Die Eingaben von Privilegien für einen bestimmten Server können
mittels dem Public Key des Servers verschlüsselt werden.
Der Mechanismus zur Weitergabe der Privilegien und der Restriktionen
von einem Server zu einem anderen sieht folgendermaßen aus:
Der Server ``A'', der die Anfrage an einen anderen Server ``B'' weiterleitet,
erstellt ein Ticket zusammen mit dem Objekt, das die Spezifikationen
der zusätzlichen Privilegien und Restriktionen für den Agenten
enthält. Mithilfe dieser Privilegien kann der Agent Dienste im
Auftrag des Servers ``A'' ausführen. Das Ticket enthält den Agenten
Name, Server Name, Hash Werte der Server ``A'' weitergegebenen Rechte und
Restriktionen, Verfallsdatum und die Signatur des Agenten Owners am
Credential-Objekt. Der Server signiert das Ticket. Das Ticket steht in
Verbindung mit Agenten, dessen Name und Credentials Signatur im Ticket
enthalten sind. Die Verfallszeit stellt sicher, das der Agent diese
Privilegien nicht unendlich lange nutzen kann.
Die Manipulation des Tickets kann erkannt werden. Zuerst wird die
Signatur des Tickets verifiziert und dann werden die Hash Werte der
vom Server zugewiesenen Privilegien und Restriktionen neu berechnet
und mit den Werten des Tickets verifiziert. Am Ende wird noch die
Signatur des Owners des Agenten Credentials Objekts verifiziert.
Ablauf der Durchsetzung der Privilegien und Restriktionen
Ein Agent besitzt beim Server eine eigene ProtectionDomain, wobei der
Server Informationen über die Agenten Schutz Domain in einer
Datenbank schreibt. Die Thread Gruppen ID, die Credentials und Tickets
Objekte werden zusammen mit den Privilegien und Restriktionen
gespeichert.
Jeder Server hat eine ACL worin die Security Policies definiert
sind. Ein Server setzt Agenten Privilegien und Restriktionen durch den
Kontext seiner eigenen Security Policies durch, welche als Dominant
betrachtet werden. Alle sicherheitssensitiven Operationen auf System
Ressourcen rufen den Ajanta SecurityManager des Servers auf. Der
SecurityManager entscheidet anhand der Security Policies des Servers,
ob der Zugriff erlaubt ist. Ist er erlaubt, werden die Privilegien und
Restriktionen, die in der Datenbank gespeichert sind, überprüft. Die
Operation wird, falls keine Security Exception auftrat, erlaubt.
Fragt ein Agent nach einer Server Ressource mithilfe der getResource
Primitive des Servers, so überprüft der Server die Privilegien und
Restriktionen des Agenten um zu sehen, ob der Zugriff erlaubt
ist. Falls ja, geht ein Aufruf mit dem Credential des Agenten an das
Ressourcen Objekt. Das Ressourcen Objekt erstellte ein passendes Proxy,
das an den Agenten zurückgegeben wird.
Das Problem der Rechtedelegation ist das Erstellen von signierten
Credentials für ein Child-Agenten, das von einem Agenten auf einem
entfernten Knoten erschaffen wurde. In Ajanta ist es einem Agenten
erlaubt, Child-Agenten zu erzeugen, jedoch sind die neuen Agenten
Credentials von dem jeweiligen Server signiert, wo das Child-Agent
erschaffen wurde. Solche Agenten werden nur mit hoch limitierten
Privilegien ausgeführt.
Proxy Objekte werden beispielsweise in Ajanta eingesetzt,
um Nachteile bei der alleinigen Verwendung des SecurityManagers zu
unterbinden. Nur der Agent besitzt eine Referenz auf dieses Proxy
Objekt [SHA 86].
In Ajanta wurde ein solches Modell wie folgt implementiert. Dabei
hält sich die Beschreibung an den Bericht von A. Tripathi und
N. Karnik [KAT 98].
Das folgend abgebildete Skeleton kommt zum Einsatz.
Eine generische Ressource:
![\includegraphics [totalheight=0.25\textheight]{anf-ac-as.eps}](img27.gif)
![\includegraphics [totalheight=0.25\textheight]{anf-ac-ma.eps}](img28.gif)
![\includegraphics [totalheight=0.25\textheight]{risk-ac-masa.eps}](img29.gif)
![\includegraphics [totalheight=0.2\textheight]{ajanta-cp.eps}](img30.gif)
![\includegraphics [totalheight=0.2\textheight]{ajanta-delegation.eps}](img31.gif)
public interface Resource {
// generic methods, common to all resources
// e.q. queries for name/id, ownership, etc.
}
public class ResourceImpl implements Resource {
// implementations of the above methods
}
Das System definiert also ein Ressourcen Interface und unterstützt eine
ResourceImpl-Klasse, welches das Interface implementiert, wobei die
Methoden dieser Klasse die generellen Funktionalitäten für alle
Ressourcen unterstützt.
Das Resource Access Protocol, welches die Mobile Agenten an die
lokalen Ressourcen bindet, ist definiert in terms generic Resource
Objekte, um es auch unabhängig von Applikations definierten Typen
beizubehalten. Alle Applikations definierten Ressourcen-Klassen müssen
das Resource Interface implementieren, wobei das typischerweise durch
Vererbung von der ResourceImpl-Klasse gemacht wird.
Als Beispiel kann eine Applikation eine Buffer Resource Interface
unterstützen, welche durch eine BufferImpl-Klasse wie folgt
implementiert wurde.
Eine gebundene Buffer Ressource:
public interface Buffer extends Resource {
// An application-defined bounded buffer
public synchronized BufItem get();
public synchronized void put (BufItem);
//etc.
}
public class BufferImpl extends ResourceImpl
implements Buffer, AccessProtocol{
// implementation of the Buffer and
// AccessProtocol methods
}
Eine Proxy-Klasse der gebundenen Buffer Ressource:
public class BufferProxy implements Buffer {
private Buffer ref;
// ref is a reference to the underlying
// resource, wich is initialized by the
// constructor (below)
BufferProxy(Buffer b) {ref = b;}
public synchronized BufItem get() {
if (isEnabled("get"))
return ref.get();
else
// throw a security exception
}
// etc.
private boolean isEnabled(String method) {
// if the named method is disabled,
// it throws a security exception.
}
}
Agenten bekommen also nicht die Referenz zu der Ressource, stattdessen
bekommen sie eine Instanz einer Proxy-Klasse geliefert. Dafür muss für
jede Applikations definierte Ressource-Klasse eine entsprechende Proxy-Klasse
definiert werden.
Ein Proxy enthält eine Referenz zu der aktuellen Ressource, welche
nicht außerhalb des Proxy sichtbar sein sollte. Die Proxy-Klasse
implementiert das Interface, das die Ressource
präsentiert. Jede Interface Methode reicht den Aufruf zu dem Ressource
Objekt weiter, nachdem festgestellt wurde, dass die Ressource
freigegeben ist.
Die Autorisation wird von der Ressource-Klasse realisiert, welche das
AccessProtocol Interface implementiert
Das Access Protocol Interface:
public interface AccessProtocol {
// Defines the generic resource access
// interface. The getProxy method returns
// a proxy object (typecasted to Resource).
public Resource getProxy();
}
Die Abb. 28 zeigt weiter zwei Agenten, die jeweils eine eigene
geschützte Umgebung besitzen. Ressourcen werden den Agenten durch
den Aufruf der jeweiligen registerResource Primitive der Agenten,
welche die Ressourcen Namen und die Referenz zu dem Ressource Objekt in
der Ressource Registry speichert, zugreifbar gemacht.
Dabei enthält jeder Eintrag Besitzerinformationen
(Owner-Informationen), welche genutzt werden, um unautorisierte
Modifikationen der Registry Einträge zu unterbinden.
Um einen Zugriff auf eine Ressource zu bekommen, muss ein Agent die getResource Primitive aufrufen und einen globalen Namen der gewünschten Ressource bereitstellen. Daraufhin sucht die Agentenumgebung die Resource Registry auf, um dass entsprechende Resource Objekt zu lokalisieren, um dann die getProxy-Methode aufrufen zu können (Schritte 1-4). Die getProxy-Methode erhält falls nötig, die Agenten Credentials durch Anfragen der Server-Domain Datenbank. Ist nach der Sicherheits Policy der Aufruf zulässig, so kreiert das Resource Objekt einen zu dem Agenten zugeordneten Proxy, welches dem Agenten durch die Agentenumgebung übertragen wird. Nun kann der Agent, durch das Proxy Objekt, freigegebene Methoden des Resource Interfaces aufrufen. (Schritte 5 und 6)
Authentifikation:
Bond Objekte können authentifiziert werden.
Autorisation:
Der Zugriffskontrollmechanismus basiert auf Zugriffsrechten, die einem
Objekt mittels einem Bond Ticket gewährt werden und die der Bond
Security Agent durchsetzt. Das Bond Ticket wird bei der Erstellung des
Bond Shadows generiert und signiert.
Ein Bond Ticket definiert die Zugriffsrechte als Möglichkeit,
KQML-Nachrichten mit spezifischen Sub-Protokollen (PropertyAccess,
AgentControl), Performative (ask-one, achieve),
Content (get, set, start-agent) und Parameter (alpha, WorkSpace)
senden zu können. Die Zugriffsrechte auf
Dienste betreffen die Leistung, das spezifische Sub-Protokoll,
Restriktionen der
Inhalte der Leistung, und Restriktionen der Parameter.
Rechteüberprüfung:
Überprüft werden die in der Policy erfolgten Autorisationen der
Bond Objekte.
Rechtedurchsetzung:
Ein Objekt kann seinen eigenen Security Agenten erstellen um seine
eigene Security Policy durchzusetzen. Eine Gruppe von Objekten kann
aber auch einen Security Agenten gemeinsam benutzen.
Ein Security Agent hat die Aufgabe, die
Berechtigung der zugreifenden Subjekte zu überprüfen.
Nur ein Secure Bond Objekt kann Subjekte
authentifizieren und die Zugriffskontrolle durchsetzen.
Der Security Agent ist fähig, Bond Tickets für ein oder mehrere
Objekte zu generieren und zu speichern und die Zugriffskontrolle
durchzusetzen. Der Security Agent stellt dabei einen Proxy auf der
Empfängerseite dar.
Kommunikationsablauf:
Vor der Kommunikation erstellt der Initiator ein Bond Shadow, welches
aus Informationen des Targets erstellt werden kann und unidirektionale
Kommunikation unterstützt. Die Kommunikation erfolgt dann immer über
dieses Shadow bis hin zum Target. Das Shadow ist sozusagen ein lokaler
Proxy für das entfernte Objekt. Der Kommunikationablauf sieht dann
folgendermaßen aus:
Jedes Bond Objekt unterstützt eine Menge an Diensten, welche für die
anderen anhand von Message Patterns, in Bond
sub-protocols nutzbar sind. So kann ein Objekt seine Properties
offenlegen und anderen Objekten erlauben, diese Properties anhand dem
property access sub-protocol zu modifizieren.
Um die Zugriffskontrolle zu realisieren, werden für jeden
KQML-Nachrichtentyp die Rechte definiert und überprüft. Jede
Nachricht besteht dabei aus einem sogenannten Performative Feld, einem
Content-Feld und einem oder mehreren Attribut-Feldern.
Um das Zugriffsmodell zu implementieren, muss das Bond Shadow Objekt
um das Zugriffkontroll-Objekt (Bond Ticket) und dem Public Key des
Ziel Objekts erweitert werden. Das Bond Ticket des Shadows ist dabei
eine Kopie des Bond Tickets des Ziel Objekts.
Der Shadow benötigt eine Kopie des Bond Tickets, welches von dem
Ziel-Objekt gewährt wurde, um die Nachrichten filtern zu können.
Es werden nur Nachrichten an das Ziel-Objekt weitergeleitet,
welche mit den Zugriffsrechten des Bond Tickets übereinstimmen.
Die Shadows auf der Client und der Server Seite implementieren die Zugriffskontrolle:
Ein Bond SecurityContext beinhaltet sicherheitsrelevante Objekte, die unterschiedliche Sicherheitsfunktionen implementieren. Jedes sicherheitsrelevante Objekt implementiert eine von Bond definierte Sicherheitsschnittstelle. Folgende Schnittstellen sind enthalten:
Jedes Bond Objekt besitzt die Möglichkeit, seine eigene Security Policy auszuwählen. Interfaces für Sicherheitsüberprüfungen müssen jedoch einheitlich sein. Es wurden für alle Sicherheitsfunktionen abstrakte Java Klassen definiert. Dazu gehören die Sicherheitsüberprüfungen und die Ticket Generierung. Jedes Objekt hat die Wahlmöglichkeiten, diese abstrakten Security-Klassen zu implementieren. Es gibt default Security-Klassen, falls man keine eigenen implementieren will.
Es wird eine benutzerbestimmbare Zugriffskontrolle (DAC) implementiert, wobei jede
Ressource eine Zugriffsliste besitzt, welche die erlaubten Aktionen eines jeden Owners,
das ist der Anwender des Agenten, spezifiziert.
Dadurch können Zugriffe auf das Agentensystem beschränkt werden.
Sobald ein Agent einen nicht vertrauenswürdigen Rechner besucht, wird er
als anonymer Agent angesehen. Ihm kann nicht mehr vertraut werden.
Ein aktiver Schutz des Agenten ist also nicht vorhanden.
Authentifikation:
Jeder D`Agent Server unterscheidet zwischen anonymen Agenten und
Agenten, denen ein Anwender zugeordnet werden kann.
Der Owner des Agenten muss hierfür authentifiziert werden, wobei
sich der authentifizierte Anwender als autorisierter Nutzer
in einer Liste des Servers aufgeführt werden muss.
Autorisation:
Ist die Identität des Owners sichergestellt, werden dem Agenten die
betreffenden Zugriffsrestriktionen erteilt (Autorisation).
Die Autorisation erfolgt durch konfigurierbare Policies,
unterstützt durch ein Sprachenunabhängiges Policymodul für
jede System Ressource.
Ein erlaubter Zugriff kann zusätzlich limitiert werden.
Die meisten Ressourcen-Manager sind mit einfachen Security Policies
implementiert. Jeder Ressourcen-Manager hat eine Konfigurationsdatei,
welche die Zugriffsrechte für einen einzelnen Nutzer spezifiziert.
Der Manager initialisiert diese Zugriffsliste beim Start und überprüft den
Zugriff auf Basis des Owners jeder Anfrage mit den Einträgen in der
Liste. Der Manager weiß, ob der Owner authentifiziert werden konnte,
bzw. ob der Agent auf derselben Maschine ausgeführt wird.
Rechteüberprüfung:
Jede Ressource erhält einen eigenen Ressourcen-Manager, der kontrolliert,
ob der Zugriff erlaubt ist oder nicht.
Beispielsweise kann der CPU Ressourcen-Manager entscheiden, ob der Agent
die CPU nutzen darf und wenn, dann wie lange bzw. mit welcher
Priorität [LWO 97].
Rechtedurchsetzung:
Das System überwacht die Einhaltung der Zugriffsrestriktionen (Enforcement).
Ein sprachabhängiges Rechtedurchsetzungsmodul sendet Anfragen auf Ressourcen zu einem
stationären Agenten, den Ressourcen-Manager, der die
Sicherheitspolicy für diese Ressource bestimmt.
Jede Sprache besitzt ihr eigenes Durchsetzungs Modul. Einige
Entscheidungen bzgl. Ressourcen werden auch durch den Code des Agenten
durchgesetzt.
Zugriffsrestriktionen werden mithilfe von Safe Tcl, dem SecurityManager oder dem
Scheme 48 Modul durchgesetzt.
Die Rechtedurchsetzung übernimmt die Safe-TCL Infrastruktur.
Der Safe-Tcl Kernel Interpreter fängt dabei sensitive Prozeduraufrufe
ab. Beim ersten Zugriffsversuch wird der Ressourcen-Manager nach der
Zugriffsberechtigung befragt. Dabei wird die Antwort für erneute
Anfragen zwischengespeichert. Diese Architektur trennt dabei klar den
Mechanismus (Safe-Tcl) von der Policy (Ressourcen-Manager), was
unterschiedliche Policies zulässt. Der Ressourcen-Manager ist somit
aber auch unabhängig von der Programmiersprache.
Java Durchsetzungsmodul
Explizit soll nun das Durchsetzungsmodul in D`Agents für Java
betrachtet werden. Dieses Modul ist durch den Java SecurityManager
implementiert. Die Java SecurityManager-Klasse beinhaltet einige
Zugriffskontrollmethoden. Zum Beispiel checkExec, checkRead und
checkExit. Die Java System Klassen rufen diese Methoden auf, um
prüfen zu können, ob diese Operationen erlaubt sind. Jede
Check-Methode überprüft dabei die interne Zugriffsliste und
kontaktiert, falls nötig den Ressourcen-Manager.
Ressourcen:
Ressourcen werden in zwei Typen eingeteilt:
Momentan existieren 6 Ressourcen-Manager:
Schutz einer Gruppe von Agentensystemen:
Entweder befinden sich die Rechner unter einer administrativen
Kontrolle (LAN einer Organisation) oder nicht (Internet).
Die Maschinen innerhalb einer administrativen Kontrolle vertrauen sich
in der Regel, misstrauen jedoch den meisten Maschinen im Internet.
Innerhalb einer Umgebung bei denen man von vertrauenswürdigen Rechnern
ausgeht, bekommt ein Agent eine maximale Menge an Ressourcen zugeteilt,
solange er sich in dieser Umgebung befindet.
D`Agents unterstützt dies durch das Einbinden eines ``usage vector'' in
den Agenten, der den maximalen und den momentanen
Ressourcenverbrauch auflistet.
Internetweit ist eine Ressourcenlimitierung jedoch nicht einsetzbar. Momentan wird an einer Market-based Methode gearbeitet, bei dem ein Agent für seinen Ressourcenverbrauch bezahlen muss [BRK 98].
Es existieren Beispielimplementierungen eines Währungs-Modells, eines Banking Systems und eine Anzahl von währungsabhängigen Ressourcen-Managern. Dabei erlaubt diese Infrastruktur den Ressourcen-Managern, Preise für Ressourcen zu setzen und Agenten dynamisch an die Ressource-Preis Umgebung anzubinden. [BRK 98]. Aktivitäten von Mobilen Agenten, die elektronische Zahlungsverfahren, ein Banking System und eine Anzahl von Ressource Managern nutzen, können somit kontrolliert werden.
Der Ablauf gestaltet sich wie folgt (vgl. Abb. 31):
Die Policy wird in einer Datei TBF (Trust Boot File) auf der
Festplatte des Nutzers abgelegt. Sie beinhaltet Zertifikate oder
die Public Keys. Die Signaturen innerhalb des Trust Boot File
repräsentieren Parteien, denen unterschiedliche Rechte weitergegeben werden
können. Zertifikate können auch mithilfe von URLs angegeben werden,
die den Ort des Zertifikats definieren. Die Zertifikate können dann
mithilfe der entsprechenden Public Keys verifiziert werden.
Rechte können durch den Einsatz von Zertifikatketten delegiert werden.
Vorteile:
Bei Grasshopper wird zwischen externer Sicherheit und interner Sicherheit unterschieden. Externe Sicherheit beschreibt die Kommunikation über die Systemgrenzen hinweg, entfernte Interaktionen und die Migration eines Agenten. Interne Sicherheit bei Grasshopper bezieht sich auf den Schutz der Schnittstellen der Agenten, Agentensysteme und der Ressourcen auf einem Agentensystem vor unautorisierten Zugriffen durch Agenten.
Um ein Sicherheitsprotokoll für die entfernten Interaktionen zu
nutzen, muss der Agent bei der Erstellung eines Server-Proxies
einen Kommunikations-Empfänger spezifizieren:
serverProxy = (IAsyncServerAgent)ProxyGenerator.newInstance (IAsyncServerAgent.class, serverID, "socketssl://myHost:7000/myAgency");
Für das Sicherheitsprotokoll der Migration muss ebenfalls ein Kommunikations-Empfänger als Parameter der move()-Methode spezifiziert werden:
move(new GrasshopperAddress( "socketssl://myHost:7000/myAgency"));
Authentifikation:
Der Agent wird durch seine Owner authentifiziert. Die Authentifikation
wird mittels Signaturen realisiert.
Autorisation:
Durch die Authentisierung wird
die Autorisation mittels einer Policy ermöglicht. Der Agentensystem-
Administrator kann diese Policy konfigurieren.
Rechteüberprüfung:
Grasshopper verwendet den SecurityManager zur Rechteüberprüfung.
Dabei werden folgende Berechtigungen überprüft:
Das Agentensystem Tacoma implementiert ein Replication and Voting-Mechanismus.
Durch den Security Automata bei Tacoma Too hängen die
momentan erlaubten Aktionen von der History des Agenten ab.
Autorisation:
Die Autorisation erfolgt über konfigurierbare Access Control Lists (ACLs)
Rechteüberprüfung und Rechtedurchsetzung:
Das Tacoma Too Projekt experimentiert mit der Technik der Software
Fault Isolation and Security Automata zur Durchsetzung der
Zugriffsrestriktionen. Ein Security Automata ist eine Zustandsmaschine,
wobei jeder Übergang einen erlaubten Zugriff auf eine Ressource
entspricht. Tacoma enthält eine Rear-Guard-Agenten, der verschwundene
Agenten neu startet.
Nach einer kurzen Einführung (Kapitel 6.1), wird die für das Rechtekonzept essentielle zentrale Kontrollinstanz (ZKI) und ihre Funktionsweise vorgestellt (Kapitel 6.2). Im Kapitel 6.3 wird die Rechtevergabe und im darauffolgenden Kapitel die Adressierung der einzelnen Entitäten von MASA beschrieben.
Um die Anforderungen einer Agentensystemarchitektur bezüglich der Autorisation zu erfüllen, wird im Kapitel 6.3.2 eine geeignete Politik-Sprache entwickelt. Mit Hilfe der Politik-Sprache kann dann eine anwendungsspezifische Autorisation der Zugriffe erfolgen. Die Autorisation erfolgt dabei anhand den vorgestellten Zugriffskontrollpolitiken.
Um Zugriffsszenarien analysieren zu können, wird im Kapitel 6.4 eine entsprechende Modellierungssprache vorgestellt. Die Modellierungssprache wird im weiteren Verlauf verwendet, um Beispielszenarien vorzustellen und daran die Rechtevergabe zu erläutern. Anhand der Modellierungssprache können einzelne Zugriffe beschrieben werden. Dadurch kann exakt bestimmt werden, welche Zugriffsrechte das jeweilige Subjekt benötigt, um einen spezifischen Zugriff erfolgreich ausführen zu können.
Das anschließende Kapitel 6.5 erläutert die Einsatzmöglichkeiten der Zugriffskontrollpolitiken. Dabei werden die Zuständigkeitsbereiche der einzelnen Politiken und ihre Funktionalität verdeutlicht.
Die im Kapitel 6.6 vorgestellte Verknüpfung der Zugriffskontrollpolitiken ist ein Hauptbestandteil des Rechtekonzepts. Durch die Verknüpfung der Politiken ist sichergestellt, dass alle Zugriffskontrollpolitiken unter der Berücksichtigung der Autonomieanforderungen durchgesetzt werden.
Kapitel 6.8 betrachtet die Rücknahme der Zugriffsrechte.
Die Realisation der in der Anforderungsanalyse geforderten Delegation der Zugriffsrechte der Agenteninstanzen wird im Kapitel 6.9 vorgestellt.
Kapitel 6.10 behandelt die Verwaltungsstruktur und deren Handhabung.
Das Kapitel 6.11 beschäftigt sich mit der Rechtedurchsetzung der Zugriffskontrollpolitiken.
Abschließend werden im Kapitel 6.12 Beispielszenarien vorgestellt.
Im Kapitel 7 wird das Rechtekonzept in die MASA Umgebung eingebettet.
Durch das Rechtekonzept ist ein Zugriff auf ein Objekt erst dann möglich, wenn
das Subjekt zuvor explizit autorisiert worden ist. Damit wird das
in Kapitel 3.5 geforderte Fail-Safe Defaults Prinzip erfüllt.
Unterschiedliche Subjekte können über die Zugriffskontrollpolitik des Endsystems, des
Agentensystems und der Agenteninstanzen autorisiert werden.
Die Zugriffsrechte innerhalb der Zugriffskontrollpolitik einer Agenteninstanz entsprechen
Wunsch-Zugriffsrechte, die die jeweilige Agenteninstanz auf einem Agentensystem
durchsetzen will.
Realisiert wird eine objekt- und subjektspezifische Autorisation der
Subjekte innerhalb der Zugriffskontrollpolitiken des Agentensystems und der
Agenteninstanz (vgl. Kapitel 2.6.3).
Damit kann eine anwendungsspezifische Zugriffskontrollpolitik formuliert werden,
wodurch die Autorisation das im Kapitel 3.4
geforderte Least-Privilege Prinzip erfüllt, d.h.
jedem Subjekt können nur die Zugriffsrechte eingeräumt werden, die für die
Bearbeitung der jeweiligen Aufgabe notwendig sind.
Die vollständige Informationssicherheit aller Objekte garantiert die Durchsetzung der Zugriffskontrollpolitiken der Agentensysteme und die Integrationsmöglichkeit, den von dem Agentensystem akzeptierten Zugriffsrechte der Agenteninstanzen. Die zentrale Kontrollinstanz (ZKI) setzt die Zugriffskontrollpolitik des Agentensystems und die von dem Agentensystem akzeptierten Zugriffsrechte der Zugriffskontrollpolitiken der Agenteninstanzen durch. Die Durchsetzung der Zugriffskontrollpolitik des Endsystems liegt in den Händen des Betriebssystems.
Durch die zentrale Kontrollinstanz (ZKI) werden alle Zugriffsmöglichkeiten, des
in Kapitel 4.1 vorgestellten Modells der
Agentensystemarchitektur MASA, einer Zugriffskontrolle unterzogen. Damit
wird das in der Anforderungsanalyse (Kapitel 3.5)
geforderte Complete-Mediation Prinzip erfüllt wird.
Das Rechtekonzept wird durch die Möglichkeit der Aufzeichnung von sicherheitsrelevanten Operationen und Zugriffen vervollständigt. Anhand der Aufzeichnungen ist es möglich, Autorisationsvorgänge und Zugriffe auf Objekte, einzelner Subjekte zuzuordnen. Das Protokollieren der sicherheitsrelevanten Zugriffe dient der Entdeckung und Beweisführung von Manipulationsversuchen.
Objekte, auf die zugegriffen werden kann, sind von der
Außenwelt abgekapselt und nur über Schnittstellen erreichbar, die durch
die zentrale Kontrollinstanz (ZKI) überwacht werden. Dadurch kann
auf ein Objekt nur zugegriffen werden, wenn die Kontrollinstanz (ZKI) den
Zugriff gewährt. Die Überprüfung basiert auf den in den
Zugriffskontrollpolitiken vergebenen und von dem Agentensystem
akzeptierten Zugriffsrechten. Die von der zentralen Kontrollinstanz (ZKI) akzeptierten
Zugriffsrechte bilden die ZKI-Policy.
Betrachtet man die Objekte der Agenteninstanzen, der Agentensysteme und der Endsysteme
(die durch das Agentensystem erreichbar sind),
so bieten sie spezifische Zugriffsschnittstellen an,
die vollständig von der zentralen Kontrollinstanz (ZKI) erfasst und überprüft werden.
Die Abb. 32 verdeutlicht die Lage der zentralen Kontrollinstanz (ZKI). Die Zugriffsschnittstellen eines Zugriffes sind ebenfalls gekennzeichnet. Die Abb. 32 zeigt weiter, ob eine Zugriffsschnittstelle über einen Java-Kanal oder über einen CORBA-Kanal angesprochen werden kann.
Die Zugriffskontrollpolitik des Endsystems beschränkt Zugriffe auf
Objekte des Endsystems. Die Zugriffsbeschränkungen sind
durch die Zugriffskontrollpolitik des Endsystems nur von statischer Art
und über den gesamten Ausführungszeitraum des Agentensystems nicht
veränderbar. Zudem können keine anwendungsspezifischen Zugriffsbeschränkungen
formuliert werden, wodurch in der Regel die Zugriffsbeschränkung durch die
Zugriffskontrollpolitik des Agentensystems zu bevorzugen ist.
Die Zugriffskontrollpolitik des Endsystems eignet sich jedoch für
Beschränkungen von Zugriffen, die niemals stattfinden dürfen.
Beispielsweise könnte hier der Zugriff auf ein Verzeichnis unterbunden werden,
auf dem ein Agentensystem (und daher auch die Agenteninstanzen)
niemals Zugriff haben soll.
Das Agentensystem ist in der Lage Zugriffe auf seine Schnittstellen über eine
Zugriffskontrollpolitik (AS-Policy) zu autorisieren. Hierunter fallen dann
auch Zugriffe auf Objekte des Endsystems, die von dem Agentensystem aus
möglich sind. Innerhalb der Zugriffskontrollpolitik
des Agentensystems kann eine anwendungsspezifische Autorisation erfolgen.
Agenteninstanzen können Zugriffe ebenfalls durch eine Wunsch-Zugriffskontrollpolitik (Wunsch-MA-Policy) beschränken. Die Zugriffskontrollpolitik beschränkt dabei die Zugriffe auf Objekte der Agenteninstanz und gegebenenfalls der Objekte der Agentensysteme und der Endsysteme, die von dem Agentensystem aus erreichbar sind.
Die Zugriffskontrollpolitik einer Agenteninstanz ist eine Wunschpolicy, da die in der Zugriffskontrollpolitik enthaltenen Zugriffsrechte vor ihrer Durchsetzung vom Agentensystem überprüft werden und nur die vom Agentensystem akzeptierten Zugriffsrechte von dem Agentensystem durchgesetzt werden.
Das Agentensystem überprüft vor der Durchsetzung eines Zugriffsrechts einer
Wunsch-MA-Policy, auf Basis von Filter-Politiken, ob das Zugriffsrecht durchgesetzt
werden darf.
Dies betrifft vor allem Zugriffsrechte, die Zugriffe auf Objekte des Agentensystems
bzw. des Endsystems oder einer anderen Agenteninstanz autorisieren.
Dabei wird geprüft, ob das Zugriffsrecht innerhalb der
Filter-Policy des Agentensystems oder der jeweiligen Agenteninstanz
als unzulässig deklariert worden ist.
Durchgesetzt werden die vom Agentensystem akzeptierten Zugriffsrechte der
Wunsch-MA-Policy durch die zentrale Kontrollinstanz (ZKI) des Agentensystems und nicht
durch die Agenteninstanz selbst.
Dadurch basiert die Informationssicherheit auf einer Vertrauensbeziehung
zwischen der Agenteninstanz und dem Agentensystem. Die Agenteninstanz
muss sich darauf verlassen, dass die Zugriffsrechte der Wunsch-MA-Policy
durch das Agentensystem durchgesetzt wird.
Die akzeptierten Zugriffsrechte der Wunsch-MA-Policies der Agenteninstanzen
und die Zugriffsrechte der AS-Policy des Agentensystems bilden die von der
zentralen Kontrollinstanz (ZKI) durchzusetzenden ZKI-Policy.
Somit bestehen folgende Beziehungen zwischen den Schnittstellen und den für die Autorisation zuständigen Entitäten:
Ein Agentensystem und eine Agenteninstanz besitzen neben den Zugriffskontrollpolitiken
auch jeweils einen Filter-Mechanismus, welcher durch eine Filter-Policy
konfigurierbar ist. Durch die Verwendung eines Filters ist es einem Agentensystem und
einer Agenteninstanz möglich, Regelungen bezüglich den zu akzeptierenden Zugriffsrechten
einer Wunsch-MA-Policy einer Agenteninstanz festzulegen.
Die innerhalb der Filter-Policy enthaltenen Einträge spezifizieren,
welche Zugriffsrechte der Wunsch-MA-Policy von dem Agentensystem nicht durchgesetzt
werden. Damit können systemglobale Bestimmungen des jeweiligen Agentensystems
und der jeweiligen Agenteninstanz durchgesetzt werden. Der Filter kommt bei der
Verknüpfung der Zugriffsrechte der Wunsch-MA-Policy mit den Zugriffsrechten der AS-Policy
(s. Kapitel 6.6) zum Einsatz.
Die Kontrolle über die Zugriffsbeschränkung der einzelnen Objekte
besitzt jeweils der Eigentümer. Der Eigentümer einer Agenteninstanz und
eines Agentensystems ist diejenige Person, die die Entität gestartet hat.
Der Eigentümer der Ressourcen des Endsystems, auf die das Agentensystem
Zugriff hat, ist das Agentensystem, welches
auf dem Endsystem ausgeführt wird.
Die Autorisation der Subjekte erfolgt durch Einträge innerhalb der Zugriffskontrollpolitik, welche den Subjekten objektspezifische Zugriffsrechte zuteilen. Bei jedem Zugriffsversuch prüft die zentrale Kontrollinstanz (ZKI) des Agentensystems, auf dem sich das Objekt befindet, ob das Subjekt über die notwendige Autorisation verfügt. Dies geschieht auf Basis der in der AS-Policy des Agentensystems und der von dem Agentensystem akzeptierten Zugriffsrechte der Wunsch-MA-Policies. Zugriffe auf Ressourcen des Endsystems werden zusätzlich durch die Zugriffskontrollpolitik des Endsystems beschränkt.
Adressierung der Entitäten innerhalb der Zugriffskontrollpolitik
In dem folgenden Abschnitt werden die einzelnen Entitäten von MASA entsprechend ihrer
Funktion, die sie bei einem Zugriff einnehmen, zugeordnet.
Durch die Zuordnung wird ersichtlich an welcher Stelle eine Entität innerhalb der
Zugriffskontrollpolitik auftreten kann.
Adressierung der Subjekte
Personen, Agentensysteme und Agenteninstanzen
können innerhalb von MASA die Funktion eines Subjekts einnehmen, d.h. sie können
die aktive zugreifende Entität sein (vgl. Kapitel 2.1).
Subjekte werden innerhalb der Zugriffskontrollpolitik durch geeignete Attribute
adressiert. Die Attribute beschreiben dabei Eigenschaften des jeweiligen Subjekts.
Damit das Subjekt innerhalb der Zugriffskontrollpolitik eindeutig adressiert werden kann,
müssen die zur Adressierung herangezogenen Eigenschaften das Subjekt eindeutig
identifizieren können. Um dies zu gewährleisten werden die folgenden Eigenschaften
der einzelnen Subjekte zur Adressierung der Entitäten innerhalb der
Zugriffskontrollpolitik herangezogen:
Die Adressierung von Personen erfolgt durch den Personennamen.
[Personenname]Die Adressierung des Agentensystems (AS) erfolgt anhand des Eintrags ``AS'' und der folgenden Eigenschaften des Agentensystems:
[AS: Eigentuemer, Anwender, Implementierer]Die Adressierung der Agenteninstanzen (MA) erfolgt anhand dem Eintrag ``MA'' und den folgenden Eigenschaften der Agenteninstanz:
[MA: Eigentuemer, Anwender, Implementierer, Gattung, History]
Betrachtet man die History, so sind Adressierungen unterschiedlicher Formen
möglich. Einerseits können hier Agentensysteme benannt werden, die nicht
besucht wurden durften ( notvisit), andererseits können auch Einträge
vorgenommen werden, die besagen, welche Agentensysteme besucht werden
durften ( visit).
(Die History einer Agenteninstanz taucht dabei in der Reihe der Eigenschaften
der Agenteninstanz auf, da sie eine für eine Agenteninstanz eindeutige
Eigenschaft über den gesamten Zeitraum, über den sich die Agenteninstanz auf
dem Agentensystem befindet, darstellt.)
Anhand der oben aufgeführten Eigenschaften können die Subjekte eindeutig
autorisiert werden. Durch die Markierung ``AS'' und ``MA'' können
Zugriffsrechte explizit einem Agenten bzw. einem Agentensystem zugeteilt werden.
Der Anwender einer Agenteninstanz kann eine Agenteninstanz, ein Agentensystem oder eine Person sein. Ist der Anwender eine Agenteninstanz oder ein Agentensystem, ist eine in sich verschachtelte Adressierung innerhalb der Zugriffskontrollpolitik möglich. Die Adressierung eines Agentensystems beispielsweise könnte, falls der Anwender eine Agenteninstanz ist, wie folgt aussehen:
[AS: Eigentuemer, [MA: Eigentuemer, Anwender, Implementierer, History], Implementierer]
Adressierung der Objekte und der Aktionen
Die von dem Endsystem, dem Agentensystem und den Agenteninstanzen
zur Verfügung gestellten Operationen können die Funktion eines
Objekts einnehmen, d.h. sie können der passive Teil eines Zugriffs sein
(vgl. Kapitel 2.1).
Da in diesem Rechtekonzept objektspezifische Zugriffsrechte
(vgl. Kapitel 2.6.2) verwendet werden, wird innerhalb des
Zugriffsrechts das jeweilige Objekt adressiert. Die Adressierung der jeweiligen Aktion,
erfolgt ebenfalls innerhalb des Zugriffsrechts.
Zugriffsrechte
Um anwendungsspezifische Zugriffsrechte vergeben zu können, d.h.
Zugriffsrechte, die auf die spezifische Aufgabe des Subjekts zugeschnitten
sind und somit dem Least-Privilege Prinzip entsprechen, werden objektspezifische
Zugriffsrechte verwendet (vgl. Kapitel 2.6.2).
Objektspezifische Zugriffsrechte enthalten neben der Aktion auch das
jeweilige Objekt des Zugriffs. Dadurch ist die Vergabe eines Zugriffsrechts,
welches nur eine bestimmte Funktionalität auf dem Objekt erlaubt, möglich.
Zugriffsrechte haben die Form:
[Aktion "z" auf "xy" ausfuehren]Dieses Recht erhält dann ein Subjekt.
Beispielsweise können folgende Berechtigungen erteilt werden:
Beispiel 1: Historyliste der Agenteninstanz XY auslesen
Beispiel 2: Agenteninstanz der Gattung XY starten
Aus Sicht der Autorisationsinstanz muss die zu autorisierende Aktion, die innerhalb
des Zugriffsrechts vergeben werden kann, bekannt sein. Handelt es sich um Aktionen
auf ein Objekt des Agentensystems bzw. Endsystems, so kann nur der Administrator des
Agentensystems Zugriffe innerhalb der AS-Policy autorisieren. Dabei ist
vorauszusetzen, dass der Administrator die innerhalb der Zugriffsrechte zu
vergebenden Aktionen kennt.
Handelt es sich um Operationen einer Agenteninstanz, so sind allgemeine Operationen und deren Aktionen, die jede Agenteninstanz zur Verfügung stellen muss, als bekannt vorausgesetzt.
Spezielle Operationen mit speziellen Aktionen, die durch die Agenteninstanz implementiert werden, sind dem Agentensystem in der Regel unbekannt und müssen von der Agenteninstanz entsprechend autorisiert werden können.
Spezifische Operationen der Agenteninstanzen können daher nur von dem Administrator der jeweiligen Agenteninstanz autorisiert werden. Die Autorisation erfolgt dabei innerhalb der Wunsch-MA-Policy. Die Agenteninstanzen müssen sich für die Durchsetzung der Zugriffsrechte auf das Agentensystem verlassen.
Die Namenvergabe der Zugriffsrechte erfolgt anhand eines festgelegten Schemas, welches im Kapitel 6.3.3 vorgestellt wird. So ist sichergestellt, dass die Zugriffsrechte, die von den Administratoren vergeben werden können, nicht falsch interpretiert werden.
Ein Zugriffsrecht wird durch einen grant-Eintrag ausgedrückt.
Dabei bestimmt der Eintrag, welches Subjekt auf welches Objekt in welcher
Art und Weise zugreifen darf.
Innerhalb der Filter-Politiken werden Zugriffsrechte, die nicht durch eine Wunsch-MA-Policy
integriert und durchgesetzt werden dürfen, mit dem forbid-Eintrag ausgedrückt.
Die Terminalsymbole ma, as und person geben
dabei den jeweiligen Typ des Eintrags an (Agenteninstanz, Agentensystem und Person).
Nach dem Terminalsymbol permission werden die spezifischen Zugriffsrechte
aufgeführt.
Folgend wird die kontextfreie Grammatik der Politik-Sprache eingeführt, die
für die Wunsch-MA-Policy, die AS-Policy und der Filter-Policy verwendet wird. Die
Notation erfolgt in der erweiterten Backus-Naur-Form (EBNF) [SCH 95].
Die Klammer ``[ ]'' bedeutet, dass der Eintrag eingefügt werden kann aber nicht muss. Die Klammer ``{ }'' bedeutet, dass der Eintrag beliebig oft (auch nullmal) wiederholt werden kann. Bei mehreren Regeln, die dieselbe linke Seite haben, wird eine einzige ``Metaregel'' (unter Verwendung des ``Metasymbols'' |) angegeben. Zur besseren Lesbarkeit werden Terminalzeichen unterstrichen und fett gedruckt. (Bei der Klammer {} handelt es sich demnach um ein Terminalzeichen und nicht um das {}-Symbol der EBNF).
![\begin{table}
\begin{tabbing}
LINKSfillup123456789:\=PF:\=RechtsFillUPwit:\kill
...
...}}} {\tt\underline{\bf ;}} {\em [ma\_filter\_entry]}\\
\end{tabbing}\end{table}](img39.gif)
Beschreibung der Variablen:
Das Zugriffsrecht entspricht dabei dem folgenden Eintrag:
![\includegraphics [totalheight=0.25\textheight]{dynamischbinden.eps}](img32.gif)
![\includegraphics [totalheight=0.15\textheight]{ac-bond.eps}](img33.gif)
![\includegraphics [totalheight=0.15\textheight]{ac2-bond.eps}](img34.gif)
![\includegraphics [totalheight=0.2\textheight]{ectm.eps}](img35.gif)
![\includegraphics [totalheight=0.3\textheight]{recht-agentmodell.eps}](img36.gif)
![\includegraphics [totalheight=0.2\textheight]{recht-politiken.eps}](img37.gif)
grant <subject> {
permission ObjektPermission {"<parameter>", "<action>"}
}
Folgend werden einige Beispiele für Zugriffsrechte gezeigt, die innerhalb
von MASA eingesetzt werden können.
Zugriffsrechte auf Ressourcen des Endsystems
Beispiel 1.1: Zugriffsrecht für einen Zugriff einer Agenteninstanz auf eine
Ressource des Endsystems [MA - ES]
grant ma.provider.provider.*.*[visit as.haendler.haendler.mnm,
[visit as.hersteller.hersteller.mnm,
[visit provider.provider.mnm]{
permission java.security.FilePermission ("/results/-", "read")
}
Dieses Zugriffsrecht erlaubt den Agenteninstanzen, die die
in dem Zugriffsrecht enthaltenen Eigenschaften
(Eigentümer=[provider], Anwender=[provider], Implementierer= alle,
Gattung=alle und höchstens die folgenden Agentensysteme in
der History=[as.haendler.haendler.mnm, as.hersteller.hersteller.mnm,
as.provider.provider.mnm]) erfüllen,
auf die ES-Ressource (das Verzeichnis:''/results/'') lesend zuzugreifen.
Dabei wird von der Überprüfung der History der
Agenteninstanz Gebrauch gemacht.
Die History der Agenteninstanz gibt an,
welche Agentensysteme mit den genannten Eigenschaften besucht werden
durften. Sind die Eigenschaften erfüllt, kann das Zugriffsrecht
erteilt werden. Die Reihenfolge der History-Einträge spielt dabei keine Rolle.
Beispiel 1.2: Zugriffsrecht für einen Zugriff einer Agenteninstanz auf eine Ressource des Endsystems [MA - ES]
grant ma.provider.*.*.as-hersteller.[notvisit as.hersteller.hersteller.mnm]{
permission java.security.FilePermission ("/results/-", "read")
}
Hierbei handelt es sich um ein Zugriffsrecht für Agenteninstanzen mit
Beschränkung der History, wobei angegeben wird, welches Agentensystem zuvor
nicht besucht werden durfte.
Die zugreifende Agenteninstanz darf nur auf das Verzeichnis zugreifen,
wenn die History der Agenteninstanz nicht das angegebene
Agentensystem aufweist.
Beispiel 1.3: Zugriffsrecht für einen Zugriff einer Agenteninstanz auf eine Ressource des Endsystems [MA - ES]
grant ma.provider.*.*.as-hersteller[visit as.*.provider.*.*]{
permission java.security.FilePermission ("/results/-", "read")
}
Das Zugriffsrecht wird an die entsprechende Agenteninstanz vergeben,
falls nur Agentensysteme besucht worden sind,
dessen Eigentümer jeweils der [provider] war.
Beispiel 1.4: Zugriffsrecht für einen Zugriff einer Agenteninstanz auf eine Ressource des Endsystems [MA - ES]
grant ma.provider.*.*.as-hersteller[visit as.*.[as.*.provider.*.*].*.*]{
permission java.security.FilePermission ("/results/-", "read")
}
Das Zugriffsrecht besitzt weitere Attribute innerhalb der History.
Dabei dürfen von Agenteninstanzen nur Agentensysteme besucht worden sein,
deren Eigentümer (authority) ein Agentensystem ist, dessen Eigentümer
wiederum der Provider ist.
Es können also Eigenschaften von Eigenschaften eines Subjekts
adressiert werden. Dies ist dann möglich, wenn eine Eigenschaft
ein Principal darstellt. Die Attribute des Principals sind dann die
weiteren Eigenschaften, die zur Adressierung herangezogen werden
können.
Beispiel 1.5: Zugriffsrecht für einen Zugriff einer Agenteninstanz auf eine Ressource des Endsystems [MA - ES]
grant ma.provider.*.*.mnm.messe.[*] , ma.haendler.*.*.mnm.messe.[*]{
permission java.security.FilePermission ("/temp", "read, write")
}
Ein Zugriffsrecht ist nicht nur an ein Subjekt oder Objekt gebunden.
Es können mehrere Subjekte, mehrere Objekte und mehrere Aktionen,
durch Hinzunahme des Wildcards * bestimmt werden.
So impliziert das wie folgt modellierte Zugriffsrecht
alle Zugriffe, deren Subjekte eine Agenteninstanz mit den folgenden
Eigenschaften sind:
Authority = [provider] oder [haendler], Implementierer = [mnm] und der
Gattung [messe]
Zugriffsrechte auf die Objekte des Agentensystems
Zugriffsrechte auf Objekte des Agentensystems beginnen mit der
Kennzeichnung masa.As. Handelt es sich um ein Zugriffsrecht auf eine
Agenteninstanz beginnt der Name des Zugriffsrechts mit masa.AsAgent.
Beispiel 2.1: Zugriffsrecht für einen Zugriff eines Agentensystems auf eine Ressource eines Agentensystems [AS - AS]
grant as.*.*.mnm {
permission masa.AsPermission ("getOwner")
}
Ein Agentensystem mit dem Implementierer [mnm] darf den Eigentümer
des Agentensystems auslesen.
Beispiel 2.2: Zugriffsrecht für einen Zugriff einer Agenteninstanz auf eine Ressource des Agentensystems [MA - AS]
grant ma.mnm.mnm.*.*.* {
permission masa.AsAgentPermission ("ma.*.*.*.*.*", "createAgent")
}
Eine Agenteninstanz mit dem Eigentümer [mnm] und dem Anwender [mnm]
darf auf dem Agentensystem eine Agenteninstanz jeglicher Art erzeugen.
Beispiel 2.3: Zugriffsrecht für einen Zugriff eines Agentensystems auf eine Ressource eines Agentensystems [AS - AS]
grant as.*.*.mnm {
permission masa.AsAgentPermission ("ma.*.*.*.*.*", "createAgent")
}
Zugriffsrechte auf Objekte einer Agenteninstanz:
Zugriffsrechte auf Objekte einer Agenteninstanz beginnen mit Namen
masa.MA.
Beispiel 3.1: Zugriffsrecht für einen Zugriff einer Agenteninstanz
auf eine Ressource einer Agenteninstanz [MA - MA]
grant ma.*.*.mnm.*.[*] {
permission masa.MaPermission ("ma.mnm.mnm.mnm.messe.[*]", "getName")
}
Dieses Zugriffsrecht erteilt eine Berechtigung für den
Zugriff auf eine Agenteninstanz.
Agenteninstanzen, welche von [mnm] implementiert worden sind, dürfen
die Aktion [getName] auf der Agenteninstanz [ma.mnm.mnm.mnm.messe.[*]]
ausführen.
Das Zugriffsrecht wird im Normalfall in der Wunsch-MA-Policy einer
Agenteninstanz vergeben und muss daher vom Agentensystem akzeptiert werden,
um auch durchgesetzt zu werden.
Die Vergabe von Zugriffsrechten durch Agenteninstanzen können von dem
Agentensystem beschränkt werden. Dadurch können z.B.
von einem Agentensystem nur Zugriffsrechte einer Agenteninstanz
durchgesetzt werden, die Objekte der Agenteninstanz selbst betreffen.
Beispiel 5: Zugriffsrecht für einen Zugriff eines Agentensystems auf eine Ressource einer Agenteninstanz [AS - MA]
grant as.*.*.mnm {
permission masa.MaAgentPermission ("ma.mnm.mnm.mnm.messe.[*]", "getName")
}
Der folgende Eintrag berechtigt Agentensysteme, welche von [mnm] implementiert worden sind, auf der Agenteninstanz mit den genannten Eigenschaften, die Aktion [getName] auszuführen. Da es sich wiederum um ein Zugriffsrecht auf eine Agenteninstanzmethode handelt, wird es ebenfalls innerhalb der Wunsch-MA-Policy vergeben. Es liegt dann wiederum am Agentensystem, dieses Zugriffsrecht durchzusetzen.
Beispiel Agentensystem Zugriffskontrollpolitik (AS-Policy)
\\
\\ Agentensystem Policy
\\
grant ma.provider.provider.*.*.[visit as.haendler.haendler.mnm,
visit as.hersteller.hersteller.mnm,
visit as.provider.provider.mnm] {
permission java.security.FilePermission("/results/", "read")
}
grant ma.provider.provider.mnm.messe.[*], ma.haendler.haendler.mnm.messe.[*]{
permission java.security.FilePermission("/results/", "read, write")
}
Beispiel Agenteninstanz Zugriffskontrollpolitik (Wunsch-MA-Policy)
\\
\\ Agenteninstanz Policy
\\
grant ma.provider.provider.*.*.[visit as.haendler.haendler.mnm,
visit as.provider.provider.mnm] {
permission java.security.FilePermission("/results/", "read")
}
[18:00 - 26.04.2001]
grant ma.provider.provider.mnm.messe.[*], ma.haendler.haendler.mnm.messe.[*]{
permission java.security.FilePermission("/results/", "read, write")
}
<location as.haendler.haendler.mnm, 0>
grant ma.provider.provider.*.*.[*]{
permission masa.MaAgentPermission ("readResult")
}
Bei der Modellierung eines Zugriffs ist auch der Ort des Subjekts und des Objekts enthalten, um Zugriffe über Systemgrenzen hinaus modellieren zu können. Die modellierten Beispielzugriffe stellen die Zugriffe in Anlehnung an das Beispielszenario aus Kapitel 1 dar.
{[as: <as>](subject, <subject>)->[as: <as>](object,<object>) | (action, <action>)}
Beispiel 1: MA greift auf eine ES-Ressource des AS zu, auf dem er sich befindet
{
[as: as1.provider.provider.mnm]
(subject, ma.provider.provider.mnm.messe.(as.provider.provider.mnm)) ->
[as: as1.provider.provider.mnm]
(object, /results/erg-haendler-071200)|
(action, write)
}
Dies ist eine Modellierung des Zugriffs einer Agenteninstanz auf ein Objekt des
Agentensystems, auf dem sich die Agenteninstanz befindet.
Modelliert wird der Zugriff der Agenteninstanz [ma-p-messe] mit den Eigenschaften: Eigentümer = [provider], Anwender = [provider], Implementierer = [mnm], Gattung = [messe] und History = [Agentensystem: Provider].
Die Agenteninstanz befindet sich auf dem Agentensystem [Provider], welches die folgenden Eigenschaften aufweist: Eigentümer = [provider], Anwender = [provider] und Implementierer = [mnm].
Bei der Ressource, auf die zugegriffen wird, handelt es sich in diesem Fall um eine Ressource des Endsystems, auf welchem das Agentensystem ausgeführt wird: ES-Ressource = [/results/erg-haendler-071200].
Auf diese Ressource wird folgende Aktion [write] ausgeführt.
Beispiel 2: MA mit Vergangenheit greift auf eine ES-Ressource
{
[as: as1.provider.provider.mnm]
(subject, ma.haendler.mnm.messe.(as.provider.provider.mnm
as.haendler.haendler.mnm,
as.hersteller.hersteller.mnm)) ->
[as: as1.provider.provider.mnm]
(object, /results/erg-hersteller-071200)|
(action, write)
}
Bei Beispiel 2 handelt es sich um eine Modellierung des Zugriffs einer
Agenteninstanz, die zuvor andere Agentensysteme besucht hat, auf ein Objekt des
Agentensystems, auf dem sich die Agenteninstanz befindet.
Modelliert wird der Zugriff der Agenteninstanz [ma-h-messe] mit den folgenden Eigenschaften: Eigentümer = [haendler], Anwender = [haendler], Implementierer = [mnm], Gattung = [messe] und der History = [as-haendler, as-hersteller], welche sich auf dem Agentensystem [provider] befindet, welches die folgenden Eigenschaften hat: Eigentümer = [provider], Anwender = [provider] und Implementierer = [mnm].
Zugegriffen wird auf die ES-Ressource: [/results/erg-hersteller-071200]. Auf der ES-Ressource wird die Aktion [write] ausgeführt. Die History gibt an, dass diese Agenteninstanz zuvor die Agentensysteme des Händlers und des Herstellers besucht hat.
Agentensysteme autorisieren Zugriffe durch die AS-Policy.
Eine Agenteninstanz kann innerhalb der Wunsch-MA-Policy Zugriffe autorisieren,
die jedoch erst von dem Agentensystem, auf dem sich die Agenteninstanz befindet,
akzeptiert werden müssen, um auch durchgesetzt zu werden.
Das Agentensystem entscheidet anhand der für das jeweilige Zugriffsrecht
zuständigen Filter-Politik, ob das Zugriffsrecht durchgesetzt wird.
Einerseits besitzt ein Agentensystem eine Filter-Politik (AS-Filter-Policy), wodurch das Agentensystem die Zugriffsrechte spezifizieren kann, die nicht durch eine Wunsch-MA-Policy einer Agenteninstanz in die ZKI-Policy integriert und durchgesetzt werden. Andererseits besitzt auch eine Agenteninstanz eine Filter-Politik (MA-Filter-Policy), in der beispielsweise eine Agenteninstanz ``A'' definieren kann, welche Zugriffsrechte das Agentensystem nicht durch eine Wunsch-MA-Policy einer weiteren Agenteninstanz ``B'', bezüglich Objekten der Agenteninstanz ``A'' durchsetzen soll. Vergibt eine Agenteninstanz innerhalb ihrer Wunsch-MA-Policy Zugriffsrechte auf Objekte einer anderen Agenteninstanz, kontrolliert die ZKI die MA-Filter-Policy der entsprechenden Agenteninstanz und entscheidet daraufhin, ob die Wunsch-Zugriffsrechte in die ZKI-Policy integriert und somit von der ZKI durchgesetzt werden können.
Findet ein Zugriff auf ein Objekt des Agentensystems statt, so kontrolliert die zentrale Kontrollinstanz (ZKI) den Zugriff, indem übeprüft wird, ob in der AS-Policy, die Bestandteil der ZKI-Policy ist, das notwendige Zugriffsrecht vorhanden ist (vgl. Abb. 34).
Innerhalb der Zugriffskontrollpolitik eines Agentensystems können folgende Zugriffe durch die Vergabe von Zugriffsrechten autorisiert werden:
Der Administrator sollte jedoch beachten, dass Zugriffe auf Objekte von Agenteninstanzen im Normalfall nur von den Agenteninstanzen mittels der Wunsch-MA-Policy autorisiert werden.
Um die Informationssicherheit der Agenteninstanzen zu schützen, sollte diese Regel zwingend eingehalten werden. Die Möglichkeit trotzdem Zugriffe auf Agenteninstanzen autorisieren zu können, spiegelt die Einbettungsbeziehung einer Agenteninstanz gegenüber des Agentensystems wider. Das Agentensystem muss daher dem Agentensystem vertrauen können.
Innerhalb der Wunsch-Zugriffskontrollpolitik einer Agenteninstanz können Zugriffsrechte vergeben werden bezüglich:
Dabei sollten in der Wunsch-MA-Policy Zugriffsrechte vergeben werden,
die bei ihrer Durchsetzung durch das Agentensystem der Agenteninstanz ermöglichen,
ihre Aufgaben zu erledigen (a,b und c).
Es ist jedoch darauf zu achten, dass einzelne Zugriffsrechte der Wunsch-MA-Policy
unter Umständen nicht von einem Agentensystem akzeptiert und damit nicht
durchgesetzt werden. Dies betrifft
vor allem Zugriffsrechte, die Zugriffe auf Objekte des Agentensystems oder des
Endsystems autorisieren (b und c). Diese Zugriffsrechte werden nur dann durchgesetzt,
wenn die Zugriffsrechte nicht innerhalb der AS-Filter-Policy des Agentensystems
bzw. der MA-Filter-Policy einer Agenteninstanz als unzulässig ( forbid)
deklariert worden sind.
Die Spezifizierung der unzulässigen Zugriffsrechte innerhalb der Filter-Politiken
kann nur der Eigentümer des Objekts der Agenteninstanz oder des Agentensystems vornehmen.
Bevor Zugriffsrechte der Wunsch-MA-Policies durchgesetzt
werden, überprüft die zentrale Kontrollinstanz (ZKI), ob das Zugriffsrecht von
der zuständigen Filter-Politik akzeptiert wird.
Zugriffsrechte der Wunsch-MA-Policy, welche Zugriffe auf die Schnittstelle der
eigenen Agenteninstanz erlauben (a), werden in der Regel von der Kontrollinstanz (ZKI)
des Agentensystems ausnahmslos akzeptiert und durchgesetzt.
Autorisation innerhalb der Wunsch-MA-Policy für spezielle Agentensysteme
Um innerhalb der Wunsch-MA-Policy die Möglichkeit zu bieten, Zugriffsrechte nach
dem Least-Privilege Prinzip zu vergeben, kann die Wunsch-MA-Policy
in Abschnitte unterteilt werden, die jeweils einem oder mehreren Agentensystemen
zugeteilt werden. Zugriffsrechte, die nur von bestimmten Agentensystemen durchgesetzt
werden sollen, besitzen innerhalb der Wunsch-MA-Policy einen Eintrag, der das
Agentensystem angibt, bei welchem das Zugriffsrecht durchgesetzt werden soll.
<location as.as_entry, secure_flag>Damit auch hier ein eventueller Missbrauch ausgeschlossen werden kann, kann das Zugriffsrecht mit dem Public Key des Agentensystems (bzw. einer Agentensystem Gruppierung) verschlüsselt werden. Das betreffende Agentensystem berücksichtigt bei der Durchsetzung der Zugriffsrechte die dem Agentensystem zugeordneten Abschnitte.
Wunsch-MA-Policy bei der Erzeugung einer neuen Agenteninstanzen durch eine Agenteninstanz
Wird durch eine Agenteninstanz auf einem fremden Agentensystem eine weitere
Agenteninstanz erzeugt, so bekommt diese weitere Agenteninstanz die Wunsch-MA-Policy
der Agenteninstanz in Form einer Kopie übermittelt. Zusätzlich wird die Kopie der
Wunsch-MA-Policy von dem Agentensystem unterzeichnet, auf dem die ``neue'' Agenteninstanz
erzeugt wurde. Die Entscheidung der Durchsetzung der in der Kopie der Wunsch-MA-Policy
enthaltenen Zugriffsrechte basiert auf der jeweiligen Vertrauensbeziehung zu
dem Agentensystem.
Die Wunsch-MA-Policy ist hier nicht mehr von einem Eigentümer sondern von einem
Agentensystem unterzeichnet.
Durch die Delegation der Zugriffsrechte besitzen die neu erzeugten Agenteninstanzen ebenfalls die für die Bearbeitung der Aufgabe notwendigen Zugriffsrechte.
Es gibt jedoch auch Szenarien, in denen eine dynamische Vergabe von
Zugriffsrechten für Agenteninstanzen benötigt werden.
Die Vergabe von Zugriffsrechten kann so z.B. von bestimmten Zustandsbedingungen abhängen.
Beispielsweise ist es sinnvoll, den Zugriff auf eine Methode einer Agenteninstanz,
welche das Ergebnis einer Messung liefert, erst nach der erfolgreichen Messung
zu erlauben. Hierfür müsste nach der erfolgreichen Messung die
Agenteninstanz die Möglichkeit haben, das Zugriffsrecht auf diese
Methode zu setzen bzw. auch wieder zurückzunehmen.
Vorstellbar ist auch die Situation,
dass eine Agenteninstanz sensitive Daten des Agentensystems bearbeitet
und in diesem Zeitraum keine Zugriffe auf diese Agenteninstanz
zugelassen werden sollen.
Daher sollte eine Agenteninstanz die Möglichkeit haben, Zugriffe dynamisch
geknüpft an Bedingungen, beschränken zu können.
Um dies zu ermöglichen, wird die Aktions-Policy eingeführt.
Damit Zugriffsrechte auch während des Lebenszyklus der Agenteninstanz dem
Umfeld dynamisch angepasst werden können besteht die Möglichkeit, die
Wunsch-MA-Policy einer Agenteninstanz durch eine ``neue'' Wunsch-MA-Policy
auszutauschen.
Erneuerung der Wunsch-MA-Policy
Damit die Zugriffsrechte während der Lebenszeit einer Agenteninstanz modifiziert
werden können, besteht die Möglichkeit, dass der Eigentümer
der Agenteninstanz eine weitere Wunsch-MA-Policy erzeugen kann und diese dann die
``alte'' Wunsch-MA-Policy ersetzt. Die neue Wunsch-MA-Policy muss dabei von ein
und demselben Eigentümer der Agenteninstanz unterzeichnet sein.
Damit der Missbrauch ausgeschlossen werden kann, ist nur der Eigentümer in der Lage,
die Wunsch-MA-Policy zu erneuern. Das Agentensystem kontrolliert auch hier die
Berechtigung. Bei einem Austausch wird dabei der Eigentümer der Agenteninstanz mit dem
Unterzeichner der Wunsch-MA-Policy verglichen.
Desweiteren kann auf jedem Agentensystem die Signatur der Wunsch-MA-Policy
mit dem Eigentümer der Agenteninstanz verglichen werden.
Ein Austausch der Wunsch-MA-Policy kann aufgrund der notwendigen Signatur des Eigentümers
in der Regel nur auf dem Home-Agentensystem der Agenteninstanz erfolgen.
Aktions Politik
Die Aktions-Policies sind Politiken, die Zugriffsrechte geknüpft an Bedingungen vergeben
können. Die Aktions-Policy wird bei einem Eintreffen einer bestimmten Bedingung
an das Agentensystem übergeben, welches die in der Aktions-Politik
enthaltenen Zugriffsrechte durchsetzen kann. Die innerhalb der Aktions-Politik
vergebenen Zugriffsrechte werden ebenfalls vor ihrer Durchsetzung auf Basis
der Filter kontrolliert.
Hat eine Agenteninstanz beispielsweise die Aufgabe, den Netzdurchsatz zu messen, so
kann die Agenteninstanz den Zugriff erst zulassen, nachdem das Ergebnis ermittelt wurde.
Um dies zu erreichen wird die Wunsch-MA-Policy, die das notwendige Zugriffsrecht
enthält, erst nachdem das Ergebnis vorliegt, an das Agentensystem überreicht.
Die Aktions-Policy ist mit der Wunsch-MA-Policy vergleichbar, jedoch können innerhalb
der Aktions-Policy nur Zugriffsrechte für Objekte der Agenteninstanz
vergeben werden.
Die Agenteninstanz kann unabhängig von dem Migrationszeitpunkt jederzeit dem
Agentensystem die Aktions-Policy zur Durchsetzung vorlegen.
Die Kontrollinstanz (ZKI) des Agentensystems überprüft, ob die
Zugriffsrechte durchgesetzt werden können.
Falls ja, werden die in der Aktions-Policy enthaltenen Zugriffsrechte
von der zentralen Kontrollinstanz (ZKI) durchgesetzt.
Die Zugriffsrechte der Aktions-Policy können jederzeit von der
Agenteninstanz wieder zurückgenommen werden.
Wird der Agent vorher beendet oder migriert die Agenteninstanz
auf ein anderes Agentensystem, werden
die Zugriffsrechte automatisch von dem Agentensystem aus der ZKI-Policy entfernt.
Das Ergebnis der Verknüpfung ist die Vereinigungsmenge der Zugriffsrechte.
Zugriffe werden erlaubt, falls mindestens ein Zugriffsrecht der AS-Policy oder
der zugelassenen Zugriffsrechte der Wunsch-MA-Policy den Zugriff erlauben.
Bei der Verknüpfung der Zugriffskontrollpolitiken werden die Autonomie-Anforderungen des Agentensystems und der betreffenden Agenteninstanz erfüllt. D.h. die Zugriffe, die nach der Zugriffskontrollpolitik AS-Policy erlaubt sind, sind nach der Verknüpfung weiterhin erlaubt. Zugriffe die explizit verboten sind, sind nach der Verknüpfung weiterhin verboten.
Die Autonomie-Anforderungen der Wunsch-MA-Policy sind nur erfüllt, falls sich die
Zugriffsrechte auf Objekte der Agenteninstanz beziehen.
Betrachtet man Zugriffsrechte innerhalb der Wunsch-MA-Policy, die Objekte des
Agentensystems bzw. anderer Agenteninstanzen betreffen, so werden die
vergebenen Zugriffsrechte nur durchgesetzt, falls sie nicht innerhalb der
jeweiligen Filter-Politik als unzulässig deklariert worden sind.
Das Agentensystem entscheidet bei der Verknüpfung der Wunsch-MA-Policy mit der
AS-Policy anhand der authentifizierten Agenteninstanz
und der Signatur der Wunsch-MA-Policy, ob die Agenteninstanz die Zugriffsrechte
vergeben darf.
Das Agentensystem überprüft vor der Integration der Wunsch-MA-Policy:
Die Verknüpfungsmöglichkeit der Wunsch-MA-Policy gestattet eine dynamische
Erweiterung der durchzusetzenden Zugriffsrechte des Agentensystems (ZKI-Policy).
Durch mobile Agenteninstanzen ist daher eine
dynamische und flexible Autorisation von Zugriffen möglich.
(1) In der Wunsch-MA-Policy können Zugriffe auf Objekte des Agentensystems und der Agenteninstanzen autorisiert werden.
(2) Migriert nun die Agenteninstanz auf ein Agentensystem, wird dem Agentensystem die Wunsch-MA-Policy übergeben, um die darin enthaltenen Zugriffsrechte durchzusetzen.
(3,4) Zuerst kontrolliert die zentrale Kontrollinstanz (ZKI) die Integrität und die Signatur der Wunsch-MA-Policy. Danach überprüft die ZKI auf Basis der AS-Policy und der Filter-Politiken, welche Zugriffsrechte der Wunsch-MA-Policy durch die ZKI durchgesetzt werden können.
(5) Die vom Agentensystem akzeptierten Zugriffsrechte der Wunsch-MA-Policy bilden zusammen mit den Zugriffsrechten der AS-Policy, die vom Agentensystem durchzusetzende ZKI-Policy.
(6) Von der zentralen Kontrollinstanz (ZKI) werden die Zugriffsrechte der AS-Policy
und die akzeptierten Zugriffsrechte der Wunsch-MA-Policy durchgesetzt.
Wunsch-MA-Policy enthält: Zugriffsrechte für Objekte des Agentensystems (AS-Obj)
Werden durch die Wunsch-MA-Policy Zugriffsrechte auf ein Objekt des Agentensystems
(AS-Obj) vergeben, überprüft die ZKI die Zugriffsrechte, so dass nur solche
Zugriffsrechte durchgesetzt werden, die den Sicherheitsbelangen des Agentensystems
nicht widersprechen. Es werden nur Zugriffsrechte von der ZKI durchgesetzt,
die nicht innerhalb der AS-Filter-Policy als unzulässig deklariert worden sind.
Wunsch-MA-Policy enthält: Zugriffsrechte für Objekte einer Agenteninstanz (MA-Obj)
Handelt es sich um Zugriffsrechte auf Objekte einer anderen Agenteninstanz (MA-Obj),
wird die MA-Filter-Policy der Agenteninstanz berücksichtigt.
Die innerhalb der MA-Filter-Policy als unzulässig deklarierten Zugriffsrechte
werden von der ZKI nicht durchgesetzt.
Filter Politik des Agentensystems
Durch den Filter besitzt das Agentensystem einen Mechanismus, der die Vergabe der
Zugriffsrechte auf Objekte des Agentensystems durch die Integration
der Wunsch-MA-Policy einer Agenteninstanzen beschränkt.
Einträge innerhalb der Filter-Policy werden in der Regel ausschließlich von berechtigten Personen vorgenommen. Dies ist in erster Linie der Administrator des Agentensystems auf dem der Filter eingesetzt wird. Der Administrator hat jedoch auch die Möglichkeit Zugriffsrechte auf die Filter-Policy zu vergeben, die einem weiteren Subjekt erlauben, Änderungen vorzunehmen. Beispielsweise könnte so einer spezifischen Agenteninstanz, die als Administrator tätig ist, ein solches Zugriffsrecht zugeteilt werden.
Filter Politik der Agenteninstanz
Da eine Agenteninstanz ebenfalls Zugriffsrechte innerhalb ihrer Wunsch-MA-Policy
vergeben kann, die die Objekte einer weiteren Agenteninstanz betreffen, muss die
zentrale Kontrollinstanz, um die Informationssicherheit der weiteren Agenteninstanzen
zu bewahren, die Filter-Policy der jeweiligen Agenteninstanz, auf die
die Zugriffsrechte zum Zugriff berechtigen, berücksichtigen.
Ein Zugriffsrecht einer Wunsch-MA-Policy auf ein Objekt einer ``fremden'' Agenteninstanz wird nur dann durchgesetzt, wenn die Agenteninstanz des Objekts innerhalb der Filter-Policy die Durchsetzung des Zugriffsrechts zulässt.
Eine Kollision kann auftreten
Durch den Einsatz der AS-Filter-Policy ist ausgeschlossen, dass
die zentrale Kontrollinstanz (ZKI) unzulässige Zugriffsrechte einer Wunsch-MA-Policy
durchsetzt. Die Autonomieanforderungen des Agentensystems werden somit erfüllt.
Durch die MA-Filter-Policy einer Agenteninstanz ist ebenso ausgeschlossen,
dass Zugriffsrechte bezüglich Objekten einer
Agenteninstanz ``A'' durchgesetzt werden, die von der Agenteninstanz ``A''
als unzulässig deklariert worden sind.
Die Überprüfung, ob ein Zugriffsrecht von der zentralen Kontrollinstanz (ZKI) durchgesetzt wird, übernimmt ebenfalls die ZKI.
Die in der Abb. 39 dargestellte Grafik beschreibt die Autorisationszusammenhänge.
(1) Das Agentensystem autorisiert durch seine AS-Policy Subjekte auf Objekte des Agentensystems oder einer Agenteninstanz auf eine bestimmter Art und Weise zuzugreifen. Einträge in die AS-Policy können über autorisierte Personen erfolgen.
(2) Eine Agenteninstanz autorisiert durch seine Wunsch-MA-Policy ebenso Subjekte auf Objekte des Agentensystem bzw. einer Agenteninstanz zuzugreifen. Die Wunsch-MA-Policy wird dabei von dem Eigentümer der Agenteninstanz erstellt.
(3) Migriert die Agenteninstanz auf ein Agentensystem, übergibt sie dem Agentensystem die Wunsch-MA-Policy. Die zentrale Kontrollinstanz (ZKI) des Agentensystems überprüft die Integrität der Wunsch-MA-Policy und die Signatur.
(4) Danach überprüft die ZKI, ob die Agenteninstanz die in der Wunsch-MA-Policy enthaltenen Zugriffsrechte vergeben darf. Die Überprüfung basiert auf Grundlage der AS-Policy und der Filter-Politiken.
(5) Die zugelassenen Zugriffsrechte werden letztendlich von der zentralen Kontrollinstanz (ZKI) bei der Zugriffskontrolle mitberücksichtigt und durchgesetzt.
(6) Greift nun ein Subjekt auf ein Objekt des Agentensystems
zu, überprüft die ZKI, ob das benötigte Zugriffsrecht
vorhanden ist. Dabei werden die Zugriffsrechte der AS-Policy und die
zugelassenen Zugriffsrechte der Wunsch-MA-Policy berücksichtigt.
Die akzeptierten Zugriffsrechte der Wunsch-MA-Policy werden bis zur Beendigung bzw. einer Migration der Agenteninstanz auf ein anderes Agentensystem von der zentralen Kontrollinstanz (ZKI) des Agentensystems berücksichtigt und durchgesetzt.
Wunsch-MA-Policy
Vom Agentensystem zugelassene Zugriffsrechte, welche eine Agenteninstanz
mittels der Wunsch-MA-Policy vergibt, sind über den gesamten Zeitraum, während sich
die Agenteninstanz auf dem Agentensystem befindet, gültig.
Terminiert die Agenteninstanz bzw. migriert die Agenteninstanz auf ein
anderes Agentensystem, werden die akzeptierten Zugriffsrechte aus der Policy
entfernt.
Enthält ein Wunsch-Zugriffsrecht ein Verfallsdatum ( time), so ist das entsprechende Zugriffsrecht nur bis zum Eintreffen des Datums gültig.
1) Rücknahme der Zugriffsrechte der AS-Policy:
a) Zugriffsrechte für Objekte des Agentensystems (Vergabe vom AS)
Die Rücknahme der Zugriffsrechte, die die Objekte des Agentensystems
betreffen, ist denkbar einfach. Soll ein Zugriffsrecht zurückgenommen
werden, wird es einfach aus der AS-Policy entfernt. Damit ist
dieses Zugriffsrecht nicht mehr innerhalb der ZKI-Policy enthalten und wird
somit auch nicht mehr durchgesetzt.
Zu beachten ist, falls das Agentensystem z.B. Zugriffe auf
ein bestimmtes Verzeichnis nicht mehr gestatten will,
es nicht reicht, das betreffende Zugriffsrecht, welches Zugriffe auf
dieses Verzeichnis zulässt, aus der AS-Policy zu entfernen.
Es können weiter Zugriffsrechte in der AS-Policy enthalten sein, die explizit
das Zugriffsrecht auf ein Unterverzeichnis dieses Verzeichnisses beinhalten und
damit weiter Zugriffe auf dieses Verzeichnis ermöglichen.
Zudem besteht die Möglichkeit, dass das Zugriffsrecht
erneut durch die Integration von Zugriffsrechten einer Wunsch-MA-Policy
in die ZKI-Policy aufgenommen und durchgesetzt wird.
In einem solchen Fall muss darauf geachtet werden, dass die
Filter-Policy die erneute Integration des Zugriffsrechts unterbindet.
Die spezifischen Zugriffsrechte müssen innerhalb der AS-Policy gesucht und entfernt
werden. Um eine sichere Rücknahme bestimmter Zugriffsrechte zu ermöglichen,
sollte die AS-Policy klar und unmissverständlich interpretierbar sein.
Dies setzt eine geeignete Strukturierung voraus.
Ein entsprechendes Tool könnte die Einträge geeignet repräsentieren,
das z.B. alle Zugriffsrechte, welche den Zugriff auf das
Dateisystem erlauben, ausgeben kann.
Wurden alle Zugriffsrechte entfernt, kann durch den Filter-Mechanismus ein Zugriffsrecht
als unakzeptabel deklariert werden wodurch
das Zugriffsrecht nicht mehr durch eine Wunsch-MA-Policy integriert werden kann.
b) Zugriffsrechte auf Objekte einer Agenteninstanz (Vergabe AS)
Das Agentensystem vergibt in der Regel keine Zugriffsrechte für
Objekte einer Agenteninstanz. Zugriffsrechte auf Agenteninstanz-Methoden
werden normalerweise von der Agenteninstanz durch die Integration
der Wunsch-MA-Policy in die ZKI-Policy vorgenommen.
Hat das Agentensystem dennoch ein solches Zugriffsrecht vergeben,
gestaltet sich die Rücknahme ebenso durch das Entfernen des
Zugriffsrechts aus der AS-Policy.
c) Zugriffsrechte für Objekte des Agentensystems (Vergabe vom MA)
Zugriffsrechte auf Objekte des Agentensystems, die durch die
Integration der Wunsch-MA-Policy in die ZKI-Policy aufgenommen
wurden, werden bei der Migration der Agenteninstanz auf ein anderes Agentensystem bzw.
bei der Beendigung der Agenteninstanz wieder aus der ZKI-Policy entfernt.
d) Zugriffsrechte für Objekte eines Agenten (Vergabe MA)
Zugriffsrechte auf Objekte von Agenteninstanzen, welche durch die
Integration der Wunsch-MA-Policy vergeben wurden, werden nur solange
durchgesetzt, wie sich die Agenteninstanz auf dem Agentensystem befindet.
2) Rücknahme der Zugriffsrechte der Wunsch-MA-Policy:
Die in der Wunsch-MA-Policy enthaltenen Zugriffsrechte können einer Agenteninstanz
nicht entzogen bzw. auch nicht verändert werden.
Sie bleiben solange erhalten, bis die Agenteninstanz beendet wird.
Die Gültigkeitsdauer eines Zugriffsrechts innerhalb der Wunsch-MA-Policy kann
durch ein Datum beschränkt werden. Das Datum gibt dabei an,
bis wann das Zugriffsrecht gültig ist.
Aussagen, wer wann Zugriff auf welches Objekt
hat, sind somit über dieses Zeitfenster möglich. Die Rücknahme der Zugriffsrechte
einer Wunsch-MA-Policy muss somit im Voraus bestimmt werden.
Um innerhalb der Wunsch-MA-Policy Änderungen bezüglich der Zugriffsrechte vorzunehmen,
muss die Agenteninstanz auf ihr Home-Agentensystem migrieren.
Nach der Modifikation muss die Wunsch-MA-Policy wiederum durch den
Eigentümer der Agenteninstanz signiert werden.
Einschränkungen bezüglich der Rücknahme der Berechtigungen
Wird eine Berechtigung zurückgenommen während ein
Zugriff stattfindet, so hat die Rücknahme für diesen Zugriff keine Auswirkungen.
Die Delegation muss jedoch ebenfalls kontrollierbar sein, so dass die Informationssicherheit nicht gefährdet ist. Die Delegation der Zugriffsrechte ist auf drei Arten möglich:
1. Explizite Berechtigung
Die Delegation der Rechte in MASA, also die Weitergabe von
Zugriffsrechten von Agenteninstanzen an Agenteninstanzen,
kann durch die Weitergabe der Wunsch-MA-Policy von einer Agenteninstanz an eine
weitere Agenteninstanz realisiert werden.
Die Agenteninstanz, welche die Wunsch-MA-Policy erhalten hat, kann sie dem Agentensystem zur Integration vorlegen und so die innerhalb der Wunsch-MA-Policy vergebenen Zugriffsrechte durchsetzen, wenn sie von dem Agentensystem akzeptiert werden.
Ein Eintrag innerhalb der Wunsch-MA-Policy kann Zugriffsrechte enthalten, die
die Agenteninstanz, die die Wunsch-MA-Policy empfängt, explizit adressiert.
Ebenso können Zugriffsrechte enthalten sein, die spezifische
Eigenschaften der Agenteninstanz adressiert (z.B. die Agentengattung), so
dass die Agenteninstanz durch die Integration der Wunsch-MA-Policy die
ihr in der Wunsch-MA-Policy zugeteilten Zugriffsrechte erlangt.
Ist beispielsweise die Agenteninstanz [ma-1] nicht
autorisiert den Netzverkehr auf dem Agentensystem des Hersteller
zu messen, kann eine weitere Agenteninstanz [ma-2] durch ihre Wunsch-MA-Policy
ein Zugriffsrecht vergeben, welches die Agenteninstanz für den
Zugriff berechtigt. Somit kann der Agenteninstanz
das Messen des Netzverkehrs ermöglicht werden.
Die zentrale Agenteninstanz kontrolliert in diesem Fall ob das Zugriffsrecht
durchgesetzt werden kann. Dabei werden Sicherheitsvorkehrungen der
Agenteninstanz und des Agentensystems berücksichtigt.
In der Wunsch-MA-Policy können die Zugriffsrechte der Agenteninstanz und der
für die Erledigung der Aufgabe involvierten weiteren Agenteninstanzen
vergeben werden.
2. Delegation durch Vertrauen des Agentensystems
Migriert eine Agenteninstanz [ma-1] auf ein Agentensystem, ist der Anwender der
Agenteninstanz bekannt. Dies kann z.B. eine weitere Agenteninstanz [ma-2] sein.
Greift nun die Agenteninstanz [ma-2] auf eine Ressource zu, wozu jedoch
nur die Agenteninstanz [ma-1] berechtigt wäre, kann das Agentensystem den
Zugriff gewähren lassen. Die Gewährung hängt von der Zugriffskontrollpolitik
des Agentensystems und dem Vertrauen zu der Agenteninstanz ab.
Um die Vergabe der Zugriffsrechte der Agenteninstanzen nach dem Least-Privilege Prinzip
zu vergeben, kann die Wunsch-MA-Policy in Abschnitte der Agentensysteme unterteilt werden.
Jeder Abschnitt wird dabei nach einem Agentensystem benannt, welches nur
die in diesem Abschnitt vorhandenen Zugriffsrechte bei der Integration berücksichtigt.
3. Delegation der Zugriffsrechte durch explizite Weitergabe durch das Agentensystem
Die letzte Form der Delegationsmöglichkeit ist die Autorisation einer
Agenteninstanz durch das Agentensystem.
Beispielsweise kann es vorkommen, dass ein Agentensystem selbst nicht in der Lage ist,
die von der Agenteninstanz geforderte Aufgabe zu bearbeiten, jedoch
ein weiteres Agentensystem konsultieren kann, welches dazu in der Lage ist.
Das Agentensystem kann daher die Migration der Agenteninstanz auf das entsprechende
Agentensystem veranlassen. Damit die Agenteninstanz auf diesem Agentensystem ebenfalls
über die notwendigen Berechtigungen verfügt, kann nun das Agentensystem
eine zusätzliche Wunsch-MA-Policy für die Agenteninstanz
erzeugen. Diese zusätzliche Wunsch-MA-Policy enthält dabei die Berechtigung, die
die Agenteninstanz benötigt, um auf dem weiteren Agentensystem die Aufgabe erledigen
zu können. Damit das weitere Agentensystem erkennt, dass es sich quasi um eine
Delegation der Aufgabenerledigung handelt, wird die zusätzliche Wunsch-MA-Policy
von dem Agentensystem, welches die Aufgabe delegiert, mit dem Private Key
des Agentensystems unterzeichnet.
Die zusätzliche Wunsch-MA-Policy enthält neben den Zugriffsrechten den Namen der Agenteninstanz.
Zu unterscheiden sind dabei Änderungen durch das Agentensystem und Änderungen,
die durch die Verknüpfung einer Wunsch-MA-Policy erfolgen. Ebenfalls unterschieden
werden muss, ob es sich bei den Zugriffsrechten um Berechtigung für den Zugriff
auf Objekte des Agentensystems oder um Objekte einer Agenteninstanz handelt.
1) Änderungen durch das Agentensystem
a) betreffend der AS-Objekte
Das Agentensystem bestimmt innerhalb der AS-Policy, wer berechtigt ist,
Änderungen bezüglich der Zugriffsrechte für Objekte des Agentensystems
innerhalb der AS-Policy vorzunehmen. Enthält die AS-Policy kein
Zugriffsrecht, welches einem Subjekt erlaubt, Änderungen an der AS-Policy
vorzunehmen, so darf nur der Eigentümer des Agentensystems Änderungen an
der AS-Policy vornehmen.
b) betreffend der MA-Objekte
Das Agentensystem vergibt keine Zugriffsrechte auf Objekte von Agenteninstanzen.
Die Agenteninstanz alleine vergibt Zugriffsrechte auf ihre Objekte. Die
Zugriffsrechte sind in der Wunsch-MA-Policy enthalten.
2) Änderung durch die Integration der Wunsch-MA-Policy
a) betreffend der AS-Objekte
Zugriffsrechte, welche die Objekte des Agentensystems betreffen, können nur von
einer durch ihre Signatur berechtigten Wunsch-MA-Policy vorgenommen werden.
Zudem durchlaufen diese Zugriffsrechte den Filter des Agentensystems, wobei
dadurch die Restriktionen des Agentensystems beachtet werden.
b) betreffend der MA-Objekte
Sollen Zugriffsrechte durchgesetzt werden, welche sich auf Objekte einer
Agenteninstanz beziehen, so dürfen in erster Linie nur Zugriffsrechte auf Objekte der
eigenen Agenteninstanz vergeben werden.
Zugriffsrechte bezüglich Objekten anderer Agenteninstanzen werden erst
durchgesetzt, nachdem die jeweilige MA-Filter-Policy berücksichtigt wurde.
Explizite Zugriffsrechte für Zugriffskontrollpolitiken
Um Änderungen der Zugriffskontrollpolitiken kontrollieren zu können, werden
Zugriffsrechte, die das Modifizieren der AS-Policy, der Wunsch-MA-Policy und der
Filter-Policy erlauben, eingeführt. Eine Änderung der Zugriffskontrollpolitiken
ist jeweils nur dann gestattet, wenn das notwendige Zugriffsrecht vorhanden ist.
Die Zugriffsrechte sind ebenfalls feingranular adressierbar, damit
beispielsweise einer Agenteninstanz erlaubt werden kann, nur
Zugriffsrechte zur Änderung der Zugriffskontrollpolitik bezüglich ihrer
Objekte zu vergeben.
Zugriffsrecht: Änderung der AS-Policy (betreffend AS-Objekte) durch eine Person
Das Zugriffsrecht zur Änderung der Zugriffsrechte in der AS-Policy, die
Objekte des Agentensystems enthalten, hat die Form:
![\includegraphics [totalheight=0.2\textheight]{recht-autorisierung-1.eps}](img41.gif)
![\includegraphics [totalheight=0.2\textheight]{recht-ma-as-policy-1.eps}](img42.gif)
![\includegraphics [totalheight=0.16\textheight]{recht-ma-integr-ma-obj-dyn.eps}](img43.gif)
![\includegraphics [totalheight=0.2\textheight]{recht-ma-integration.eps}](img44.gif)
![\includegraphics [totalheight=0.16\textheight]{recht-filter.eps}](img45.gif)
![\includegraphics [totalheight=0.2\textheight]{recht-ma-integr-ablauf.eps}](img46.gif)
permission AsAccessPolicyAsPermission ("target", "action")
Folgende Aktionen sind möglich:
Das Target bezeichnet dabei das Objekt, für das die Zugriffsrechte vergeben
werden dürfen.
Zugriffsrecht: Änderung der AS-Policy (betreffend AS-Objekte) durch MA
Änderungen können nur vorgenommen werden, wenn die AS-Filter-Policy
dies zulässt.
Zugriffsrechte: Änderung der AS-Policy (betreffend MA-Objekte) durch AS
Das Agentensystem vergibt keine Zugriffsrechte, welche Zugriffe
auf Objekte von Agenten autorisieren.
Zugriffsrechte: Änderung der AS-Policy (betreffend MA-Objekte) durch MA
Änderungen können nur vorgenommen werden, wenn die zuständige MA-Filter-Policy
dies zulässt.
Die zentrale Kontrollinstanz (ZKI) überprüft vor dem eigentlichen Zugriff,
ob das zugreifende Subjekt die notwendige Berechtigung für den Zugriff besitzt.
Hierfür werden die ZKI-Policy nach dem spezifischen Zugriffsrecht
durchsucht. Wird kein entsprechendes Zugriffsrecht gefunden, wird der Zugriff
nicht erlaubt.
Die ZKI-Policy wird dabei wie folgt durchsucht:
Angaben innerhalb der Wunsch-MA-Policy, welches Agentensystem die Zugriffsrechte durchsetzen soll, werden dabei berücksichtigt.
Der mobile Agent des Providers ma-p-messen migriert auf
das Agentensystem des Händlers as-haendler (1) und nimmt dort
Messungen des Netzdurchsatzes vor (2).
Der mobile Agent ma-p-messen kehrt auf das
Agentensystem as-provider zurück (3), um dort die
Resultate der Messungen in das Verzeichnis /results/
abzuspeichern (4).
Die in den Beispielszenarios getätigten Zugriffe werden mithilfe
der in Kapitel 6.4 definierten Modellierungssprache modelliert.
Folgende Zugriffe finden statt :
![\includegraphics [totalheight=0.35\textheight]{recht-bspszenario-einl-2.eps}](img47.gif)
(Zugriff: 1)
[as: as.provider.provider.mnm](
(subject, as.haendler.haendler.mnm) ->
(object, ma.provider.provider.mnm.messe.(as.provider.provider.mnm)) |
(action, migrateTo(as.haendler.haendler.mnm)))
(Zugriff: 2)
[as: as.haendler.haendler.mnm](
(subject, ma.provider.provider.mnm.messe.(as.provider.provider.mnm,
as.haendler.haendler.mnm)) ->
(object, socket-haendler-hersteller:4223) |
(action, durchsatzmessen))
(Zugriff: 3)
[as: as.haendler.haendler.mnm](
(subject, as.haendler.haendler.mnm) ->
(object, ma.provider.provider.mnm.messe.(as.provider.provider.mnm,
as.haendler.haendler.mnm)) |
(action, migrateTo(as.provider.provider.mnm)))
(Zugriff: 4)
[as: as.provider.provider.mnm](
(subject, ma.provider.provider.mnm.messe.(as.provider.provider.mnm,
as.haendler.haendler.mnm)) ->
(object, /results/erg-haendler) |
(action, write))
Benötigte Zugriffsrechte:
Betrachtet man die Modellierung der Zugriffe, so sind folgende
Zugriffsrechte notwendig:
Zugriffsrechte die durch die ZKI des Agentensystems des Providers durchgesetzt werden müssen
Zugriffsrechte der Zugriffskontrollpolitik des Agentensystems [as.provider.provider.mnm]:
grant ma.provider.provider.mnm.[visit as.provider.provider.mnm] {
permission masa.AsPermission ("as.haenlder.haendler.mnm", "migrateTo")
} (1a)
grant ma.provider.provider.mnm.messe.[visit as.provider.provider.mnm,
visit as.haendler.haendler.mnm] {
permission masa.AsPermission ("as.provider.provider.mnm", "migrateFrom")
} (3b)
grant ma.provider.provider.mnm.messe.[visit as.provider.provider.mnm
visit as.haendler.haendler.mnm] {
permission java.security.FilePermission ("/results/*", "write")
} (4)
Zugriffsrechte die durch die ZKI des Agentensystems des Händler durchgesetzt werden müssen
Zugriffsrechte der Zugriffskontrollpolitik des Agentensystems [as.haendler.haendler.mnm]:
grant ma.provider.provider.mnm.messe.[visit as.provider.provider.mnm] {
permission masa.AsPermission ("as.provider.provider.mnm", "migrateFrom")
} (1b)
grant ma.provider.provider.mnm.messe.[visit as.provider.provider.mnm] {
permission masa.AsPermission ("socket-h-hersteller:4223", "durchsatzMessen")
} (2)
grant ma.provider.provider.mnm.messe.[visit as.provider.provider.mnm,
visit as.haendler.haendler.mnm] {
permission masa.AsPermission ("as.provider.provider.mnm", "migrateTo")
} (3a)
Das Zugriffsrecht (1a) des Agentensystems des Providers gestattet der Agenteninstanz
ma-provider auf das Agentensystem des Händlers zu migrieren. Im Gegensatz dazu
gestattet das Zugriffsrecht (1b) des Agentensystems des
Händlers, die Agenteninstanz ma-provider auszuführen.
Das Zugriffsrecht (2) erlaubt zudem den Zugriff auf den Socket,
auf welchem die Agenteninstanz die Aktion durchsatzmessen zum Messen
des Durchsatzes durchführen darf. Die Zugriffsrechte (3a) und (3b)
ermöglichen wieder die Rückkehr der Agenteninstanz zum Agentensystem des
Providers, wobei das Zugriffsrecht abhängig von der History der
Agenteninstanz ist.
Werden die oben genannten Zugriffsrechte durch die zentrale Kontrollinstanz (ZKI) des
jeweiligen Agentensystems durchgesetzt, können alle Aktionen ausgeführt werden.
Zudem ist durch die Betrachtung der History der Agenteninstanz sichergestellt,
dass Zugriffsrechte nur an Agenteninstanzen vergeben werden, denen aufgrund
ihrer Vergangenheit noch getraut werden kann.
Damit kann ausgeschlossen werden, dass nicht vertrauenswürdige Agentensysteme die
Agenteninstanz modifiziert haben.
Möglichkeiten der Autorisation durch die AS-Policy und der Wunsch-MA-Policy
Die notwendigen Zugriffsrechte können innerhalb der AS-Policy vergeben werden oder
aber auch als Zugriffsrechte innerhalb der Wunsch-MA-Policy.
Fehlen notwendige Zugriffsrechte innerhalb der AS-Policy, so können, abhängig von
der AS-Filter-Policy des Agentensystems, die Zugriffsrechte der
Wunsch-MA-Policy durch das Agentensystem durchgesetzt werden und somit die
Bearbeitung der Aufgabe durch die Agenteninstanz ermöglichen.
Fehlen innerhalb der AS-Policy benötigte Zugriffsrechte und sind diese innerhalb
der Wunsch-MA-Policy vergeben, ist die erfolgreiche Bearbeitung der Aufgabe der Agenteninstanz
abhängig von den einzelnen Filter-Politiken. Nur die
vom Agentensystem akzeptierten Zugriffsrechte werden von der ZKI durchgesetzt.
Sind die benötigten Zugriffsrechte innerhalb der AS-Policy vorhanden,
ist die Bearbeitung der Aufgabe durch die Agenteninstanz sichergestellt.
Die spezifische Vergabe der Zugriffsrechte innerhalb der AS-Policy bedeutet jedoch
einen höheren Aufwand, da der Eintrag des benötigten Zugriffsrechts bei jedem Agentensystem,
auf dem die Agenteninstanz die Aufgabe bearbeiten muss, zu erfolgen hat.
Durch die unterschiedlichen Autorisationsmöglichkeiten kann ein Kompromiss zwischen
Informationssicherheit, Verwaltungsaufwand und Funktionalität getroffen werden.
Ein Agentensystem kann beispielsweise die jeweiligen Zugriffsrechte der Wunsch-MA-Policies überhaupt nicht betrachten und Zugriffe nur auf Basis der AS-Policy überprüfen. Hier wird also keiner Agenteninstanz getraut, wodurch die Funktionalität der Agenteninstanzen stark eingeschränkt sein kann.
Andererseits kann ein Agentensystem auch allen Agenteninstanzen trauen und jedes
Zugriffsrecht der Wunsch-MA-Policy akzeptieren.
Damit ist die Funktionalität der
Aufgabenbearbeitung einer jeden Agenteninstanz sichergestellt.
Jedoch besteht hier die Möglichkeit der Durchsetzung eines für das
Agentensystem kritischen Zugriffsrechts.
Das Agentensystem kann die Vergabe spezifischer Zugriffsrechte durch den
Einsatz des Filters mittels der AS-Filter-Policy unterbinden.
Das Zugriffsrecht (2) auf dem Agentensystem des Händlers stellt beispielsweise ein für ein Agentensystem kritisches Zugriffsrecht dar, während die Zugriffsrechte (1b) und (3a) in der Regel weniger kritisch für das Agentensystem sind.
Der Zugriff auf ein Socket sollte aus Sicht des Agentensystems nicht jede
Agenteninstanz erlangen können. Daher ist es wahrscheinlich, dass diese Zugriffsrechte
beispielsweise durch die AS-Filter-Policy unterbunden werden und so nur
explizit durch das Agentensystem mittels der AS-Policy vergeben werden können.
Doch gerade bei expliziten Zugriffsrechten, die beispielsweise nur ein
Subjekt adressieren, ist der Verwaltungsaufwand relativ hoch und bei
zunehmender Anzahl der Subjekte schnell unpraktikabel.
Hier empfiehlt sich der Einsatz der Wunsch-MA-Policy zur Vergabe der notwendigen
Zugriffsrechte.
Aus Sicht des Agentensystems können spezifische Wunsch-MA-Policies entsprechend autorisiert und somit auch durchgesetzt werden.
Die Agenteninstanz des Providers ma-p-messen migriert auf
das Agentensystem des Händlers as-haendler (1) und nimmt dort
Messungen des Netzdurchsatzes vor (2).
Die Agenteninstanz ma-p-messen erteilt dem
Agentensystem as-haendler den Auftrag eine Agenteninstanz
der Gattung messen zu erzeugen (5),
die den Netzdurchsatz auf dem Agentensystem as-hersteller messen
soll (6).
Hierfür muss eine Agenteninstanz des Händlers ma-h-messen auf das
Agentensystem des Herstellers as-hersteller migrieren (7)
und dort ebenfalls Messungen vornehmen (8).
Die Agenteninstanz ma-p-messen kehrt auf das
Agentensystem as-provider zurück (3), um dort die
Resultate der Messungen in das Verzeichnis /results/
abzuspeichern (4).
Die Agenteninstanz des Händlers ma-h-messen migriert dann
ebenfalls nach der Beendigung der Messung auf das Agentensystem
des Providers as-provider (9) und speichert die
Ergebnisse ebenfalls in das Verzeichnis /results/ (10).
Folgende Zugriffe finden statt:
![\includegraphics [totalheight=0.4\textheight]{recht-bspszenario-2.eps}](img48.gif)
(1)
[as: as.provider.provider.mnm](
(subject, as.haendler.haendler.mnm) ->
(object, ma.provider.provider.mnm.messe.(as.provider.provider.mnm)) |
(action, migrateTo(as.haendler.haendler.mnm)))
(2)
[as: as.haendler.haendler.mnm](
(subject, ma.provider.provider.mnm.messe.(as.provider.provider.mnm,
as.haendler.haendler.mnm)) ->
(object, socket-haendler-hersteller:4223) |
(action, durchsatzmessen))
(3)
[as: as.haendler.haendler.mnm](
(subject, as.haendler.haendler.mnm) ->
(object, ma.provider.provider.mnm.messe.(as.provider.provider.mnm,
as.haendler.haendler.mnm)) |
(action, migrateTo(as.provider.provider.mnm)))
(4)
[as: as.provider.provider.mnm](
(subject, ma.provider.provider.mnm.messe.(as.provider.provider.mnm,
as.haendler.haendler.mnm)) ->
(object, /results/erg-haendler) |
(action, write))
(5)
[as: as.haendler.haendler.mnm](
(subject, ma.provider.provider.mnm.messe.(as.provider.provider.mnm,
as.haendler.haendler.mnm)) ->
(object, as.haendler.haendler.mnm) |
(action, createAgent(ma.haendler.haendler.mnm.messe)))
(6)
[as: as.haendler.haendler.mnm](
(subject, ma.provider.provider.mnm.messe.(as.provider.provider.mnm,
as.haendler.haendler.mnm)) ->
(object, ma.haendler.haendler.mnm.messe.(as.haendler.haendler.mnm)) |
(action, auftrag(messung(as.hersteller.hersteller.mnm))))
(7)
[as: as.haendler.haendler.mnm](
(subject, as.haendler.haendler.mnm) ->
(object, ma.haendler.haendler.mnm.messe.(as.haendler.haendler.mnm)) |
(action, migrateTo(as.hersteller.hersteller.mnm))
(8)
[as: as.hersteller.hersteller.mnm](
(subject, ma.haendler.haendler.mnm.messe.(as.haendler.haendler.mnm,
as.hersteller.hersteller.mnm)) ->
(object, socket-hersteller-haendler:4223) |
(action, durchsatzmessen))
(9)
[as: as.hersteller.hersteller.mnm](
(subject, as.hersteller.hersteller.mnm) ->
(object, ma.haendler.haendler.mnm.messe.(as.haendler.haendler.mnm,
as.hersteller.hersteller.mnm)) |
(action, migrateTo(as.provider.provider.mnm))
(10)
[as: as.provider.provider.mnm](
(subject, ma.haendler.haendler.mnm.messe.(as.haendler.haendler.mnm,
as.hersteller.hersteller.mnm)) ->
(object, /results/erg-hersteller) |
(action, write))
Benötigte Zugriffsrechte die durch die ZKI der Agentensysteme durchgesetzt werden müssen
Um die oben aufgeführten Zugriffe durchführen zu dürfen, müssen die
folgenden Zugriffsrechte durch die ZKI der einzelnen Agentensysteme
durchgesetzt werden. Es werden die minimal benötigen
Zugriffsrechte der Agentensysteme aufgeführt (Least-Privilege Prinzip).
Die History der Agenteninstanzen
wird jedoch nicht betrachtet. Die Zugriffsrechte enthalten deshalb als Eintrag
( visit *), was zum Ausdruck bringt, dass der Agent vorher beliebige
Agentensysteme besucht haben darf.
ZKI-Policy des Agentensystems: as.provider.provider.mnm
grant ma.provider.provider.mnm.[visit *] {
permission masa.AsPermission ("as.haendler.haendler.mnm", "migrateTo")
} (1a)
grant ma.provider.provider.mnm.messe.[visit *] {
permission java.secuity.FilePermission ("/results/*", "write")
} (4)
grant ma.provider.provider.mnm.messe.[visit *] {
permission masa.AsPermission ("as.haendler.haendler.mnm", "migrateFrom")
} (3b)
grant ma.haendler.haendler.mnm.messe.[visit *] {
permission masa.AsPermission ("as.hersteller.hersteller.mnm", "migrateFrom")
} (9b)
grant ma.haendler.haendler.mnm.messe.[visit *] {
permission java.security.FilePermission ("/results/*", "write")
} (10)
ZKI-Policy des Agentensystems: as.hersteller.hersteller.mnm
grant ma.haendler.haendler.mnm.[visit *] {
permission masa.AsPermission ("as.haendler.haendler.mnm", "migrateFrom")
} (7b)
grant ma.haendler.haendler.mnm.messe.[visit *] {
permission masa.AsPermission ("socket-h-haendler:4223", "durchsatzMessen")
} (8)
grant ma.haendler.haendler.mnm.[visit *] {
permission masa.AsPermission ("as.provider.provider.mnm", "migrateTo")
} (9a)
ZKI-Policy des Agentensystems: as.haendler.haendler.mnm
grant ma.provider.provider.mnm.messe.[visit *] {
permission masa.AsPermission ("as.provider.provider.mnm", "migrateFrom")
} (1b)
grant ma.provider.provider.mnm.messe.[visit *] {
permission masa.AsPermission ("socket-h-hersteller:4223", "durchsatzMessen")
} (2)
grant ma.provider.provider.mnm.messe.[visit *] {
permission masa.AsPermission ("ma.haendler.haendler.mnm.messe.
[as.haendler.haendler.mnm]", "createAgent")
} (5)
grant ma.provider.provider.mnm.messe.[visit *] {
permission masa.agentMesse.MaPermission ("as.hersteller.hersteller.mnm",
"durchsatzMessen")
} (6)
grant ma.haendler.haendler.mnm.messe.[visit *] {
permission masa.AsPermission ("as.hersteller.hersteller.mnm", "migrateTo")
} (7a)
grant ma.provider.provider.mnm.messe.[visit *] {
permission masa.AsPermission ("as.provider.provider.mnm", "migrateTo")
} (3a)
Um die Möglichkeit der Weitergabe von Zugriffsrechten zu verdeutlichen, soll das Beispielszenario 1 aus Kapitel 1 betrachtet werden, wobei beim Agentensystem as-hersteller folgendes, zum Messen des Durchsatzes notwendiges Zugriffsrecht (perm-ma-h-messen) fehlt:
grant ma.haendler.haendler.mnm.messe.[visit *] {
permission masa.AsPermission ("socket:4223", "durchsatzMessen")
} (8)
Migriert die Agenteninstanz
ma.haendler.haendler.mnm.messe(as.haendler.haendler.mnm) auf das
Agentensystem as.hersteller.hersteller.mnm und versucht dort auf
das Socket socket:4223 zuzugreifen, um den
Durchsatz zu messen, wird aufgrund des fehlenden Zugriffsrechts
der Zugriff vom Agentensystem des Herstellers nicht zugelassen.
Nun können folgende Delegationsmöglichkeiten genutzt werden (vgl. Kapitel 6.9):
Beispiel eines Filter-Policy Eintrags, der die Integration nicht erlaubt:
In diesem Beispiel wird jeder Agenteninstanz verboten, das entsprechende
Zugriffsrecht zu setzen.
![\includegraphics [totalheight=0.35\textheight]{recht-delegation-perm-ma-h-messen.eps}](img49.gif)
\\
\\ Filter-Policy
\\
forbid ma.*.*.*.*.*.* {
[
grant signedBy "Netztester" {
permission masa.AsPermission ("socket:4223", "durchsatzMessen")
}
]
}
Beispiel eines AS-Policy Eintrags, der den Zugriff erlaubt:
\\
\\ AS-Policy
\\
grant ma.haendler.provider.*.*.[visit as.haendler.haendler.mnm] {
permission masa.AsPermission ("socket:4223", "durchsatzMessen")
}
In diesem Kapitel werden die konkreten Techniken vorgestellt, die eine Umsetzung des entwickelten Modells ermöglichen.
Die checkPermission()-Methode des AccessControllers entscheidet, ob bei einem Zugriff die notwendige Berechtigung vorliegt. Der folgende Aufruf entscheidet beispielsweise, ob der lesende Zugriff auf die Temp-Datei erlaubt wird oder nicht:
FilePermission perm = new FilePermission("/temp/Datei", "read");
AccessController.checkPermission(perm);
Durch die System Security Policy können Zugriffsrechte auf spezifische Objekte vergeben werden.
Zugriffsrechte können zur Laufzeit geändert werden. Damit die Änderung
wirksam wird, muss das Policy-Objekt neuinitialisiert werden.
Hierfür steht die refresh()-Methode des Policy-Objekts zur Verfügung.
Für die Bestimmung der Zugriffsrechte eines Programms, werden
bei dem Einsatz der Default Policy Klasse PolicyFile die Einträge der
System Security Policy durchsucht und mit der CodeSource des aufrufenden
Programms verglichen.
Die in den Einträgen, die mit der CodeSource übereinstimmen, vorhandenen
Permission-Objekte, bilden das Permissions-Objekt der
ProtectionDomain [OAK 00,GON 98,IBM 99b,ACC02].
CodeSource
Die CodeSource ist in der Standard Java Implementierung ein einfaches Objekt, welches
lediglich die Herkunftsadresse der Klasse in Form einer URL und der Signatur der
Klasse, falls vorhanden, widerspiegelt. Die SecureClassLoader-Klasse
ist verantwortlich für die Erstellung und Manipulation des CodeSource-Objekts [COS02].
Während bei der Benutzung des URLClassLoaders jede URL ein unterschiedliches
CodeSource-Objekt bekommt, besteht auch die Möglichkeit, dass jede Klasse ein eigenes
CodeSource-Objekt besitzt, bzw. dass verschiedene Gruppen von Klassen derselben
Herkunft (URL) verschiedene CodeSource-Objekte haben.
Permissions
Der Access Controller operiert auf Permission-Objekten. Ein Permission-Objekt
ist eine Instanz der Permission-Klasse.
Ein Permission-Objekt assoziiert mit einer Klasse repräsentiert die Berechtigungen
der Klasse.
Der AccessController überprüft, ob das notwendige Permission-Objekt in
der betreffenden ProtectionDomain vorhanden ist. Zur Überprüfung wird die
implies()-Methode, die von dem betreffenden Permission-Objekt
implementiert wird, herangezogen. Die implies()-Methode überprüft, ob ein
Permission-Objekt das notwendige Permission-Objekt impliziert.
Bei dem folgenden Check-Aufruf überprüft der AccessController mittels der implies()-Methode der SocketPermission, ob der String `` host:6000, connect'' innerhalb der Policy vorhanden ist. Die Methode legt außerdem fest, welche weiteren String-Formen diese Berechtigung implizieren.
SocketPermission sp = new SocketPermission(host:6000, connect); AccessController.checkPermission(sp);
Die Permissions enthalten für jeden Typ einer Permission
(z.B. FilePermission) eine PermissionCollection. Die
PermissionCollection enthält dabei jede Permission, die demselben Typ
entsprechen. Dadurch wird die Abfrage, ob ein Subjekt eine
entsprechende Permission besitzt, erleichtert.
System Security Policies
In der Default Konfiguration der Java 2 Security Architecture wird die Policy-Klasse durch
die PolicyFile-Klasse (sun.security.provider.PolicyFile)
repräsentiert, wobei Zugriffe in der default Einstellung
durch Einträge in eine ASCII-Datei, der System Security Policy, autorisiert werden können.
Es kann nur eine Instanz der Policy-Klasse geben, welche jedoch im
Gegensatz zum SecurityManager ausgetauscht werden kann.
Die System Security Policy bildet die CodeSource auf Permissions ab. Geht man davon
aus, dass durch den CodeSource das Subjekt adressiert wird und durch
die Permission das Objekt und die betreffende Aktion, so wird auf
Basis der Security Policy dem Subjekt die Berechtigung erteilt, auf ein Objekt
mittels der spezifischen Aktion zuzugreifen.
Die System Security Policy wird durch eine oder mehrere
persistente Policy Konfigurationen repräsentiert.
Jede Policy Konfiguration kann dabei als eine ASCII-Datei, als eine serialisierte
binäre Datei der Policy-Klasse oder in einer Datenbank gespeichert sein.
Die Policy-Klasse konstruiert die Permissions anhand der Policy Konfiguration.
Die Zugriffsrechte werden durch Einträge spezifiziert.
Ein Eintrag enthält dabei die Informationen, die zur Erzeugung einer
ProtectionDomain (CodeSource) und den zu dieser ProtectionDomain
zugehörigen Zugriffsrechten herangezogen werden [POL 00].
Innerhalb der Security Policy sind Permissions, und innerhalb der Permissions
sind Operationen eingekapselt.
ProtectionDomain
Eine ProtectionDomain entspricht einem CodeSource und die Gruppe von
Permissions, welche dem CodeSource ereilt worden ist.
Eine ProtectionDomain enthält demnach alle Zugriffsrechte für ein bestimmtes Subjekt
auf Objekte in einer speziellen Art und Weise zuzugreifen.
Jede Klasse bekommt eine einzige ProtectionDomain zugewiesen, welche von dem ClassLoader gesetzt wird. Der ClassLoader ruft entsprechend die getPermission(CodeSource)-Methode auf, welche die für diese CodeSource in der Policy-Datei definierten Permissions zurückliefert. Mit der zugewiesenen ProtectionDomain stehen somit auch die zugeteilten Permissions zur Verfügung.
Als Rückgabewert erhält der Lader vom Policy-Objekt das PermissionCollection-Objekt der jeweiligen Entität. Dieses PermissionCollection-Objekt wird zusammen mit der CodeSource der Entität zur Erzeugung der spezifischen ProtectionDomain verwendet.
policy = Policy.getPolicy(); PermissionCollection perms = policy.getPermissions(CodeSource)Bei dem Aufruf wird die CodeSource der ProtectionDomain (CodeBase (URL) und Schlüssel Attribute) mitgeteilt. Das Policy-Objekt durchsucht (parst) daraufhin die globale Policy und liefert auf Basis der Policy Konfiguration das Permissions-Objekt zurück.
Das Policy-Objekt kann durch den setPolicy()-Aufruf ausgetauscht werden. Hierfür wird jedoch eine spezifische Berechtigung benötigt. Das aktuelle Policy-Objekt bekommt man mittels der getPolicy()-Methode. Die refresh()-Methode initialisiert die Konfigurationen des Policy-Objekts erneut. Werden die Policy Konfigurationen beispielsweise in Dateien gespeichert, so werden diese Dateien bei dem refresh()-Methodenaufruf erneut gelesen. Abhängig von gegebenen Cache-Strategien kann der refresh()-Methodenaufruf keine Auswirkungen auf schon geladene Klassen haben [POL 00].
Die combine()-Methode enthält zwei Argumente.
Das erste Argument enthält die ProtectionDomains des aktuellen
execution-Thread und das zweite Argument enthält die
ProtectionDomains des Parent-Thread.
Die combine()-Methode liefert als Ergebnis eine modifizierte ProtectionDomain. Durch den Einsatz des DomainCombiner können ProtectionDomains der auf dem Stack befindlichen Klassen modifiziert werden. Dem Execution-Thread können durch die combine-Methode ProtectionDomains hinzugefügt werden oder es können spezifische ProtectionDomains entfernt werden. Weiterhin besteht die Möglichkeit, nur einzelne individuelle ProtectionDomains zu modifizieren. Einer ProtectionDomain können so beispielsweise neue Permissions zugewiesen werden.
Bei den einzelnen Schnittstellen muss einerseits die Überwachung der eigenen Schnittstellen und die Überwachung fremder Schnittstellen, das sind Schnittstellen, die von einer anderen als der überwachenden Entität implementiert werden, unterschieden werden.
Bei jedem Zugriff entscheidet die ZKI, ob die Aktion ausgeführt werden darf
oder nicht. Um eine Entscheidung treffen zu können, besitzt die ZKI eine
Schnittstelle, mit der abgefragt werden kann, ob der Zugriff eines bestimmten
Subjekts erlaubt ist.
Betrachtet man die zentralen Aufgaben der ZKI, nimmt sie die Stellung der
globalen Policy der JVM ein.
Die ZKI implementiert dabei, um die feingranularen Zugriffskontrollentscheidungen
treffen zu können, die eingeführte Policy-Sprache.
Eigene CORBA Schnittstellen
Die Methoden, die die einzelnen Funktionen der Schnittstelle implementieren,
werden überwacht, indem vor der eigentlichen Ausführung der Methode
die Berechtigung des zugreifenden Subjekts überprüft wird.
Dies geschieht, indem die ZKI befragt wird. Die Entscheidung der ZKI basiert
auf den innerhalb der ZKI-Policy enthaltenen Einträgen.
Fremde CORBA Schnittstellen
Wird eine Funktion der CORBA-Schnittstelle einer Agenteninstanz aufgerufen,
führt die ORB-Instanz die entsprechende Methode der Agenteninstanz aus.
Der ORB muss daher explizit die ZKI nach der Entscheidung, ob der
Zugriff zugelassen ist oder nicht, befragen.
Der ORB müsste, um dies bewerkstelligen zu können, die Access Decision-Objekte
des Security Functionality Level 2 unterstützen [MAF 00, Kapitel 2.4].
Der in MASA eingesetzte ORB unterstützt diesen Level jedoch nicht, wodurch
die Zugriffskontrolle in dieser Art und Weise noch nicht implementiert werden
kann.
Schnittstellen des Endsystems
Die Schnittstellen des Endsystems werden durch das Java-API repräsentiert.
Um Entscheidungen bezüglich der Zugriffsrechte zu treffen, werden
Sicherheitsmechanismen von der Java 2 Security Architecture
in modifizierter Form verwendet.
Migriert eine Agenteninstanz auf das Agentensystem oder wird auf dem
Agentensystem eine Agenteninstanz gestartet, ermittelt die ZKI
anhand der definierten Eigenschaften der Agenteninstanz
(vgl. Kapitel 4.3),
die der Agenteninstanz durch die ZKI-Policy zugeteilten
Zugriffsrechte. Beim Ladevorgang der Agenteninstanz wird der Agenteninstanz
eine ProtectionDomain mit den ermittelten Zugriffsrechten zugewiesen.
Die CodeSource der ProtectionDomain ist die eindeutige
Kennzeichnung der Agenteninstanz auf dem Agentensystem.
Hierfür wird eine eigene CodeSource-Klasse für MASA implementiert.
Die Zugriffskontrolle von Zugriffe von Agenteninstanzen, die auf dem
Agentensystem ausgeführt werden, kann daher durch den
Einsatz des AccessControllers erfolgen.
Greift die Agenteninstanz auf eine Ressource zu, wird anhand der Zugriffsrechte der ProtectionDomain dieser Agenteninstanz entschieden, ob die notwendige Berechtigung vorhanden ist. Da die Zugriffsrechte durch den Einsatz der MASA Policy-Klasse anhand der definierten Eigenschaften einer Agenteninstanz ermittelt werden, erfolgt eine feingranulare Zugriffskontrolle.
Damit die ZKI-Policy von der JVM, die die Ablaufumgebung des Agentensystems darstellt, als systemglobale Policy durchgesetzt wird, müssen folgende spezifischen Einträge innerhalb der Java Security Property-Datei (``javahome''/lib/security/java.security) vorgenommen werden. Die Trennung der Politiken ist sinnvoll, um bei einem Zwischenfall die Durchsetzung der Agenteninstanz-Politiken unterbinden zu können.
# Agentensystem Policy
as-policy.url.1=file:{java.home}/lib/security/as.policy
# Policies der Agenteninstanzen
ma-policy.url.1=file:{java.home}/lib/security/ma.policies
Der erste Eintrag gibt den Ort der von der ZKI durchzusetzenden AS-Policy an.
Der zweite Eintrag bestimmt den Ort der MA-Policies-Datei, in die die
zulässigen Zugriffsrechte der einzelnen MA-Policy-Dateien integriert
werden. Betrachtet man die Vereinigungsmenge der Zugriffsrechte, so ergibt sich
die in dem Rechtekonzept dargestellte ZKI-Policy.
In dieser Implementierung werden die Konfigurationen der Politiken der Agentensysteme
und Agenteninstanzen in einer ASCII-Datei vorgenommen.
Die Einträge der ASCII-Datei entsprechen dabei der in Kapitel 6.3.2
eingeführten Policy-Sprache.
Die Realisation mittels der ASCII-Dateien stellt dabei
nur einen Lösungsweg dar. Die Implementierung kann ebenfalls mithilfe von
Datenobjekten realisiert werden, um nicht explizit in eine Datei schreiben
zu müssen.
Realisation der ZKI-Policy:
Überprüfung der MA-Policy ( agentPolicyCheck())
Für die Überprüfung der Zugriffsrechte einer MA-Policy
auf ihre Zulässigkeit hin, muss eine geeignete Methode ( agentPolicyCheck())
bereitgestellt werden, welche die Zugriffsrechte der MA-Policies
auf ihre Zulässigkeit hin überprüft. Die agentPolicyCheck()-Methode
setzt dabei die Restriktionen der AS-Filter-Policy des Agentensystems und
die betroffenen MA-Filter-Policies der Agenteninstanzen durch.
Als Resultat liefert die Methode die akzeptierten, von dem Agentensystem
durchzusetzenden Zugriffsrechte der MA-Policies.
Die agentPolicyCheck-Methode vergleicht jedes einzelne Zugriffsrecht der MA-Policy mit der zuständigen Filter-Politik. Ist das Zugriffsrecht innerhalb der Filter-Politik als unzulässig deklariert, wird es nicht in die ma.policies-Datei aufgenommen und daher nicht von der ZKI des Agentensystems durchgesetzt.
Handelt es sich um Zugriffsrechte bezüglich Zugriffen auf das Agentensystem
bzw. Endsystem, wird der Eintrag mit jedem einzelnen Eintrag des
Agentensystem-Filters (AS-Filter-Policy) verglichen.
Autorisiert das Zugriffsrecht der MA-Policy
einen Zugriff auf ein Objekt einer Agenteninstanz, so wird der
Filter dieser Agenteninstanz (MA-Filter-Policy) zum Vergleich herangezogen.
Damit die in die ma.policies-Datei hinzugefügten Zugriffsrechte
von der ZKI des Agentensystems durchgesetzt werden, muss das MASA Policy-Objekt
neu initialisiert werden. Das MASA Policy-Objekt stellt hierfür die
refresh()-Methode bereit.
Integration einer neuen MA-Policy ( combineAgentPolicies())
Für die Integration der akzeptierten Zugriffsrechte in die ma.policies-Datei
muss eine geeignete Methode bereitgestellt werden ( combineAgentPolicies()).
Die combineAgentPolicy()-Methode erweitert die ma.policies-Datei um
ein Zugriffsrecht und setzt zusätzlich für jedes Zugriffsrecht eine Marke.
Aus der Marke ist neben dem Zeitpunkt der Integration
auch die Agenteninstanz, welche das Zugriffsrecht integriert, ersichtlich.
Die Marke wird als Kommentar ( # MARKE (NOT EDIT): Marke)in die ma.policies Datei eingetragen. Die MASA Policy-Klasse wertet die Marke daher nicht aus.
Verlässt eine Agenteninstanz das Agentensystem bzw. wird eine Agenteninstanz beendet, können so die von der Agenteninstanz vorgenommenen Einträge wieder entfernt werden. Hierfür muss die Methode deleteAgentPermissions(agentAttributs) zur Verfügung gestellt werden. Die Methode sucht nach den jeweiligen Einträgen und entfernt diese aus der ma.policies-Datei. Durch einen erneuten refresh()-Aufruf werden die Änderungen von der ZKI übernommen.
# Filter Policy des Agentensystems
as-filter.url.1=file:{java.home}/lib/security/as.filter
# Filter Policy der Agenteninstanz
ma-filter.url.2=file:{java.home}/lib/security/ma.filters
Die Filter-Policy einer Agenteninstanz wird dabei zusammen mit der MA-Policy dem Agentensystem vor dem Laden der Agenteninstanz übergeben.
Durch den folgenden Eintrag innerhalb der Java Security Property Datei wird die Masa Policy-Klasse von der JVM als systemglobale Policy verwendet:
policy.provider=masa.security.provider.MASAPolicyFile
Die Klasse MASAPolicyFile wird von java.security.Policy abgeleitet. Damit wird die MASA Policy-Klasse in die Java 2 Security Architecture integriert.
Innerhalb der MASA Policy-Klasse müssen neben den Funktionalitäten, die die
Standard Policy-Klasse PolicyFile von Sun implementiert, bestehende Funktionen modifiziert
bzw. neue implementiert werden.
Durch das MASA Policy-Objekt sind folgende Funktionen zu realisieren:
Betrachtet man innerhalb der Java Security Property-Datei die Ortsangaben der durchzusetzenden Policy-Dateien, so sind hier die Änderungen bezüglich der as.policy- und der ma.policies-Dateien zu beachten. Zudem wird innerhalb dieser Datei die Lage der Filter-Politiken definiert.
Die Attributs-Objekte entsprechen der Funktionalität der CodeSource-Objekte der Standard Java 2 Security Architecture.
Die des agentAttributs-Objekts zugewiesenen Zugriffsrechte werden
durch die Methode getAgentPermissions(agentAttributs) ermittelt.
Auf Anfrage muss ebenso ein PermissionsCollection-Objekt auf Basis der AgentensystemAttributs- oder PersonAttributs-Objekte erzeugt werden.
Folgende Methoden liefern das jeweilige Permissions-Objekt:
getAgentensystemPermissions(agentsystemAttributs)
getPersonPermissions(personAttributs)
Eine Agenteninstanz wird jeweils durch einen eigenen AgentenClassLoader geladen. Jede Agenteninstanz kann so unterschieden und eine eigene eindeutige ProtectionDomain zugewiesen werden. Der AgentenClassLoader wird von SecureClassLoader abgeleitet, wodurch der Sicherheitsmechanismus der ProtectionDomain für Agenteninstanzen eingesetzt werden kann.
Vor dem Laden einer Agenten-Klasse überprüft der AgentenClassLoader, ob der Agent die benötigte Berechtigung besitzt, um die Klasse zu laden und zu definieren. Realisiert wird dies durch die Verwendung der System.getSecurityManager().checkPackageAccess()-Methode innerhalb des AgentenClassLoaders. Desweiteren werden vor dem Laden der Agenteninstanz die der Agenteninstanz durch die ZKI-Policy zugewiesenen Zugriffsrechte ermittelt. Das MASA Policy-Objekt implementiert dafür die getAgentPermissions()-Methode, welche auf Basis der einzelnen Attribute der Agenteninstanz die in der ZKI-Policy zugeteilten Zugriffsrechte ermittelt.
agentPermissions = java.security.Policy.getPolicy().getAgentPermissions(agentAttributs);
Mit den ermittelten Zugriffsrechten und der MASA-CodeSource wird eine ProtectionDomain der Agenteninstanz erzeugt.
agentProtectionDomain = new java.security.ProtectionDomain(CodeSource, agentPermissions);
Durch die explizite Zuweisung ist es aus der Sicht der
Zugriffskontrolle möglich, mehrere Agenteninstanzen der
gleichen Gattung auf ein und demselben Agentensystem auszuführen
und die Zugriffskontrolle durch den Einsatz des AccessControllers zu
regeln, da die Eindeutigkeit der ProtectionDomain gegeben ist.
protected final Class defineClass(String name, byte date[],
int offset, int length, agentProtectionDomain pd)
Durch den in der define()-Methode enthaltenen ProtectionDomain Parameter,
werden der Agenteninstanz die expliziten Permission-Objekte, welche
in der ProtectionDomain enthalten sind, zugewiesen.
Kritische Zugriffe auf Ressourcen des Endsystems werden
durch den AccessController überprüft. Greift nun eine Agenteninstanz
auf eine Ressource des Endsystems zu, so überprüft der
AccessController den Zugriff. Hierfür werden die auf dem
Stack befindlichen ProtectionDomains auf die in der
ProtectionDomain enthaltenen Zugriffsrechte hin
überprüft.
Da die ProtectionDomain der Agenteninstanz die mithilfe des
MASA Policy-Objekts ermittelten Zugriffsrechte auf Basis der ZKI-Policy
enthält, erfolgt eine feingranulare Zugriffskontrolle auf
Basis der Eigenschaften der Agenteninstanz.
Die Abb. 43 stellt die involvierten Komponenten der Zugriffskontrolle dar.
Eine Agenteninstanz kann so ein dynamisches Zugriffsrecht, geknüpft an bestimmten Bedingungen, auf Ihre Objekte vergeben. Tritt eine bestimmte Bedingung ein, so überreicht sie die Aktions-Policy an das Agentensystem. Das Agentensystem kontrolliert die in der Aktions-Policy vorhandenen Zugriffsrechte. Die ProtectionDomain der Agenteninstanz wird durch den DomainCombiner-Mechanismus um die von dem Agentensystem akzeptierten Zugriffsrechte der Aktions-Policy erweitert.
Bedingungen:
Ablauf: Erzeugung der ProtectionDomain einer Agenteninstanz (vgl. Abb. 44):
Der Ablauf der Zugriffskontrolle ist in Abb. 45 dargestellt. Dabei entspricht der Ablauf der Sicherheitsarchitektur der Java 2 Security Architecture mit Ausnahme der eigenen Policy-Klasse.
Erweiterung der ProtectionDomain durch Zugriffsrechte der Aktions-Policy
Mit dem Interface DomainCombiner aus dem Package java.security
kann ein dynamisches Updaten der ProtectionDomain, die mit dem
momentan aktuellen AccessControlContext verbunden ist, erfolgen.
Durch die Modifizierungen mittels combine
können neue ProtectionDomains in den Stack aufgenommen werden,
ProtectionDomains aus dem Stack entfernt
werden oder die existierenden ProtectionDomains upgedatet werden.
Die combine()-Methode richtet sich bei einem Update nach
Informationen, welche innerhalb des DomainCombiners eingekapselt sind.
Aufrufe der Methode:
AccessController.getContext und der Methode
AccessController.checkPermission involvieren die Methode
DomainCombiner.combine.
Für die Integration der vom Agentensystem akzeptierten Zugriffsrechte der
Aktions-Policy einer Agenteninstanz, muss die ProtectionDomain der
Agenteninstanz um zusätzliche Zugriffsrechte erweitert werden.
Beim Beenden bzw. bei Migration auf ein anderes Agentensystem müssen
die nachträglich hinzugefügten Einträge wieder entfernt werden.
Ablauf: Integration der Aktions-Policy:
Damit besitzt die ProtectionDomain der Agenteninstanz die von dem Agentensystem akzeptierten und in den Aktions-Policy enthaltenen Zugriffsrechte.
In dieser Arbeit wurde ein Rechtekonzept für die Mobile Agent System Architecture
(MASA) entwickelt. Dabei wurden grundlegende
Anforderungen einer Agentensystemarchitektur beachtet.
In dem vorgestellten Rechtekonzept werden, aufbauend auf den vorhandenen
Authentifikationsmechanismen, die Rechtevergabe (Autorisation) und die
Rechtedurchsetzung genauer betrachtet und realisiert. Dabei wird auf die
strikte Trennung der Sicherheitspolitik und des Durchsetzungsmechanismus Wert gelegt.
Der Autorisation liegt eine sprachbasierte
Spezifizierung von Zugriffsrechten mithilfe bestimmter Kriterien der
Subjekte, Objekte und Zugriffsarten zugrunde.
Durch die dafür eigens entwickelte Politik-Sprache wird eine anwendungsspezifische,
feingranulare Zugriffskontrolle der Agentensysteme und der Agenteninstanzen ermöglicht.
Zusätzlich kann die Entscheidungsfindung noch von der Vergangenheit einer
Agenteninstanz abhängig gemacht werden, wodurch die Sicherheit entsprechend erhöht wird.
Das Agentensystem stellt die oberste Hierarchie des Rechtekonzepts dar. Ein Agentensystem
kann jederzeit Zugriffsrechte zurücknehmen, die Filter-Policy konfigurieren und damit
Regeln bezüglich der Integration von Zugriffsrechten einer Wunsch-Zugriffskontrollpolitik
einer Agenteninstanz treffen.
Um die Informationssicherheit von Agenteninstanzen gewähren zu können,
wurde neben der Zugriffskontrollpolitik eines Agentensystems, die Wunsch-Zugriffskontrollpolitik
der Agenteninstanzen eingeführt. Eine
Agenteninstanz ist in der Lage, dem Agentensystem eine Wunsch-Zugriffskontrollpolitik
vorzulegen, um diese, unter Beachtung der Autonomieanforderungen, durchsetzen zu lassen.
Durch die Integration der von einem Agentensystem akzeptierten Zugriffsrechte
der Wunsch-Zugriffskontrollpolitik einer Agenteninstanz wird eine Autorisation
von Subjekten über mehrere Agentensysteme und
daher auch über Administrationsgrenzen hinaus ermöglicht.
Die Autorisation bezieht sich dabei sowohl auf Objekte des
Agentensystems als auch auf Objekte einer Agenteninstanz.
Die Autorisation von Objekten einer Agenteninstanz können dabei der
Eigentümer der Agenteninstanz aber auch weitere Subjekte, welche
von dem Eigentümer autorisiert wurden, vornehmen.
Um eine dynamische, an Bedingungen geknüpfte, Autorisation zu ermöglichen, wurden
Aktions-Policies eingeführt.
Durch die Aktions-Policies wird
eine dynamische Zugriffsrecht-Vergabe auf die Objekte
der Agenteninstanz realisiert. Eine Agenteninstanz kann dadurch Zugriffe auf
ihre Objekte in Abhängigkeit bestimmter Zustände
gewähren oder unterbinden.
Auch die Delegation der Zugriffsrechte wurde betrachtet und realisiert.
Agenteninstanzen können so autorisiert werden, dass sie die ihnen zugeteilte Aufgabe
einer Agenteninstanz bearbeiten können.
Für das Rechtekonzept wurde ein Implementierungskonzept angegeben.
Das Implementierungskonzept integriert das Rechtekonzept in die Java 2 Security Architecture,
wodurch MASA von den Sicherheit-Features von Java profitieren kann.
Ausblick
Mit dem vorgestellten Rechtekonzept ist die Informationssicherheit der
Agentensystemarchitektur sichergestellt. Für zukünftige Arbeiten
können die folgend genannten Punkte angegangen werden:
API - Application Programming Interface
CA - Certificate Authority
CMIP - Common Management Information Protocol
CORBA - Common Object Request Broker Architecture
CRL - Certificate Revocation List
CSP - Cryptographic Service Provider
DAC - Discretionary Access Control
DCE - Distributed Computing Environment
DES - Data Encryption Standard
DFS - Distributed File Service (DCE)
DN - Distinguished Name
DNS - Domain Name Service
DOD - Department of Defense
DSA - Data Encryption Standard
FIPA - Foundation for Intelligent Physical Agents
GUI - Graphic User Interface
ID - Identifier
IETF - Internet Engineering Task Force
IIOP - Internet Inter-ORB Protocol
JAAS - Java Authentication and Authorisation Service
JAR - Java Archive
JCA - Java Cryptography Architecture
JCE - Java Cryptography Extension
JDK - Java Developement Kit
JVM - Java Virtual Machine
MAC - Mandatory Access Control
MAC - Message Authentication Code
MASIF - Mobile Agent System Interoperability
NFS - Network File System
NIS - Network Information Service
NIST - National Institute for Standards and Technology
NOS - Network Operating Service/System
OMG - Object Management Group
ORB - Object Request Broker
PKCS - Public Key Cryptography Standards
QoS - Qualitiy of Service
RMI - Remote Method Invocation
RPC - Remote Procedure Call
SKIP - Simple Key Management for Internet Protocols
SNMP - Simple Network Management Protocol
SPI - Service Provider Interface
TCB - Trusted Computing Base
URL - Uniform Resource Locator
VPN - Virtual Privat Network
![\includegraphics [totalheight=0.2\textheight]{impl-autor2.eps}](img50.gif)
![\includegraphics [totalheight=0.28\textheight]{impl-permissionobjekt-3.eps}](img51.gif)
![\includegraphics [totalheight=0.28\textheight]{impl-ablauf-ma-es2.eps}](img52.gif)