Kernel Parameter für das SAP Security Audit Log (SAL) – Vorsicht vor Inkonsistenzen

Schließlich stellt der Security Audit Log im Rahmen von internen und externen Audits (Jahresabschlussprüfung) eine wichtige Informationsquelle mit Nachweisfunktion dar. Nachfolgend beschreiben wir zunächst die Aufgabe des SAL, gehen anschließend kurz auf die Basisfunktionalität ein und zeigen auf, was sich ab dem EHP 7 für Sie geändert hat.

Wozu wird das SAL benötigt?

An das SAP ERP als rechnungslegungsrelevantes System werden seitens der Gesetzgebung hohe Anforderungen an die Richtigkeit der Daten und insbesondere auf die Nachvollziehbarkeit von Datenänderungen gestellt. Grundsätzlich wird mindestens eine 2-Systemlandschaft gefordert (Entwicklungs- und Produktionssystem). Hierzu zählt auch eine Funktionstrennung zwischen der IT-Abteilung und dem Fachbereich (Finzanzbuchhaltung, HR-Abteilung, Controlling etc.). Das heißt, die Mitarbeiter der IT-Abteilung mit ihren weitreichenden Berechtigungen sollten im Normalfall keinen direkten Zugriff auf das Produktivsystem haben. Denn es besteht unter anderem das Risiko, dass über direkte Tabellenänderungen oder nicht ausreichend getestete Programme die Richtigkeit der Daten oder eben die Nachvollziehbarkeit von Datenänderungen nicht mehr gewährleistet sind. Besonders kritisch sind in diesem Zusammenhang Notfallbenutzereinsätze zu sehen, auf die wir auch in unserem Beitrag FireFighter, Emergency-User & Co. – Software für ein SAP Notfallbenutzerkonzept eingehen. Das Security Audit Log adressiert dieses Risiko, weil die Datenänderungen auf Benutzerbasis zusätzlich in einem besonders zugriffsgeschützten Bereich protokolliert werden und so nachvollzogen werden können.

Howto: Kernel Update

Wie bei einem Betriebssystem sollte auch der Kernel-Prozess immer auf dem neusten Stand sein!

Jetzt anfordern

Howto: Kernel Update

×

Pflege über Profilparameter

Bis einschließlich EHP 6 existierten zwei Wege, um den Security Audit Log zu aktivieren und zu parametrisieren (Transaktion SM19): die statische und die dynamische Konfiguration. Bei der statischen Variante wird die SAL-Konfiguration über Profil- bzw. Instanzparameter in der Datenbank abgelegt und ist nach jedem Systemstart aktiv. Wenn also das Security Audit Log dauerhaft betrieben werden soll, muss eine statische Konfiguration angelegt und als aktive Konfiguration bestimmt werden. Über sogenannte Filter können nun einzelne Benutzer oder Benutzerräume in die SAL-Protokollierung aufgenommen werden, wobei die maximale Anzahl an Filtern vom Releasestand abhängt. Bei der dynamischen Konfiguration hingegen, kann der SAL während des laufenden Betriebs aktiviert und angepasst werden. Lediglich die Anzahl der parallelen Filter kann nicht mehr geändert werden. Zu den weiteren Einstellmöglichkeiten zählen:

• der/die Mandant(en), die protokolliert werden sollen
• die Auditklassen (Dialoganmeldung, RFC-Anmeldung etc.)
• die Kategorie der Ereignisse (alle/kritische/schwerwiegende)
• die Größe/der Pfad der Audit-Dateien

Lesen Sie hierzu auch unseren Beitrag HowTo: Konfiguration des SAP Security Audit Log, in dem wir detailliert auf die Einstellmöglichkeiten eingehen und Ihnen Empfehlungen geben.

Im Audit wird nun in der Regel zunächst über die Transaktion RZ10 geprüft, ob die Parameter aus regulatorischer Sicht, auf Basis der Unternehmensvorgaben oder entsprechend der Best Practices  gepflegt sind. Zusätzlich wird an dieser Stelle häufig über die Tabelle “PAHI” ein Blick auf die Historie der Parametereinstellungen geworfen, um kurzfristige Änderungen aufzudecken.

Neues ab EHP 7

Über den neuen Tab “Kernel-Parameter” in Transaktion SM19 kann ab EHP 7 der Security Audit Log systemweit aktiviert werden. Achtung: die Profilparameter funktionieren anschließend nicht mehr.

