Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Zugriffsbedingungen definieren

Die Definition von Zugriffsbedingungen umfasst zwei Schritte:

  1. Die Festlegung der Subjekttypen, für die die Bedingungen gelten sollen. Subjekttypen sind USER, GROUP, OTHERS und das GUARDS-Pseudosubjekt ALL-USERS

  2. Die Definition der Zugriffsbedingungen

Um Zugriffsbedingungen optimal formulieren zu können, ist die Kenntnis der Logik der Bedingungsauswertung unerläßlich. Für die Bedingungsauswertung ordnet GUARDS die Bedingungen und deren Auswertung nach Subjekttypen. Die Auswertung der Subjekttypen USER, GROUP und OTHERS wird abgebrochen, sobald der erste Treffer erzielt wurde. Die Auswertung kann immer nur eines von zwei Ergebnissen liefern: WAHR (Bedingungen sind erfüllt) oder FALSCH (Bedingungen sind nicht erfüllt).

Einträge für die Subjekttypen USER, GROUP, OTHERS und ALL-USERS sind optional. Wurden überhaupt keine Bedingungen definiert, lautet das Ergebnis der Auswertung immer, dass die Bedingungen nicht erfüllt sind. Ein leeres Guard existiert z.B. in der Zeit zwischen seiner Erzeugung mit dem Kommando CREATE-GUARD und der Definition der ersten Bedingung mit /ADD-ACCESS-CONDITIONS oder nachdem alle Definitionen mit /REMOVE-ACCESS-CONDITIONS gelöscht wurden.

Reihenfolge der Auswertung der Subjekttypen:

  • USER

    Die Bedingungen von USER werden als Erstes ausgewertet. Bei USER sind die Bedingungen hinterlegt, die explizit für eine Kennung (userid) gelten sollen. Bei der logischen Auswertung werden zuerst die Einträge für USER durchsucht, ob für die zur Prüfung anstehende Kennung ein Eintrag vorhanden ist. Wird eine Übereinstimmung gefunden, werden die für diese Kennung hinterlegten Bedingungen ausgewertet.

    Lautet das Ergebnis der Auswertung WAHR, wird gleich mit der Auswertung der Bedingungen des Subjekttyps ALL-USERS fortgefahren.

    Lautet das Ergebnis der Auswertung FALSCH, wird die Auswertung abgebrochen, und GUARDS übermittelt das Ergebnis FALSCH an die aufrufende Objektverwaltung.

  • GROUP

    Spricht die Bedingungen an, die explizit für eine Benutzergruppe gelten sollen. Bei der logischen Auswertung werden als Zweites die Einträge für GROUP durchsucht, ob für die Gruppe, zu der die zur Prüfung anstehende Kennung gehört, ein Eintrag vorhanden ist. Wird eine Übereinstimmung gefunden, werden die für diese Gruppe hinterlegten Bedingungen ausgewertet.

    Lautet das Ergebnis der Auswertung WAHR, wird gleich mit der Auswertung der Bedingungen des Subjekttyps ALL-USERS fortgefahren.
    Lautet das Ergebnis der Auswertung FALSCH, wird die Auswertung abgebrochen, und GUARDS übermittelt das Ergebnis FALSCH an die aufrufende Objektverwaltung.

  • OTHERS

    Spricht die Bedingungen an, die für alle Benutzer gelten sollen, die nicht durch Einträge für USER oder GROUP erfasst worden sind.

    Lautet das Ergebnis der Auswertung WAHR, wird mit der Auswertung der Bedingungen von ALL-USERS fortgefahren.

    Lautet das Ergebnis der Auswertung FALSCH, wird die Auswertung abgebrochen und GUARDS übermittelt das Ergebnis FALSCH an die aufrufende Objektverwaltung.

Sind in einem Guard weder Einträge für den Subjekttyp USER noch für GROUP oder OTHERS vorhanden, lautet das Ergebnis der Auswertung immer FALSCH.

  • ALL-USERS

    ist ein Pseudo-Subjekttyp, über den Zusatzbedingungen hinterlegt werden können, die nur dann ausgewertet werden, wenn die vorangegangenen Prüfungen für USER, GROUP und OTHERS zum Ergebnis WAHR geführt haben.

    Auf diese Weise können Zugriffsbedingungen in ein Guard eintragen werden, die für alle im Guard festgelegten Subjekttypen und Subjekte gelten, ohne dass sie dafür bei jedem einzelnen Subjekttyp selber festgemacht werden müssen.

    Beispiel

    In einem Guard wurden unter dem Subjekttyp USER für die Benutzerkennungen PETER, PAUL und MARY und unter dem Subjekttyp GROUP für die Benutzergruppe TEAM festgelegt, dass ein Zugriff erlaubt ist. Über den Subjekttyp OTHERS wird vereinbart, dass "alle Anderen" keine Zugriffsberechtigung haben.

    %   User   PAUL     has ADMISSION
    %   User   PETER    has ADMISSION
    %   User   MARY     has ADMISSION
    %   Group  TEAM     has ADMISSION
    %   Others          has NO ADMISSION 
    

    Kurzfristig soll der Zugriff auch für die unter USER und GROUP festgelegten Subjekte (PETER, PAUL, MARY, TEAM) verboten werden.

    Um nun nicht alle betroffenen Zugriffsbedingungen in ADMISSION=*NO abändern zu müssen, wird der Pseudo-Subjekttyp ALL-USERS verwendet, mit dem die Zugriffsbedingung ADMISSION=*NO nur einmal festgelegt werden muss und trotzdem für "Alle" gilt:

    %   User   PAUL     has ADMISSION
    %   User   PETER    has ADMISSION
    %   User   MARY     has ADMISSION
    %   Group  TEAM     has ADMISSION
    %   Others          has NO ADMISSION 
    %   Alluser         has NO ADMISSION 
    

    Greift z.B. Subjekt MARY zu, wird nach Überwindung der ersten Schutzhürde (WAHR) die zusätzlichen ALL-USERS-Prüfung durchlaufen, die das Prüfergebnis FALSCH liefert. Greift ein Subjekt zu, das nicht unter die Kategorien USER und GROUP fällt, wird die OTHERS-Prüfung durchlaufen, die das Ergebnis FALSE liefert. In diesem Fall wird die Prüfung abgebrochen, ohne dass die ALL-USERS-Prüfung durchlaufen wird.


