Nachdem mit den vorangehenden Kapiteln die Authentisierung einer handelnden Entität ermöglicht wird, ist die Grundvoraussetzung für eine Autorisierung von Aktionen gegeben.
Nachdem bereits in Kap. 3.4 die für die Autorisierung relevanten Schnittstellen vorgestellt wurden, soll nun detaillierter betrachtet werden, wo und wie die Autorisierung für diese Schnittstellen durchgeführt werden kann.
Betrachtet man die verschieden Ansätze aus Kap. 3.6, so kommt man zu dem Schluß, daß für eine Sicherheitsarchitektur, welche die gestellten Anforderungen erfüllt, eine Kombination der vorgestellten Ansätze notwendig ist.
Für eine grobe Trennung zwischen Ressourcen, die durch das
Agentensystem generell erreichbar sein sollen und jenen, die niemals
erreichbar sein sollen, eignen sich Sicherungsmaßnahmen im Endsystem.
Wegen der Plattformabhängigkeit und schlechten Managebarkeit darf
die Trennung dabei nur so vorgenommen werden, daß diese über einen langen
Zeitraum Bestand hat und vor allem keine Änderungen dieser
Sicherungsmaßnahmen zur Laufzeit des Agentensystems vorgenommen werden
müssen. Zusicherungen, die mit ``immer'' oder ``niemals''
attributiert sind, können so umgesetzt werden.
Beispielsweise könnte eine solche Trennung Teile des lokalen Dateisystems vom Zugriff des Agentensystems ausschließen oder den Zugriff auf ein bestimmtes Netz-Interface sperren, auf dessen Segment niemals zugegriffen werden darf.
Die fallweise Autorisierung der Schnittstellen des Endsystems muß
demnach eine Ebene höher, also durch das Agentensystem vorgenommen
werden, denn zum einen kann das Agentensystem die notwendige
Unterscheidung verschiedener Entitäten vornehmen. Zum anderen
entsteht hierdurch eine zentrale, im gesamten SmA plattformunabhängige
Komponente, die eine vereinheitlichte Managementschnittstelle
bereitstellt, was die Voraussetzung für die Erfüllung der Forderung
nach einfacher Managebarkeit ist. Daneben ist das Agentensystem auch
für die Autorisierung seiner eigenen Schnittstelle verantwortlich.
Aber auch der Zugriff auf Schnittstellen einer Agenteninstanz müssen durch das Agentensystem autorisierbar sein. Dies ermöglicht, daß Agenteninstanzen die eigene Schnittstellen anbieten und dafür keine eigenen Autorisierungsmaßnahmen ergreifen, aber kritische Aktionen auf dem Agentensystem oder Endsystem ausführen, trotzdem ausgeführt werden können. Dies wird an einem Beispiel deutlich:
Eine Agenteninstanz E sei vertrauenswürdig und könne deshalb eine kritische Aktion A auf dem Endsystem ausführen. Bietet E aber auch eine eigene Schnittstelle zum Auslösen von A an und autorisiert deren Nutzung nicht, so könnte ein Angreifer diese Schnittstelle nutzen, um A unberechtigterweise auf dem Endsystem auszuführen, da aus der Sicht des Agentensystems A vom vertrauenswürdigen E ausgeführt wird. Kann aber das Agentensystem Zugriffe auf die Schnittstellen von E autorisieren, kann die unberechtigte Nutzung dieser Schnittstelle ohne Zutun der Agenteninstanz verhindert werden.
Eine extrem feingranulare, individuelle Überprüfung von Aktionen kann
nur durch die jeweilige Entität selbst erfolgen, die die Schnittstelle
für die Aktion bereitstellt. So sind beispielsweise Agenteninstanzen für
die Überprüfung der Parameter bei Benutzung einer Schnittstelle selbst
verantwortlich, da nur sie die genaue Semantik der Funktion und damit
die in der Signatur verzeichneten Parameter kennen. Gleiches gilt für
die Schnittstellen, die das Agentensystem selbst anbietet.
Zusammenfassend zeigt Tabelle
5.3 die Beziehungen zwischen
Schnittstellen und den für deren Autorisierung zuständigen Entitäten
Nach vorhergehendem Absatz tritt ein weiteres Problem in Erscheinung. Die Schnittstelle einer Agenteninstanz wird danach sowohl durch das Agentensystem als auch durch die Agenteninstanz selbst autorisiert. Damit sind Kollisionen in den Entscheidungen nicht auszuschließen.
Die einfachste Art solche Konflikte zu lösen ergibt sich durch eine einfache Priorisierung der Entscheidungsträger. So gelangt man zu einer Entscheidungshierarchie.
Da das Agentensystem nicht nur für seine eigene Sicherheit verantwortlich zeichnet, sondern auch für andere Agenteninstanzen und insbesondere das Endsystem, genießen ``Negativ''-Entscheidungen des Agentensystems eine höhere Priorität als Entscheidungen von Agenteninstanzen. D.h. wenn eine Agenteninstanz zwar die Benutzung einer eigenen Schnittstelle genehmigt, kann das Agentensystem dies immernoch ablehnen.
Im umgekehrten Fall kann eine Ablehnung durch die Agenteninstanz nicht durch das Agentensystem ``aufgehoben'' werden.
Die zentrale Frage der Autorisierung ist
Damit diese Frage fallweise ohne Eingriff einer Person beantwortet
werden kann müssen Regeln formuliert werden, nach denen diese
Entscheidungen zu treffen sind. Ein Satz solcher Regeln wird im
folgenden Policy genannt.
In einer solchen Policy muß es zunächst also die Möglichkeit geben die Entität E zu adressieren. Nun ist es allerdings nicht praktikabel, diese Adressierung allein über den Identifikator von E zu bewerkstelligen, da die Menge der möglichen Entitäten, und damit die konkreten Identifikatoren, in einem SmA weder endlich noch von vorneherein aufzählbar sind. Dies hat zur Folge, daß sich hierauf basierend keine allgemeinen Regeln formulieren lassen.
Vielmehr ist es notwendig weitere charakteristische Parameter einer Entität zu Rate zu ziehen, da nur solche Parameter vor der tatsächlichen Anfrage bekannt sind.
In Abschnitt 5.5.1 sind diese
charakteristischen Parameter in Form von Attributen der
Principals
bereits definiert worden und können nun für die Formulierung von
Regeln benutzt werden.
Daraus abgeleitet lassen sich die folgenden Überprüfungen anstellen:
Sei E ein Principal
Falls E ein Agentensystem ist:
Falls E eine Agenteninstanz ist:
Da die Attribute Authority, Implementierer, Agentensystem selbst wieder vom Typ Principal sind, lassen sich auch rekursiv fortgesetzte Bedingungen über die Attribute formulieren:
Weiterhin ist die boolsche Verknüpfung solcher Bedingungen wünschenswert, um komplexere Regeln formulieren zu können:
Eine weitere Flexibilisierung in der Formulierung von Regeln wird dann erreicht, wenn Attribute des Eigentümers einer Policy über symbolische Konstanten für die Vergleichsoperationen zu Verfügung gestellt werden. Sei MEINE_AUTHORITY nun die symbolische Konstante für den Eigentümer der Entität, die die Policy auswertet, dann könnte eine Regel lauten:
Nachdem jetzt die Bedingungen formuliert werden können ist es möglich anhand dieser Bedingungen Erlaubnisse für die Benutzung einer Schnittstelle zu erteilen, indem man in Abhängigkeit von Bedingungen Aktionen erlaubt:
Die hier informell vorgestellten Überprüfungen markieren das Minimum
dessen, das benötigt wird, um Regeln formulieren zu können, die
gleichzeitig
Eine Einschränkung des Umfangs der Formulierungsmöglichkeiten ist zwar denkbar, bedeutet aber immer, daß Teilaspekte sicherheitsrelevanter Informationen nicht überprüft werden können oder die Flexibilität in der Formulierung von Regeln eingeschränkt wird.
Mit den bis hierhin vorgestellten Mitteln lassen sich die Entitäten flexibel adressieren. Gleiches gilt bis dato aber nicht für Aktionen, diese können nur nach ihrer Art benannt werden. Häufig genügt es aber nicht nur die Aktion ihrem Typus nach zu betrachten, auch die konkrete Belegung der Parameter einer Aktion können die Entscheidung über die Durchführung der Aktion beeinflussen.
Beispielsweise sei eine Aktion ErzeugeAgenteninstanz mit dem Parameter Agentengattung betrachtet. Soll nun nur die Erzeugung von Instanzen bestimmter Agentengattungen gestattet werden, so besteht keine Möglichkeit dies zu formulieren.
Betrachtet man parametrisierte Aktionen näher, so zerfallen diese in
zwei Kategorien:
Die erste Kategorie läßt sich auf Aktionen ohne Parameter abbilden, indem man für jede Parameterbelegung eine eigene Aktion definiert.
Beispiel: Eine Aktion Dateizugriff mit dem Parameter Zugriffsart und dessen möglichen Belegungen Lesen, Schreiben, LesenUndSchreiben kann auf die Aktionen DateiLesen, DateiSchreiben und DateiLesenSchreiben abgebildet werden.
Ist die Menge der Parameterbelegungen aber nicht
endlich5.2, werden wiederum Entscheidungsregeln
benötigt, die es ermöglichen eine konkrete Parameterbelegung zu
analysieren.
Beispiel: Eine Aktion SystemkommandoAusführen mit dem Parameter Kommando vom Typ String, kann nicht in einzelne diskrete Aktionen zerlegt werden, da die Menge der möglichen Belegungen von Kommando praktisch nicht aufzählbar ist.
Entscheidungsregeln für Parameterbelegungen für den allgemeinen Fall, im voraus, auch nur informell, zu spezifizieren, ist aber nicht möglich, da hierfür die Semantik der einzelnen Parameter bekannt sein müßte. Eine Spezifikation solcher Entscheidungsregeln muß demnach immer individuell für den Einzelfall erstellt werden.
Faßt man nun die Erkenntnisse über die Adressierung von Aktionen in Policies mit jenen über die in Abschnitt 5.8.1 gemachte Analyse über eine sinnvolle Durchführung der Autorisierung zusammen, ergibt sich folgendes Bild:
In Agentensystemen ist eine sinnvolle Autorisierung von Aktionen nur im Folgenden Umfang möglich:
Im Rahmen der Entscheidungshierarchie kann dann durch Agenteninstanzen eine weitere, individuelle Autorisierung der eigenen Methoden erfolgen.
Generische Policies können also nur Aktionen behandeln, die
entweder keine Parameter besitzen oder die Betrachtung der Parameter
außen vorlassen.
Um eine solche Policy nun konkret formulieren zu können und damit auch eine plattformunabhängige Instanz zum Management von Policies zu schaffen, ist die Schaffung einer formale Sprache denkbar, die folgende Eigenschaften besitzt:
Um auch die individuellen Semantiken der einzelnen Schnittstellen behandeln zu können, d.h. konkret Methoden inklusive ihrer Parameter zu betrachten, sollte die Policy-Sprache modular erweiterbar sein.
Die konkrete Spezifikation einer solchen Policy-Sprache, die all diese Eigenschaften unterstützt, muß im Rahmen dieser Arbeit unterbleiben und könnte Gegenstand einer weiteren Arbeit werden.
Neben einer Policy für die Benutzung der einzelnen Schnittstellen werden aber weitere Entscheidungen notwendig, die in eigene Policies formuliert werden können:
Somit seien nun die folgenden Policies konkret definiert:
Alle drei genannten Policy-Typen müssen durch ein Agentensystem implementiert werden, Authentication Policy und Permission Policy können optional auch zusätzlich durch Agenteninstanzen erweitert werden. Dann wird die Priorisierung der Entscheindungen nach Abschnitt 5.8.2 vorgenommen.
Die Permission Policy bestimmt dabei im Fall eines Agentensystems über
die Erlaubnis zur Benutzung der eigenen Methode, der Methode der
Schnittstelle zum Endsystem und über den Zugriff auf Methoden eines
Agenten. Die Permission Policy einer Agenteninstanz dagegen ist nur für
eigene Methoden zuständig, die an ihren Schnittstellen angeboten werden.
Die Eingangs im vorangegangenen Kapitel gestellte Frage
``Darf eine Entität E eine Aktion A durchführen?''
kann jetzt mit den vorgestellten Mitteln vollständig beantwortet werden.
Wird von einer Entität E eine Anfrage zur Durchführung einer Aktion A an eine Entität F gestellt, so authentisiert F die anfragende Entität mittels der Authorization Policy und den in Abschnitt 5.5.3 geschilderten Verfahren. Wenn E authentisiert werden konnte, dann überprüft F anhand der Permission Policy, ob die Aktion ausgeführt werden darf.
Wird von der Permission Policy die Ausführung der Aktion genehmigt, so wird die Aktion ausgeführt. Kann die anfragende Entität nicht authentisiert werden oder stellt die Permission Policy einen negativen Bescheid aus, so wird die Aktion nicht durchgeführt. Außerdem wird die Entität, die die Aktion ausführen wollte, darüber informiert, daß die Aktion nicht ausgeführt wurde. Ob und wie ausführlich eine Begründung für die Ablehnung beigefügt wird, ist davon abhängig, inwieweit man einem potentiellen Angreifer Hinweise für weitere Angriffe geben möchte, bzw. hängt auch mit der Benutzerfreundlichkeit des Systems ab; näheres hierzu soll an dieser Stelle nicht betrachtet werden.
Wird die Ausführung einer Aktion nicht gestattet, sind noch weitere Sanktionen denkbar. Begeht z.B. eine lokale Agenteninstanz einen ``schwerwiegenden'' Sicherheitsverstoß, so wäre beispielsweise denkbar, daß dieser terminiert wird. Die Art der Sanktionen kann optional wiederum durch eine Policy bestimmt werden.
verschiedene Belegungen annehmen