Von QSECURITY 20 nach QSECURITY 40 – Teil 2

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.

Von Sicherheitsstufe 30 auf Sicherheitsstufe 40 wechseln

Die Prozedur für den Wechsel von Sicherheitsstufe 30 auf Sicherheitsstufe 40 ähnelt dem Wechsel von Sicherheitsstufe 20 auf Sicherheitsstufe 30, aber Ihr Augenmerk sollte dabei auf den Programmen liegen, die gegen die Einschränkungen der Sicherheitsstufe 40 verstoßen, die früher in diesem Kapitel beschrieben wurden.

Zur Übersicht was in den unterschiedlichen Sicherheitsstufen unterstützt wird:

Neben den in Tabelle 1 genannten Funktionen ist es wichtig zu wissen dass die Sicherheitsstufe die standardmäßig vergebenen Sonderberechtigungen bestimmt. Um den Begriff der Sonderberechtigungen zu verstehen und wie diese zu den Benutzerklassen gehören wenn Sie ein Benutzerprofil erstellen, drücken Sie die Hilfe-Taste auf dem Parameter Benutzerklasse und diese erläutert das Zusammenspiel:

Hilfe zur Benutzerklasse

Gibt die Art des Benutzers an, der diesem Benutzerprofil zugeordnet ist: Sicherheitsbeauftragter, Sicherheitsadministrator, Programmierer, Systembediener oder Benutzer. Die Benutzerklasse steuert die im Menü gezeigten Auswahlmöglichkeiten. Sonderberechtigungen werden nur erteilt, wenn *USRCLS für den Parameter Sonderberechtigung (SPCAUT) angegeben wird. Wurde SPCAUT(*USRCLS) angegeben, variieren die Sonderberechtigungen abhängig vom QSECURITY-Wert. 

*SAME

Der Wert ändert sich nicht.

*USER

Auf QSECURITY-Sicherheitsstufe 10 oder 20 verfügt der Benutzer über die  Berechtigungen *ALLOBJ und *SAVSYS.

Auf QSECURITY-Sicherheitsstufe 30 oder höher hat der Benutzer keine Sonderberechtigungen.

*SECOFR

Auf allen Sicherheitsstufen verfügt der Sicherheitsbeauftragte über die folgenden Sonderberechtigungen:

*ALLOBJ

*SAVSYS

*JOBCTL

*SERVICE

*SPLCTL

*SECADM

*AUDIT

*IOSYSCFG

*SECADM

Auf QSECURITY-Sicherheitsstufe 10 oder 20 verfügt der Sicherheitsadministrator über die Sonderberechtigungen *ALLOBJ, *SAVSYS, *SECADM und *JOBCTL.

Auf QSECURITY-Sicherheitsstufe 30 oder höher verfügt der Benutzer über die Sonderberechtigungen *SECADM.

*PGMR

Auf QSECURITY-Sicherheitsstufe 10 oder 20 verfügt der Programmierer über die Sonderberechtigungen *ALLOBJ, *SAVSYS und *JOBCTL.

Auf QSECURITY-Sicherheitsstufe 30 oder höher hat der Benutzer keine Sonderberechtigungen.

*SYSOPR

Auf QSECURITY-Sicherheitsstufe 10 oder 20 verfügt der Systembediener über die Sonderberechtigungen *ALLOBJ, *SAVSYS und *JOBCTL.

Auf QSECURITY-Sicherheitsstufe 30 oder höher verfügt der Benutzer über die Sonderberechtigungen *SAVSYS und *JOBCTL.

Wenn Sie ein Benutzerprofil erstellen, können Sie Sonderberechtigungen auf der Grundlage der Benutzer-Klasse auswählen. Sonderberechtigungen werden zu Benutzerprofilen ebenfalls hinzugefügt oder davon entfernt wenn Sie die Sicherheitsstufe ändern.

Sicherheitsstufe 40 betrifft fast jedes Objekt, wenn nicht gar jedes Objekt auf dem System. Da es einiges bei der Umstellung auf Level 40 zu beachten gibt, ist es hilfreich wissen, dass es einen "empfohlenen Weg" gibt, sich auf diese doch wesentliche Änderung im System vorzubereiten. Das Tool, das alle Experten empfehlen, ist das Auditjournal. Sie müssen das Auditjournal erstellen und einschalten, dessen Inhalt für eine Weile überwachen um sicher zu sein, dass Ihr System mit Ihren Anwendungen die Sicherheitsstufe 40 oder höher unterstützt. Dies führt uns auf weine weitere Frage: "Brauche ich Journalisierung um auf Sicherheitsstufe 40 laufen zu können?"

