HINTERGRUND DER ERFINDUNG
-
Die vorliegende Erfindung bezieht sich im allgemeinen auf
ein System und ein Verfahren zur Implementierung einer
hierarchischen Politik für das Computer-Systemmanagement.
Insbesondere bezieht sich die vorliegende Erfindung auf
ein System und ein Verfahren zur Implementierung einer
hierarchischen Politik für das Computer-Systemmanagement,
das es einem weniger erfahrenen Systemmanager erlaubt,
schwierigere Tätigkeiten des Systemmanagements
auszuführen, das von einer Vergrößerung des Wirkungsgrades seines
Einsatzes begleitet wird.
-
M. S. Sloman und J. D. Moffet haben mehrere Artikel über
Politik veröffentlicht. Siehe zum Beispiel: Sloman, M. S.,
Moffet, J. D. und Twiddle, K. P.: "Domino Domains and
Policies: An Introduction to the Project Results", Domino
Paper Arch/IC/4, 20. Februar 1992, Dept. of Computing,
Imperial College, University of London; Moffet, J. D. und
Sloman, M. S.: "Representation of Policies as System
Objects", November 1991, SIGOIS Bulletin, Bd. 12,
Nrn. 2 & 3, S. 171-184; und Moffet, J. D. und Sloman,
M. S.: "Policy Conflict Analysis in Distributed System
Management", 12. April 1993, soll im Journal of
Organizational Computing erscheinen. In dem ersten aufgeführten
Artikel führen die Autoren das Prinzip der "Domänen" ein,
die einer gemeinsamen Menge von Politiken eine Menge
gemanagter Objekte zuordnen.
-
Sloman und Moffet beschreiben auch Politikhierarchien.
Die erörterten Hierarchien basieren jedoch lediglich auf
der Verbesserung von problemorientierten allgemeinen
Politiken. Eine problemorientierte Politik kann zum
Beispiel sein: "Schutz vor Verlust", die zu "wöchentliche
Datensicherung" verbessert werden kann. Dieser Zugang ist
äußerst begrenzt und unterscheidet sich grundlegend von
den nachstehend in der vorliegenden Erfindung offenbarten
Prinzipien. Darüber hinaus erörtern Sloman und Moffet
nicht, wie "Einmischungen" von Politiken auf gemanagte
Objekte angewendet werden können, ferner erörtern sie
nicht die Verwendung von Schablonen.
-
Die X/Open enthält ebenfalls eine Politik als einen der
Dienste, die in ihrer Grundstruktur für das
Systemmanagement bereitgestellt werden. Siehe zum Beispiel: X/Open,
"Systems Management: Management Services for an OMG
Environment (Draft 0.5)", 19. Dezember 1994. Der hierin
vorgeschlagene Zugang verwendet das Prinzip der
Politikbereiche, das, obwohl es oberflächlich die in der
vorliegenden Erfindung offenbarten Politikgruppen unterstützt,
keinerlei Vererbungssemantik für Hierarchien derartiger
Politikbereiche spezifiziert und nur zuläßt, daß ein
gemanagtes Objekt nur Mitglied eines einzelnen
Politikbereichs ist. Darüber hinaus läßt X/Open keine vielfachen
Schablonen für den gleichen Objekttyp in einem gegebenen
Politikbereich zu. Kurz, der X/Open-Zugang unterstützt
nicht die Vererbung, die Schablonen und die
Mitgliedschaft der Semantik, die notwendig sind, um eine
zufriedenstellende hierarchische Politik für das Computer-
Systemmanagement angemessen zu implementieren.
-
US-A-5.414.812 (Filip u. a.) schafft ein System für die
Verwendung objektorientierter hierarchischer
Darstellungen, um eine Konfigurationsdatenbank für ein
geschichtetes Kommunikations-Untersystem eines Computernetzes zu
implementieren. Fig. 1 beschreibt ein Netz 10, worin
jeder der Netzcomputer 11, 15, 17, 19 eine
Konfigurationsdatenbank 29 enthält, die eine objektorientierte
Aus
führung für ein
Offene-Kommunikation-Kommunikationsuntersystem (Open systems Interconnection - OSI) verwendet. Es
wird eine Vielzahl von Objektklassen geschaffen, für jede
Schicht des siebenschichtigen ISO-OSI-Computernetzes nach
Fig. 3 wird eine Objektklasse geschaffen (oder eine
Objektklasse wird für eine Schichtenkombination
geschaffen). Zum Beispiel implementiert in Fig. 4 und 5 die
Anwendungsmodus-Objektklasse (Application Mode object
class - APPM) 41 die Sitzungsschicht 5 der Fig. 3 und die
Darstellungsschicht 6 der Fig. 3, während die
Anwendungsinstanz-Objektklasse (Application Entity object
class - APPE) 43 die Anwendungsschicht 7 der Fig. 3
implementiert. Jedes Objekt in jeder Objektklasse ist
durch eine Menge von Attributen definiert, die für dieses
Objekt eindeutig sind. Eine Konfigurationsdatenbank 29
wird in jedem der Computer 11, 15, 17, 19 der Fig. 1
unterhalten. Eine Konfigurationsdatenbank 29 wird
verwendet, um das Netz 10 der Fig. 1 jedesmal, wenn eine
Nachricht von einem Computer zu einem anderen gesendet wird,
zu konfigurieren. Um die Konsistenz/Integrität jeder der
Computer-Konfigurationsdatenbanken 29 sicherzustellen,
implementiert jedes der
Konfigurations-Unterstützungsmodule 27 nach Fig. 1 (die in Fig. 6 in allen Einzelheiten
gezeigt sind), eines für jeden der Computer 11, 15, 17,
19, eine Menge von Validierungsregeln. In Fig. 6 schafft
ein Kommandoverarbeitungs-Unterstützungsabschnitt 90
anfängliche Validierungsprüfungen für
Anwenderdaten/Wechsel, die in der Konfigurationsdatenbank 29 ausgeführt
wurden, und ein Objektunterstützungsabschnitt 100 enthält
eine Menge von sich auf die Konfigurationsdatenbank 29
beziehende Objektunterstützungs- und
Validierungsprogrammen. Fig. 8 zeigt den Prozeß der Erzeugung und
Unterhaltung einer Konfigurationsdatenbank 29. Bei
Schritt 151 gibt der Anwender ein Kommando ein, um ein
Datensegment, das sich auf ein Objekt in einer speziellen
Objektklasse bezieht, hinzuzufügen. Es werden drei
Gül
tigkeitsprüfungen 155, 157, 163 ausgeführt. Wie in Fig. 8
gezeigt ist, endet ein Mißerfolg einer Gültigkeitsprüfung
155, 157, 163 mit einer ERROR MESSAGE (Fehlermeldung).
Wenn keine Ungültigkeit bei 155, 157, 163 gefunden wird,
wird die spezielle Konfigurationsdatenbank 29 bei Schritt
167 ergänzt.
ZUSAMMENFASSUNG DER ERFINDUNG
-
Die vorliegende Erfindung schafft ein System gemäß dem
folgenden Anspruch 1 und ein Verfahren gemäß dem
folgenden Anspruch 8 zur Implementierung einer hierarchischen
Politik für das Computer-Systemmanagement.
-
Das System und das Verfahren der vorliegenden Erfindung
überwindet vorteilhaft die Mängel von derartigen früheren
Zugängen und unterstützt die "Einmischungen", die
Vererbung, Schablonen und die Mitgliedschaftssemantik durch
die Verwendung eines Politikmodells, welches einem
relativ dienstjungen Systemmanager erlaubt, die schwierigeren
Computer-Systemmanagementaufgaben eines dienstälteren
Systemmanagers auszuführen. Wenn so verfahren wird,
werden die Kosten des Systembesitzes gesenkt, indem der
Betrag an Fachkenntnis vermindert wird, der erforderlich
ist, um die Computersysteme eines Unternehmens zu
managen, wodurch eine Verminderung der Anzahl von
dienstälteren Systemmanagern, die für seinen Betrieb erforderlich
sind, ermöglicht wird.
-
Wie hierin offenbart ist, besitzt die Politik zwei
grundlegende Dienste, die verwendet werden, um diese
Verbesserung zu verwirklichen, a) Dienste für die
Standardisierung der Konfiguration des Computersystems; und Dienste
für die Verminderung/Begrenzung des Schadens von nicht
böswilliger Zweckentfremdung des Computersystems.
-
In dem hierin offenbarten System und Verfahren ist
"Politik" spezifiziert in bezug auf: 1) gemanagte Objekte
und 2) gemanagte Objektattribute. Die gemanagten Objekte
sind Abstraktionen von Betriebsmitteln, die durch die
Systemmanager manipuliert werden. Alle gemanagten Objekte
sind Realisierungen einer gemanagten Objektklasse. Ein
gemanagter Objekttyp (oder eine Klasse) beschreibt eine
Gruppe von Objekten mit ähnlichen Eigenschaften
(Attributen), gemeinsamem Verhalten (Operationen),
gemeinsamen Beziehungen zu anderen gemanagten Objekten und
gemeinsamer Semantik. Die Typen (oder Klassen) von
gemanagten Objekten enthalten zum Beispiel: Anwender, Hosts
und Drucker. Ein Beispiel für ein gemanagtes Objekt
könnte ein spezieller Computeranwender sein: "Anwender".
-
Andererseits sind die gemanagten Objektattribute die
Charakteristiken (oder Eigenschaften) eines gemanagten
Objektes. Managementanwendungen manipulieren die
Attribute eines gemanagten Objektes, um ein gemanagtes Objekt
zu managen. Beispiele für mögliche Attribute eines
gemanagten Objekts des Typs: "Anwender" enthalten: den
Anwendernamen, die Anwenderidentifikation ("UID"), die
Gruppenidentifikation ("GID"), das Paßwort, das
Stammverzeichnis und den Standort im Mail-Spooler.
-
Die Systemmanager können die Typen der gemanagten Objekte
oder deren zugeordnete Attribute nicht allgemein
definieren, da neue Typen von gemanagten Objekten im allgemeinen
durch die Entwickler der Betriebsmittel definiert werden
müssen. Die Systemmanager können jedoch gemanagte Objekte
oder definierte gemanagte Objekttypen erzeugen und
löschen, und sie können die Attribute der gemanagten
Objekte, die sie erzeugen, manipulieren.
-
Mit Bezug auf die Politikdienste ist hierin offenbart,
daß ein gemanagtes Objekt aus Attributen bestehen kann,
und Politiken können für jedes der gemanagten
Objektattribute spezifiziert sein. Zum Beispiel kann ein
gemanagtes Objekt der Klasse X die Attribute besitzen: A, B und
C. Jedes dieser Attribute kann eine Politik besitzen. Ein
spezifisches Beispiel einer Politik ist, daß die Länge
des Paßwortattributes eines Anwenderobjekts größer als
sechs Zeichen sein muß. Unter Verwendung des hierin
offenbarten Systems und Verfahrens definiert der
dienstältere Manager folglich eine Politik, indem er die
Ausdrücke spezifiziert, die die Beschränkungen für die
Attribute einer Klasse gemanagter Objekte definieren.
-
Viele Systemmanagementorganisationen besitzen eine
hierarchische Definition der Politiken. Zum Beispiel kann es
Firmen-, Abteilungs- und Gruppenpolitiken geben. Jede
dieser Politiken besitzt einen Einfluß-Geltungsbereich.
Zum Beispiel muß der Firmenpolitik durch das ganze
Unternehmen hindurch gefolgt werden, der Abteilungspolitik muß
überall in der Abteilung gefolgt werden und so weiter.
Diese Charakteristik erzeugt eine Verschachtelung der
Politiken: ein gemanagtes Objekt in einer gegebenen
Abteilung muß der Abteilungs- und der Firmenpolitik
folgen. Daher müssen die Politikdienste eine
Verschachtelung der Politiken unterstützen.
-
Dieses System und dieses Verfahren der hierin offenbarten
vorliegenden Erfindung läßt ebenso zu, Politiken auf eine
hierarchische Art zu spezifizieren. Politiken sind
Politikgruppen zugeordnet, und Politikgruppen können auf eine
hierarchische Art angeordnet werden. Eine Politikgruppe
kann ebenso eine Menge von ihr zugeordneten gemanagten
Objekten besitzen, und die einer gegebenen Politikgruppe
zugeordneten gemanagten Objekte müssen den Politiken
folgen, die der Politikgruppe zugeordnet sind.
KURZBESCHREIBUNG DER ZEICHNUNG
-
Die vorangehenden und andere Merkmale und Aufgaben der
vorliegenden Erfindung sowie die Art ihrer Verwirklichung
werden augenscheinlicher und die Erfindung selbst wird am
besten verstanden durch Bezugnahme auf die folgende
Beschreibung einer zweckmäßigen Ausführung, die in
Verbindung mit der beigefügten Zeichnung gegeben wird,
worin:
-
Fig. 1A eine vereinfachte Darstellung eines universellen
Arbeitsplatzrechners ist, der einen Teil der
Betriebskonfiguration bildet, in welcher die vorliegende Erfindung
verwendet wird;
-
Fig. 1B und 1C die allgemeine Architektur einer möglichen
Implementierung des Systems und des Verfahrens für die
Implementierung einer hierarchischen Politik für das
Systemmanagement der vorliegenden Erfindung erläutern,
unter Verwendung einer Client-Server-Konfiguration, die
die Verwendung des Systems durch einen relativ
dienstjungen Systemmanager (zum Beispiel um ein Anwenderpaßwort zu
ändern) bzw. das Management des Systems durch einen
erfahreneren Systemmanager erläutert, um möglicherweise
durch Hinzufügen, Löschen oder Modifizieren der
Wechselbeziehung zwischen Politiken in einer Politikhierarchie
Politiken zu ändern;
-
Fig. 2 ein repräsentatives Klassenschaltbild ist, das die
Vererbung und die Einschließung in einer möglichen
Klassenhierarchie für ein gemanagtes Objekt erläutert,
welches zum Beispiel einen Host-Computer oder eine
Politikgruppe enthalten kann, die gemanagte Objekte enthält und
worin eine Politikgruppe Kinder hat, welche gemanagte
Objekte sind, und ein gemanagtes Objekt Eltern hat,
welche Politikgruppen sind;
-
Fig. 3 ein vereinfachtes Blockschaltbild einer
Politikbeziehung ist, die drei Politikgruppen besitzt: A, B und C,
jede besitzt verschiedene Politiken, die einen Teil davon
bilden;
-
Fig. 4 ein vereinfachtes Blockschaltbild einer
repräsentativen Einmischung von Politikgruppen ist, die dasselbe
gemanagte Objekt als Mitglied besitzen;
-
Fig. 5 ein vereinfachtes Blockschaltbild einer möglichen
grundlegenden Umgebung für das System und das Verfahren
der vorliegenden Erfindung ist, worin ein repräsentativer
Teil der vorher erläuterten Organisation in funktionale
Untergruppen geteilt ist: Publikationen ("PUBs") und
menschliche Beziehungen (Human Relations - "HR");
-
Fig. 6 ein weiteres Schaltbild der Umgebung nach Fig. 5
ist, das bestimmte, den organisatorischen Funktionen PUBs
bzw. HR zugeordnete Politiken veranschaulicht;
-
Fig. 7 ein weiteres vereinfachtes Schaltbild der
hypothetischen Anordnung des Springs-Standortes ist, das den
vorangegangenen Figuren zugeordnet ist und eine
repräsentative Aufschlüsselung der verschiedenen lokalen Netze
(local area networks - LANs) im Gebrauch zeigt;
-
Fig. 8 ein darauf folgendes Schaltbild ist, das die
Geographie des Springs-Standortes erläutert, die
physische Anordnung der LANs mit ihren jeweiligen Politiken
und die verschiedenen, vorher erläuterten, gemanagten
Objekte;
-
Fig. 9 ein spezifisches Beispiel für eine
Politik-Einmischung für den Anwender "Johnson" ist, worin er ein
Mitglied sowohl der HR- als auch der
Südflügel-LAN-Politikgruppen ist;
-
Fig. 10 ein vereinfachter Blockschaltplan einer einzelnen
Politikgruppe ist, die einer Anzahl von Anwender- und
Host-Schablonen für ein spezielles gemanagtes Objekt
zugeordnet ist;
-
Fig. 11A und 11B ein repräsentativer Ablaufplan für die
Implementierung der hierarchischen Politik für das
Systemmanagement sind, offenbart für die Funktion:
ManagedObject::ValidateProposedValue (AttributeName,
AttributeValue);
-
Fig. 12A und 12B ein repräsentativer Ablaufplan für die
Implementierung der Funktion: PolicyGroup::
GetPolicies(ManagedObjectClass, AttributeName) sind; und
-
Fig. 13 ein repräsentativer Ablaufplan für die
Implementierung der Funktion: User::set_UserIdentifier(newValue)
ist.
BESCHREIBUNG EINER ZWECKMÄßIGEN AUSFÜHRUNG
-
Die Umgebung, in der die vorliegende Erfindung verwendet
wird, umfaßt das allgemeine, dezentrale Computersystem,
worin universelle Computer, Arbeitsplatzrechner oder
Personal-Computer über Kommunikationsverbindungen
verschiedenen Typs verbunden sind, in einer Client-Server-
Anordnung, worin Programme und Daten, viele in der Form
von Objekten, durch verschiedene Mitglieder des Systems
für die Ausführung und den Zugriff durch die anderen
Mitglieder des Systems verfügbar gemacht werden. Einige
der Elemente eines universellen Arbeitsplatzrechners sind
in Fig. 1A gezeigt, worin ein Prozessor 1 gezeigt ist,
der einen Eingabe/Ausgabe-Bereich ("E/A"-Bereich) 2, eine
Zentraleinheit ("CPU") 3 und einen Speicherbereich 4
besitzt. Der E/A-Bereich 2 ist mit einer Tastatur 5,
einer Anzeigeeinheit 6, einer Plattenspeichereinheit 9
und einer Compact-Disk-Festwertspeicher-Laufwerkseinheit
("CDROM"-Laufwerkseinheit) 7 verbunden. Die CDROM-Einheit
7 kann einen CDROM-Datenträger 8 lesen, welcher typisch
Programme 11 und Daten enthält. Die
Computerprogrammprodukte, die die Mechanismen enthalten, um die Vorrichtung
und die Verfahren der vorliegenden Erfindung zu
verwirklichen, können in dem Speicherbereich 4 oder auf einer
Plattenspeichereinheit 9 oder auf der CDROM 8 eines
derartigen Systems stehen.
-
In Fig. 1B und 1C ist die allgemeine Architektur einer
möglichen Implementierung des Computersystems 10 gezeigt,
welches das System und das Verfahren für die
Implementierung einer hierarchischen Politik für das
Systemmanagement der vorliegenden Erfindung verwendet, zum Beispiel
unter Verwendung einer Client-Server-Konfiguration.
-
Die Verwendung des Computersystems 10 durch einen
dienstjungen Systemmanager 12 ist in Fig. 1B gezeigt, worin der
Systemmanager 12 über eine (nicht gezeigte)
Anwenderschnittstelle auf den Client-Computer 14 zugreift. Der
Client-Computer 14 besitzt eine direkt zugeordnete
Datenbank 18. Der Client-Computer 14 ist ebenfalls mit einem
Server-Computer 20 verbunden, der eine vorherbestimmte
Politikgruppe besitzt, die eine Anzahl von Politiken 22
besitzt, die dieser zugeordnet ist, wie nachstehend
ausführlicher beschrieben werden wird. Der
Server-Computer 20 besitzt ebenfalls eine zugeordnete Datenbank 24,
welche auf einem internen oder externen
Computer-Massenspeicher-Untersystem stehen kann. In der erläuterten
Client-Server-Ausführung kann der Großteil der Politiken
22 in der Datenbank 24 des Server-Computers 20 stehen,
obwohl es ebenso möglich ist, daß sie anderswo in dem
Computersystem 10 resident ist.
-
Andererseits ist das Management des Computersystems 10 in
Fig. 1C gezeigt, worin ein dienstälterer Systemmanager
als eine Systemmanagementfunktion 26 erläutert ist, die
über eine (nicht gezeigte) Anwenderschnittstelle auf
einen Client-Computer 14 zugreift, um die verschiedenen
Politiken 22 einer Politikgruppe für den Server-Computer
20 anfänglich herzustellen, welche in einer zugeordneten
Datenbank 24 gespeichert sein können. Die
Systemmanagementfunktion 26 erlaubt dem dienstälteren Systemmanager,
die Hierarchie zwischen den verschiedenen Politiken 22
innerhalb einer speziellen Hierarchie zu ändern, und die
Politiken 22 innerhalb einer speziellen Hierarchie
hinzuzufügen, zu löschen oder zu modifizieren. Das Management
des in Fig. 1C gezeigten Computersystems 10 ist im
gewissen Sinn mit der in Fig. 1B erläuterten Verwendung
rekursiv, in Anbetracht der Tatsache, daß die Verwendung des
Computersystems 10 ebenfalls ein Management von ihm ist.
-
Wenn in dem speziellen erläuterten Beispiel der
Systemmanager 12 die Attribute eines speziellen Anwenders ändern
muß, zum Beispiel das Paßwort des Anwenders, wird auf den
Client-Computer 14 direkt über die Anwenderschnittstelle
zugegriffen, wie es in Fig. 1B gezeigt ist. Der Client-
Computer 14 führt dann eine Anforderung an den Server-
Computer 20 aus, der dann durch die in seiner Datenbank
24 unterhaltenen Politiken 22 läuft, um zu bestimmen,
welche zu der spezifischen Anforderung passen. Die
Politiken 22, die danach zu dem Client-Computer 14
zurückgeleitet werden, sind die, die der dienstältere
Systemmanager früher und unabhängig bestimmt hat, die für die
spezielle Anforderung relevant waren und die in die
Datenbank 24 des Sever-Computers 20 eingegeben wurden,
wie in Fig. 1C gezeigt ist. Die für die Anforderung
relevanten und an den Client-Computer 14 zurückgeleiteten
Politiken 22 werden dann in der Datenbank 18 gespeichert
und ausgewertet. Wenn die durch den dienstjüngeren
Systemmanager 12 beabsichtigte Paßwortänderung alle von dem
Server-Computer 20 zurückgeleiteten Politiken 22
passiert, kann die Änderung ausgeführt werden.
-
In Fig. 2 erläutert ein repräsentatives Klassenschaltbild
30 die Vererbung in einer möglichen Klassenhierarchie für
ein gemanagtes Objekt, das zum Beispiel einen
Host-Computer 34 oder eine Politikgruppe 36, die die gemanagten
Objekte 32 enthält, enthalten kann. Wie beschrieben ist,
hat die Politikgruppe 36 Kinder, die die gemanagten
Objekte 32 sind. Ein gemanagtes Objekt 32 hat Eltern, die
die Politikgruppen 36 sind. Wie nachstehend mit Bezug auf
repräsentative Pseudocodes für die Implementierung des
Systems und des Verfahrens der vorliegenden Erfindung und
auf die entsprechenden Ablaufpläne nach Fig. 11A-B, 12A-B
und 13 ausführlicher beschrieben wird, gibt es eine
Wechselbeziehung zwischen den gemanagten Objekten 32 und
den Politikgruppen 36, die objektorientierte ("OO")
Programmierungsprinzipien verwenden.
-
Unter Verwendung der OO-Prinzipien kann eine Anzahl von
Klassen definiert werden, die ihrerseits zu den
Objekttypen in Beziehung stehen können. Diese Klassen werden dann
in Unterklassen von Klassen verfeinert. Als ein Beispiel
könnte eine Klasse "Personen" (ein gemanagtes Objekt 32)
enthalten, mit Unterklassen von "Personen", die
"Angestellte" (eine Politikgruppe 36) sind. Eine
"Adresse" kann der Klasse der "Personen" zugeordnet
werden, während "Gehalt" den "Angestellten" zugeordnet
sein kann. Unter Verwendung einer stufenweisen
Verfeinerung erben die "Angestellten" (eine Politikgruppe 36)
alle Charakteristiken der "Personen" (ein gemanagtes
Objekt 32), einschließlich der Namen, Adressen und
ähnli
chem.
Mit anderen Worten, ein gemanagtes Objekt 32 kann
Unterklassen besitzen, z. B. den Host 34 und die
Politikgruppe 36, und eine Politikgruppe 36 kann eine Überklasse
besitzen, z. B. das gemanagte Objekt 32.
-
In Fig. 3 ist eine beispielhafte Politikanordnung 60
gemäß der vorliegenden Erfindung gezeigt. Die
Politikanordnung 60 erläutert drei Politikgruppen: Politikgruppe
A 42, Politikgruppe B 46 und Politikgruppe C 48. Wie
früher erwähnt wurde, ist eine Politik durch einen
gemanagten Objekttyp und ein Attribut definiert. In der
Politikgruppe A 42 befinden sich zwei Politiken. Die
erste Politik steht für das Paßwortattribut des
Anwendertyps. Diese Politik legt fest, daß die Länge des
Paßwortattributes größer als sechs Zeichen sein muß. Das
bedeutet, daß das anwendergemanagte Objekt Jones 44, das ein
Mitglied der Politikgruppe A 42 ist, ein Paßwort besitzen
muß, daß größer als sechs Zeichen ist. Die zweite Politik
steht für die Auslagerungsplatzattribute eines gemanagten
Objekts des Host-Typs. Diese zweite Politik legt fest,
daß der Wert des Auslagerungsplatzattributes größer als
200 sein muß.
-
Es ist ebenso wichtig anzumerken, daß eine gegebene
Politikgruppe Politiken für vielfache Typen gemanagter
Objekte enthalten kann. In dem Beispiel nach Fig. 4 ist
zu erkennen, daß die Politikgruppe A 42 sowohl eine
Politik für Hosts als auch für Anwender enthält.
-
Die Politikgruppe B 46 und die Politikgruppe C 48 sind
"Kinder" der Politikgruppe A. Das bedeutet, daß die
Politikgruppen B und C 46, 48 den Politiken in der
Politikgruppe A 42 zusätzlich zu ihren lokal definierten
Politiken folgen müssen. Daher müssen gemanagte Objekte
des Anwendertyps (z. B. das anwendergemanagte Objekt
Smith 52), die Mitglieder der Politikgruppe B 46 sind,
der in der Politikgruppe A 42 definierten
Anwenderpaßwort-Längenpolitik und der lokal definierten Politik für
das GID-Attribut des Anwendertyps (worin GID gleich 41
sein muß) folgen. Außerdem muß das hostgemanagte Objekt
Cheyenne 50 ebenso den Hostpolitiken folgen, die von der
Politikgruppe A 42 geerbt wurden. Das heißt, der Wert des
Auslagerungsplatzattributes von Cheyenne 50 muß größer
als 200 sein.
-
Die Politikgruppe C 48 besitzt eine Politik, die für
dieselben gemanagten Objekttypen und Attribute definiert
ist wie für eine seiner Eltern (z. B. Anwenderpaßwort).
In dieser Situation muß ein anwendergemanagtes Objekt,
z. B. das anwendergemanagte Objekt Johnson 54, das ein
Mitglied der Politikgruppe C 48 ist, sowohl die Politiken
der Eltern (Politikgruppe A 42) für das Anwenderpaßwort
als auch seine lokalen Politiken für das Anwenderpaßwort
befriedigen. Folglich muß das Paßwortattribut für ein
anwendergemanagtes Objekt Johnson 54, welches ein
Mitglied der Politikgruppe C 48 ist, eine Paßwortlänge
besitzen, die größer ist als sechs Zeichen (laut
Politikgruppe A 42), ferner muß das Paßwort ein numerisches
Zeichen enthalten (laut Politikgruppe 48). Es ist
anzumerken, daß, obwohl es möglich ist, widersprüchliche
Politiken in den Eltern und Kindern zu erzeugen, die
unmöglich zu befriedigen sind, die Annahme gemacht wurde,
daß die Bestimmung der Politikkonflikte und die Korrektur
dieser Konflikte durch die dienstälteren Systemmanager
ausgeführt werden wird.
-
In Fig. 4 ist jetzt ein Beispiel einer
Politik-Einmischung 60 gezeigt. Als Hintergrund sei angemerkt, daß es
eine Anzahl von "Typen" von Politiken gibt, die die
Systemmanager definieren können. Als ein Beispiel kann
ein Systemmanager Regeln für die Optimierung der Leistung
definieren. Diese Regeln können sich auf die physischen
Standortverhältnisse zwischen den gemanagten Objekten
stützen (eine geographische Grundlage) oder diese Regeln
können sich auf die spezielle Implementierung eines
speziellen Betriebsmittels stützen. Ein spezifisches
Beispiel kann die Absicherung sein, daß das System, das
den Mail-Spool für einen gegebenen Anwender unterhält,
auf dem gleichen LAN steht, welches das Büro des
Anwenders mit dem Netz verbindet.
-
Ein Systemmanager kann ebenso Regeln definieren, die
helfen, die Sicherheit und die Verantwortlichkeit eines
Betriebsmittels abzusichern, und diese Regeln können sich
zum Beispiel auf die Beziehungen eines gegebenen Objekts
zwischen den Unternehmensorganisationen stützen (eine
organisatorische Grundlage). Spezifische Beispiele können
die Zuordnung derselben GID zu allen Mitgliedern einer
gegebenen Organisation oder eines Projektes enthalten,
oder zu sichern, daß dieselben Regeln für die
Paßwortauswahl durch alle Mitglieder einer gegebenen Anwendergruppe
befolgt werden (z. B. muß die Länge eines Paßwortes
größer als 6 Zeichen sein).
-
Ein Systemmanager kann weiter Regeln definieren, um die
Standardisierung der Systemkonfiguration zu sichern (eine
Grundlage der Standardisierung der Konfiguration). Oft
stützen sich diese Regeln auf den Typ und die spezielle
Verwendung eines gegebenen Betriebsmittels. Beispiele
enthalten das Definieren eines gemeinsamen Musters für
den Standort der Postdatei (z. B. /var/mail/< username> ).
-
Wie aus den vorangehenden Beispielen offensichtlich ist,
kann ein gegebenes gemanagtes Objekt 68 einige Attribute
besitzen, die durch Leistungsüberlegungen beherrscht
werden, einige Attribute werden durch
Sicherheitsüberlegungen beherrscht und einige Attribute werden durch
Überlegungen zur Standardisierung der Konfiguration
beherrscht. Gegeben durch den weiten Bereich von
Überlegungen oder Typen von Politiken ist es außerdem sehr
unwahrscheinlich, daß der Systemmanager diese
Politiktypen in einer einzelnen Hierarchie verknüpfen will, und
der Systemmanager kann spezialisierte Hierarchien für
verschiedene Politiktypen definieren wollen.
-
Getrennte, auf dem "Typ" der Politik basierende
Hierarchien lassen einen Zugang der Politik-Einmischung 60 zu
der Politikzuordnung zu einem speziellen gemanagten
Objekt 68 zu. Ein Systemmanager kann deshalb ein
gegebenes gemanagtes Objekt den spezialisierten
Politikbereichen zuordnen, die die gewünschten Politiken
bereitstellen. Folglich kann, wie es in Fig. 4 gezeigt ist, ein
gegebenes anwendergemanagtes Objekt 68 ein Mitglied eines
Politikbereiches, welcher auf Sicherheitspolitik
spezialisiert ist (z. B. eine organisatorisch gestützte
Politikgruppe 64), ein Mitglied eines Politikbereiches,
welcher auf Leistung spezialisiert ist (z. B. eine
geographisch gestützte Politikgruppe 62), und ein Mitglied
eines Politikbereiches, der die Standardisierung der
Konfiguration unterstützt (z. B. eine auf die
Standardkonfiguration gestützte Politikgruppe 66), sein.
-
Unter Bezugnahme auf die Fig. 5, 6 und 7 und den
folgenden Text kann das Prinzip der Politiken und
Politikgruppen besser verstanden werden. In dieser beispielhaften
Erläuterung wird die Annahme gemacht, daß der Anwendertyp
des gemanagten Objekts (Jones 76, Smith 78, Johnson 80
und Jackson 82) die folgenden Attribute besitzen kann:
Name, UID, GID, Paßwort, Mail-Spooler und
Stammverzeichnis. Die grundlegenden Bedingungen und die Umgebung für
die Erläuterung sind, daß die anwendergemanagten Objekte
ein Teil einer Organisation sind, die durch eine gegebene
Menge von Systemmanagern gemanagt wird, d. h. die
Springs-Organisation 70.
-
Die Springs-Organisation 70 ist physisch auf zwei lokale
Netze verteilt: das Südflügel-LAN 90 und das Nordflügel-
LAN 92, und ist ebenfalls ferner in auf die Funktion
gestützten Unterorganisationen geteilt: die HR-Gruppe 74
und die PUBs-Gruppe 72. Die PUBs-Gruppe 72 hat die
Anwender: Jones 76 und Smith 78, während die HR-Gruppe 74 die
Anwender Johnson 80 und Jackson 82 hat. Die durch das
Nordflügel-LAN 92 versorgten Büros enthalten Johnsons
Büro 106 und Jacksons Büro 108. Die durch das Südflügel-
LAN 90 versorgten Büros enthalten Jones Büro 102 und
Smiths Büro 104.
-
In dem erläuterten Beispiel wird angenommen, daß die
folgenden Politiken Politiken der Springs-Organisation 70
sind:
-
1) Der Standort des Mail-Spoolers und das
Stammverzeichnis müssen lokal in dem LAN sein, in dem das
Büro des Anwenders vorhanden ist.
-
a) was das Nordflügel-LAN 92 anbelangt:
-
i. der Mail-Spooler für Anwender,
deren Büros durch dieses LAN 92 versorgt
werden, muß der Host Springs 98 sein; und
-
ii. das Stammverzeichnis für
Anwender, deren Büros durch dieses LAN 92 versorgt
werden, müssen sich auf den Hosts Rocky 100
oder Springs 98 befinden.
-
b) was das Südflügel-LAN 90 anbelangt:
-
i. der Mail-Spooler für Anwender,
deren Büros durch dieses LAN 90 versorgt
werden, muß der Host Mastermind 94 sein; und
-
ii. das Stammverzeichnis für
Anwender, deren Büros durch dieses LAN 92 versorgt
werden, müssen sich auf den Hosts Mastermind
94 oder Cheyenne 96 befinden.
-
2) Alle Anwender der Springs-Organisation 70 müssen
ein Paßwort besitzen, dessen Länge größer als 6
Zeichen ist.
-
3) Jede der Untergruppen der Springs-Organisation 70
muß eine andere GID und jedes Mitglied einer
Untergruppe muß die gleiche GID besitzen.
-
4) Alle Anwender in der HR-Gruppe 74 müssen außer dem
Besitz eines Paßwortes, dessen Länge größer als 6
Zeichen ist, ebenso ein nicht-alphabetisches Zeichen
in ihrem Paßwort haben.
-
Die folgenden Politikmengen und Politikgruppen
befriedigen die vorangehenden Beschränkungen:
-
1. Politikgruppe der Springs-Organisation 70
-
a. Politiken: Länge des Anwenderpaßwortes > 6
Zeichen
-
b. Mitglieder: PUBs-Politikgruppe 72, HR-
Politikgruppe 74
-
2. PUBs-Politikgruppe 72
-
a. Politiken: Anwender-GID = 40
-
b. Mitglieder: Smith 78, Jones 76
-
3. HR-Politikgruppe 74
-
a. Politiken: Anwender-GID = 41,
Anwenderpaßwort muß ein nichtnumerisches Zeichen enthalten
-
b. Mitglieder: Johnson 80, Jackson 82
-
4. Politikgruppe des Nordflügel-LAN 92
-
a. Politiken: Mail-Spooler des
Anwenders = Springs 98, Stammverzeichnis des Anwenders
muß entweder Rocky 100 oder Springs 98 sein.
-
b. Mitglieder: Jacksons Büro 108, Johnsons
Büro 106.
-
5. Politikgruppe des Südflügel-LAN 90
-
a. Politiken: Mail-Spooler des
Anwenders = Mastermind 94, Stammverzeichnis des
Anwenders muß entweder Mastermind 94 oder Cheyenne 96
sein.
-
b. Mitglieder: Jones's Büro 102, Smiths Büro
104
-
Wie vorher angemerkt wurde, können Politikgruppen
verschachtelt werden. Das heißt, eine Politikgruppe kann
andere Politikgruppen enthalten. Spezifisch in Fig. 6
erbt eine Politikgruppe, die von anderen Politikgruppen
eingeschlossen ist, die Politiken, die durch die
einschließenden Gruppen definiert sind. In dem obigen
Beispiel erben die Mitglieder der HR- und
PUBs-Politikgruppen 74, 72 die Politiken von der Politikgruppe der
Springs-Organisation 70 (Länge des
Anwenderpaßwortes > 6). Außerdem müssen die Mitglieder der HR-Gruppe 74
die Beschränkungen hinsichtlich des Anwenderpaßwortes
befriedigen, worin es zumindest ein nicht-alphabetisches
Zeichen enthalten muß. Schließlich müssen die Mitglieder
der HR-Gruppe 74 ebenso eine GID von 41 besitzen, und die
Mitglieder der PUBs-Gruppe 72 müssen eine GID von 40
besitzen.
-
Ein gemanagtes Objekt kann ein Mitglied von mehreren
Politikgruppen sein. In dem obigen Beispiel und
zusätzlich speziell in Fig. 8 ist die allgemeine
Springs-Geographie 110 gezeigt. Als ein Beispiel ist der Anwender
Jackson 82 ein Mitglied der HR-Gruppe (Fig. 5 und 6) und
der Politikgruppen des Nordflügel-LAN 92 (Fig. 7).
Folglich besitzt der Anwender Jackson die auf ihn
angewendeten Politiken der HR-Gruppe 74 (Länge des
Anwenderpaßwortes > 6, Anwenderpaßwort muß auch ein
nicht-alphabetisches Zeichen enthalten und die Anwender-GID muß gleich
41 sein) und die auf ihn angewendeten Politiken des
Nordflügel-LAN 92 (Mail-Spooler des Anwenders = Springs
98, Stammverzeichnis des Anwenders muß entweder Rocky 100
oder Springs 98 sein).
-
Wie in Fig. 9 in einem vereinfachten Format gezeigt ist,
ist der Anwender Johnson 106 sowohl ein Mitglied der HR-
Politikgruppe 112 als auch der
Nordflügel-LAN-Politikgruppe 114. Ähnliche Erläuterungen, die veranschaulichen,
welche Politiken auf die Anwender Jones 76 und Smith 78
angewendet werden, können leicht hergestellt werden, um
deren Mitgliedschaft in mehreren Politikgruppen und die
Politiken der jeweiligen Politikgruppen zu beschreiben.
-
Der dienstältere Systemmanager kann verbindliche und
beratende Politiken besitzen. Eine verbindliche Politik
läßt nicht zu, daß eine vorgeschlagene Änderung
ausgeführt wird, wenn sie die Politik verletzt. Andererseits
würde eine beratende Politik die Politikverletzung
identifizieren und es zulassen, das Objekt zu sicheren.
-
Wenn ein Attribut eines gemanagten Objektes zu
modifizieren ist, wird der vorgeschlagene Wert überprüft, um zu
bestätigen, daß der vorgeschlagene Wert die Politiken in
all den Politikgruppen befolgt, in denen das gemanagte
Objekt Mitglied ist. Wenn der vorgeschlagene Wert die
Politik nicht befolgt, dann wird die vorgeschlagene
Modifizierung des Attributes nicht zugelassen.
-
Es ist anzumerken, des es für ein gemanagtes Objekt in
einer gegebenen Gruppe möglich ist, den Politiken der
Gruppe nicht zu folgen, wenn die Politiken der Gruppe
verändert wurden, nachdem das gemanagte Objekt vorher ein
Mitglied der Gruppe geworden ist. Diese Mitglieder werden
nicht aus der Politikgruppe entfernt. Diese Mitglieder
werden als nicht der Politik folgend markiert.
-
In dieser Hinsicht ist es wichtig zu betonen, daß
Anwendungen, die die Attribute eines gemanagten Objektes
manipulieren, im Idealfall zu modifizieren sind, um die
Überprüfungsroutinen zur Validierung der Politik
aufzuru
fen. Trotzdem kann die Sicherung, daß gemanagte Objekte
nur durch Anwendungen modifiziert werden können, die eine
Politiküberprüfung ausführen, nicht völlig machbar sein.
Als eine Folge können andere Anwendungen modifiziert
werden müssen, um die gemanagten Objekte periodisch
abzutasten und die Menge der gemanagten Objekte
zurückzuleiten, die der Politik nicht folgen.
-
In Fig. 10 ist eine Politikgruppe 120 im Zusammenhang mit
einem Paar Anwenderschablonen 122, 124, einer
Host-Schablone 126 und einem gemanagten Objekt 128 gezeigt. Gemäß
dem System und dem Verfahren der vorliegenden Erfindung
können sowohl die Schablonen als auch die Klone verwendet
werden, um die anfänglichen Werte für die Attribute
bereitzustellen, wenn ein gemanagtes Objekt 128 erzeugt
wird. Die Schablonen 122-126 sind Politikgruppen
zugeordnet, und die in der Schablone spezifizierten Werte für
die Attribute müssen den Politiken, die der Politikgruppe
120 zugeordnet sind, folgen. Wie gezeigt ist, kann die
Politikgruppe 120 mehreren Schablonen 122-126 für den
gleichen Typ gemanagter Objekte 128 zugeordnet sein. Eine
Politikgruppe kann ebenfalls mehreren Schablonen für
verschiedene Typen gemanagter Objekte (z. B. die
Anwenderschablonen 122, 124 und die Host-Schablone 126)
zugeordnet sein. Nicht alle der Attribute einer Schablone
müssen spezifizierte Werte besitzen.
-
Gemäß der vorliegenden Erfindung können Schablonen ebenso
verwendet werden, um für den dienstjüngeren Systemmanager
die Hierarchie der Politikgruppen zu vereinfachen.
Schablonen können auf eine Art ähnlich wie Lesezeichen
verwendet werden, um dem dienstjüngeren Systemmanager
anzuzeigen, welche Politikgruppen er in neuen Ausprägungen
erzeugen kann. Diese Funktionalität sollte eng mit der
Anwenderschnittstellen-Technologie des Computersystems 10
(Fig. 1B und 1C) zusammengefügt werden.
-
Das System und das Verfahren der vorliegenden Erfindung
unterstützt ebenso das Klonen gemanagter Objekte. Ein
Klon besitzt all die gleichen Werte der Attribute des
Originals, ausgenommen die Attribute, die verwendet
werden, um die Ausprägung des Objektes zu identifizieren.
Außerdem ist der Klon ein Mitglied all der gleichen
Politikgruppen wie das Original. Das Original muß ein
gemanagtes Objekt sein, das all den seinen
Mitgliedschaften zugeordneten Politiken folgt.
-
Unter Verwendung des obigen Beispiels mit Bezugnahme auf
die vorangegangenen Figuren und mit der Annahme, daß der
Systemmanager einen neuen Anwender der HR-Gruppe 74
erzeugen will, der ebenso ein Büro besitzt, welches durch
das Nordflügel-LAN 92 versorgt wird, dann könnte der
Systemmanager zum Beispiel den Anwender Jackson 82
klonen. Der Klon wäre ein Mitglied der HR-Politikgruppe 74
und der Politikgruppe des Nordflügel-LAN 92.
-
Das Klonen und die Verwendung von Schablonen sparen dem
Systemmanager Zeit, da nicht alle Systemmanager die
Semantik lernen und die geeigneten Werte für jedes
Attribut bestimmen müssen. In dieser Hinsicht kann ein
dienstälterer Systemmanager das "Original" oder die Schablone
für den Gebrauch durch die dienstjüngeren Systemmanager
definieren. Überdies muß der Systemmanager nicht die
Werte für jedes der Attribute manuell eingeben, und er
kann lediglich die Werte des Klones oder der Schablone
akzeptieren. Das führt dazu, daß der Systemmanager
effizienter wird und weniger zu Eingabefehlern neigt.
Schließlich kann die disziplinierte Verwendung von Klonen
und Schablonen viel zur Sicherung der Standardisierung
der Konfigurationen gemanagter Objekte beitragen.
-
In den Fig. 11A und 11B ist zusätzlich ein
repräsentativer Ablaufplan für die Implementierung der Funktion zur
Bestimmung, ob ein vorgeschlagenes Attribut für ein
gemanagtes Objekt der Politik folgt oder nicht, im
Zusammenhang mit dem folgenden Pseudocode des Blocks 1 für die
Implementierung des Prozesses gezeigt. Der nachstehend
bereitgestellte Pseudocode ahmt für die Erleichterung des
Verständnisses den von bekannten OO-Programmiersprachen
nach, z. B. C++ und SmalltalkTM.
-
Der Prozeß 130 beginnt bei Schritt 132, ein Ergebnis=wahr
zuzuweisen, und dann wird bei Schritt 134 eine Menge
namens set_of_policies_for_eval erzeugt. Dann folgt
Schritt 136, in dem eine Eltern-Iterationseinrichtung
erzeugt und an den Anfang der set_of_parent_PolicyGroup-
Menge gesetzt wird.
-
Nach dem Entscheidungsschritt 138 ruft, wenn sich die
Eltern-Iterationseinrichtung nicht am Ende der
set_of_parent_olicyGroup-Menge befindet, bei dem Schritt
140 die Politikgruppe, auf die durch die
Eltern-Iterationseinrichtung gezeigt wird, die Funktion getPolicies auf
und weist das Ergebnis tmp_set zu. Bei den Schritten 142
und 144 werden die Mitglieder von der tmp_set zu der
set_of_policies_for_eval hinzugefügt, und die Eltern-
Iterationseinrichtung wird zu dem nächsten Mitglied der
set_of_parent_PolicyGroup-Menge bewegt. Wenn sich jetzt
andererseits bei dem Entscheidungsschritt 138 die Eltern-
Iterationseinrichtung an dem Ende der
set_of_parent_PolicyGroup-Menge befindet, bei Schritt
140, geht der Prozeß 130 zu Schritt 146 über, um die
Politik-Iterationseinrichtung an den Anfang der
set_of_policies_for_eval-Menge zu setzen.
-
Bei dem Entscheidungsschritt 148 wird die
Iterationseinrichtung ausgewertet, um zu bestimmen, ob er auf das Ende
der set_of_policies_for_eval zeigt oder nicht. Wenn das
wahr ist, geht der Prozeß zu Schritt 156 über, um das
Ergebnis zurückzuleiten. Wenn das falsch ist, geht der
Prozeß zu dem Entscheidungsschritt 150 über, um zu
bestimmen, ob die Politik, auf die durch die
Iterationseinrichtung gezeigt wird, für den vorgeschlagenen Wert
gültig gesetzt wird (AttributeValue), oder wahr (gültig)
zurückleitet. Wenn das falsch ist, geht der Prozeß zum
Schritt 152 über, um Ergebnis=falsch zuzuweisen, und dann
zu Schritt 154, um die Politik-Iterationseinrichtung zu
dem nächsten Mitglied der set_of_policies_for_eval-Menge
zu bewegen, dann zurück zu dem Entscheidungsschritt 148.
Wenn das wahr ist, wird Schritt 152 umgangen, direkt zu
Schritt 154 für den Rücksprung zu dem
Entscheidungsschritt 148.
-
Im Grunde weist der Programm-Prozeß 130 den
Server-Computer 20 (Fig. 1B) an, alle Politiken der Eltern des
gemanagten Objektes von seiner Datenbank 24 auszulesen, die
in Beziehung zu einem speziellen Attribut des gemanagten
Objektes stehen. Die zurückgeleiteten Politiken werden
dann in bezug auf den vorgeschlagenen Wert ausgewertet,
und wenn der Wert eine der Politiken verfehlt, scheitert
der vorgeschlagene Wert für das Attribut. Um zu
bestimmen, welche Politiken der verschiedenen Eltern
zurückzuleiten sind, verläßt sich das System auf die
Politikgruppe, um zu bestimmen, wer die Eltern des gemanagten
Objektes sind, und ob sie irgendwelche Politiken
besitzen, die sich auf den vorgeschlagenen Wert des Attributes
(d. h. Anwenderpaßwörter) beziehen, oder nicht. In
Wirklichkeit wird durch den Server-Computer 20 und seine
zugeordnete Datenbank 24, welche früher durch den
dienstälteren Systemmanager (Fig. 1C) eingegeben wurde, eine
rekursive Durchsuchung des Baums der Politikgruppen
unternommen.
Block 1:
Class ManagedObject
-
class ManagedObject
-
/* Attribute */
-
name;
-
set_of_parent_PolicyGroups;
-
/* Funktionen */
-
validateProposedValue(AttributeName, AttributeValue):
-
return (boolean);
-
polymorphic class_of_self():
-
returns (the narre of the class of the
caller);
-
end class ManagedObject
-
/* Funktionsdefinitionen für Managedcbject */
-
validateProposedValue(AttributeName, AttributeValue)
-
create empty set_of_policies_tor_eval;
-
passedPolicy = TRUE;
-
for each parent in set_of_parent_PolicyGroups do
set_of_policies =
Parent.getPolicies(class_of__
self(),AttributeName);
-
add set of policies to
set_of_policies_for_eval;
-
end for loop;
-
for each policy in set_of_policies_for_eval
do
-
if (policy.validate(AttributeValue) == FALSE)
then
-
passedPolicy = False;
-
end if
-
end for loop;
-
return passedPolicy;
-
end function validateProposedValue;
-
In den weiteren Fig. 12A-12B ist ein repräsentativer
Prozeßablauf 160 gezeigt, um das Auslesen der anwendbaren
Politiken zu ermöglichen, wenn der Klassenname des
gemanagten Objektes und der Name des gemanagten
Objektattributes (d. h. Paßwort) gegeben ist. Der erläuterte
Prozeßablauf 160 ahmt den Pseudocode des folgenden Blocks 2
nach.
-
Bei Schritt 162 wird eine Menge namens
return_set_of_policies erzeugt, und eine
Politik-Iterationseinrichtung wird erzeugt und bei Schritt 164 auf den
Anfang von set_of_policies gesetzt. Bei dem
Entscheidungsschritt 166 wird die Politik-Iterationseinrichtung
getestet, um zu bestimmen, ob er sich am Ende von
set_of_policies befindet. Wenn das wahr ist, wird die
Eltern-Iterationseinrichtung bei Schritt 174 auf den
Anfang der set_of_parent_PolicyGroup gesetzt. Wenn das
falsch ist, wird beim Entscheidungsschritt 168 der class-
Name und der Name der Politik, auf die durch die
Iterationseinrichtung gezeigt wird, getestet, um zu bestimmen,
ob er der gleiche wie die ManagedObject-Klasse und der
attributName ist, der in diese Funktion weitergegeben
wurde.
-
Wenn das wahr ist, wird die Politik, auf die die
Iterationseinrichtung zeigt, bei Schritt 170 zu der
return_set_of_policies hinzugefügt und die
Iterationseinrichtung wird bei Schritt 172 zu dem nächsten Mitglied
von der set_of_policies bewegt. Wenn das falsch ist, wird
der Schritt 170 umgangen und der Prozeß 160 geht zum
Schritt 172 über und springt dann zu dem
Entscheidungsschritt 166 zurück.
-
Dem Schritt 174 folgend bestimmt der Entscheidungsschritt
176, ob die Eltern-Iterationseinrichtung auf das Ende von
set_of_parent_PolicyGroup zeigt. Wenn das wahr ist, geht
dann der Prozeß direkt zum Schritt 184 über, um
return_set_of_policies zurückzuleiten. Wenn das falsch ist,
wird bei Schritt 178 der Wert set_of_policies zugewiesen,
der von dem Aufruf nach getPolicies(className_of_
ManagedObject, name_of_attribute) für das Elternteil
zurückgesandt wird, auf das durch die
Eltern-Iterationseinrichtung gezeigt wird. Danach wird bei Schritt
180 die set_of_policies zu der return set_of_policies
hinzugefügt, und bei Schritt 182 wird die
Iterationseinrichtung zu dem nächsten Mitglied der
set_of_parent_PolicyGroup bewegt. Der Prozeß 160 springt
dann zu dem Entscheidungsschritt 176 zurück.
-
Im Betrieb wird eine Durchsuchung erst auf allen lokal
definierten Politiken ausgeführt, d. h., den Politiken,
die lokal zu der Politikgruppe sind. Sie werden
analysiert, um zu bestimmen, ob es eine Übereinstimmung in dem
Klassennamen und dem Attributnamen gibt. Falls eine
Übereinstimmung gefunden wird, wird die Politik in die
Menge gelegt, die zurückgeleitet werden wird. Nach der
lokalen Durchsuchung werden die Eltern abgefragt, was die
Politiken für die spezielle Klasse und das spezielle
Attribut anbelangt, und die zurückgeleiteten Politiken
werden ebenso zu der Menge der zurückzuleitenden
Politiken hinzugefügt. Die vervollständigte Menge wird dann
zurückgeleitet, und diese wird dann zu dem gemanagten
Objekt weitergegeben, das die Anforderung ausgeführt hat,
wo die Auswertung was Politik-Konformität anbelangt
stattfindet.
Block 2:
Class PolicyGroup
-
class PolicyGroup subclass of ManagedObject
/* Attribute */
-
set_of_children_ManagedObjects;
-
set_of_policies;
-
/*_Funktionen */
-
getPolicies(class_of_ManagedObject,
name_of_attribute):
-
returns (a set of policies);
-
class_of_self ();
-
end class PolicyGroup
/* Funktionsdefinitionen für PolicyGroup */
-
function getPolicies(className_of_ManagedObject,
name_of_attribute)
-
create an empty return_set_of_policies;
-
for each policy in set_of_policies do:
-
if(policy.classname == class-
Name_of_ManagedObject AND policy.attributeName ==
name_ofattribute)
-
then
-
add policy to return_set_of_policies;
-
end if;
-
end for loop;
-
for each parent in set_of_parent_PolicyGroups do:
-
set_of_policies =
-
Parent.getPolicies(className_of_ManagedObject,
name_of_attribute);
-
add set_of_policies to
return_set_of_policies;
-
end for loop;
-
return return_set_of_policies;
-
end function getPolicies
function class_of_self()
-
return "PolicyGroup"
-
end function class_of_self;
-
Mit Bezug auf den nachstehenden Pseudocode des Blocks 3
ist ein Beispiel von Klassen-Politik gezeigt. Es ist zu
wiederholen, daß Politikgruppen eine Liste von Politiken
enthalten, und jede Politik in dieser Liste besitzt einen
Klassennamen und ein Attribut, um anzuzeigen, für was die
Politik gilt. Der Politikausdruck kann genaugenommen die
Politik selbst sein. Jede Politik besitzt eine Funktion,
die "gültig setzen" genannt wird, und der vorgeschlagene
Wert wird in die Politik gesetzt, um eine "wahr"- oder
"falsch"-Anzeige für den Wert zurückzusenden.
Block 3:
Class Policy
-
class Policy
-
/* Attribute */
-
className; /* Name der Klasse des ManagedObject, auf
das diese Politik angewendet wird */
-
attributeName; /* Name des Attributs der Klasse
className */
-
policyExpression;
-
/* Funktionen *
/validate(aProposedAttributeValue) return
(Boolean);
-
end class Policy
/* Funktionsdefinitionen für Policy */
-
validate(aProposedAttributeValue)/*
-
Verwende aProposedAttributeValue in dem vom
Systemmanager definierten Politikausdruck. Das Ergebnis des
Politikausdrucks wird zurückgeschickt.
-
end function validate
-
Zusätzlich in Fig. 13 und dem folgenden Pseudocode des
Blocks 4 ist jetzt ein Beispiel einer Klasse gezeigt, die
die Politik überprüft. Der Prozeß 190 beginnt bei dem
Entscheidungsschritt 192, wo der vorgeschlagene Wert
getestet wird, was UserIdentifier und newValue anbelangt,
um ihn auf wahr gültig zu setzen. Wenn das wahr ist, wird
bei Schritt 194 der UserIdentifier dem newValue
zugewiesen, und der Prozeß 190 ist bei dem Rücksprungschritt 196
abgeschlossen. Wenn das falsch ist, wird der Schritt 194
direkt zu dem Rücksprungschritt 196 umgangen.
Block 4:
-
An Example of a class which checks Policy class User
subclass of Managed Object
-
/* Attribute */
-
UserIdentifier;
-
/* Funktionen */
-
class of self ();
-
set_UserIdentifier(newValue) returns error code;
-
end class User
/* Funktionsdefinitionen für Anwender */
-
function class of self ()
-
return "User";
-
end function;
-
function set UserIdentifier(newValue)
-
if
-
(validateProposedValue("UserIdentifier", newValue)
-
then
-
UserIdentifier = newValue;
-
end if;
-
end function set_UserIdentifier;
-
Das hierin offenbarte System und das Verfahren für die
Implementierung einer hierarchischen Politik für das
Computer-Systemmanagement ist in der Zuweisung von
Politiken zu gemanagten Objekten sehr anpassungsfähig. Wie
früher dargelegt wurde, sind Politiken Regeln für die
Werte von Attributen gemanagter Objekte. Politikgruppen
sind die grundlegenden Systembausteine dieses Modells,
die einer Menge von Politiken eine Menge gemanagter
Objekte zuordnen. Ferner können Politikgruppen Mitglieder
anderer Politikgruppen sein, wobei eine Politikgruppe die
Politiken ihrer Eltern-Politikgruppen erbt. Dieses
Merkmal kann verwendet werden, um die hierarchische
Spezifikation der Politik zu unterstützen. Überdies läßt das
hierin offenbarte System und Verfahren zu, daß eine
gegebene Politikgruppe mehrere Eltern hat, die in diesem
Zusammenhang die "Einmischung" von Politiken von den
Eltern zulassen.
-
Die Systemmanager können die Standardisierung der
Konfiguration der gemanagten Objekte als ein Mittel verwenden,
die Belastung des Managements großer Anzahlen von
Ausprägungen einer gegebenen Klasse von gemanagten Objekten zu
vermindern. Die Standardisierung vermindert die
Komplexität der ununterbrochenen Systemmanagementfunktionen, da
weniger Informationen zu unterhalten und zu verstehen
sind, und da es weniger Sonderfälle gibt. Folglich macht
es die hierin vorgeschlagene Standardisierung leichter,
spezielle Konfigurationen zu optimieren und deren Fehler
zu suchen. Die Verwendung des Klonens und der Schablonen
schafft freiwillige Mittel für die Standardisierung,
während Validierungspolitiken und Politikgruppen ein Mehr
an verbindlichen Mitteln der Standardisierung
bereitstellen.
-
Die Verkleinerung oder Begrenzung des Schadens aus nicht
böswilliger Zweckentfremdung wird über Politiken
unterstützt. Politiken können ausdrücklich verwendet werden,
um die Menge der Werte für ein gegebenes Attribut auf
eine "sichere" Menge von Werten zu beschränken, wobei der
Mechanismus der Politikgruppe sicherstellt, daß die