Einrichtung und Auswertung der Kernel-Parameter im SAP Security Audit Log (SAL)

Das Security Audit Log (SAL) ist für die Prüfung eines SAP-Systems eine der wichtigsten Quellen. Mit EHP 7 hat sich die Art geändert, wie es konfiguriert wird: Neben den Profilparametern gibt es Kernel-Parameter, die systemweit gelten und Vorrang haben. Wer das nicht weiß, prüft am falschen Ort.

Warum das Security Audit Log für die Prüfung zählt

Ein ERP-System unterliegt gesetzlichen Anforderungen an die Richtigkeit der Daten und die Nachvollziehbarkeit von Änderungen. Daraus folgen in der Praxis eine Systemlandschaft aus mindestens Entwicklung und Produktion und die Funktionstrennung zwischen IT und Fachbereichen. Besonders kritisch sind Zugriffe, die diese Trennung bewusst aufheben, etwa Notfallbenutzereinsätze.

Genau hier setzt das Security Audit Log an: Es protokolliert sicherheitsrelevante Ereignisse benutzerbezogen in einem geschützten Bereich, unabhängig von den Änderungsbelegen der Anwendung. In der internen Revision und in der Jahresabschlussprüfung ist es deshalb eine zentrale Nachweisquelle. Damit der Nachweis trägt, muss das Log vollständig, dauerhaft und auf allen Instanzen gleich konfiguriert sein.

Konfiguration bis EHP 6: Profilparameter und SM19

Bis EHP 6 wird das Security Audit Log in der Transaktion SM19 eingerichtet, in zwei Varianten:

• Statische Konfiguration: Die Einstellungen liegen als Profil- beziehungsweise Instanzparameter in der Datenbank und sind nach jedem Systemstart aktiv. Für den Dauerbetrieb braucht es eine aktive statische Konfiguration. Filter legen fest, welche Benutzer oder Benutzerkreise erfasst werden; wie viele Filter möglich sind, hängt vom Release ab.
• Dynamische Konfiguration: Das Log lässt sich im laufenden Betrieb einschalten und anpassen, ohne Neustart. Nur die Anzahl der parallelen Filter ist festgelegt.

Eingestellt werden unter anderem die zu protokollierenden Mandanten, die Auditklassen (zum Beispiel Dialoganmeldung oder RFC-Anmeldung), die Ereigniskategorie (alle, kritisch, schwerwiegend) sowie Größe und Ablageort der Audit-Dateien. Die wichtigsten Profilparameter sind rsau/enable (Log ein oder aus), rsau/selection_slots (Anzahl der Filter), rsau/user_selection (Benutzerfilter) und rsau/max_diskspace/local (Plattenplatz).

In der Prüfung wird üblicherweise in der Transaktion RZ10 nachgesehen, ob diese Parameter den regulatorischen Vorgaben, den Unternehmensrichtlinien oder den gängigen Empfehlungen entsprechen. Ergänzend zeigt die Tabelle PAHI, ob Parameter kurzfristig, etwa unmittelbar vor der Prüfung, geändert wurden.

Ab EHP 7: Kernel-Parameter in SM19

Mit EHP 7 kam in SM19 der Reiter „Kernel-Parameter” hinzu. Über ihn wird das Security Audit Log systemweit aktiviert und eingestellt, ähnlich wie die Sicherheitsrichtlinien für Passwörter (SECPOL) systemweit gelten. Drei Dinge sind dabei entscheidend:

1. Kernel-Parameter übersteuern die Profilparameter. Sobald sie gesetzt sind, sind die bekannten rsau/*-Profilparameter ohne Wirkung. Wer weiter mit Profilparametern arbeiten will, muss die Kernel-Parameter abschalten.
2. Gepflegt wird nicht mehr in RZ10, sondern direkt im Security Audit Log. In RZ10 steht also unter Umständen ein Wert, der nicht gilt.
3. Abgelegt werden die Werte in der Tabelle RSAUPROF. Dafür legt das System Profile mit dem Namen $KERNEL$ an; jeder Slot steht für einen Parameter. Slot 0006 beispielsweise entscheidet, ob mehrere Audit-Dateien pro Tag geschrieben werden.

Beim Aktivieren erscheint eine Sicherheitsabfrage. Wird sie verneint, sind die Applikationsserver nicht einheitlich konfiguriert.

Was das für die Prüfung bedeutet

Eine Prüfung, die nur die Profilparameter liest, kann ab EHP 7 in die Irre führen: Ein über rsau/enable = 0 scheinbar abgeschaltetes Log kann durch Kernel-Parameter sehr wohl aktiv sein, und umgekehrt sagt ein gesetzter Profilparameter nichts darüber aus, was tatsächlich protokolliert wird. Auch die Änderungshistorie liegt an einem anderen Ort: Änderungen an den Kernel-Parametern stehen nicht in PAHI, sondern werden über die Tabellenprotokollierung (rec/client) für RSAUPROF geschrieben.

Für die Prüfung heißt das:

• Beide Stellen lesen: die Profilparameter in RZ10 und den Reiter „Kernel-Parameter” in SM19.
• Feststellen, was gilt: Sind Kernel-Parameter aktiv, zählen sie, nicht die Profilparameter.
• Historie auswerten: mit dem Report RSTBHIST (zum Beispiel über SA38) für die Tabelle RSAUPROF, Suche nach den Profilen $KERNEL$. PAHI allein reicht nicht.
• Konsistenz prüfen: Bei Kernel-Parametern gilt die Einstellung systemweit; bei Profilparametern bleibt der Vergleich über alle Instanzen nötig.

Einschätzung

Aus Sicht der Compliance ist die Neuerung ein Fortschritt. Kernel-Parameter gelten nach dem Neustart systemweit; das Risiko, dass die Verteilung auf einzelne Applikationsserver fehlschlägt und das Log dort fehlt, entfällt. Der Prüfer muss nicht mehr jede Instanz einzeln auf Konsistenz prüfen.

Zwei Dinge bleiben unbefriedigend. Je nach Release sind zwei Stellen zu prüfen, Profilparameter und SM19. Und die Tabelle RSAUPROF war für die Filter gedacht; mit den $KERNEL$-Profilen wird sie zweckentfremdet, und die uneinheitliche Struktur macht die Auswertung umständlicher, als sie sein müsste.

Hinweis: In neueren Releases (ab SAP NetWeaver 7.50 mit Support Package 03, also auch in S/4HANA) ersetzen die Transaktionen RSAU_CONFIG, RSAU_READ_LOG und RSAU_ADMIN die bisherigen SM19, SM20 und SM18. Die Unterscheidung zwischen Profil- und Kernel-Parametern und die Ablage in RSAUPROF bleiben.

Eine ausführlichere Fassung dieses Beitrags mit Abbildungen ist auf dem Experten-Blog rz10.de erschienen: Kernel-Parameter für das SAP Security Audit Log (SAL): Vorsicht vor Inkonsistenzen.