Die einfache Antwort auf diese Frage ist "Ja", aber es ist nicht exakt das gleiche Konzept wie Datenbank-Journalisierung Sie brauchen zum Einrichten des Auditjournals ein Journalobjekt auf Ihrem System und müssen Journalempfänger an dieses anhängen, ähnlich wie bei der Datenbankjournalisierung. Dann müssen Sie Ihrem System über die Systemwerte QAUDLVL und QAUDLVL2 genau beibringen, welche Art von Sicherheitsprüfungen aufgezeichnet und gesucht werden sollen.

Sicherheitsprüfungen deshalb, weil diese bereits mit Sicherheitsstufe 30 existieren. Nur sind diese in Sicherheitsstufe 30 nicht wirksam, doch es gibt sie. Mit anderen Worten, ab Sicherheitsstufe 40, weiß das System, dass Ihr Code die Integrität oder andere Regeln der Sicherheitsstufe 40 oder 50 Regeln verletzt. Nachdem das System den Fehler aufgezeichnet hat, was sich natürlich auf die Leistung auswirkt, wird bei Sicherheitsstufe 30 das Programm trotzdem funktionieren. In Sicherheitsstufe 40 und 50, erzeugt diese Ausführung Meldungen und der Job schlägt fehl.

Die gute Nachricht ist, dass Sprung von Sicherheitsstufe 30 auf 40 keine Änderungen an den Profilen oder Berechtigungslisten mit sich bringt, so dass, wenn alles gut geht, es leicht umzustellen ist. Darüber hinaus hat es absolut keinen Einfluss auf die Programme, die Berechtigungen übernehmen (sogenannte Adopted Authority), sofern diese Standard-Interfaces verwenden.

Nach Konfiguration der Audit Journalisierung zum Aufzeichnen von Fehlern, beobachten Sie es für eine Zeit, die so lang sein sollte um alle Geschäftsvorfälle die vorkommen zu beinhalten. Am Besten geschieht dies zum Ende des Geschäftsjahres mit allen jährlichen, vierteljährlichen, monatlichen und täglichen Abläufen. Das Ziel muss sein soviel Prozesse wie möglich durchzuspielen um zu sehen, ob Einträge im Auditjournal mit Typ AF (Authority Failure – Berechtigungsfehler) generiert werden.

Die Einträge im Audit Journal vom Typ AF werden nicht so viele sein, selten gibt es Audit-Journale mit mehr als 100 Seiten. Das ist in der Regel keine große Sache in Bezug auf die Speicherung und die Auswirkungen auf die Leistung geht gegen Null.

Sie werden erstaunt sein, was auf Ihren Auditprotokollen erscheint, wenn Sie diese zum ersten Mal untersuchen. Sie tun bestimmt nur was notwendig ist um schnell auf die Sicherheitsstufe 40 wechseln zu können. Aber es gibt eine Menge von anderen Optionen die Ihnen helfen können Ihr System transparenter zu machen. Sollten Sie mit der Auswertung der Audit-Journale an ihre Grenzen stoßen, gibt es einige Produkte von Security-Anbietern die Ihnen die Arbeit durch vordefinierte Regeln und Auswertungen leichter machen.

Bevor Sie mit der Audit-Journalprozedur beginnen, sollten Sie eine Bestandsaufnahme aller Software-Pakete auf Ihrem System vornehmen und alle Anbieter kontaktieren um zu sehen, ob diese konform mit Sicherheitsstufe 40 sind. Wenn sie nicht kompatibel sind, und Sie die Programme brauchen, können Sie die Sicherheitsstufe 40 nicht umsetzen bevor kein Update verfügbar ist und Sie dies installiert haben.  Die meisten Anbieter sind bereits mit ihren Software-Version kompatibel, aber trotzdem ist es an Ihnen die Entscheidung zu treffen. Deshalb, egal was Ihnen die Verkäufer sagen, lassen Sie trotzdem das Journal für eine Weile laufen, um sicherzustellen, dass sauber funktioniert.

