von Carol Woodbury

 Mythos Nr. 1: Benutzer-Klasse

Beginnen möchte ich mit einer Besprechung des Attributs Benutzer-Klasse im Benutzerprofil. Die Benutzer-Klasse wird nie für den Abgleich der Zugriffsrechte verwendet. Ich wünschte, ich hätte einen Dollar für jedes Mal, wenn mich hierzu jemand gefragt hat und bei der Beschreibung der Situation gesagt hat: „Der Benutzer ist in der *SECOFR Benutzer-Klasse.“

Wenn es darum geht festzustellen, warum ein Benutzer nicht zugreifen kann oder aber auf ein Objekt zugreifen kann, auf das er eigentlich nicht zugreifen darf, dann kann man das Attribut Benutzer-Klasse getrost ignorieren. Welche Benutzer-Klasse eingestellt ist, spielt einfach keine Rolle; der Algorithmus, der die Zugriffsberechtigung checkt, fragt das Attribut Benutzer-Klasse gar nicht ab.

Der Benutzer könnte in der Benutzer-Klasse *USER sein und alle nur möglichen Berechtigungen haben oder er könnte der *SECOFR Benutzer-Klasse zugeordnet sein und über gar keine besonderen Berechtigungen verfügen.

Wenn jemand sich also in diesem Zusammenhang das Klassen-Attribut ansieht, kann das durchaus dazu führen, dass er von falschen Voraussetzungen ausgeht. Die Benutzer-Klasse wird nur verwendet, um als Default Wert den Arbeitsbereich des Benutzers festzulegen wenn es darum geht, welche IBM i Menü-Optionen der Benutzer sehen soll und um festzulegen, ob besondere Zugriffsrechte beim IPL des Systems eingestellt werden müssen zwischen dem Security Level 20 und einem höheren Security Level.

 

 

Mythos Nr. 2: Adopted Authority

Die meisten Leute wissen, dass die Adopted Authority durch das Einstellen eines Attributs in einem Programm zugewiesen wird. Das Problem ist jedoch, dass viele Leute in diesem Zusammenhang an das falsche Attribut denken. Die Adopted Authority hängt von zwei Programm-Attributen ab: Use Adopted Authority (USEADPAUT) und User Profile (USRPRF). Es ist – wenn man sich den Namen ansieht – ganz offensichtlich, warum die meisten Leute denken, der Parameter USEADPAUT habe die Kontrolle, aber das stimmt nicht. Die Kontrolle hat das Attribut USRPRF. Wenn USRPRF auf *USER – den Defaultwert – eingestellt wird, übernimmt das Programm nicht. Wenn USRPRF dagegen *OWNER enthält, dann übernimmt das Programm die Berechtigungsstufe des Programms Owner, wenn die Person, die das Programm aufruft, über keine ausreichende Berechtigung verfügt.

Aber was wird dann durch das Attribut USEADPAUT gesteuert? Hier möchte ich zunächst einmal feststellen, dass die Übernahme der Berechtigungsstufe durch ein Programm (i.e. USRPRF enthält *OWNER) dazu führt, dass diese Berechtigungsstufe auch für alle in Folge aufgerufenen Programme gilt. Der Parameter USEADPAUT steuert dann, ob ein solches Programm die Berechtigungsstufe, die es durch ein zuvor laufendes Programm erhielt, auch tatsächlich verwendet. Das ist die einzige Möglichkeit, um zu verhindern, dass die weitergereichte Berechtigung verwendet wird.

Mythos Nr. 3: Adopted Authority und dynamisches SQL

Weiter im Zusammenhang mit Adopted Authority – trifft es immer zu, dass alles was innerhalb eines Programms passiert oder initiiert wird, dessen Berechtigung übernimmt, wenn das Programmattribut von User Profile auf *OWNER eingestellt ist?

Nicht immer. Enthält das Programm dynamisches SQL, dann passiert das nicht, da dynamisches SQL keinen Zugriff auf die übernommene Berechtigung des Programms hat. Wenn Sie wollen, dass das SQL-Statement die Berechtigung übernimmt, müssen Sie das Attribut Dynamic User Profile auf *OWNER stellen, wenn Sie Ihr Programm kompilieren. Ich sage hier ausdrücklich „wenn“ im zeitlichen Sinne. Sie können die Attribute, die die Übernahme der Berechtigung steuern, entweder zu dem Zeitpunkt setzen, wenn Sie das Programm kompilieren wollen oder indem Sie den Befehl Change Program (CHGPGM) laufen lassen. Es gibt bedauerlicherweise kein Interface, das es ermöglichen würde, das Attribut Dynamic User Profile nach der Kompilierung zu ändern. Zu diesem Zweck müssen Sie immer rekompilieren.

Mythos Nr. 4: ALLOBJ Sonderberechtigung

