2.4.2 Anforderungen an Policies

Policies sind Regeln. Dabei werden die einzelnen Aussagen von Reglements als Policy-Regel bezeichnet, das gesamte Regelwerk kurz als 'Die Policy'. Policies sind zum Beispiel:

• die Gabel liegt links vom Teller und das Messer rechts
• zwischen 18:00 Uhr und 9:00 Uhr haben die Eingänge zum Gebäude verschlossen zu sein
• ab 9:00 Uhr morgens ist mindestens ein Mitarbeiter im Büro
• die Rechnungen für Kunde A in München gehen grundsätzlich nicht an den Kunden selbst, sondern an seine Mutterfirma in Berlin
• die abzuschickende Post wird in die blaue Kiste mit der Aufschrift 'Postausgang' gelegt
• alle Mitarbeiter der Abteilung Technik haben einen Schlüssel für den Technikraum
• wenn jemand auf diesem Gerät von der Nummer 1234 aus anruft, bekommt er einen login-prompt, ansonsten wird das Gespräch nicht angenommen (Zugangsbeschränkung auf Geräten)

Man sieht, daß Regeln in den verschiedensten Teilen des Lebens vorkommen und nicht unbedingt technischer Natur sein müssen. Fast alle sind der Art: 'Wenn dieses und jenes gegeben ist, dann veranlasse oder verweigere etwas'.

Policy-Regeln können nicht nur konkrete Daten betreffen, wie zum Beispiel eine IP-Adress-Angabe, sondern auch Abrechnungsmodalitäten, Freieinheiten, Sperrung von Services und sonstige Besonderheiten:

• der Nutzer A darf den Drucker D nutzen, aber nicht den Drucker P
• wenn das Nomadische System X Zugang bekommt, darf den Nomadischen Systemen Y und Z nicht gleichzeitig Zugang gewährt werden
• der Service S darf nur von 5 Nutzern gleichzeitig verwendet werden
• alle Accountingdaten bezüglich Drucker werden von Service B gesammelt.
• wenn die Außenanbindung eine Auslastung von 90% hat, wird eine zweite Leitung dazugeschaltet

Im Fall von Managementsystemen im Computer sind Policies Gruppen von Regeln, die man festlegen kann und an denen sich alle teilnehmenden Komponenten soweit wie möglich orientieren müssen. Solche Komponenten entsprechen dann einem PEP. Sie setzen die Regeln durch. Ausgenommen sind Komponenten, die nicht policyfähig sind (weil sie so alt sind, daß ihre Implementierung die Integration in ein Managementsystem und die Verwendung von Policies nicht vorsieht). Sie werden PIN genannt. Würden sich die Aktionen, die aus einer solchen Gruppe von Regeln resultieren, gegenseitig widersprechen, spricht man von einem Policy-Konflikt. Solche Konflikte sollten vermieden werden. Treten sie trotzdem auf, müssen sie speziell behandelt werden, d.h. alle betroffenen PEPs müssen miteinander koordiniert werden. Policy-Konflikte kann man erkennen und bereits im PDP entsprechend behandeln.

Um zu ermitteln, welche Arten von Policies beim Management Nomadischer Systeme benötigt werden, wurden die beiden bereits bekannten Grundszenarien um mögliche Policy-Regeln erweitert. Bevor man Policy-Regeln in Klassen oder Typen unterteilen kann, benötigt man Beispiel-Regeln. Zur Findung expliziter Regeln wird angenommen, daß:

alle Services des Systems nicht frei zugänglich sind:

Will der Nutzer einen Service nutzen, muß er sich authentifizieren. Dies passiert im klassischen Fall durch einen Benutzernamen und ein Passwort. Man kann einen Nutzer aber auch anhand der eindeutigen MAC-Adresse seiner Ethernet-Karte identifizieren oder anhand seines Daumenabdruckes (biometrische Verfahren).

sämtliche genutzten Ressourcen finanziell verrechnet werden müssen:

