von Willy Günther

Mit dieser neuen Funktion bekommen wir die Möglichkeit, die Zugriffe die eine Anwendung ausführt, und die Sicherheitsüberprüfungen die vom System durchgeführt werden, aufzuzeichnen. Damit sehe ich welche Zugriffsrechte benötigt werden, und ich sehe auch welche Zugriffsrechte das Benutzer Profil verwendet, das auf die Anwendung bzw. die Datenbank zugreift. Dadurch lässt sich feststellen, ob ein Benutzer mehr Rechte besitzt als er für seine Aufgaben benötigt. Damit ist eine Optimierung der Zugriffsrechte möglich, die sicherstellt, dass die erforderlichen Rechte vorhanden sind aber der Benutzer nicht unnötige Rechte besitzt.
Durch das Aufzeichnen der Zugriffe kann ich auch feststellen auf welche Objekte die Anwendung / der Benutzer zugreift.

Das Tool dokumentiert aber nicht alle Zugriffsrechte. Special Authorities wie z. B. *JOBCTL oder *SAVSYS generieren keine Einträge. Betriebssystem Objekte die in der *SYSTEM Domain laufen oder Objekte in der QTEMP oder QSPL werden nicht aufgezeichnet. Mehr Details zu den Ausnahmen finden Sie hier:

https://ibm.biz/Bdjac8

Mit der Authority Collection kann ich die Zugriffe und die vorhanden bzw. erforderlichen Zugriffsrechte dokumentieren und dem Security Verantwortlichen zur Verfügung stellen. Das Tool macht keine Vorgaben oder Optimierungsvorschläge. Die Auswertung der Daten und die Planung und Optimierung der System Sicherheit liegt in der Verantwortung des Sicherheitsverantwortlichen.

Das Sammeln der Informationen muss explizit gestartet werden und erfolgt nicht automatisch. Die Auswertung der gesammelten Daten erfolgt über den IBM Navigator for i oder über individuelle SQL Abfragen.

Aktivierung und Beendigung einer Authority Collection

Das Erfassen der Zugriffsdaten erfolgt immer für ein Benutzerprofil. Bei dem Befehl STRAUTCOL muss ich ein Benutzerprofil angeben dessen Zugriffsdaten ich erfassen möchte. Für jedes Benutzerprofil dessen Daten gesammelt werden sollen, muss ich einen STRAUTCOL Befehl absetzen. Es ist wichtig, das effektive Benutzerprofil auszuwählen unter dem der Job ausgeführt wird. Ich kann bei STRAUTCOL auch ein Gruppenprofil angeben, dann werden aber keine Daten erfasst außer das Gruppenprofil ist der effektive Benutzer eines Jobs.

Das gilt auch für den Eigner eines Objektes. Als kleines Beispiel folgende Überlegung.
OWN1 ist der Eigner des Programms PGM1 und dieses Programm verwendet Adopted Authority. Es verwendet also die Berechtigungen von OWN1. Wenn der Benutzer USR1 dieses Programm benutzt, ich bei STRAUTCOL aber den Benutzer OWN1 angebe, dann werden keine Zugriffsdaten für die Verwendung dieses Programms aufgezeichnet. Ich muss die Authority Collection für den Benutzer USR1 starten, um zu sehen auf welche Objekte der Benutzer USR1 zugegriffen hat. In den aufgezeichneten Daten sieht man dann, dass das Programm PGM1 Adopted Authorities vom Benutzer OWN1 verwendet.

Beim Aufrufen von STRAUTCOL kann ich umfangreiche Angaben zu den Objekten machen, für die ich Zugriffsdaten aufzeichnen möchte. Als Standard werden alle Objekte und alle Objekt Typen (z. B. *FILE, *PGM ..) im System ASP aufgezeichnet.
Ich kann nur bestimmte Objekt Typen auswählen, mit Wildcards den Namen der Objekte einschränken oder nur Objekte in einer ausgewählten Bibliothek aufzeichnen.
Auch Zugriffe auf IFS und DLO Objekte können aufgezeichnet werden und es ist auch möglich einen User ASP auszuwählen.

Um vollständige Daten zu erhalten, ist es wichtig die Aufzeichnung bis zur Beendigung der Anwendung inklusive dem Full Close der Dateien durchzuführen. Nur dadurch ist sichergestellt, dass alle relevanten ­Zugriffsinformationen erfasst werden.

Beendet wird eine aktive Authority Collection mit dem Befehl ENDAUTCOL. Auch bei diesem Befehl muss ein Benutzerprofil angegeben werden. Der Befehl ENDAUTCOL USRPRF(WGTEST) beendet das Sammeln von Zugriffsdaten für den Benutzer WGTEST.

Löschen von gesammelten Zugriffsdaten
Zugriffsdaten die nicht länger benötigt werden, lassen sich mit dem Befehl DLTAUTCOL löschen. Das Löschen der Daten erfolgt immer für ein Benutzerprofil. Um die Daten für das Benutzerprofil WGTEST zu löschen verwenden wir den Befehl

