MAGAZIN

Technik & Integration
also zumindest die Source lesen, schützen
Sie jedoch Ihre Produktionsumgebung
vor unerwünschten Änderungen und alles
ist bestens.
Kontrollieren der besonderen
Zugriffsberechtigung *JOBCTL
Frage: Wir verteilen unsere Benutzer
auf zwei Umgebungen und würden gern
ein höheres Maß an Sicherheit im Hinblick
auf die Zugriffsberechtigung erreichen.
Einige Benutzer benötigen die Zugriffsberechtigung
*JOBCTL für ausgewählte
Job-Queues, aber andere
Benutzer mit der Zugriffsberechtigung
*JOBCTL sollten nicht auf dieselbe Job-
Queue zugreifen können, während
wieder andere User Zugriff auf alle Job-
Queues benötigen. Ich habe verschiedene
Szenarien getestet, ohne hier weiterzukommen.
Könnten Sie mir in dieser
Sache weiterhelfen?
Antwort: Sie haben wirklich Glück.
OS/400 war von Anfang an als Multi-
User-, wenn nicht sogar als Multi-Company-Betriebssystem,
konzipiert. Es ist
also nicht sehr schwer, das zu realisieren,
was Sie sich wünschen. Ich kann verstehen,
dass einige User mit der Job-Queue-
Zugriffsberechtigung Probleme haben,
da Sie einfach ganz anderen Regeln unterliegt
als andere OS/400-Objekte.
Zunächst will ich darauf eingehen, was
die Zugriffsberechtigung *JOBCTL bietet.
Die besondere Zugriffsberechtigung
*JOBCTL ermöglicht einem Benutzer,
alle Eintragungen jeder Output-Queue
oder Job-Queue anzuzeigen, zu ändern,
zu löschen, zu halten oder freizugeben,
wenn diese erstellt wurde, während der
Parameter Operator Controlled mit
OPRCTL(YES) definiert war. Der Parameter
OPRCTL(YES) bedeutet auf eine
Output-Queue oder Job-Queue bezogen,
dass jeder Benutzer, der über die besondere
Zugriffsberechtigung *JOBCTL verfügt,
keine individuelle OS/400-Zugriffsberechtigung
benötigt, um mit den Eintragungen
der Queue zu arbeiten. Wenn
Benutzer über die besondere Zugriffsberechtigung
*JOBCTL verfügen, können
sie auch dann mit diesen Eintragungen
arbeiten, wenn ihre OS/400-Zugriffsberechtigung
mit *EXCLUDE definiert ist.
Security Patrol
Wenn User nicht über die besondere Zugriffsberechtigung
*JOBCTL verfügen
oder die Queue mit OPRCTL(YES) erstellt
wurde, benötigen die Benutzer
OS/400-Object-Level-Zugriffsberechtigungen
(*USE, *CHANGE, *ALL), um
sich Eintragungen einer Queue anzusehen
beziehungsweise mit Ihnen zu arbeiten.
Natürlich wäre es am einfachsten,
allen Profilen mit Ausnahme derer, die
sie unbedingt benötigen, die Zugriffsberechtigung
*JOBCTL zu verwehren. Ich
nehme jedoch an, dass es noch einen anderen
Grund dafür gibt, dass diese User
die Zugriffsberechtigung *JOBCTL benötigen
und schlage deshalb eine andere
Lösung vor.
Unterteilen Sie Ihre Benutzer in die drei
Kategorien USERA, USERB und SYS-
OP. USERA benötigt Zugriff auf die
JOBQA, nicht aber auf JOBQB. USERB
sollte nicht auf JOBQA, jedoch auf JOB-
QB zugreifen können. SYSOP muss auf
alle Job Queues zugreifen können. Beginnen
Sie damit, die JOBQA zu erstellen,
definieren Sie dabei
OPRCTL(*NO) und editieren Sie die
Objektzugriffsberechtigungen für dieses
Job Queue-Objekt (EDTOBJAUT). Die
Zugriffsberechtigung für JOBQA sollte
so definiert sein, dass hier USERA =
*CHANGE und PUBLIC = *EXCLUDE
gilt. Auch die JOBQB sollte so definiert
werden, dass OPRCTL(*NO) definiert
ist. Ihre Objektzugriffsberechtigungen
sollten so definiert sein, dass USERB =
*CHANGE und PUBLIC = EXCLUDE
gilt. Wenn OPRCTL(NO) definiert ist,
ermöglicht die besondere Zugriffsberechtigung
*JOBCTL keinen Sonderzugriff
auf diese Queues. USERA und
USERB sind auf ihre Objektzugriffsberechtigungen
für die Queues beschränkt.
Falls sie unter *PUBLIC fallen,
gilt ein Ausschluss (EXCLUDE).
Nun bleibt noch das Profil SYSOP. Geben
Sie SYSOP nicht nur die Sonderzugriffsberechtigung
*JOBCTL sondern
auch *SPLCTL. *SPLCTL wirkt sich
ähnlich wie die Sonderzugriffsberechtigung
*ALLJOB aus, nur dass sich
*SPLCTL ausschließlich auf das Spooling
von Queues (JOB-Queues und Output-Queues)
beschränkt. Die Sonder-
24 www.midrangemagazin.de Januar 2002
zugriffsberechtigung *SPLCTL wird
nicht durch den Parameter OPRCTL
oder durch reguläre OS/400-Objektzugriffsberechtigungen
eingeschränkt,
was den Zugriff auf Job-Queues anbelangt.
Sie eignet sich deshalb nur für die
Benutzer, die unbeschränkten Zugriff
auf alle Queues benötigen.
Die im Vorhergehenden beschriebene
Vorgehensweise funktioniert sowohl für
Output-Queues als auch für Job-
Queues. Falls Benutzer die Zugriffsberechtigung
*JOBCTL benötigen, wird
die beschriebene Vorgehensweise bewirken,
dass diese User ausschließlich auf
die Queues beschränkt werden, die Sie
auch sehen sollen.
Umstellung auf
QSECURITY Level 40
Frage: Wir tragen uns mit dem Gedanken,
von Level 20 zunächst auf Level 30
und anschließend auf Level 40 umzustellen.
Können Sie uns dazu Tipps geben?
Antwort: Wenn Sie von Level 20 ausgehen,
sollten Sie sich nicht mit Level 30
aufhalten und direkt auf Level 40 umstellen.
Der Großteil der Schwierigkeiten
tritt beim Übergang auf QSECURI-
TY Level 30 auf. Die Probleme, die sich
bei der Umstellung von Level 30 auf Level
40 stellen, sind eher trivialer Natur.
John Earl arbeitet als Chief
Technology Officer für die PowerTech
Group in Kent, Washington.
Er ist unter der Adresse
johnearl@400security.com
zu erreichen. Er dankt Pat Botz
von IBM und Tom Liotta von der
PowerTech Group für Ihre Mithilfe
bei der Beantwortung der ersten
Frage dieser Security Patrol.
Sekundärinformationsmaterial:
• OS/400 Security Reference
V4R4 (SC41-5302-03,
CD-ROM QB3ALC03)