Hier befasse ich mich mit dem Parameter *ALLOBJ und der Sonderberechtigung. In manchen Unternehmen bin ich auf den Fall gestoßen, dass dem Gruppenprofil eines Benutzers *ALLOBJ zugewiesen wurde und dann sollte der Zugriff auf die verschiedenen Dateien und Befehle durch *EXCLUDE gesteuert werden. Man war der Meinung, die Berechtigungen des Benutzers auf diese Weise kontrollieren zu können.

Tatsächlich jedoch wird der IBM i Algorithmus, der die Zugriffsberechtigung checkt, sobald er direkt beim User auf *ALLOBJ stößt, gar nicht weiter prüfen, ob bei diesem Benutzer eventuell ein Ausschluss für eine Datei oder ein Objekt eingegeben wurde.

So vermittelt das oben beschriebene Vorgehen unglücklicherweise ein trügerisches Gefühl von Sicherheit. Der Benutzer, der versucht mit einem Objekt zu arbeiten, von dem er im obigen Szenario mit *EXCLUDE ausgeschlossen werden sollte, wird zwar eine Message erhalten „Not authorized to Object xxx“. Das Problem ist aber, dass der Benutzer diese Barriere ohne Weiteres umgehen kann, indem er den Job zum Beispiel mit einem Profil startet, das kein *EXCLUDE für dieses Objekt enthält. Und das ist nur eine Möglichkeit. Es gibt einfach zu viele Objekte, die man für den User sperren müsste, um alle Möglichkeiten der Umgehung auszuschließen. Und man kann sich natürlich nie sicher sein, dass man alle Varianten des Zugriffs abgedeckt hat.

Zusätzlich müsste man auch noch nach jedem Upgrade das System daraufhin prüfen, ob mit dem neuen Release nicht etwa neue Möglichkeiten des verbotenen Zugriffs eröffnet wurden.

Um auf der sicheren Seite zu sein, muss man es einfach als Tatsache akzeptieren, dass durch die Zuteilung der Sonderberechtigung mittels *ALLOBJ – ob auf individueller Ebene oder auf Gruppenebene – der Benutzer jedenfalls auf jedes beliebige Objekt im System zugreifen kann.

Mythos Nr. 5: Security Level 20

Viele Leute nehmen fälschlicherweise an, auf der Sicherheitsebene 20 gebe es keine Überprüfung der Zugriffsberechtigung. Das mag zwar so aussehen, Tatsache aber ist, dass derselbe Algorithmus die Zugriffsberechtigung auf Ebene 20 checkt, wie auf Ebene 50.

Es sieht nur so aus, als gebe es keine Sicherheitsüberprüfung, weil als Default-Wert bei der Erstellung aller Profile die Sonderberechtigung durch den Parameter *ALLOBJ vorgegeben ist. Deshalb können alle Benutzer auf alle Objekte des Systems primär mal zugreifen.

Nachdem dieser Algorithmus auf allen Ebenen gilt, können Sie nach der Erstellung eines Profils dann die Sonderberechtigung durch Entfernen des Parameters *ALLOBJ entfernen und Ihre Sicherheitseinstellungen testen, bevor Sie zum nächsten Sicherheits-Level gehen.

Mythos Nr. 6: Passwort-Ablauf Intervall

Wenn wir eine Sicherheitsprüfung durchführen, lassen wir auch einen Bericht erstellen, der ausweist, bei welchen Profilen das Passwort-Ablauf-Intervall auf *NOMAX gestellt ist. Untersuchen wir diese Profile dann, so stellen wir fest, dass es bei einigen davon gar kein Passwort gibt. Manche Administratoren geben bei Profilen, die kein Passwort haben, das Passwort-Ablauf-Intervall mit *NOMAX an, da sie irrtümlicherweise annehmen, dass das System dies prüft und dann irgendwie verlangen würde, dass das Profil ein neues Passwort anmeldet. So funktioniert das aber nicht. Wenn das Profil kein Passwort hat, so wird das Passwort-Intervall-Attribut nie ausgelesen. Man kann daher problemlos das Passwort-Ablauf-Intervall auf *SYSVAL, dem ursprünglichen Default-Wert belassen und so vermeiden, dass der Auditor (oder wir) einen Bericht erhält, mit Passworten, die sich nie verändern.

Mythos Nr. 7: QAUDLVL2

Ich habe festgestellt, dass das Abspeichern von Audit Journal Receivers in den meisten Unternehmen nicht ernst genommen wird. In manchen Unternehmen werden sie überhaupt ohne Sicherung aus dem System gelöscht. Ein solches Vorgehen kann in manchen Fällen gegen die geltenden Vorschriften verstoßen. So verlangen beispielsweise die Kreditkarten-Unternehmen, dass Prüfergebnisse online vorgehalten werden oder mindestens 90 Tage für einen einfachen Zugriff verfügbar gemacht werden und dass alle Prüfergebnisse mindestens ein Jahr gespeichert werden. Stellen Sie daher sicher, dass Ihre Methode der Sicherung von Audit Journal Receivers

