Bei einer Jobvariable können folgende Zugriffsmerkmale gesteuert werden (in Klammern die Bezeichnung der Schutzmöglichkeiten):
Zugriffsberechtigte Benutzer bzw. Benutzergruppen (Mehrbenutzbarkeit, Mehrbenutzerzugriff)
Lese- und/oder Schreibberechtigung ggf. nach Zugriffsberechtigten differenziert (Zugriffsart, Mehrbenutzerzugriff)
Kennwörter für den Zugriff (Kennwörter)
Zeitliche Befristung des Zugriffs (Schutzfrist)
Schutzmechanismus | Schutzmöglichkeiten | Granularität der Zugriffsberechtigten |
GUARDS  |
| individuelle Zugriffsprofile  |
BASIC-ACL  |
| Zugriffsprofile für Gruppen  |
Standardschutz | Standardzugriffskontrolle
Weitere Schutzmöglichkeiten
| Eigentümer oder alle |
Tabelle 4: Übersicht der Schutzmöglichkeiten für eine Jobvariable
Die Schutzmöglichkeiten für eine Jobvariable sind auf den drei Ebenen Standardschutz (unterste Ebene), BASIC-ACL und GUARDS (höchste Ebene) angeordnet (siehe Tabelle 4). Für den Schutz einer Jobvariable gilt immer der stärkste aktivierte Schutzmechanismus.
Der Einsatz von Kennwörtern und der Schutzfrist (Freigabedatum) ist unabhängig vom aktiven Schutzmechanismus, d.h. er ist auch bei BASIC-ACL und GUARDS möglich. Die Zugriffskontrolle (Mehrbenutzbarkeit und Zugriffsart) wird bei diesen beiden Schutzmechanismen verfeinert, indem bei BASIC-ACL drei Gruppen (OWNER, GROUP und OTHERS) sowie bei GUARDS Zugriffsprofile für einzelne Benutzer gebildet werden.
Koexistenz der Zugriffsmechanismen
Bild 1: Hierarchie der Schutzmechanismen für Jobvariablen
Bild 1 verdeutlicht, dass die jeweils höhere Schutzebene die Funktionalität der darunter liegenden Schicht voll abdeckt.
Die Koexistenz zwischen Standardzugriffskontrolle (USER-ACCESS, ACCESS), BASIC-ACL und Guards wird folgendermaßen geregelt:
Die Werte der USER-ACCESS- bzw. ACCESS-Operanden werden in den Katalog eingetragen, unabhängig davon, ob sie im aktuellen Schutzzustand durch höherwertige Schutzmechanismen (BASIC-ACL oder Guards) auch aktuell wirksam werden. Besteht ein höher priorisierter Schutz, werden die Einträge erst nach dessen Deaktivierung berücksichtigt.
Der BASIC-ACL-Operand setzt die BASIC-ACL-Indikatoren im Katalogeintrag der Jobvariable unabhängig davon, ob der Schutz der Jobvariable durch BASIC-ACL oder einen höher priorisierten Schutz (Guards) bestimmt wird. Besteht ein höher priorisierter Schutz, werden die Einträge erst nach dessen Deaktivierung berücksichtigt.
Standard-Zugriffsschutz
Die Standard-Zugriffskontrolle bietet die Schutzmerkmale Zugriffsart und Mehrbenutzbarkeit. Darüber hinaus können im Standard-Zugriffsschutz (aber auch bei BASIC-ACL und GUARDS) eine Schutzfrist und Kennwortschutz für eine Jobvariable festgelegt werden.
Zugriffsart
Mit dem Operanden der Kommandos CREATE-JV und MODIFY-JV-ATTRIBUTES kann ein Benutzer festlegen, welche Zugriffsart er auf eine Jobvariable erlaubt.
ACCESS=*BY-PROTECTION-ATTR | Die Zugriffsart erfolgt abhängig vom Wert des Operanden PROTECTION-ATTR (siehe Abschnitt „Default-Protection (Benutzerdefinierte Standardwerte)“) |
ACCESS=WRITE | Lese- und Schreibzugriffe erlaubt |
ACCESS=READ | Lesezugriff erlaubt |
Auf Makro-Ebene (Makro CATJV) entspricht der Operandenwert PROTECT=DEFAULT dem Operandenwert ACCESS=*BY-PROTECTION-ATTR bei den Kommandos. Der PROTECT-Operand bezieht sich jedoch nicht nur auf die Zugriffsart, sondern auf alle Schutzmerkmale. Die Operandenwerte für Lese- und Schreibzugriff sind identisch mit denen der Kommando-Operanden.
Mehrbenutzbarkeit
In den Kommandos CREATE-JV und MODIFY-JV-ATTRIBUTES wird mit dem Operanden USER-ACCESS festgelegt, welche Benutzerkennungen auf die Jobvariable mit den zuvor vergebenen Zugriffstypen zugreifen können (Mehrbenutzbarkeit):
USER-ACCESS=*BY-PROTECTION-ATTR | Der Zugriff erfolgt abhängig vom Wert des Operanden PROTECTION-ATTR (siehe Abschnitt „Default-Protection (Benutzerdefinierte Standardwerte)“) |
USER-ACCESS=*OWNER-ONLY | Nur der JV-Eigentümer kann zugreifen |
USER-ACCESS=*ALL-USERS | Alle Benutzerkennungen dürfen zugreifen |
Auf Makro-Ebene (Makro CATJV) entsprechen die Operandenwerte SHARE=NO / YES den Werten USER-ACCESS=*OWNER-ONLY/ *ALL-USERS.
Schutzfrist
Mit Vereinbarung einer Schutzfrist kann eine Jobvariable für einen festgesetzten Zeitraum gegen Veränderung und Löschen geschützt werden.
Beim Erzeugen der Jobvariablen wird im Ausgabefeld EXPIR-DATE des Kommandos SHOW-JV-ATTRIBUTES standardmäßig das aktuelle Tagesdatum eingetragen. Dieses Datum wird automatisch aktualisiert, wenn der Inhalt der Jobvariablen verändert wird.
Mit dem Kommando MODIFY-JV-ATTRIBUTES kann im Operanden RETENTION-PERIOD angegeben werden, wie viele Tage ab dem aktuellen Tagesdatum die Jobvariable gegen Wertänderungen und gegen Löschen geschützt sein soll. Bei Vereinbarung einer Schutzfrist wird das Tagesdatum um die angegebene Anzahl Tage hochgesetzt. Das Datum (in EXPIR-DATE) zeigt jetzt an, wann die Jobvariable erstmals wieder verändert werden darf. Der Eintrag im Ausgabefeld EXPIR-DATE bleibt bis Ablauf der Schutzfrist unverändert. Danach wird er wieder automatisch dem aktuellen Tagesdatum angepasst, wenn der Inhalt der Jobvariablen verändert wird.
Auf Makro-Ebene (Makro CATJV) entspricht der Operand RETPD dem Operanden RETENTION-PERIOD.
Kennwortschutz
Zusätzlich kann der Zugriff auf eine Jobvariable von der Kenntnis eines Kennwortes abhängig gemacht werden.
Im Kommando CREATE-JV bzw. MODIFY-JV-ATTRIBUTES kann im Operanden READ-PASSWORD ein Lese-Kennwort und im Operanden WRITE-PASSWORD ein Schreib-Kennwort vereinbart werden.
Im Jobvariablen-Eintrag wird in den Feldern READ-PASS und WRITE-PASS mit dem Wert YES angezeigt, dass ein Lese- bzw. Schreib-Kennwort vereinbart wurde. Ist kein Kennwort vereinbart, so ist der Wert NONE.
Standardmäßig ist eine neu erzeugte Jobvariable nicht mit Kennwörtern geschützt.
Vor dem Zugriff ist das erforderliche Kennwort mit dem Kommando ADD-PASSWORD in die Kennwort-Tabelle des Auftrags einzutragen. Dieser Eintrag hat Gültigkeit bis Auftragsende. In einigen Kommandos kann das Kennwort im Operanden PASSWORD bzw. JV-PASSWORD angegeben werden. Die Zugriffsberechtigung besteht dann nur für Zugriffe bei Ausführung des Kommandos.
Ist ein Kennwort vereinbart, muss dieses von allen Benutzern ohne Systemverwaltungsrechte angegeben werden, auch wenn mit dem Kommando MODIFY-JV-ATTRIBUTES Schutzmerkmale geändert werden sollen.
Kennwortschutz | zusätzlicher Schutz | erforderliche Angaben für | ||
READ-PASS | WRITE-PASS | Lesezugriff | Schreibzugriff | |
NONE | NONE | kein Schutz | keine | keine |
YES | NONE | Lesezugriff | Lese-Kennwort | Lese-Kennwort |
NONE | YES | Schreibzugriff | keine | Schreib-Kennwort |
YES | YES | Lesezugriff | Lese- oder Schreib- | Schreib-Kennwort |
Tabelle 5: Kennwortschutz-Kombinationen und Angaben für Lese- oder Schreibzugriff
Bei dem Versuch, auf eine Jobvariable ohne das erforderliche Kennwort zuzugreifen, wird der nicht privilegierte Benutzer mit einer Zeitstrafe belegt. Die Dauer der Zeitstrafe ist abhängig von dem eingestellten Systemparameter PWPENTI und kann einen Wert von null bis 60 Sekunden annehmen. Während dieser Zeit ist keine weitere Eingabe möglich.
In den Kommandos SHOW-JV, MODIFY-JV, MODIFY-JV-CONDITIONALLY, MODIFY-MONJV, DELETE-JV und den entsprechenden Makros kann das Kennwort noch im Kommando angegeben werden (Operand PASSWORD). Bei der Angabe eines falschen Kennwortes wird geprüft, ob das Kennwort bereits in der Kennwort-Tabelle enthalten ist. Ist das Kennwort dort nicht enthalten ist, handelt es sich um einen unberechtigten Zugriffsversuch. Im anderen Fall ist der Zugriff berechtigt und das Kommando wird ausgeführt.
Auf Makro-Ebene (Makro CATJV) entsprechen die Operanden RDPASS und WRPASS den Operanden READ-PASSWORD und WRITE-PASSWORD.
Schnittstellenübersicht
Kommando/Makro | Funktion |
CREATE-JV/CATJV | Jobvariable anlegen und Festlegen von Schutzmerkmalen mit den |
MODIFY-JV-ATTRIBUTES / CATJV | Ändern der Schutzmerkmale mit den |
SHOW-JV-ATTRIBUTES / STAJV | Ausgeben der Schutzmerkmale |
Tabelle 6: Kommandos und Makros zur Festlegung von Standardschutz-Merkmalen
Die Tabelle gibt einen zusammenfassenden Überblick über die Kommandos und Makros zur Festlegung der Standardschutzmerkmale Zugriffsart (ACCESS), Mehrbenutzbarkeit (USER-ACCESS / SHARE), Schutzfrist (RETENTION-PERIOD / RETPD) und Kennwortschutz (READ-PASSWORD und WRITE-PASSWORD / RDPASS und WRPASS).
Beispiel
/create-jv jv=status,prot=*par(access=*write,user-access=*all-users, read-pass=c'rdpw',write-pass=c'wrpw')
Die Jobvariable status wird angelegt mit folgenden Eigenschaften:
Lese- und Schreibzugriff sind erlaubt
Alle Benutzerkennungen dürfen zugreifen
Ein Leseschutz-Kennwort ('rdpw') wird gesetzt
Ein Schreibschutz-Kennwort ('wrpw') wird gesetzt
BASIC-ACL-Schutz
In einer BASIC-ACL (einfache Zugriffskontroll-Liste) können die Zugriffsrechte Lesen und Schreiben für die Benutzerklassen OWNER, GROUP und OTHERS explizit vergeben werden.
Diese Schutz-Möglichkeit besteht nicht für temporäre Jobvariablen.
Bei aktiviertem BASIC-ACL-Schutz muss für einen Zugriff jeweils das erforderliche Zugriffsrecht explizit gesetzt sein. Im Gegensatz zur Standard-Zugriffskontrolle (mit ACCESS und USER-ACCESS) folgt in einer BASIC-ACL aus dem Schreibrecht nicht implizit das Leserecht. Für den Lesezugriff muss das Leserecht explizit gesetzt sein.
Die Benutzer werden in folgende Benutzerklassen eingeteilt:
OWNER ist die Benutzerkennung des Eigentümers bzw. der Systembetreuung.
GROUP sind alle Benutzerkennungen, die zur Benutzergruppe des Eigentümers gehören. In der Grundfunktion (ohne SECOS) sind dies alle anderen Benutzerkennungen, da nur eine Benutzergruppe existiert. Bei Einsatz des Software-Produktes SECOS können mit der Funktioneinheit SRPM mehrere Benutzergruppen definiert werden. Zugriffe von Benutzern, die nicht explizit zu einer anderen Gruppe als der des Eigentümers gehören, werden weiterhin gemäß der Zugriffsrechte von GROUP ausgewertet (Der Eigentümer einer Jobvariable kann nur maximal einer Gruppe angehören). Zugriffe der Benutzer, die explizit einer anderen Benutzergruppe angehören, werden dann gemäß der Zugriffsrechte von OTHERS ausgewertet.
OTHERS sind alle Benutzerkennungen, die explizit einer anderen Benutzergruppe als der des Eigentümers oder keiner Benutzergruppe angehören. Falls SECOS nicht eingesetzt wird, sollten die Zugriffsrechte wie für GROUP vergeben werden, um Änderungen bei zukünftigem Einsatz von SECOS zu vermeiden.
Die BASIC-ACL-Schutzmerkmale werden nur gesetzt, wenn mindestens eine Zugriffsberechtigung explizit vergeben wurde (BASIC-ACL wird aktiviert). Mit dem Kommando SHOW-JV-ATTRIBUTES werden die BASIC-ACL-Schutzmerkmale in den Ausgabefeldern OWNER, GROUP und OTHERS angezeigt. Je Benutzerklasse können die Werte „R W“ (lesen und schreiben), „R -“ (nur lesen), „- W“ (nur schreiben) oder „- -“ (kein Zugriff) angezeigt werden. Die Felder werden nur bei aktivierter BASIC-ACL angezeigt.
Mit dem Kommando CREATE-JV bzw. MODIFY-JV-ATTRIBUTES können im Operanden BASIC-ACL mit explizitem Setzen von Zugriffsrechten der BASIC-ACL-Schutz aktiviert, Zugriffrechte verändert, oder der BASIC-ACL-Schutz wieder ausgeschaltet werden. Standardmäßig wird eine Jobvariable ohne BASIC-ACL erzeugt.
Bei aktivierter BASIC-ACL erfolgt die Zugriffskontrolle entsprechend den gesetzten Zugriffsrechten. Die Standard-Schutzmerkmale Mehrbenutzbarkeit und Zugriffsart werden dann nicht ausgewertet.
Bei Einsatz von SECOS können mehrere Benutzergruppen existieren. Damit besteht auch die Möglichkeit, die Zugriffsrechte der Gruppe des Eigentümers und anderer Benutzergruppen unterschiedlich zu vergeben.
Bei Aktivierung des BASIC-ACL-Schutzes für eine bereits bestehende Jobvariable kann der Benutzer mit der Angabe BASIC-ACL=*PREVIOUS eine BASIC-ACL erstellen, die den Werten der Standard-Zugriffskontrolle entspricht (siehe Kommando MODIFY-JV-ATTRIBUTES im Handbuch „Kommandos“ [1]). Beim Erzeugen einer Jobvariablen kann mit der Angabe BASIC-ACL=*STD eine BASIC-ACL erstellt werden, in der nur der Eigentümer alle Zugriffsrechte besitzt.
Die Makros und ihre Operanden zur Festlegung des BASIC-ACL-Schutzes sind ( zusammen mit den Kommandos ) in der folgenden Schnittstellenübersicht aufgeführt.
Schnittstellenübersicht
Kommando/Makro | Funktion |
CREATE-JV/CATJV | Jobvariable anlegen und Festlegen von Schutzmerkmalen |
MODIFY-JV-ATTRIBUTES / CATJV | Ändern der Schutzmerkmale |
SHOW-JV-ATTRIBUTES / STAJV | Ausgeben der Schutzmerkmale |
ADD-USER-GROUP | Benutzergruppe in den Benutzerkatalog eines Pubsets eintragen und Zuordnung von Benutzerkennungen zu einer Benutzergruppe |
REMOVE-USER-GROUP | Benutzergruppe löschen |
SHOW-USER-GROUP | Benutzergruppeneintrag anzeigen |
Tabelle 7: Kommandos und Makros zur Festlegung des Zugriffsschutzes mit BASIC-ACL-Schutz
Beispiel
/create-jv jv=jv.develop——————————————————————————————————————————————— (1)
/add-user-group group-id=develop1,add-group-member=user1——————————————— (2)
/mod-jv-attr jv=jv.develop,protection=(basic-acl=(
owner=(read=*yes,write=*yes),
group=(read=*yes)
others=(read=*no)————————————————————————————————— (3)
(1) | Eine Jobvariable „jv.develop“ wird erzeugt |
(2) | Eine Gruppe mit dem Namen „develop1“ wird vom Eigentümer der Jobvariable „jv.develop“ angelegt und die eigene Benutzerkennung (hier USER1) als Gruppenmitglied eingetragen. |
(3) | Für die Jobvariable „jv.develop“ wird der Zugriffsschutz über eine BASIC-ACL vereinbart. Der Eigentümer der Jobvariable darf lesend und schreibend auf sie zugreifen. Die Mitglieder der Gruppe des Jobvariablen-Eigentümers („develop1“) dürfen die Jobvariable nur lesen. Alle anderen Benutzerkennungen („others“) dürfen nicht auf die Jobvariable zugreifen. |
GUARDS-Schutz
Die Zugriffskontrolle für Jobvariablen kann über Guards (Generally Usable Access ContRol ADministration System) erfolgen. Dieser Zugriffsschutz wird nur wirksam, falls das Subsystem GUARDS geladen ist (Teil des Softwareproduktes SECOS, siehe [9]). Die Schutz-Möglichkeit besteht nicht für temporäre Jobvariablen.
Der Zugriff auf eine Jobvariable wird über ein spezielles Zugriffsprofil (Guard) geregelt, das alle Bedingungen enthält, unter denen ein Zugriff erlaubt oder verwehrt wird (Datum, Uhrzeit, Zeitraum, Benutzerkennung). Jedes Zugriffsprofil wird mit entsprechenden GUARDS-Kommandos erstellt und unter einem vom Anwender vergebenen Namen im Guardskatalog als Eintrag abgespeichert. Jeder Pubset verfügt über einen Guardskatalog, der unabhängig von den Benutzerdateien verwaltet wird.
Der Zugriff auf eine mit einem Guard geschützte Jobvariable ist nur möglich, falls die im Guard-Eintrag festgelegten Bedingungen dies zulassen.
Aktivierung des Guards-Schutzes
Der Guard-Schutz wird aktiviert, wenn bei einem CREATE-JV-Aufruf der Operand GUARDS mit einem Wert ungleich *NONE angegeben wird.
Werden dabei nicht für alle Zugriffsrechte Guards zugewiesen, so werden die nicht angegebenen Zugriffsrechte auch als „nicht angegeben“ (*NONE) in den Dateikatalog eingetragen. Bei der Zugriffskontrolle wird ein entsprechender Zugriff abgewiesen, weil keine Rechte festgelegt wurden. Das Schreibrecht impliziert bei GUARDS nicht das Leserecht.
Die Makros und Operanden zur Festlegung des GUARDS-Schutzes sind (zusammen mit den Kommandos) in der folgenden Schnittstellenübersicht aufgeführt.
Schnittstellenübersicht
Kommando/Makro | Funktion |
CREATE-JV/CATJV |
|
MODIFY-JV-ATTRIBUTES / CATJV |
|
SHOW-JV-ATTRIBUTES / STAJV | Ausgeben der Schutzmerkmale |
CREATE-GUARD | Guard anlegen (enthält noch keinen Schutzmechanismus) |
DELETE-GUARD | Guard löschen |
ADD-ACCESS-CONDITIONS | Zugriffsbedingungen eines Guards festlegen |
MODIFY-ACCESS-CONDITIONS | Zugriffsbedingungen eines Guards ändern |
SHOW-ACCESS-CONDITIONS | Zugriffsbedingungen eines Guards ausgeben |
SHOW-ACCESS-ADMISSION | Zugriffsbedingungen eines Guards ausgeben, die für die aufrufende Benutzerkennung gültig sind |
Verknüpft wird eine Jobvariable mit einem Guard-Eintrag, indem bei den entsprechenden Operanden des Makros/Kommandos (CATJV/CREATE-JV, MODIFY-JV-ATTRIBUTES) ein Guard-Name eingetragen wird. Die Verknüpfung wird im Katalogeintrag der Jobvariablen festgehalten.
Beispiel
/create-guard guard-name=protjv———————————————————————————————————————— (1)
/create-jv guardjv,protection=(guards=(read=protjv,write=*none))——————— (2)
/add-access-conditions guard-name=protjv,
subjects=*user(user-id=mueller),
admission=*par(time=*interval(from=07:00,to=17:00)) (3)
(1) | Das Guard „protjv“ wird angelegt. |
(2) | Die Jobvariable „guardjv“ wird angelegt und der Zugriffsschutz über GUARDS aktiviert durch die Verknüpfung mit dem Guard „protjv“. Der Leseschutz wird über diesen Guard geregelt, schreibende Zugriffe sind nicht erlaubt. |
(3) | In das Guard „protjv“ wird eingetragen, dass der Benutzer „mueller“ (auf die Jobvariable „guardjv“) zugreifen darf und zwar zwischen 7 und 17 Uhr. (Falls das angegebene Guard noch nicht existiert, wird es automatisch angelegt.) |
Der Katalogeintrag für den Guard-Schutz kann auch ohne das Subsystem GUARDS erstellt werden. Es besteht dann jedoch kein Zugriffsrecht auf die Jobvariable.
Wird für eine Jobvariable ein Guard-Schutz aktiviert, werden alle nicht explizit gesetzten Zugriffsarten des GUARDS-Operanden (READ und/oder WRITE) mit *NONE belegt. Der Zugriff über diese Zugriffsarten ist dann nicht möglich. Beispielsweise wird bei Ausführung von /modify-jv-attributes jvtest,protection=(guards=(read=protjv)) automatisch protection=(guards=(read=protjv,write=*none)) gesetzt.
Erst zum Zeitpunkt des Zugriffs auf eine mit Guards geschützte Jobvariable wird geprüft, ob der angegebene Guard-Eintrag (Guard-Name) existiert, ob er verwendet werden darf und ob dem Benutzer auf Grund dieses Zugriffsprofils ein Zugriff in der entsprechenden Zugriffsart erlaubt ist.
Hinweis
Auf eine Jobvariable kann nicht zugegriffen werden, wenn in deren Katalogeintrag Schutz über Guards eingetragen ist, für den angegebenen Guard-Namen jedoch noch kein Zugriffsprofil im Guard-Katalog definiert ist. Gleiches gilt, wenn der Katalogeintrag für den Zugriffsschutz über Guards ohne das Softwareprodukt SECOS erstellt wurde.
Für Guards einer fremden Benutzerkennung muss die Zugriffsberechtigung bestehen. Die Zugriffsberechtigung für einen Guard wird erst geprüft, wenn dieser Guard zur Zugriffskontrolle benötigt wird.
Deaktivierung des Guards-Schutzes
Ein Guard-Eintrag wird nur durch die Angabe des Operanden GUARDS=*NONE (in den Kommandos CREATE-JV und MODIFY-JV-ATTRIBUTES) zurückgesetzt. Besitzt die Jobvariable anschließend keinen BASIC-ACL-Eintrag, wird der Zugriffsschutz der Jobvariable nur durch die Standardzugriffskontrolle, die Kennwörter und die Schutzfrist geregelt.