Aktuelles zur OS/400-Sicherheit: Security Patrol

Ansehen aber nicht kopieren!

Frage:

Ich würde gern veranlassen, dass meine User Source-Dateien unserer Produktionsbibliothek anzeigen können, jedoch nicht die Möglichkeit haben, Teile dieser Dateien in eine andere Bibliothek zu kopieren. Das Kopieren in eine Programmierer- oder Testbibliothek ist für gewöhnlich der erste Schritt, wenn Änderungen vorgenommen werden und ich wüsste gern vorab Bescheid, wenn Änderungen in Betracht gezogen werden. Gibt es eine Möglichkeit, das zu realisieren?

Antwort:

Das von Ihnen erwähnte Problem ist ein klassisches Problem aus dem Bereich Computerwissenschaften. Wenn Sie einem Benutzer ermöglichen, Daten anzuzeigen, können Sie dann darauf Einfluss nehmen, wie der User die Daten verwendet? Puristen würden darauf mit nein, Techniker mit möglicherweise antworten. Wenn Sie einem Benutzer erlauben, Source Code anzuzeigen, müssen Sie sich zunächst darüber im Klaren sein, dass Sie im Grunde erlauben, dass eine Kopie der Source an den Bildschirm des entsprechenden Benutzers gesendet wird. Sobald der Code auf dem Bildschirm des Benutzers erscheint, kann ihn der User mit Cut-and-Paste in einen anderen Editor übernehmen und so Ihre Sicherheitsvorkehrungen umgehen.

In der Realität sind die meisten Anwendungsprogramme jedoch so umfangreich, dass allein ihre Größe die Benutzer davon abschreckt, den in diesem Fall sehr langwierigen Prozess des Kopierens auf sich zu nehmen. Falls dieses Risiko für Sie akzeptabel ist, könnten Sie Ihren Benutzern ein Programm anbieten, das ihnen übernommene Zugriffsberechtigungen zur Verfügung stellt, die ihnen ermöglichen, die Source mit Hilfe des SEU-Browsers anzuzeigen. In Abbildung 1 finden Sie ein Beispielprogramm, dass diese Vorgehensweise ermöglicht. Stellen Sie bitte sicher, dass das Benutzerprofil, dessen Zugriffsberechtigung Sie übernehmen, über keine höhere Zugriffsberechtigung als *USE für Source-Dateien verfügt, da SEU Zugang zu einer Befehlszeile bietet und Sie sicherlich nicht wünschen, dass die Benutzer durch eine Kombination aus übernommener Zugriffsberechtigung und Zugriff auf eine Befehlszeile uneingeschränkten Zugriff auf die Daten haben.

Abbildung 1: Benutzen Sie ein Programm wie das hier dargestellte, um zu ermöglichen, dass in SEU übernommene Zugriffsberechtigungen genutzt werden können.

Als ich Ihr Problem mit einigen meiner Kollegen besprach, waren manche darüber erstaunt, warum es Ihnen Sorgen macht, wenn ein Benutzer die Möglichkeit hat, Programmobjekte zu erstellen. Wenn Sie verhindern wollen, dass Benutzer Produktionsprogramme ersetzen können, gibt es eine bessere Möglichkeit, das zu erreichen. Geben Sie Ihren Benutzern einfach nicht die Möglichkeit, Produktionsprogramme zu löschen. Wenn die Benutzer nur über die Zugriffsberechtigung *USE für ein Produktionsprogramm verfügen (die ausreicht, um ein Programm auszuführen), sind Sie nicht in der Lage, das Produktionsprogramm durch eine Version des Programms zu ersetzen, die sie möglicherweise selbst erstellt haben.

Einen weiteren Grund nicht zu verhindern, dass Benutzer Source-Code lesen können, sehe ich im Bereich effizientes Arbeiten. Clevere User wissen, wie nützlich es ist, wenn man Code bestehender Programme kopieren kann, um ein neues Programm zu erstellen. Wenn Sie Ihrem Team diese Möglichkeit nehmen, zwingen Sie Ihre Mitarbeiter möglicherweise dazu, das Rad neu zu erfinden, wenn Sie ein Programm erstellen. Lassen Sie sie 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.

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 SYSOP. USERA benötigt Zugriff auf die JOBQA, nicht aber auf JOBQB. USERB sollte nicht auf JOBQA, jedoch auf JOBQB 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 Sonderzugriffsberechtigung *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 und 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 QSECURITY Level 30 auf. Die Probleme, die sich bei der Umstellung von Level 30 auf Level 40 stellen, sind eher trivialer Natur.

Sekundärinformationsmaterial:

OS/400 Security Reference V4R4 (SC41-5302-03, CD-ROM QB3ALC03)