1. es ermöglicht, mühelos festzustellen, welche Receivers wieder aktiviert werden müssen, sobald Sie ein Vorkommnis nachvollziehen müssen und
2. behalten Sie immer die für Ihr Unternehmen geltenden Vorschriften im Auge.

Mythos Nr. 8: Object Auditing

Und weil wir gerade beim Thema Auditing sind: Eine weitere Frage bezieht sich auf den Systemwert QAUDCTL, der die Überwachung ein- oder ausschaltet. Wenn für den Systemwert QAUDCTL nicht der Wert *OBJAUD festgelegt wird, findet für einzelne Objekte keine Überwachung statt. Lassen Sie mich das näher erläutern: Das System bietet zwei Arten von Überwachung an: Die Überwachung von Aktionen zeichnet Ereignisse wie das Erstellen und Löschen von Objekten, Zugriffsversuche ohne ausreichende Berechtigung (Berechtigungsfehler) und Ähnliches auf. Die Objekt-Überwachung liest oder aktualisiert einzelne Objekte. Ich wurde schon öfter darum gebeten, herauszufinden, warum keine Audit-Einträge geschrieben werden, wenn ein Objekt geändert wird. In allen diesen Fällen hatte man zwar die Objekt-Überwachung mit dem Befehl CHGOBJAUD konfiguriert, aber nicht daran gedacht, die Einstellung *OBJAUD zum Systemwert QAUDCTL hinzuzufügen.

Hinweis: Ein weiterer Grund, warum man eventuell keine Object Auditing-Einträge findet, könnte darin liegen, dass die Aktion, die mit dem Objekt vorgenommen wird, nicht dafür vorgesehen ist, einen Audit-Eintrag zu generieren. Im Security Reference Manual, Anhang E, finden Sie eine Aufstellung, welche Aktionen bei welchen Objekttypen Audit-Einträge erzeugen.

Mythos Nr. 9: Audit-Journal-Einträge

Ein weiterer Mythos, der sich um das Thema Auditing rankt, lautet etwa so: Wenn man das Auditing einmal aktiviert hat, muss man jeden Audit-Journal-Eintrag, der generiert wurde, auch überprüfen. Ich weiß nicht, woher diese Auffassung stammt, aber sie ist definitiv falsch. Tatsächlich sehen sich selbst Anwender, die regelmäßig Berichte über das Audit-Journal erstellen, nicht jeden Eintrag genau an. Ich kenne nur einen Fall, wo jeder Eintrag überprüft wird, und diese Firma beschäftigt eine Vollzeitkraft nur mit dieser Aufgabe. Unvorstellbar, wie langweilig das sein muss! Ich bin dafür, dass das Auditing auf jedem System aktiviert wird und dass regelmäßig Berichte darüber erstellt werden. Aber auch, wenn Sie sich nicht dazu entschließen, Berichte zu erstellen, empfehle ich, das Auditing zu aktivieren, sodass Sie, falls doch einmal etwas passiert, zumindest die forensischen Informationen dafür haben, den Zwischenfall aufzuklären. Stellen Sie sicher, dass Ihre Audit-Journal-Receiver gesichert werden, damit Sie auch auf länger zurückliegende Ereignisse noch reagieren können.

Mythos Nr. 10: Inaktive Profile

Der letzte Mythos, auf den ich eingehen will, handelt von der Entdeckung inaktiver Profile. Viele Anwender zögern anscheinend damit, Benutzerprofile zu löschen oder wenigstens auf *DISABLED zu setzen. Ich habe aber auch schon Geschichten von Profilen gehört, die gelöscht wurden, während sie aktiv waren. Das Problem bestand immer darin, dass das falsche Datum überprüft wurde. Ich habe festgestellt, dass beim versehentlichen Löschen aktiver Profile immer das letzte Sign-On-Datum überprüft wurde. Stattdessen muss das letzte Verwendungsdatum geprüft werden. Dieses Datum wird unabhängig davon gepflegt, wie das Profil genutzt wird – vie FTP, ODBC, übertragene Batchjobs oder interaktive Anmeldung am System. Achten Sie also auf das letzte Verwendungsdatum anstelle des letzten Anmeldedatums, und machen Sie sich daran, Ihr System aufzuräumen!

Und sagen Sie es allen Ihren Freunden weiter!

Ich hoffe, ich konnte dazu beitragen, das eine oder andere Geheimnis aufzuklären, das im Zusammenhang mit IBM i Systemsicherheit kursiert. Gehen Sie jetzt mutig voran und verbreiten Sie Ihr neues Wissen, so dass wir uns in Zukunft alle sicherer fühlen können.

Carol Woodbury ist Vorstand und Mitbegründerin von SkyView Partners Inc., einem Unternehmen, das sich auf Sicherheitsrichtlinien und Compliance Software und Services spezialisiert hat. Sie ist Systemsicherheitsexpertin, bekannte Autorin von Fachpublikationen und vielfach ausgezeichnete Vortragsrednerin.

Übersetzt und für den deutschsprachigen Markt überarbeitet von Mathias Spateneder.