Dienstleistungen verursachen in der Regel Kosten. Diese können materieller Art sein, wie Druckerpapier oder virtueller Art sein, wie Rechenzeit. Alle diese Kosten kann man in Geldkosten umrechnen (z.B. eine Seite Druckerpapier kostet 10 Pfennige und 20 Minuten Rechenzeit 20 Pfennige). Um diese Kosten auch vom Benutzer einfordern zu können, muß man erfassen, wieviel Service welcher Nutzer genutzt hat. Wenn zum Beispiel gedruckt wird, wird Druckerpapier verbraucht, wer Web-Surft, verbraucht IP-Volumen und wer elektronische Videos sammelt, verbraucht Plattenplatz. Weiß man, wer wie viel verbraucht hat, kann man dem Nutzer dies in Rechnung stellen. Eine solche Buchführung hat noch einen weiteren positiven Nebeneffekt: unliebsame Überraschungen wie: 'das Druckerpapier ist alle' oder 'der Drucker benötigt eine neue Tonerkasette, aber es ist noch keine nachbestellt worden', kann man vermeiden indem man diese Daten auswertet und rechtzeitig automatisch auf einen niedrigen Bestand der Ressource hinweist.(So daß diese nachgekauft werden kann.)

ein Quality of Service oder SLA angeboten werden soll:

'Quality of Service' (QOS) ist die Möglichkeit, einen bestimmten Nutzer bevorzugt zu behandeln. Auch Vereinbarungen bezüglich einer Dienstleistung und der damit zusammenhängenden Qualität und Bezahlung sind Teil des Serrvice Level Agreements oder Quality of Service. So könnte man beispielsweise mit dem Nutzer vereinbaren: Wenn er einen Druckjob absendet - also den Druckservice nutzen möchte - wird der als nächstes behandelt, egal wie viele andere Druckjobs bereits auf Abarbeitung warten. Auch eine garantierte Bandbreite ist ein Quality-of-Service-Merkmal. Solche bevorzugte Behandlung bedeutet aber andererseits wieder zusätzlichen Aufwand dadurch, daß eventuell weitere Hardware gekauft werden muß, um diesen Zusatzservice anbieten zu können. Somit kostet QOS Geld, welches in der Regel auf den Verursacher, also denjenigen, der bevorzugt behandelt wird, umgelegt wird.

Ein QOS, Abrechnungen von verbrauchten Ressourcen und Zugangsbeschränkungen kann man als Regel und somit als Policy betrachten. Damit kann man einem Benutzer Policy-Regeln zuordnen in denen seine Quality-of-Service-Merkmale stehen oder sein Benutzername mit Passwort erfasst sind.

Policies kann man aber auch einem Service zuordnen. Diese Zuordnung kann von der Art sein: 'wenn der Nutzer X (der durchaus wieder ein Service sein darf) den betreffenden Service nutzen will, wird er vorrangig behandelt (oder die Nutzung verweigert)'.

Policies kann man auch einem kompletten Managementsystem zuordnen und festlegen: 'täglich um 22:00 Uhr müssen alle Geräte mit Festplatten, ein Backup ihrer Platten machen' oder 'alle Services, die externe Geräte (Drucker) ansteuern sind zwischen 22:30 und 6:00 Uhr nicht verfügbar, es sei denn, in den Policies des Nutzers steht etwas Gegenteiliges'.

Um Policies innerhalb eines Systems möglichst effizient umsetzen zu können, verwendet man ein Client-Server-System. Dabei übernimmt der Service, welcher einem Nutzer eine Dienstleistung erbringen soll, die Rolle des Clients und fragt bei einem Policy-Service nach, welche Regelungen er für diesen Nutzer anwenden soll. Der Policy-Service wertet die Regeln aus und teilt das Ergebnis dem anfragenden Service mit. Der Policy-Service wird in diesem Fall als PDP bezeichnet. Der anfragende Service bekommt vom PDP eine Art Anweisung, was er zu tun hat und setzt diese Anweisung um. Er übernimmt die Rolle des PEP.