Von QSECURITY 20 nach QSECURITY 40 – Teil 1

Doch, es gibt sie noch, Systeme mit Systemwert QSECURITY = 20. Seit Jahren wird von IBM Sicherheitsstufe 40 empfohlen und neue Systeme auch mit diesem Wert ausgeliefert. Nur werden bei Systemübernahmen oftmals auch Einstellungen wie diese auf den Alt-Stand zurückgesetzt. Das Risiko ist nicht zu unterschätzen. Wie Sie von Sicherheitsstufe 20 über 30 auf 40 wechseln ist Bestandteil dieser Artikelserie.

Sicherheitsstufe 20, Zwangsmenüs und alles ist in Ordnung. Jeder Anwender kann nur das aufrufen was im Menü steht und das war es? Schön und gut, das Ganze hat nur einen Haken: Seit jetzt schon vielen Jahren gibt es nicht nur die meist geliebte und meist gehasste Anzeige der grün/schwarzen 5250 Emulation, sondern durch die Einführung des TCP/IP Protokolls wurde die damals noch AS/400 für Zugriffe von extern geöffnet. Vorher, mit dem SNA-Protokoll (Systems Network Architektur) war die Kommunikation weitestgehend auf Host-Systeme beschränkt, nun kamen plötzlich die PCs mit all ihren Möglichkeiten ins Spiel.

So konnten – und können immer noch – Anwender über eine einfache IBM System i Access Sitzung mit den entsprechend installierten Optionen Daten aus den Power i Systemen mit wenigen Mausklicks auf PCs übertragen, oder Auswertungsprogramme starten die über SQL-Anweisungen Daten aus diesen Power i Datenbanken z. B. in Excel übertragen.

Datenübertragung vom System i

Was ist jetzt die Sicherheitsstufe 20 noch wert, wenn jeder Anwender auf alle Daten des Systems uneingeschränkt (*ALLOBJ-Berechtigung) zugreifen kann? Ok, es soll tatsächlich Firmen geben in denen jeder Mitarbeiter alles wissen darf, aber normalerweise ist so eine Vorgehensweise securitytechnisch gesehen eine Katastrophe.

Dagegen muss als erstes etwas unternommen werden. Empfehlenswert ist die Sicherheitsstufe 40 weil selbst bei dieser, erfahrene Programmierer die Sicherheitsprüfungen nicht umgehen können. Wenn Sie ein neues Power i System im Betrieb nehmen und vorher noch keines dieser Systeme hatten, empfehlen alle Sicherheitexperten grundsätzlich mit Sicherheitsstufe 40 zu beginnen.

Auch aus anderen Gründen ist die Menüsicherheit mit Sicherheitsstufe 20 nicht ausreichend ist. Oftmals brauchen Anwender doch Zugriff auf eine Befehlszeile oder auf Auswertungssoftware zur Analyse der Unternehmensdaten. Benutzer auf Sicherheitsstufe 20 sollten jedoch keinerlei Zugriff auf die Befehlszeile oder auf Query-Funktionalität erhalten, denn das Benutzerprofil mit der Sonderberechtigung *ALLOBJ berechtigt sie zum uneingeschränkten Zugriff auf alle Daten im System.

Wenn Ihr System Sicherheitsstufe 20 verwendet, bietet Sicherheitsstufe 30 eine spürbare Verbesserung der gesamten Sicherheit. Auch Sicherheitsstufe 40 kostet nicht zusätzliche Systemleistung oder Overhead. Sicherheitsstufe 40 verhindert potentielle Integritäts- oder Sicherheitsprobleme, die von Programmen ausgehen, die in besonderen Fällen die Sicherheitsvorkehrungen umgehen können.

Sicherheitsstufe 40

Nachfolgend finden Sie eine Zusammenfassung des erhöhten Schutzes auf Sicherheitsstufe 40.

• Interne Schnittstellen - Das System unterbindet Versuche, Systemprogramme, die nicht als Schnittstellen auf Aufrufebene definiert sind, direkt aufzurufen. Beispiel: Direkter Aufruf des befehlsverarbeitenden Programms für den Befehl SIGNOFF. Der Schutz der internen Schnittstellen auf Sicherheitsstufe 40 und höher beinhaltet z. B. die Verhinderung des Zugriffs auf interne Systemstrukturen über die Zeiger-Funktionalität von Sprachen wie C, PASCAL oder MI.

• Jobübergabe - Wenn in einer Jobbeschreibung ein Benutzerprofilnamen als Wert für das Feld USER verwendet wird, können alle Jobs, die mit der Jobbeschreibung übergeben werden, mit Attributen ausgeführt werden, die von diesem Benutzerprofil stammen. Ein unberechtigter Benutzer könnte einen Sicherheitsverstoß begehen, indem er einen Job für die Ausführung unter dem in der Jobbeschreibung angegebenem Benutzerprofil übergibt.

