SAP Security Audit Log: Konfiguration, Auswertung & Best Practices

Das SAP Security Audit Log (SAL) ist eines der wichtigsten Werkzeuge für die Überwachung sicherheitsrelevanter Aktivitäten in SAP-Systemen. Trotzdem ist es in vielen Unternehmen entweder gar nicht aktiviert oder so konfiguriert, dass es im Ernstfall wenig hilft. Dieser Artikel zeigt, wie Sie das SAL systematisch einrichten, auswerten und in Ihre Security-Strategie integrieren.

Was ist das Security Audit Log?

Das Security Audit Log zeichnet sicherheitsrelevante Ereignisse im SAP-System auf – von erfolgreichen und fehlgeschlagenen Anmeldeversuchen über Transaktionsaufrufe bis hin zu Änderungen an Benutzerstammsätzen. Anders als das Systemlog (SM21) fokussiert sich das SAL gezielt auf Security-relevante Aktivitäten und liefert die Datenbasis für forensische Analysen und Compliance-Nachweise.

Seit SAP NetWeaver 7.50 empfiehlt SAP die neue Konfigurationstransaktion RSAU_CONFIG als Nachfolger der klassischen SM19. RSAU_CONFIG bietet granularere Filteroptionen und eine bessere Verwaltung der Audit-Policies.

Konfiguration mit SM19 und RSAU_CONFIG

Die Grundkonfiguration erfolgt in zwei Schritten: Zunächst aktivieren Sie das Security Audit Log über den Profilparameter rsau/enable = 1. Anschließend definieren Sie Filter, die festlegen, welche Ereignisse für welche Benutzer protokolliert werden.

In RSAU_CONFIG können Sie statische und dynamische Filter anlegen. Statische Filter greifen nach einem Systemneustart, dynamische Filter können zur Laufzeit aktiviert werden – ideal für zeitlich begrenzte Intensiv-Überwachung bei Verdacht auf unregelmäßige Aktivitäten.

Wichtige Profilparameter: rsau/max_diskspace/local bestimmt die maximale Dateigröße, rsau/selection_slots die Anzahl verfügbarer Filter-Slots. Planen Sie mindestens 500 MB Speicherplatz für produktive Systeme ein.

Welche Ereignisse sollten protokolliert werden?

Eine sinnvolle Minimalkonfiguration umfasst folgende Ereigniskategorien:

• Dialog-Anmeldungen: Erfolgreiche und fehlgeschlagene Logins, insbesondere mit privilegierten Benutzern (SAP*, DDIC, Notfallbenutzer)
• RFC-/API-Zugriffe: Anmeldungen über RFC-Schnittstellen, die häufig als Angriffsvektor genutzt werden
• Transaktionsstarts: Aufrufe kritischer Transaktionen wie SE16, SM59, SU01, STMS, SE38
• Änderungen an Benutzerstammsätzen: Anlage, Änderung, Sperre und Entsperrung von Benutzern
• Berechtigungsprüfungen: Fehlgeschlagene Autorisierungsprüfungen als Indikator für Zugriffsversuche

Für SAP_ALL-Benutzer und Notfallbenutzer empfehlen wir eine lückenlose Protokollierung aller Aktivitäten. Für Standardbenutzer genügt in der Regel die Protokollierung von Anmeldungen und kritischen Transaktionen.

Filter-Strategien und Performance-Auswirkungen

Ein häufiger Fehler ist die übermäßige Protokollierung: Wer alles für alle Benutzer aufzeichnet, erzeugt nicht nur riesige Datenmengen, sondern beeinträchtigt auch die Systemperformance. Nutzen Sie einen risikobasierten Ansatz: Definieren Sie Benutzergruppen nach Risikoprofil und passen Sie die Protokollierungstiefe entsprechend an.

In der Praxis hat sich ein Drei-Stufen-Modell bewährt: Stufe 1 für alle Benutzer (nur Anmeldungen), Stufe 2 für privilegierte Benutzer (Anmeldungen + kritische Transaktionen), Stufe 3 für Notfallbenutzer (vollständige Protokollierung). Dieses Modell minimiert den Performance-Impact auf unter 2% und liefert dennoch aussagekräftige Daten.

Auswertung mit SM20 und RSAU_READ_LOG

Die Transaktion SM20 bietet eine interaktive Auswertung des Audit Logs. Für systematische Analysen empfiehlt sich jedoch RSAU_READ_LOG, das erweiterte Filterfunktionen und einen ALV-Grid-Export bietet. So können Sie die Daten in Excel oder anderen Tools weiterverarbeiten.

Regelmäßige Auswertungsroutinen sollten folgende Szenarien abdecken: Mehrfache Fehlanmeldungen (Brute-Force-Indikator), Anmeldungen außerhalb der Geschäftszeiten, Nutzung kritischer Transaktionen durch unberechtigte Benutzer und ungewöhnliche RFC-Aktivitäten.

SIEM-Integration

Für Echtzeitauswertung und Korrelation mit anderen Sicherheitsereignissen empfiehlt sich die Integration in ein SIEM-System (Security Information and Event Management). SAP bietet mit dem SAP Enterprise Threat Detection (ETD) eine native Lösung. Alternativ können SAL-Daten über XAL/XAL2-Schnittstellen, den SAP Audit Log Connector oder direkte Datenbankabfragen an externe SIEM-Systeme wie Splunk, QRadar oder Microsoft Sentinel übertragen werden.

Wichtig: Definieren Sie Use Cases und Korrelationsregeln vorab. Ein SIEM ohne sinnvolle Regeln produziert nur Rauschen statt verwertbarer Alerts.

Compliance-Anforderungen

Das Security Audit Log ist eine zentrale Anforderung in nahezu allen relevanten Compliance-Frameworks: SOX verlangt die Überwachung privilegierter Zugriffe, ISO 27001 fordert die Protokollierung sicherheitsrelevanter Ereignisse (Kontrolle A.12.4), und die DSGVO erfordert die Nachvollziehbarkeit von Zugriffen auf personenbezogene Daten. Dokumentieren Sie Ihre Konfiguration und Auswertungsprozesse – Auditoren bewerten nicht nur, ob das SAL aktiv ist, sondern auch, wie systematisch es ausgewertet wird.

Fazit

Ein richtig konfiguriertes Security Audit Log ist kein Nice-to-have, sondern eine grundlegende Sicherheitsmaßnahme. Der Aufwand für die Einrichtung ist überschaubar, der Nutzen im Ernstfall enorm. Beginnen Sie mit einer risikobasierten Konfiguration, etablieren Sie regelmäßige Auswertungsroutinen und integrieren Sie das SAL in Ihre übergreifende Security-Monitoring-Strategie.

Jetzt anfragen →

Weitere Artikel

Brauchen Sie Unterstützung bei diesem Thema?

Wir helfen Ihnen bei der Umsetzung – von der Analyse bis zum Go-Live.

Jetzt anfragen

← Alle Artikel