Ähnlich der Sicherheitsrichtlinien für Passwortvorgaben (siehe hierzu SAP-Passwortregeln: Profilparameter und Security Policies via SECPOL), sind ab EHP 7 die so genannten dynamischen Kernel-Parameter hinzugekommen. Und wie die Sicherheitsrichtlinien auch, gelten diese systemweit und übersteuern, sofern gesetzt, die altbekannten Profilparameter. Das heißt im Umkehrschluss: möchten Sie weiterhin den Security Audit Log über die Profilparameter aussteuern, müssen die Kernel-Parameter deaktiviert sein! Neu ist zudem, dass Sie die Kernel-Parameter direkt über den Security Audit Log einstellen und nicht mehr über die Pflege der Profilparameter (Transaktion RZ10). Hierbei werden in der Tabelle RSAUPROF neue Profile mit dem Namen “$KERNEL$” und je einem sogenannten Slot angelegt. Jeder Slot repräsentiert hierbei den Wert eines Kernel-Parameters (z. B. Slot 0006 > “mehrere Audit-Dateien pro Tag: ja / nein”).

Wird diese Sicherheitsabfrage verneint, sind nicht alle Server auf dem gleichen Stand!

Für den Auditor ist zunächst der Hinweis wichtig, dass eine Prüfung auf den bekannten Instanzparameter zu irreführenden Ergebnissen führen kann. Denn ein über den Profilparameter “rsau/enable” ausgeschalteter SAL kann über die Kernel-Parameter dennoch aktiv sein. Des Weiteren ist beim Einsatz der Kernel-Parameter die Historie der Parameteränderungen nicht mehr in der Tabelle PAHI zu finden. Denn die Änderung der Kernel-Parameter werden nun über die “rec/client”-Protokollierung auf die Tabelle RSAUPROF geschrieben. Eine Auswertung muss daher über den Report RSTBHIST erfolgen (bspw. über Transaktion SA38 > RSAUPROF). Suchen Sie hierbei nach den Profilen mit “$KERNEL$”.

Die Änderungen der Kernel-Parameter wird in der Tabelle RSAUPROF protokolliert. Rufen Sie dazu den Report RSTBHIST auf und suchen Sie nach den Profilen “$KERNEL$”. Die Slots entsprechen den einzelnen Parametern.

Die Kernel-Parameter werden, anders als die Profilparameter, in der Tabelle RSAUPROF abgelegt. Jeder “SLOT” entspricht hierbei einem Parameter.

Fazit

Aus Compliance-Sicht sind die Kernel-Parameter ein Fortschritt. Sie gelten nach einem Neustart systemweit und beheben damit eine Schwäche der Profilparameter: wird beim anlegen und speichern der Profilparameter die Verteilung auf alle Applikationsserver verneint bzw. schlägt diese fehl, sind diese nicht homogen konfiguriert. Folglich entfällt bei den Kernel-Parametern für den Auditor auch die Notwendigkeit, im Zweifel alle Instanzen auf die Konsistenz der Profilparameter zu prüfen. Negativ sind aus unserer Sicht jedoch zwei Dinge. Erstens, es kann bei einem Audit in Abhängigkeit vom Releasestand notwendig sein, an zwei Stellen zu prüfen. Nämlich in den Profilparametern und in der Transaktion SM19. Und zweitens, dass die Kernel-Parameter in die Tabelle RSAUPROF geschrieben werden, die originär für die Aufnahme der Filter konzipiert wurde und somit zweckentfremdet wird. Hierdurch ergibt sich eine heterogene Datenstruktur, die aufgrund einer mangelnden Transparenz die Prüfung erschwert.

Links

• SAP-Hilfe: “Dynamic Kernel Parameters for the Security Audit Log (changed)”; URL: https://help.sap.com/doc/saphelp_nwpi711/7.1.1/en-US/45/b4a73cdd402734e10000000a155369/frameset.htm
• FireFighter, Emergency-User & Co. – Software für ein SAP Notfallbenutzerkonzept;  URL: https://rz10.de/sap-berechtigungstools/firefighter-software-fuer-sap/
• HowTo: Konfiguration des SAP Security Audit Log; URL:  https://rz10.de/sap-berechtigungen/aktivierung-und-konfiguration-des-sap-security-audit-log/
• Konfiguration des Security Audit Log; URL: https://rz10.de/sap-grc/konfiguration-des-security-audit-log/
• SAP-Passwortregeln: Profilparameter und Security Policies via SECPOL; URL: https://rz10.de/sap-berechtigungen/sap-passwortregeln-profilparameter-und-security-policies-via-secpol/