Bevor wir uns der Einrichtung und des Anhängens des Journals widmen, lassen Sie uns die Art der Einträge, nach denen Sie im Journal schauen müssen anschauen, damit Sie verstehen lernen, ob Sie mit Sicherheitsstufe 40 arbeiten können. Die beste Quelle dafür ist die Tabelle des IBM Sicherheits-Referenz-Handbuch. Nachstehend zur Vereinfachung diese Tabelle:

¹    Ein Berechtigungsfehler (AF) wird in das Auditjournal geschrieben wen die Auditierung aktiv ist.

²    Wenn der Prozessor den erweiterten Hardwarespeicherschutz unterstützt

³   Programme die vor V1R1 erstellt wurden, haben keinen Validierungswert

⁴   Wenn Sie einen von IBM gelieferten Befehl ändern kann er nicht länger als System Domain Programm aufgerufen werden.

Wenn Sie die Auditierungs-Funktion in einer unteren Sicherheitsstufe wie 30 verwenden, meldet das System Journaleinträge für die meisten Aktionen die in obiger Tabelle dargestellt sind. Sie erhalten Warnungen in Form von Journaleinträgen für potenzielle Integritätsverletzungen. Wie Sie in der Tabelle sehen können, verursachen Integritätsverletzungen auf Sicherheitsstufe 40 und höher Fehlermeldungen, die ausgeführte Operation schlägt fehl.

Die andere Sache, die Sicherheitsstufe 40 abfängt ist die Verwendung von nicht unterstützten Schnittstellen. Bei Sicherheitsstufe 40 und höher, verhindert das System Versuche, System-Programme aufzurufen die nicht als Call-Level-Interface dokumentiert sind. Zum Beispiel schlägt ein direktes Aufrufen des Befehlsverarbeitungsprogramms für den SIGNOFF Befehl fehl. Das System nutzt seine eigenen Tricks, um diese zu ermöglichen. Ohne dies jetzt detailliert erklären zu wollen, prüft es das Domain Attribut eines Objekts und das State-Attribut eines Programms, um diesen Schutz zu erzwingen. Jedes Objekt gehört entweder zur *SYSTEM Domäne oder der *USER Domäne. Auf *SYSTEM Domänen-Objekte kann nur von *SYSTEM State Programmen oder Programmen, die den *System State erben in einem unterstützten Mode (*INHERIT) zugegriffen werden. Die Programme sind entweder als *SYSTEM State, *INHERIT State oder *USER State eingestuft. Die *USER State Programme können direkt nur auf *USER Domain-Objekte zugreifen. Wenn *USER State Programme direkt *SYSTEM Domain-Objekte verwenden, resultiert das in einem Fehler, wie in obiger Tabelle angegeben.

Eine Domänen- oder State-Verletzung bewirkt, dass die Operation an der Sicherheitsprüfung der Stufe 40 und höher fehlschlägt. Bei allen Sicherheitsstufen wird aber ein Eintrag vom Typ AF in das Auditjournal geschrieben, wenn die Auditierungs-Funktion aktiv ist. Wenn eine Domänen-  oder State-Verletzung auftritt, die Auditierungs-Funktion aktiviert ist und der Systemwert QAUDLVL *PGMFAIL enthält wird ein Eintrag vom Typ D oder R in das Auditjournal geschrieben sobald versucht wird ein nicht unterstütztes Interface zu verwenden.

Bei Sicherheitsstufe 40 und höher, muss ein Benutzer um einen Job zu übergeben *USE-Berechtigung sowohl für die Jobbeschreibung, als auch für das Benutzerprofil das in der Jobbeschreibung angegeben ist haben. Andernfalls schlägt die Übergabe fehl. Bei Sicherheitsstufe 30 läuft der Job, wenn der Benutzer der den Job übergibt *USE-Berechtigung nur auf die Jobbeschreibung hat.  Wenn die Audit-Funktion aktiviert ist und der Systemwert QAUDLVL auf *AUTFAIL enthält, wird ein AF-Eintrag mit Subtyp J in das Auditjournal geschrieben.

Jeder der sich ohne Benutzer-ID und Kennwort bei Sicherheitsstufe 30 durch Drücken der Enter-Taste über bestimmte Subsysteme anmeldet erhält Zugriff auf das System. Bei Sicherheitsstufe 40 und höher, stoppt das System Versuche sich so anzumelden. Wenn Audit aktiv ist und der Systemwert QAUDLVL *AUTFAIL enthält wird ein AF-Eintrag, Subtyp S im Auditjournal aufgezeichnet.

