Um Administration in größeren Netzwerken bewältigen zu können ist ein Policy-basiertes Management System sinnvoll. Der Ansatz, alle Geräte von einer Stelle aus mit einer Software administrieren zu können, ist nicht einfach umzusetzen. Die Anzahl der zu verwaltenden Geräte allein schon ist überwältigend, und die Szenarien, wie sie eingesetzt werden könnten, unüberschaubar. Außerdem ist ein großer Freiheitsgrad nötig, da sich die Policies ständig ändern können. So ist es zum Beispiel nicht ungewöhnlich, von einem Tag auf den anderen ein Gerät einem anderen Nutzer zuzuweisen.
Eine Sprache, um Policy-basiertes Management zu beschreiben, ist Ponder. Sie ist relativ einfach gehalten, um die Einarbeitung zu erleichtern. Die grundsätzliche Idee ist, Geräte und Nutzer in hierarchischen "Domains" zu verwalten. Das erleichtert die Strukturierung und Übersichtlichkeit, da Geräte und Nutzer bezüglich Ort oder Verwendungszweck zu Gruppen zusammengefaßt werden können, und mehrere davon wieder zu größeren Gruppen. Gruppen auf oberster Ebene werden als Domains bezeichnet, tiefere als Subdomains. Soll einem Element (oder einer ganzen Subdomain) nun eine andere Policy zugewiesen werden, wird sie einfach an eine andere Stelle in der Hierarchie verschoben.
Policies skalieren gut und sind sehr flexibel. Die gute Skalierung kommt daher, dass Policies im Wesentlichen nur einmal erstellt werden und einer Domain zugewiesen werden, womit sie nicht nur für alle Elemente dieser Domain gelten, sondern auch für alle Subdomains. Eine Gruppierung von Geräten räumlicher Nähe oder ähnlicher Nutzung - wie zum Beispiel alle Computer in einem Terminal-Raum - ist offensichtlich sinnvoll, da für solche Geräte auch ähnliche Sicherheits- und Verwendungsmerkmale gelten. Werden in den Terminal-Raum weiter Rechner hinzugestellt, kommen sie einfach in die gleiche Domain - und somit gelten für sie sofort die gleichen Einstellungen. Die Flexibilität des Systems liegt darin, dass die Policies geräteunabhängig sind. Ein Sicherheitsmerkmal kann nicht nur einem Windows- oder Unix-Computer zugewiesen werden, sondern auch einem Drucker.
Diese Idee der Policies, und damit Computer, Computerteile, Programme und ganze Firmenstrukturen zu organisieren, ist in den letzten Jahren stark konkretisiert worden. Es wurde sogar begonnen, Interfaces für spezielle Anwendungsbereiche zu programmieren. Oft ist Administration aber ein evolutionärer Prozess, da sich das zu administrierende Umfeld ständig ändert und sich erst im laufenden Betrieb herausstellt, ob ein Verfahren nützlich ist. Policies, Sicherheitsrichtlinien und Gruppenzuweisungen ändern sich also ständig. Die Policy-Sprache muss also einfach zu erlernen und zu benutzen sein, und es muss Tools geben, um Organisationsstrukturen einfach überschauen und bearbeiten zu können.
Im Idealfall sollten Administratoren nichts mit der Implementierung oder der internen Repräsentation der Policies zu tun haben. Werkzeuge sollten das erstellen, bearbeiten und löschen von Policies ermöglichen und Policies auf Konflikte analysieren können. Der Lebenszyklus der Policies sollte automatisiert und vom Nutzer unsichtbar ablaufen.
Hier sollen einige Tools und deren Eigenheiten vorgestellt werden. Das bisher namenlose Toolkit implementiert Spezifikation, Verteilung und Verwaltung von Policies, die in der Ponder-Sprache beschrieben werden. Domains sind mit Hilfe von LDAP-Verzeichnissen implementiert und speichern die für Policies und Gruppierung notwendigen Daten, Personen und die Einheiten, die die Policies implementieren. Es ist ein Browser enthalten, der die Domainstruktur für den Benutzer übersichtlich darstellen kann, eine integrierte Entwicklungsumgebung (IDE) inklusive Policy-Compiler sowie Werkzeuge, um Policies und Rollen während der Laufzeit zu verwalten.
Die Architektur benutzt LDAP, um den Domain Service zu implementieren, Java RMI ist die Middleware, über die die Systemkommunikation zwischen den Komponenten funktioniert. Alle Tools sind in Java geschrieben und benutzen Swing als graphische Oberfläche.
Als Beispielszenario soll ein Backup-System für eine große Software- Entwicklungs-firma betrachtet werden. Es ist vorstellbar, daß für die gesamte Firma ein großes Backup-System existiert, das einmal im Monat alle wichtigen Daten sichern soll. Diese große Firma ist in Abteilungen gegliedert, die zum Teil auch eigene, kleinere Backup-Systeme besitzen, die öfter ein Backup durchführen (zum Beispiel täglich).
Es wird schnell klar, daß es nicht nur einen Backup-Administrator geben kann, der die ganze Arbeit macht. Viel praktischer wären Backup-Administratoren in jeder Abteilung, denen bestimmte Aufgaben delegiert werden. So kann der Backup-Administrator der Firma den Abteilungs-Administratoren die Aufgabe deligieren, was von innerhalb der Abteilung in das große Backup gehört. Die Abteilungs-Administratoren können außerdem, im Rahmen ihrer Möglichkeiten, auf Abteilungs-Servern häufigere und detailliertere Backups durchführen. Es ergibt sich eine natürlich Hierarchie, die sich auch in der Domain-Struktur wiederspiegelt.
In der Hierarchie befinden sich im Zweig "users" alle Benutzer, die in der Firma arbeiten - unter anderem im Zweig "admin" auch die Administratoren. Diesen Zweig würde man weiter unterteilen, um der Tatsache rechnung zu tragen, daß verschiedene Administratoren für verschiedene Abteilungen oder auch unterschiedliche Aufgaben zuständig sind. Der "system/res"-Zweig enthält die Dateien und Daten, nach Abteilungen gegliedert. Der "system/servers"-Zweig enthält die Server, z.B. Backup-Server und Mail-Server. Der Zweig "managementInfo" enthält alle für die Policies wichtigen Daten. Nur Policy- und Security-Administratoren haben Zugriff dazu.
Benutzer haben normalerweise nur Zugriff auf ihre eigenen Komponenten (z.B. der Computer an ihrem Arbeitsplatz oder ein "Home"-Verzeichnis) und die Komponenten, die ihrer Abteilung gehören. Benutzern kann explizit erlaubt werden, auf andere Komponenten zuzugreifen. Benutzer haben normalerweise nicht die Möglichkeit, Funktionen auszuführen, die ein Administrator tun würde, aber der Administrator kann einem oder mehreren Benutzern die Erlaubnis dazu erteilen, er kann die Arbeit "deligieren".
Der Domain-Browser ist eine Schlüsselkomponente des ganzen Toolkits. Mit ihm kann man Objekt auswählen und gruppieren um ihnen Policies zuzuweisen, um sie zu überwachen oder um Verwaltungsaufgaben auszuführen. In der momentanen Implementation sind allerdings nur Operationen, die die Policies betreffen, möglich. Der Browser liest seine Daten direkt über ein LDAP-Interface vom Domain Service und stellt sie graphisch dar.
Der Domain-Browser ist das einzige Werkzeug, das direkten Kontakt zur LDAP-Schnittstelle hat, alle anderen benutzen das Java RMI Interface, das die Ponder Runtime Library zur Verfügung stellt. Der Domain-Browser ist eine Art Koordinationspunkt für das Management Toolkit, aber nicht in dem Sinne, dass die anderen Tools nicht ohne ihn funktionieren würden, sondern eher, dass er eine wichtige Benutzerschnittstelle darstellt. Wann immer der Benutzer in irgendeinem Tool eine Domain auswählen will um eine bestimmte Funktion auszuführen, kann er per Knopfdruck den Domain-Browser starten, um mit ihm die Domain auszuwählen. Die Eingabe in Form eines Directory-Pathes ist in den meisten Fällen auch möglich und natürlich schneller, wenn man mit dem System gut vertraut ist und die Pfadstruktur auswendig kennt. Bis es aber soweit ist, ist ein Werkzeug zur Visualisierung der Baumstruktur für die Benutzerfreundlichkeit unverzichtbar.
Die Wahl der Darstellungsform ist nicht trivial. Da es sich bei den Domains um eine hierarchische Struktur handelt, liegt es nahe, eine Baum-Ansicht zu wählen. Die Domainstruktur ist aber nicht wirklich ein Baum, sondern genau genommen ein azyklischer Graph, wo Domains von mehreren Eltern-Domains abstammen können. Nach mehreren Versuchen mit zweidimensionalen Viewern wurde hier eine Fischaugen-Sicht gewählt, die fokussierte Teile größer darstellt als weiter entfernte. In dieser Ansicht können ca. 10-mal mehr Knoten dargestellt werden, als es mit einer 2D-Sicht möglich wäre. Außerdem ist die Navigation in einer solchen Ansicht einfacher.
Die Navigation ist einfach: Man hält den Graphen mit der Maus fest und schiebt ihn über die hyperbolische Ebene. Das sieht dann so aus, als würde man den Graphen über eine Kugel ziehen, oder als würde man einen Teil des Graphen durch eine Linse betrachten.
Das kann trotzdem noch ganz schön unübersichtlich sein. Am Rande der hyperbolischen Ebene liegen die Domains sehr dicht zusammen und auch übereinander, und in der Mitte können Querverbindungen laufen. Diese Querverbindungen entstehen nicht aus der Hierarchie, sondern können nachträglich eingefügt werden, um einer Domain Eigenschaften einer andern Domain hinzuzufügen (Mehrfach-Ableitung). Solche Verbindungen führen kreuz und quer durch den Viewer und machen das Bild unübersichtlich. Wenn sich die Domains je nach Zugehörigkeit neu anordnen würden (man stelle sich die Verbindungen als Gummibänder vor), wäre das Bild sicherlich übersichtlicher. Außerdem ist der root-Knoten anfangs immer in der Mitte, was nicht unbedingt die intuitive Auffassung einer Hierarchie unterstützt.
Das Bild zeigt eine einfache, kleine Domain-Struktur, wie sie für das Beispiel-Szenario aussehen könnte. In der Domain "Users" würden, aufgeteilt nach Standpunkt des Arbeitsplatzes und Arbeitsgebiet, die Benutzer stehen. Unter "System" sind die Hardware-Komponenten, die verwaltet werden sollen, zusammengefaßt.
Elemente der Struktur können ausgewählt und bearbeitet werden. Alle Elemente haben ein Popup-Menü, das die möglichen Aktionen enthält. Andere Tools können direkt aus diesen Menüs gestartet werden, um spezielle Aufgaben auf den Objekten durchzuführen. Die Objekte können dabei verschiedene Elemente darstellen: Es können Benutzer, Rollen oder Netzwerkkomponenten sein. Auch die Veränderung der Graphstruktur selbst ist möglich, so kann man Teilgraphen kopieren, einfügen und verschieben. Teilgraphen können ein- und ausgeblendet werden, um die Übersichtlichkeit zu erhöhen.
Zusammengesetzte Policy-Strukturen wie Rollen oder Beziehungen zwischen Domains werden, genau wie Domains, als Ordner dargestellt, dessen Unterbäume die einzelnen Policy-Komponenten darstellen.
Editierte Domainstrukturen können wieder per LDAP im Domain Service gespeichert werden. Die Möglichkeit, etwas rückgängig zu machen, beschränkt sich auf das neue einlesen der Domainstruktur vom Service. Da der Browser außerdem Benachrichtigungen vom System erhält, wenn sich der Domain Service verändert hat, ist auch in begrenztem Umfang eine Zusammenarbeit mehrerer Leute möglich. Wenn allerdings zwei Leute gleichzeitig die Struktur editieren, ist ein vermischen der Änderungen nicht möglich.
Ponder Policies können, je nach Anwendungsgebiet, in ein passendes Format übersetzt werden. Handelt es sich um Aktionen wie zum Beispiel Dateizugriffe bei einem Backup-Vorgang, so kann die Policy in ausführbaren Code, der zu dem jeweiligen Gerät passt, übersetzt werden. Handelt es sich um Beschreibungen von Verhaltensweisen, so könnte es in ein beschreibendes Dateiformat wie XML übersetzt werden. Zugriffsberechtigungen können den verschiedensten Umgebungen zugewiesen werden, wie Firewalls, Zugangsberechtigungen für Betriebssysteme oder Datenbanken und Java-Berechtigungen. Die Entscheidung, welches Ausgabeformat angemessen ist, muß das Compiler-Framework selbst treffen - schließlich kann er mit Hilfe des Domain Services feststellen, um welche Art von Gerät es sich handelt und welche Formate das Gerät versteht.
Policies werden erst durch eine syntaktische Analyse und eine semantische Analyse geschickt, ein Code Assembler erzeugt einen "intermediate code", der im LDAP-Verzeichnis gespeichert wird. Sobald eine Policy Anwendung findet, wird ein passender Code-Generator aufgerufen, um für das Gerät verständlichen Code zu erzeugen.
Für jedes Ausgabeformat, das unterstützt werden soll, wird ein Compiler Back-end benötigt. Das Compiler-Framework erlaubt dabei das spätere Einfügen zusätzlicher Codegeneratoren, ohne den Compiler selbst neu übersetzen zu müssen. Der Compiler basiert auf einem LALR(1)-Parser, der mit Hilfe von SableCC, einem objektorientierten Java-Compiler-Compiler, erzeugt wurde. Nach der syntaktischen und der semantischen Analyse wird temporärer Code (IC, intermediate code) erzeugt, der dann von den Code-Generatoren weiterverarbeitet wird. Das Code-Assembler Modul speichert den erzeugten Code dann im Domain Service ab.
Das Compiler-Framework übersetzt die Ponder-Spezifikationen in Java-Code, vorgesehen (aber noch nicht vollständig implementiert) sind die Ausgabeformate
Der Policy Editor verknüpft den Domain Browser und den Compiler in einer Integrierten Entwicklungsumgebung (IDE). Masken erleichtern die Eingabe und den Umgang mit Ponder. Der Domain-Browser kann direkt aufgerufen werden, um das Ziel für Policies zu bestimmen. Bestehende Policies können mit dem Domain-Browser ausgewählt, bearbeitet, recompiliert und zurückgespeichert werden. Einhängte Compilerzusätze können vom Editor aus an- und abgeschaltet werden, um zu kontrollieren, was für Code erzeugt wird.
Die IDE unterstützt den Benutzer bei der Eingabe durch farbliche Hervorhebungen und automatische Einrückung. Für einzelne Funktionen sind spezielle Dialoge vorhanden, die bei der korrekten Parametereingabe helfen, so ist für Timer-Funktionen ein Dialogfeld mit Kalender zur Datumsselektion vorhanden. Andere Dialoge hingegen sind fast nur mit Abkürzungen beschriftet, was nicht wirklich weiterhilft.
Es gilt nicht nur, Domains zu verwalten und deren Policies, sondern auch den "Lebenszyklus" der Policies. Policies werden in Java Klassen durch den Compiler übersetzt und in der Domain Hierarchie gespeichert. Die Instanziierung einer Policy erzeugt ein Java Objekt der zugehörigen Klasse, welches die Attribute der Policy in angemessener Weise repräsentiert. Es wird begleitet von einem von drei speziellen Policy Control Objects (Authorization, Refrain oder Obligation Control Object), die für die Zugriffsrechte zur Laufzeit und die Verbreitung der Policy zuständig sind.
Ein Objekt kann "dormant" sein, dann ist es nicht geladen aber instanziiert. Es kann geladen werden, dann wird es zu den Enforcement Components der Ponder Runtime Library übertragen, und wenn es geladen ist, kann es aktiviert werden. Nur ungeladene Policies können gelöscht werden. Dieser Lebenszyklus wird durch das Policy Control Object koordiniert. Das Control Object ist außerdem der Punkt, an dem Konflikte, wie die Statusveränderung von zwei Administratoren gleichzeitig, ausgehandelt werden.
Ponder Policies werden normalerweise nicht einzelnen Geräten oder Benutzern zugewiesen, sondern Domains, die dann die Geräte oder Benutzer enthalten. Wird ein neues Gerät einer Domain zugewiesen, so müssen alle Policies dieser Domain für das neue Objekt geladen und möglicherweise auch aktiviert werden. Daher haben Domains immer Referenzen auf ihre Policies, schon alleine aus dem Grund, dass die Policy-Objekte auch dann weiter existieren müssen, wenn die Domain gerade mal leer ist. Anders herum halten die Control Objects eine Liste von Domains, denen sie zugewiesen sind. Sie werden von LDAP informiert, wenn sich Domainzugehörigkeiten ändern, so dass die Daten in den Enforcement Components auf dem neuesten Stand gehalten werden kann.
Viele von den beschriebenen Verhaltensweisen sind Automatisiert, so dass der Administrator sich damit nicht beschäftigen muss. Um den Lebenszyklus der Policy Objekte kontrollieren zu können, gibt es eine Management Konsole, mit der Objekte geladen, entladen, aktiviert und deaktiviert werden können. Die Objekte werden wie gewohnt mit dem Domain-Browser ausgewählt. Wird dabei eine Domain ausgewählt, werden alle enthaltenen Policy Objekte geladen und angezeigt. Ein eingebautes Kommandozeileninterface ermöglicht dabei die interaktive Instantiierung neuer Policy Typen.
Bei den Policies kann es zu Koflikten kommen. So kann man z.B. eine Gruppe ("Students") von einem Zugriff auf eine Domain ausschließen, aber einem Mitglied dieser Gruppe den Zugriff auf eine Subdomain derer wieder erlauben.
In diesem Fall ist nicht klar, ob der Zugriff erlaubt oder verwehrt werden muß. Um das zu vermeiden, müssen Präzedenzen eingeführt werden, so kann man zum Beispiel generell angeben, dass immer die spezifischere Definition stärker sein soll. Das wäre in der Domain-Hierarchie dadurch erkennbar, dass die Domain weiter unten im Graph steht. Eine andere Möglichkeit, die zwar generell die sicherste Alternative darstellt, aber nicht immer Sinn ergibt, ist, der negativen Autorisation einen höheren Stellenwert einzuräumen.
Im Policy Editor kann eine Suche nach Konflikten veranlasst werden, alternativ kann auch immer beim Speichern im Domain Server eine Suche durchgeführt werden.
Den erstellten Sicherheitsrichtlinien werden normalerweise Rollen zugeordnet, wie zum Beispiel Administrator, normaler User oder Gast. Es kann aber auch Rollen geben, die keine Person, sondern eine automatisierte Funktion darstellen, wie z.B. ein Backup-Server.
Um einem Benutzer eine Rolle zuzuordnen, benutzt man das User-Role Management Tool. Es bietet drei Ansichten.
Mit der User Management View kann man neue User anlegen, Domains zuordnen oder aus Domains löschen. Einen Benutzer einer Domain zuweisen bedeutet, dass in der Domain eine Referenz auf das Benutzerobjekt angelegt wird. Die dafür notwendigen Datenobjekte werden durch die Benutzerschnittstelle vom Benutzer unsichtbar gehalten.
Mit der Management Component View können neue Policy Management Components für Benutzer erstellt werden und auch wieder gelöscht werden. Sie können hier auch gestartet und wieder angehalten werden. PMCs sind Objekte, die an der zu verwaltenden Resource selbst als Proxy interagieren können, sie können aber auch als Agents agieren um die Rechte der Benutzer zu interpretieren. Verschiedene PMC-Datentypen existieren für verschiedene Anwendungen wie Backupsysteme oder Sicherheitsmanagement. Damit das funktionieren kann, muss auf jedem Endgerät ein PMC-Server laufen.
Mit der User-Role Management View können Benutzern Rollen zugewiesen und wieder entfernt werden. Jedes Userobjekt enthält eine Liste von Rollen, die auf diese Weise aktualisiert werden kann. Für einen Benutzer können auch einzelne Rollen aktiviert und wieder deaktiviert werden.
Solche Rollen können mit dem Policy Editor erstellt werden und werden dann auf dem Domain Server gespeichert. Diese Rollen werden Benutzern (oder Domains) zugeordnet, womit die Benutzer diese Rollen "einnehmen".
Die vorgestellten Tools konnten nicht vollständig getestet werden, da sie zum Teil noch gar nicht lauffähig sind - in dem Falle konnte jeweils nur die Beschreibung beurteilt werden.
Insbesondere fällt die Wahl eines hyperbolischen Viewers als Domain-Browser auf. Diese Wahl wurde von den Entwicklern vor allem mit der Anzahl der darstellbaren Elemente begründet, so können in einem Feld gleicher Größe in der hyperbolischen Ansicht etwa 10mal mehr Elemente dargestellt werden, als es mit einer zweidimensionalen Ansicht möglich wäre. Es wurden auch mehrere Ansätze verglichen, unter anderem soll auch noch eine zweidimensionale Baum-Ansicht (wie aus dem Windows Explorer bekannt) implementiert werden, die kleinere Ausschnitte des Domain-Graphen darstellt. Alle Tools sind mit diesem Domain-Browser verknüpft, etwa um Domains zu selektieren oder um einfach nur den Domain-Graphen zu visualisieren. Eine automatische Neuanordnung der Domain-Knoten, so daß verbundene Domains näher beieinander liegen, könnte möglicherweise die Übersichtlichkeit erhöhen.
Die Ponder-Spezifikationen sind sehr vielseitig und umfangreich. Es gibt noch weitere zusammengesetzte Konzepte, in dem vorliegenden Toolkit werden bisher nur Rollen bearbeitet. Der Domain-Viewer kann aber auch andere zusammengesetzte Policy Objekte anzeigen, indem das Objekt als Domain dargestellt wird, dass die Policies, aus denen es zusammengesetzt ist, als Elemente enthält.
Ansonsten sind an vielen Stellen schon interessante Features zu erkennen: Der Policy-Editor hebt wichtige Worte farblich hervor und alle Tools sollen in eine Management Console eingebettet werden – wo aber viele Menüpunkte noch ausgegraut sind.
Policies for Network and Distributed Systems Management http://www-dse.doc.ic.ac.uk/Research/policies/
Policy-Based Network Management http://www.networkcomputing.com/1024/1024f1.html