DLTAUTCOL USRPRF(WGTEST)

Das regelmäßige Löschen von Daten in einer Authority Collection ist sinnvoll, um einen übersichtlichen Datenbestand zu erhalten. Eine Authority Collection kann nur gelöscht werden wenn sie nicht aktiv ist.

Um festzustellen welche Authority Collections existieren und ob diese zur Zeit aktiv sind kann die folgende SQL Abfrage verwendet werden:

SELECT AUTHORIZATION_NAME, AUTHORITY_COLLECTION_ACTIVE FROM QSYS2.USER_INFO WHERE AUTHORITY_COLLECTION_REPOSITORY_EXISTS='YES'

Um gesammelte Authority Collection Daten für spätere Analysen aufzuheben können diese Daten per SQL Anweisung in einer separaten Tabelle abgespeichert werden. Der folgende SQL Befehl sichert die Authority Daten des Benutzer WGTEST in der Tabelle AUTH_WGTEST in der QGPL.

„CREATE TABLE QGPL.AUTH_WGTEST AS (SELECT * FROM 
AUTHORITY_COLLECTION WHERE USER_NAME = ‘WGTEST‘) WITH DATA“

Damit kann ich Daten z. B. für Dokumentationszwecke längerfristig aufheben und trotzdem meinen aktuellen Authority Datenbestand übersichtlich halten.

Analyse der gesammelten Authority Collection Daten

Die gesammelten Authority Daten können über den Navigator for i ausgewertet werden oder über direkte SQL Abfragen. Der Navigator erlaubt auch die Erfassung und dass Löschen von gesammelten Authority Daten. Diese Auswahl finde ich unter dem Punkt „Manage Collections“.

Der Zugriff über den Navigator ist sehr einfach und erfordert keine SQL Kenntnisse. Ich muss ein Benutzerprofil angeben und schon werden mir die ­Authority Daten für diesen Benutzer angezeigt. Ich kann im Navigator die anzuzeigenden Spalten auswählen und auch Regeln definieren nach denen die Daten gefiltert werden.
Die Standard Anzeige für Authority Collection Daten sieht dann folgendermaßen aus.
Über den Button Aktionen habe ich die Möglichkeit weitere Einstellungen auszuwählen. Dort lässt sich z.B. die Auswahl und Anordnung der angezeigten Spalten anpassen oder ich kann auswählen, dass ich die Daten im HTML oder CSV Format exportieren möchte.

Die zweite Möglichkeit ist die direkte Abfrage über den SQL View AUTHORITY_COLLECTION. Bei dieser Methode habe ich mehr Möglichkeiten die Daten nach verschiedenen Kriterien auszuwerten weil ich dort den vollen Umfang der SQL Sprache nutzen kann. Mit der SQL Abfrage

„SELECT * FROM QSYS2.AUTHORITY_COLLECTION WHERE AUTHORIZATION_NAME ='WGTEST'“

bekomme ich die Zugriffe für den Benutzer WGTEST angezeigt.

„SELECT * FROM QSYS2.AUTHORITY_COLLECTION WHERE AUTHORITY_CHECK_SUCCESFUL=‘0‘“

zeigt alle Zugriffe bei denen die Zugriffsüberprüfung nicht erfolgreich war.

Als Beispiel einige interessante Spalten in dem View AUTHORITY_COLLECTION.

DETAILED_REQUIRED_AUTHORITY zeigt an welche Zugriffsrechte benötigt werden, um auf ein Objekt zugreifen zu können.

DETAILED_CURRENT_AUTHORITY und DETAILED_CURRENT_ADOPTED_AUTHORITY enthalten die Zugriffsrechte des Jobs während der Berechtigungsprüfung für ein Objekt.

AUTHORITY_SOURCE und ADOPTED_AUTHORITY_SOURCE enthalten die Information woher die Authority stammt z. B. aus dem Benutzerprofil oder aus einer Authorization List etc.

Die genauen Werte der einzelnen Felder und eine komplette Darstellung der Informationen, die über den View AUTHORITY_COLLECTION abgefragt werden können finden Sie hier:

https://ibm.biz/BdjKW5

Weiterführende Informationen

Umfangreiche Informationen zum Thema Authority Collections finden Sie im IBM Knowledge Center: https://ibm.biz/Bdjy8Z
Weiterführende Informationen zum Thema Security für IBM i 7.3 finden Sie hier: https://ibm.biz/BdjyU6
IBM i 7.3 Informationen im IBM Knowledge Center: https://ibm.biz/Bd4V8C
Eine aktuelle IBM i Roadmap und weitere Informationen finden Sie hier: https://ibm.biz/Bdsv7V

Über den Autor

Der Autor Willy Günther ist Senior IT Spezialist bei der IBM Deutschland GmbH
wiguenth (ät) de.ibm.com