• *USE-Berechtigung - Mit Sicherheit auf Sicherheitsstufe 30 wird der Job unter der Voraussetzung ausgeführt, dass die übergebende Person *USE-Berechtigung für die Jobbeschreibung besitzt. Auf Sicherheitsstufe 40 und höher muss der Benutzer, der den Job übergibt, *USE-Berechtigung für die Jobbeschreibung und das in der Jobbeschreibung angegebene Benutzerprofil besitzen. Anderenfalls wird der Job fehlschlagen. Diese Eigenschaft ist für die meisten Power i Systeme der wichtigste Vorteil der Sicherheitsstufe 40 gegenüber Sicherheitsstufe 30. Die Standardberechtigung für die Benutzerprofile ist *EXCLUDE. Daher müssen die Benutzer ausdrücklich Berechtigung erhalten, um Jobs als andere Benutzer ausführen zu können.

• Anmelden ohne Kennwort. Auf Sicherheitsstufe 30 und niedriger ist es bei bestimmten Subsystembeschreibungen möglich, sich ohne Benutzerkennung und Kennwort anzumelden. Auf Sicherheitsstufe 40 und höher verhindert das System jeden Versuch der Anmeldung ohne Benutzerkennung und Kennwort.

Ich empfehle Ihnen, Ihr Power i System mit Sicherheitsstufe 40 in Betrieb zu nehmen, wenn Sie nicht Software von Drittanbietern installiert haben, die mit den Restriktionen der Sicherheitsstufe 40 nicht kompatibel ist.

Planen Sie jedoch nach Möglichkeit nicht von Sicherheitsstufe 20 direkt auf Sicherheitsstufe 40 zu wechseln, solange Ihr System aktiv im Produktionsbetrieb ist.

Die vorbereitenden Schritte, die für einen reibungslosen Übergang auf Sicherheitsstufe 40 erforderlich sind, werden in zwei Abschnitten beschrieben: Von Sicherheitsstufe 20 auf Sicherheitsstufe 30 (diese Prozedur wird bei Systemen eingesetzt, um von Sicherheitsstufe 20 auf Sicherheitsstufe 30 zu wechseln) und von Sicherheitsstufe 30 auf Sicherheitsstufe 40. Wenn Sie die beschriebenen Schritte ausführen, können Sie Ihre Geschäftsleitung, Benutzer und Auditoren von Ihrer neuen Power i Sicherheitsstufe überzeugen und beeindrucken.

Von Sicherheitsstufe 20 auf Sicherheitsstufe 30 wechseln

Der Wechsel von Sicherheitsstufe 20 auf Sicherheitsstufe 30 geschieht, indem Sie den Systemwert QSECURITY auf 30 ändern. Die Aktivierung von Sicherheitsstufe 30 wird mit dem nächsten IPL ausgeführt. Wenn Sie von Sicherheitsstufe 20 auf Sicherheitsstufe 30 wechseln, ändert das System beim nächsten IPL alle Benutzerprofile. Sonderberechtigungen werden den Benutzerprofilen hinzugefügt bzw. entfernt und so an die Sonderberechtigung für die Benutzerklasse angepasst.

Leider ist die Umstellung auf Sicherheitsstufe 30 nicht ganz unproblematisch. Wenn Ihr System Produktionsanwendungen auf einer niedrigeren Sicherheitsstufe ausführt, sollten Sie die Sicherheit auf Objektebene konfigurieren und testen, bevor Sie zur Sicherheitsstufe 30 wechseln. Wenn Sie den Systemwert ohne ausreichende Planung ändern, ist es möglich, dass Ihr Telefon ständig von frustrierten Anwendern belegt wird, die sich darüber beklagen, dass Aufgaben, die früher problemlos ausgeführt werden konnten, mit Nachrichten wie „keine Berechtigung“ fehlschlagen.

Wenn Sie auf Sicherheitsstufe 30 wechseln, wird die Berechtigung *ALLOBJ aus allen Benutzerprofilen entfernt, bei denen es sich nicht um die Benutzerklasse *SECOFR handelt. Benutzer, die früher über *ALLOBJ-Zugriff auf alle Objekte im System verfügten, benötigen nun spezifische Berechtigung für den Zugriff auf alle Objekte. Der nachfolgend beschriebene schrittweise Prozess ermöglicht den reibungslosen Übergang von Sicherheitsstufe 20 auf Sicherheitsstufe 30.

1. Ändern Sie den Systemwert QSECURITY nicht sofort von 20 auf 30. Arbeiten Sie weiter mit Sicherheitsstufe 20, während Sie den Benutzern die Berechtigung für die Objekte erteilen.