Dann gibt es noch die Enhanced Hardware Storage-Protection. Diese Hardware-Einrichtung ermöglicht Blöcke von System-Informationen auf der Festplatte als read-write, read-only, oder ohne Zugriff zu definieren. Bei Sicherheitsstufe 40 und höher, steuert das System, wie *USER State-Programme auf diese geschützten Blöcke zugreift. Diese Unterstützung ist auf Systemen mit Sicherheitsstufen kleiner als 40 nicht verfügbar. Diese Fähigkeit ist bei den meisten einigermaßen aktuellen Power i Systemen verfügbar. Wenn Auditierung aktiviert wird und der Systemwert QAUDLVL *PGMFAIL enthält, wird ein AF-Eintrag, Subtype R in das Auditjournal geschrieben wenn solche Verletzungen auftreten.

Während der Auditierung auf Sicherheitsstufe 30 vor der Migration auf 40 haben Sie die Möglichkeit, Ressourcen-Sicherheit für alle Ihre Anwendungen zu testen. Deshalb beginnen Sie den Audit-Prozess, bevor Sie diesen Schritt machen. Auf diese Weise und durch eine gründliche Analyse der Journaleinträge, sind Sie in der Lage herauszubekommen wann Sie keine Probleme beim Umstieg auf Sicherheitsstufe 40 haben werden.

Wie oben erwähnt sind die beiden kritischsten einzustellenden Werte für den QAUDLVL-Systemwert der *PGMFAIL und *AUTFAIL. *PGMFAIL protokolliert Journaleinträge für alle Zugriffsversuche welche bei Sicherheitsstufe die Integrität verletzen, *AUTFAIL erfasst ungültig Anmeldungen (leer) sowie fehlende Berechtigungen auf Jobbeschreibungen und Benutzerprofile.

Nachdem Sie die Audit-Umgebung eingerichtet und aktiviert haben, ist Ihre Aufgabe, die Überwachung des Auditjournals auf *AUTFAIL und *PGMFAIL Einträge,  während des Betriebs all Ihrer Anwendungen solange Sie noch auf Sicherheitsstufe 30 sind. Die wichtigsten Subtypen innerhalb der AF-Einträge sind:

 • B – Ein Programm hat eine restriktierte Maschineninterface-Anweisung aufgerufen

 • C – Ein Programm ist bei Objektvalidierung fehlgeschlagen

 • D – Programm griff auf ein Objekt über ein nicht unterstütztes Interface zu

 • J – Jobbeschreibungs- und Benutzerprofil-Berechtigungsfehler

 • R – Versuch auf geschützten Bereich der Festplatte zugreifen

 • S – Standard-Anmeldeversuch ohne Benutzer-ID/Kennwort

Dies sind die Codes, die auf das Vorkommen von Integritätsverletzungen Ihren Anwendungen hinweisen wenn Sie Sicherheitsstufe 40 verwenden würden.

Noch eines bevor wir beginnen die Objekte zu erstellen die Sie brauchen um Audit-Journalisierung zu implementieren: Alle Programme die vor OS/400 Version 1 Release 3 erstellt wurden (und das dürften relativ wenige sein), haben sie keine Validierungs Codes. Dies ist kein ernstes Problem, aber es wird ein Problem mit Sicherheitsstufe 40, wenn Sie diese Objekte zurückspeichern. Die beste Möglichkeit ist, ein CHGPGM auf jedes dieser Programme anzuwenden und den FRCCRT Parameter zur Erstellung der Validierungscodes für diese Programme einzusetzen.

Auf Sicherheitsstufe 40, basierend auf Ihren Einstellungen der drei System-Werte, Objekt beim Zurückspeichern prüfen (QVFYOBJRST), Umsetzung beim Zurückspeichern erzwingen (QFRCCVNRST) und Objektrückspeicherung zulassen (QALWOBJRST), wird das System die Aktion, die Sie anfordern verwenden. Bei der Wiederherstellung arbeiten diese Werte als eine Reihe von Filtern, um festzustellen, ob ein Programm ohne Änderung wiederhergestellt wird, ob es neu erstellt (konvertiert) wird, wie es wiederhergestellt wird, oder ob es nicht an wiederhergestellt wird.

Nachdem Sie alle diese Fragen gelöst haben, stellen Sie auf Sicherheitsstufe 40 um.

Lesen Sie weiter im nächsten TechKnowLetter.