Wer hat sich wann mit welchem Benutzer angemeldet? Wer hat einen Benutzerstamm geändert, einen kritischen Report gestartet oder über RFC auf das System zugegriffen? Ohne das SAP Security Audit Log lassen sich diese Fragen nach einem Vorfall oft nicht mehr beantworten – und bei einer Revision fehlt der Nachweis. Trotzdem ist das Audit Log in vielen Systemen gar nicht oder nur unvollständig aktiv. Dieser Beitrag zeigt, wie Sie es sauber einrichten: Parameter, Filter, Speicher, Auswertung und Betrieb.
Was das Security Audit Log aufzeichnet
Das Security Audit Log (SAL) protokolliert sicherheitsrelevante Ereignisse auf dem Applikationsserver – unabhängig davon, ob sie über SAP GUI, Fiori, RFC oder Hintergrundverarbeitung entstehen. Die Ereignisse sind in Klassen gegliedert:
| Ereignisklasse | Typische Inhalte |
|---|---|
| Dialog-Anmeldung | Erfolgreiche und fehlgeschlagene Anmeldungen, Sperren nach Falscheingaben |
| RFC/CPIC-Anmeldung | Anmeldungen über Schnittstellen, inklusive fehlgeschlagener Versuche |
| RFC-Funktionsaufruf | Aufgerufene Funktionsbausteine – nützlich, aber sehr datenintensiv |
| Transaktionsstart | Gestartete und wegen fehlender Berechtigung abgelehnte Transaktionen |
| Reportstart | Gestartete Reports, auch im Hintergrund |
| Benutzerstammänderung | Anlegen, Ändern, Sperren und Löschen von Benutzern, Passwortänderungen |
| Systemereignisse | Änderungen an der Audit-Konfiguration, Debugging mit Änderung von Werten, Start und Stopp |
| Sonstige Ereignisse | Weitere sicherheitsrelevante Ereignisse, etwa Dateizugriffe oder Änderungen über Werkzeuge |
Jedes Ereignis hat zudem eine Kritikalität (niedrig, mittel, hoch). Gerade diese Einstufung hilft später beim Filtern: Kritische Ereignisse will man für alle Benutzer sehen, unkritische nur für ausgewählte.
Schritt 1: Profilparameter setzen
Die Grundlage sind einige wenige Profilparameter. In aktuellen Releases werden sie in der Transaktion RSAU_CONFIG gepflegt, in älteren Systemen über RZ10 im Instanz- oder Default-Profil.
| Parameter | Empfehlung | Wirkung |
|---|---|---|
| rsau/enable | 1 | Schaltet das Security Audit Log ein |
| rsau/user_selection | 1 | Erlaubt Filter mit Benutzer-Mustern und Ausschlüssen |
| rsau/selection_slots | ausreichend gross, z. B. 10 oder mehr | Anzahl verfügbarer Filter |
| rsau/integrity | 1 | Schützt die Logdateien gegen unbemerkte Veränderung |
| rsau/log_peer_address | 1 | Protokolliert die IP-Adresse statt nur des Terminalnamens |
| rsau/max_diskspace/* | an Volumen und Aufbewahrung anpassen | Begrenzt den Speicher je Datei bzw. insgesamt |
Für den Integritätsschutz wird zusätzlich ein Schlüssel benötigt, der in RSAU_CONFIG hinterlegt wird. Danach lässt sich in der Auswertung prüfen, ob eine Logdatei nachträglich verändert wurde – ein Punkt, den Revisoren zunehmend nachfragen.
Schritt 2: Filter sinnvoll definieren
Die Kunst liegt im Filterdesign: zu wenig, und wichtige Ereignisse fehlen; zu viel, und die Dateien laufen voll, ohne dass sie jemand auswertet. Bewährt hat sich ein Aufbau in drei Stufen, wie ihn auch SAP in Hinweis 2676384 empfiehlt:
- Alle Ereignisse für besondere Benutzer: Standardbenutzer wie SAP* und DDIC, Notfall- und Firefighter-Benutzer sowie Benutzer externer Dienstleister – in allen Mandanten.
- Kritische Ereignisse für alle Benutzer: Fehlgeschlagene Anmeldungen, Benutzerstammänderungen, Änderungen an der Audit-Konfiguration, Debugging mit Wertänderung und ähnliche Ereignisse – für alle Benutzer in allen Mandanten.
- Gezielte Ergänzungen: etwa erfolgreiche RFC-Anmeldungen technischer Benutzer, wenn Schnittstellen geprüft werden sollen, oder Transaktionsstarts in besonders sensiblen Mandanten.
Zwei Hinweise aus der Praxis: Vergessen Sie nicht den Mandanten 000 – dort sind Standardbenutzer oft noch aktiv. Und protokollieren Sie RFC-Funktionsaufrufe für alle Benutzer nur bewusst und zeitlich begrenzt; die Datenmenge ist erheblich.
Statische und dynamische Konfiguration
Die statische Konfiguration wird gespeichert und ist nach jedem Neustart aktiv – sie ist der Normalfall. Die dynamische Konfiguration wirkt sofort auf allen Instanzen, geht aber beim Neustart verloren. Sie eignet sich für gezielte Untersuchungen, etwa wenn ein Benutzer für einige Tage vollständig protokolliert werden soll.
Schritt 3: Speicher und Aufbewahrung planen
Das Audit Log schreibt Dateien in das Verzeichnis, das der Parameter DIR_AUDIT vorgibt – je Applikationsserver. Planen Sie den Platz anhand einer Testphase: Aktivieren Sie die Filter für zwei Wochen und messen Sie die tatsächliche Dateigrösse. Ist das konfigurierte Limit erreicht, werden keine weiteren Einträge geschrieben. Ein volles Audit-Verzeichnis muss deshalb im Monitoring auffallen.
Wie lange die Protokolle aufbewahrt werden, legt Ihre Revision fest. Ältere Dateien werden in der Regel archiviert oder an ein zentrales System übergeben und erst danach mit RSAU_ADMIN (früher SM18) gelöscht.
Schritt 4: Auswerten – regelmässig und nicht nur im Ernstfall
Die Auswertung erfolgt in RSAU_READ_LOG (früher SM20). Ein Audit Log, das niemand liest, schützt nur halb. Wir empfehlen drei Ebenen:
- Täglich bzw. automatisiert: Alarme bei kritischen Ereignissen, zum Beispiel Anmeldungen mit SAP*, Benutzersperren in hoher Zahl oder Änderungen an der Audit-Konfiguration.
- Monatlich: Durchsicht der Aktivitäten von Notfallbenutzern und externen Benutzern, abgeglichen mit den freigegebenen Anträgen.
- Bei Bedarf: gezielte Analysen nach Vorfällen oder Hinweisen der Fachbereiche.
In grösseren Landschaften lohnt sich die Übergabe an ein zentrales SIEM oder an SAP Enterprise Threat Detection. Dann lassen sich Ereignisse mehrerer Systeme korrelieren, etwa Anmeldeversuche desselben Benutzers auf mehreren Systemen innerhalb weniger Minuten.
Häufige Fehler
- Audit Log aktiv, aber ohne Filter – es wird schlicht nichts protokolliert.
- Filter nur im Produktivmandanten, nicht in 000 und nicht auf allen Instanzen geprüft.
- Dateigrösse zu knapp bemessen, sodass das Log nach einigen Tagen stillsteht.
- Kein Prozess für die Auswertung – Befunde werden erst im Audit entdeckt.
- Die Konfiguration selbst wird nicht überwacht; eine Änderung der Filter fällt niemandem auf.
Das Security Audit Log ergänzt die Prüfung der Berechtigungen: Das Log zeigt, was geschehen ist, die Berechtigungsprüfung, was hätte geschehen können. Wie Sie Benutzer, Rollen und kritische Berechtigungen regelmässig prüfen, beschreibt unser Beitrag zum SAPify Security Audit. Bei der Einrichtung und Auswertung unterstützen wir Sie im Rahmen unserer SAP Security Beratung.
Häufige Fragen
Beeinträchtigt das Security Audit Log die Performance?
Welche Transaktionen gelten in aktuellen Releases?
Ersetzt das Audit Log die Änderungsbelege von Benutzern und Tabellen?
Fazit
Ein gut eingerichtetes Security Audit Log ist eine der wirksamsten und zugleich günstigsten Sicherheitsmassnahmen in einem SAP-System. Entscheidend sind wenige Dinge: Parameter aktivieren, Filter nach dem Drei-Stufen-Prinzip definieren, Speicher realistisch planen, Integritätsschutz einschalten – und die Auswertung als festen Prozess etablieren.
