IBM i: Sicherheitsgrundlagen für die Administration – Sonderberechtigungen, Objektberechtigungen, QSECURITY und QAUDJRN

Worum es geht

Die Zugriffskontrolle von IBM i besteht aus zwei voneinander unabhängigen Ebenen. Sonderberechtigungen (Special Authorities), die über den Parameter SPCAUT eines Benutzerprofils vergeben werden, steuern systemweite Fähigkeiten und nicht den Zugriff auf ein einzelnes Objekt. *ALLOBJ (All-Object) erlaubt den Zugriff auf jede Ressource des Systems, unabhängig von den Berechtigungseinstellungen des jeweiligen Objekts. Selbst ein Objekt, das für diesen Benutzer ausdrücklich auf *EXCLUDE gesetzt ist, wird dadurch zugänglich. Das Anlegen oder Ändern von Benutzerprofilen ist damit allein aber nicht möglich; dafür ist die separate Sonderberechtigung *SECADM (Security Administrator) erforderlich. Um *SECADM an andere zu vergeben, braucht ein Benutzer sowohl *ALLOBJ als auch *SECADM.

Objektberechtigung (Object Authority) ist die Ebene pro Objekt: Sie legt fest, wer eine bestimmte Bibliothek, Datei oder ein bestimmtes Programm lesen, ändern oder verwalten darf. DSPOBJAUT zeigt, wer für ein Objekt berechtigt ist (Eigentümer, private Berechtigungen, *PUBLIC sowie eine allfällige Berechtigungsliste, die das Objekt schützt). EDTOBJAUT bearbeitet diese Berechtigungen interaktiv, GRTOBJAUT und RVKOBJAUT tun dies nicht interaktiv. Ein Eintrag *GROUP in der Spalte „User“ dieser Anzeige bedeutet, dass der Anfragende über ein Gruppenprofil und nicht direkt über sein eigenes Benutzerprofil für das Objekt berechtigt war. Das sollte geprüft werden, bevor der Schluss gezogen wird, ein Benutzer habe keinen Zugriffsweg auf ein Objekt.

Der Systemwert QSECURITY legt die allgemeine Sicherheitsstufe fest (in aktuellen Releases 20, 30, 40 oder 50, mit aufsteigender Strenge; Stufe 10 lässt sich nicht mehr einstellen). Ab Stufe 40 werden zusätzlich Programme abgewiesen, die nicht unterstützte Schnittstellen verwenden oder andere Integritätslücken aufweisen. DSPSYSVAL QSECURITY zeigt die aktuelle Stufe an. Eine Änderung wird erst beim nächsten IPL wirksam und ist ein systemweiter Eingriff mit grosser Wirkung. Sie gehört in ein Änderungsfenster und ist keine Routineaufgabe.

Das Journal QAUDJRN ist der Sicherheits-Audit-Trail von IBM i: Objektzugriffe, Berechtigungsfehler, Profiländerungen und mehr werden dort protokolliert, sofern das Journal existiert und das Auditing über die Systemwerte QAUDCTL und QAUDLVL aktiviert ist (zum Beispiel *AUTFAIL und *PGMFAIL, um Berechtigungs- und Programmfehler zu protokollieren). CHGSECAUD legt das Journal bei Bedarf an und setzt diese Werte in einem Schritt, statt sie von Hand zu konfigurieren. Anders als bei QSECURITY werden Änderungen an diesen Audit-Systemwerten ohne IPL wirksam.

Warum es wichtig ist

Ein Agent, der administrative Aufgaben auf IBM i übernimmt, sollte jeweils die kleinste Sonderberechtigung verwenden, mit der sich die Aufgabe erledigen lässt: für die Profilverwaltung etwa nur *SECADM statt *ALLOBJ. Er sollte ausserdem wissen, dass das Erhöhen von QSECURITY oder das Einschalten des Auditings für QAUDJRN folgenreiche, prüfbare Änderungen sind und keine routinemässige Konfiguration.

So wird es angewendet

• Vor der Vergabe von *ALLOBJ die Sonderberechtigungen des Profils prüfen (DSPUSRPRF) und klären, ob eine engere Berechtigung (*SECADM, *JOBCTL, *SAVSYS usw.) genügt.
• Berechtigungen für bestimmte Objekte mit DSPOBJAUT/EDTOBJAUT prüfen und setzen, statt reflexartig auf *ALLOBJ-Zugriff auszuweichen, um einen Berechtigungsfehler zu umgehen.
• DSPSYSVAL QSECURITY sowie die Konfiguration von QAUDJRN/QAUDLVL prüfen, bevor Annahmen darüber getroffen werden, was protokolliert wird und was nicht.
• Jede Änderung an QSECURITY, QAUDCTL oder an Sonderberechtigungen derselben Änderungskontrolle unterstellen wie eine Konfigurationsänderung in der Produktion.

Stolpersteine

• *ALLOBJ als „darf alles“ verstehen, einschliesslich Profilverwaltung. Ohne *SECADM ist diese nicht möglich.
• Annehmen, QAUDJRN erfasse standardmässig alles. Das Auditing ist optional und richtet sich nach den konfigurierten QAUDLVL-Werten.
• Übersehen, dass das Erhöhen von QSECURITY auf 40 oder höher Programme funktionsunfähig machen kann, die auf Integritätslücken angewiesen waren, welche die tieferen Stufen tolerierten. Vor einer Änderung in der Produktion testen.