2. Weisen Sie die Benutzer Gruppen zu.

•  Bestimmen Sie, ob Benutzergruppen mit ähnlichen Jobanforderungen vorhanden sind, wie z. B. Benutzer aus der gleichen Abteilung, die Zugriff auf die gleichen Informationen benötigen. Einige Benutzer gehören eventuell zu keiner derartigen Gruppe.

•  Spezifizieren Sie die Sonderberechtigung *NONE, wenn Sie ein Gruppenprofil für Benutzer mit ähnlichen Anforderungen erstellen. Das Kennwort für Gruppenprofile sollte *NONE sein, um so die Anmeldung als Gruppenprofil zu verhindern. Ich empfehle eine Namenskonvention für Gruppenprofile (wie z. B. GRPXXX), um Gruppenprofile eindeutig zu kennzeichnen. Ein Beispiel für den Befehl zur Erstellung eines Gruppenprofils für die Vertriebsabteilung ist:

CRTUSRPRF USRPRF(GRPVTR) +

PASSWORD(*NONE) SPCAUT(*NONE) +

TEXT('Gruppenprofil Vertriebsabteilung‘)

•  Verwenden Sie den Befehl CHGUSRPRF – Benutzerprofil ändern, um individuelle Benutzerprofile einer Gruppe zuzuweisen.

Wenn Sie die Benutzer einem Gruppenprofil zuweisen, empfehle ich die Verwendung des Parameters OWNER(*GRPPRF). Damit kennzeichnen Sie das Gruppenprofil als Eigner der neuen Objekte, die von den Benutzern in der Gruppe erstellt werden. Der Befehl für die Zuweisung der Benutzer zum Gruppenprofil GRPCTR lautet:

CHGUSRPRF USRPRF(user_profile) +

GRPPRF(GRPVTR) OWNER(*GRPPRF)

3. Erstellen Sie ein Testbenutzerprofil. Sie können das Testbenutzerprofil verwenden, um fehlende Berechtigung zu entdecken und das Problem zu korrigieren, bevor es sich auf die Produktionsbenutzer auswirkt. Wenn Sie die Testbenutzerprofile erstellen, weisen Sie die Sonderberechtigung *NONE zu und nehmen das Benutzerprofil in die Gruppe auf. Der folgende Befehl beschreibt die Erstellung des Testprofils für die Vertriebsgruppe:

CRTUSRPRF USRPRF (TESTVTR) PASSWORD(X) +

USRCLS(*USER) INLPGM(—) INLMNU(—) +

SPCAUT(*NONE) GRPPRF(GRPVTR) + TEXT('Testprofil

für die Vertriebsgruppe‘)

Die Parameterwerte, die im oben beschriebenen Wert als '— angegeben werden, sollten dieselben sein wie die Werte, die den Benutzern in dieser Gruppe aktuell zugewiesen sind. Eine einfache Methode für das Kopieren der Parameter aus einem vorhanden Benutzerprofil besteht darin, den Befehl WRKUSRPRF - Mit Benutzerprofil arbeiten - zu verwenden und die Kopieroption (Option 3) auszuwählen. Mit dieser Aktion wird eine Bedienerführung für das neue Profil mit den aktuellen Werten ausgegeben. Sie müssen nur noch den Profilnamen, die Benutzerklasse, Sonderberechtigung, Gruppenprofil und Text ändern.

4. Suchen und korrigieren Sie mit dem Testprofil für die Gruppe Bedingungen, bei denen die Nachricht „Nicht berechtigt“ angezeigt wird.

•  Melden Sie sich mit dem Benutzerprofil TESTVTR an und führen Sie die Aufgaben eines Benutzers in der Vertriebsgruppe aus.

•  Wenn eine Aufgabe mit der Nachricht „Nicht berechtigt“ angezeigt wird, verwenden Sie den Befehl GRTOBJAUT - Objektberechtigung erteilen -, um den erforderlichen Zugriff auf das Gruppenprofil zuzuweisen oder die Zugriffsberechtigung für das Objekt auf *PUBLIC zu setzen.

•  Eine Alternative für die Erteilung von Zugriffsberechtigung ist die Verwendung der Berechtigungsübernahme durch Programme.

•  Arbeiten Sie weiterhin mit dem Benutzerprofil TESTVTR, bis Sie alle Aufgaben eines Mitglieds der Gruppe ausführen können.

5. Entfernen Sie die Berechtigung *ALLOBJ eines einzelnen Produktionsbenutzers in der Gruppe.

•  Informieren Sie diesen Benutzer, dass Sie die Systemsicherheit verbessern möchten. Fordern Sie ihn dazu auf, sich an Sie zu wenden, sobald sicherheitsbezogene Anwendungsprobleme auftreten.

•  Entfernen Sie aus diesem individuellen Profil mit Hilfe des Befehls CHGUSRPRF die Berechtigung SPCAUT(*ALLOBJ). Wenn der Produktionsbenutzer Nachrichten zur Nichtberechtigung erhält, erteilen Sie die erforderliche Berechtigung der Allgemeinheit (*PUBLIC), dem Gruppenprofil oder dem individuellen Profil. In den meisten Fällen sollten die Objekte über Berechtigung *PUBLIC verfügen oder über Berechtigung für das Gruppenprofil, deshalb ist nicht zu erwarten, dass andere Mitglieder der Gruppe Nachrichten über eine Nichtberechtigung erhalten.

Setzen Sie Ihre Arbeit fort, bis der Produktionsbenutzer alle Aufgaben ausführen kann.

6. Entfernen Sie mit dem Befehl CHGUSRPRF den Wert *ALLOBJ aus allen anderen Profilen der Gruppenmitglieder.

7. Löschen Sie das Testbenutzerprofil TESTVTR, das in Schritt 3 erstellt wurde. Nicht verwendete Profile, die bei Testläufen übriggeblieben sind oder von Benutzern stammen, die versetzt wurden und nicht mehr im System arbeiten, sind eine in vielen Systemen häufig anzutreffende Sicherheitslücke. Das Problem kann am einfachsten gelöst werden, indem die nicht verwendeten Benutzerprofile sofort gelöscht werden.

8. Wiederholen Sie die Schritte 3 bis 7 für jede weitere Gruppe. Wählen Sie jeweils eine Gruppe aus und bearbeiten Sie diese vollständig, bevor Sie die nächste Gruppe konfigurieren.

9. Nun wenden Sie sich den Benutzern zu, die nicht Mitglieder eines Gruppenprofils sind. Nachdem Sie alle Produktionsbenutzer, die Mitglieder einer Gruppe sind, mit ausreichender Berechtigung ausgestattet haben, müssen Sie die *ALLOBJ-Zugriffsrechte den übrigen Benutzern entziehen, die nicht Mitglied einer Gruppe sind. Der Befehl DSPAUTUSR - Berechtigte Benutzer anzeigen - kann alle Benutzerprofile und ihre Gruppenmitgliedschaft anzeigen.

DSPAUTUSR kann darüber hinaus Profile anzeigen, die zu keinem Gruppenprofil gehören. Ich empfehle Ihnen, die Einstellungen für Benutzer, die zu keiner Gruppe gehören, erst nach Beendigung der Arbeit mit allen Gruppen vorzunehmen. Auf diese Weise können Sie die Anzahl der Anrufe reduzieren, die Sie von Benutzern mit Berechtigungsproblemen erhalten.

10. Vergeben Sie an privilegierte Benutzer Berechtigungen für die Arbeitsstationen. Wenn der Systemwert QLMTSECOFR (Zugriff des Sicherheitsadministrators auf die Einheiten begrenzen) 1 (Ja) beträgt, müssen Benutzer mit spezieller *ALLOBJ- oder *SERVICE-Berechtigung wie z. B. QSECOFR spezifische Berechtigung erhalten, auf Einheiten mit Sicherheitsstufe 30 oder höher zuzugreifen. Geben Sie diesen Benutzern für die Arbeitsstation, die sie verwenden, *CHANGE-Berechtigung.

11. Ändern Sie den Systemwert. Nachdem Sie aus allen Profilen außer denen der Benutzer der Benutzerklasse *SECOFR die Berechtigung *ALLOBJ entfernt haben, können Sie den Systemwert QSECURITY von 20 auf 30 ändern, ohne die Benutzer in Aufruhr zu versetzen. Wenn Sie den Systemwert von 20 auf 30 ändern und ein IPL ausführen, wird *ALLOBJ aus allen Benutzerprofilen entfernt. Wenn Sie die Schritte 1 bis 10 befolgen, muss das System keine Sonderberechtigung hinzufügen oder entfernen, um die Standardeinstellungen für Sicherheitsstufe 30 zu berücksichtigen. Nachdem der Systemwert geändert wurde und ein IPL erfolgt ist, können Sie sich gratulieren. Aber vergewissern Sie sich, dass Sie nicht den letzten, wichtigen Schritt vergessen haben.

Nachdem Sie nun viel Zeit damit verbracht haben, die Benutzerprofile und Benutzergruppen mit der korrekten Berechtigung zu versehen, müssen Sie SAVSECDTA - Sicherheitsdaten speichern – oder SAVSYS - System sichern - ausführen, um eine Sicherungskopie der Benutzerprofile und Berechtigungen zu erstellen.

Lesen Sie weiter im nächsten TechKnowLetter.