Bild 19: Logische Auswertung der Zugriffsbedingungen nach Subjekttyp

Hinweis

Die für den Subjekttyp USER, GROUP oder OTHERS festgelegten Zugriffsbedingungen (Bedingung a) und diejenigen für Pseudo-Subjekttyp ALL-USERS (Bedingung b) sind durch logisches UND miteinander verknüpft. Das bedeutet, ein Zugriff ist nur dann erlaubt, wenn sowohl Bedingung a, als auch Bedingung b zutrifft. GUARDS überprüft bei der Definition von Zugriffsbedingungen jedoch nicht, ob widersprüchliche Bedingungen vorliegen. Daher muss der Eigentümer eines Guards sorgfältig prüfen, ob Unstimmigkeiten zwischen den Zugriffsbedingungen für die Subjekttypen USER, GROUP oder OTHERS einerseits und denen für den Pseudo-Subjekttyp ALL-USERS andererseits existieren. Diese können dazu führen, dass ein Zugriff, der eigentlich erlaubt sein sollte, abgewiesen wird.

Beispiel

Die Zugriffsbedingung für den Subjekttyp USER legt einen Zeitraum von 08:00 bis 13:00 fest, die Bedingung für ALL-USERS bestimmt dagegen einen Zeitraum von 12:00 bis 18:00. Der Zugriff für einen in der Bedingung für USER festgelegten Benutzer ist nur erlaubt, wenn beide Bedingungen zutreffen. Dies ist in diesem Beispiel von 12:00 bis 13:00 der Fall. Ein Zugriff dieses Benutzers um 9:00 würde dagegen abgewiesen, obwohl die Bedingung für den Subjekttyp USER erfüllt ist.

Dieses Verhalten kann allerdings auch erwünscht sein, z.B. um ein Objekt für einen bestimmten Zeitraum generell zu sperren. Daher liegt es in der Verantwortung des Eigentümers eines Guards, zu beurteilen, ob unerwünschte Widersprüche vorliegen oder nicht.

Beispiel für die Verwendung von ALL-USERS

Auf eine Datei soll nur über das Programm EDT zugegriffen werden dürfen.
Die Bedingung „Zugriff nur über das Programm EDT“ wird nur für den Pseudo-Subjekttyp ALL-USERS festgelegt.

Definition für USER:

/add-access-conditions guard-name=guardexa, -
/  subjects=*user(user-identification=edtuser), -
/  admission=*yes

Definition für GROUP:

/add-access-conditions guard-name=guardexa, -
/  subjects=*group(group-identification=edtgroup), -
/  admission=*yes

Definition für OTHERS:

/add-access-conditions guard-name=guardexa, -
/  subjects=*others, -
/  admission=*yes

Definition für ALL-USERS:

/add-access-conditions guard-name=guardexa,-
/  subjects=*all-users, -
/  admission=*parameters(program=$edt)

Obwohl weder für USER, noch für GROUP oder OTHERS die Bedingung „Zugriff nur über das Programm EDT“ festgelegt ist, wird der Zugriff wunschgemäß über die für ALL-USERS eingetragene Bedingung geregelt.

Zusätzlich soll dem Benutzer EDTUSER der Dateizugriff über das Programm SORT erlaubt sein:

/modify-access-conditions guard-name=guardexa, -
/  subjects=*user(user-identification=edtuser), -
/  admission=*parameters(program=($edt,$sort))

Für den Benutzer unter der Kennung EDTUSER sind die Bedingungen weiterhin WAHR, wenn er mit dem Programm EDT auf die mit Hilfe von GUARDS geschützte Datei zugreift. Wenn er jedoch einen Zugriff auf die Datei mit dem Programm $SORT versucht, wird die Bedingungsauswertung durch GUARDS als Prüfergebnis FALSCH liefern, da die Zugriffsbedingung für ALL-USERS einen Zugriff nur über das Programm $EDT erlaubt. GUARDS überprüft die Bedingungen in einem Guard nicht auf Folgerichtigkeit. Der Eigentümer des Guards muss selbst beurteilen, ob Unstimmigkeiten dieser Art gewollt sind oder nicht.