Teilweise wird es gefordert, teilweise ist es unerwünscht – wer sich mit Security Audit Funktionen im SAP beschäftigt, wird verschiedene Positionen zum Thema antreffen. So oder so ist es nützlich für die Basisadministration, weswegen die Funktionen kurz dargestellt werden sollen.
Vorbereitung
Wer den Security Audit verwenden will, sollte sich folgende Parameter anschauen :
rsau/enable .. Aktivieren der Audit Funktionen
Das Aktivieren der Audit-Funktionen beim Start setzt alle in SM19 gesetzten Filter aktiv.
DIR_AUDIT .. Konfiguration des Audit Zielverzeichnisses
Der Standard für DIR_AUDIT ist „../DVEBMGS00/log/audit_<yyyymmdd>“, diese Files werden übrigens auch angelegt wenn nur der rsau-Parameter gesetzt ist, aber keine Filter definiert wurden.
rsau/max_diskspace/local .. max. Platz für Auditdatei
Nach Erreichen der Größe in diesem Parameter stoppt die Auditierung. Bei Angabe des Wertes ist die Angabe von M (=MB), K (=KB) möglich. Keine Einheit steht für Angabe in Bytes.
Statisch oder dynamisch?
Wer Audit-Funktionen nicht permanent braucht, aktiviert diese dynamisch (bis zum nächsten Systemstart aktiv). Dynamisch lässt sich bspw. auch der Audit aktivieren, wenn rsau/enable nicht gesetzt ist.
Wer jedoch Vorgaben folgen muss, in denen das Audit permanent gefordert ist, konfiguriert es statisch. Dieser startet nur mit dem rsau-Parameter. Es ist für längerfristigen (meist vorgeschriebenen) Einsatz gedacht.
Konfiguration
In der Transaktion SM19 lässt sich die Konfiguration vornehmen. Um nicht jedes Einzelereignis mühsam an- und abschalten zu müssen hat man Audit-Klassen entwickelt, die ungefähr den Informationsbedarf von Betriebsprüfern in strukturierter Form darstellen.
Die Detailanzeige bietet dazu noch einmal interessante Hintergrundinformationen, welche Ereignisse in den Klassen stecken :
Schade : Auch hier hat die SAP noch keine dynamischen Listenbreiten eingeführt. Wer horizontale Scrollbalken mag, wird hier glücklich werden.
Auswertung
Die Auswertung geschieht über die SM20. Der entsprechende Dialog ist wenig überraschend gestaltet, und bietet alle wichtigen Funktionen zur Einschränkung der teilweise recht umfangreichen gesammelten Daten.
Hinweis : SM19 und SM20 sind zwei der Lieblingskinder der Revision, denn hier lassen sich u.U. detaillierte Auswertungen anlegen, die auf den User beschränkt werden können. Es gilt das Motto aller Porzellankisten : „Handle with care!“.
Die Protokolle können unübersichtlich werden, je nachdem wie lange und wie viele Daten Sie mitschreiben wollen. Daher wurde die Transaktion SM18 geschaffen, in der Sie die Protokolle (mind. drei Tage alt) regelmäßig reorganisieren können. Sie geben im Dialog einfach die Anzahl der Tage an, eine Einplanung im Hintergrund ist möglich.
Abschließend noch der Tipp :
Betriebswirtschaftlich relevante Informationen sollten Sie wenn möglich nicht vom Weitblick der SAP Entwickler abhängig machen. Obwohl man darauf achtet, abwärtskompatibel zu bleiben, ist es meines Wissens nach von der SAP nicht garantiert, dass Sie Logs vom Release 4.0B definitiv auch mit NW 7.3 noch lesen können.
Daher empfiehlt es sich, die Protokolle nicht (nur) im Betriebssystem vorzuhalten, sondern möglichst anwendungsunabhängig für alle Systeme zentral in einem geschützten Data Store abzulegen. So sind auch Prüfungsanforderungen in fernerer Zukunft kein Problem.
ST03N, STAD, USMM, bitte?
Im Audit-Umfeld mäandern noch einige weitere funktional oder begrifflich verwandte Transaktions-Kollegen durch die SAP-Welt, von denen ich die mir geläufigsten kurz mal vom „SAP Security Audit“ abgrenzen will.
ST03N Performance-Analyse
Auch hier lässt sich nachvollziehen, welcher Benutzer welche Anwendungen verwendet hat. Der Fokus liegt hier jedoch auf der Systemlast. Die Ergebnisse lassen sich insbesondere übersichtlich nach Zeit-Abschnitten zusammenfassen (bspw. 14:00 – 15:00 Uhr), bzw. auch nach Anteilen der Einzelschritte pro Dialogschritt aufsplitten (bspw. 500ms Datenbankzugriffszeit). Sicherheitsaspekte werden hier überhaupt nicht berücksichtigt.
STAD Anwendungsstatistik
Eine etwas anwendungsbezogenere Sicht, die auch detaillierte Speicherverbrauchsstatistiken und Kommunikationsschritte (RFC) auflistet. Insbesondere für Fehlersuche und Entwicklung spannend.
USMM Systemvermessung
In schöner Regelmäßigkeit erhalten SAP-Kunden eine Aufforderung, die Systemvermessung durchzuführen. Dabei werden Benutzer je nach Status (aktiv, gesperrt, gelöscht), nach Aktivitätslevel (Super-User usw.) und nach Lizenztyp (SU01) aufgelistet und ausgewertet, Außerdem werden Belege und andere branchenspezifische Bewegungsdaten vermessen (Patientenfälle im IS-H bspw.).
Das Ergebnis wird im Anschluss an die SAP übermittelt, womit diese die aktuellen Lizenzverträge prüft und ggf. anpasst. Kleiner Tipp : wer User loswerden will, sollte sie sperren. Kurzfristig gelöschte User tauchen im Audit Protokoll auf, und sorgen manchmal bei den Lizenzprüfern für Kopfkratzen.
Das Obligatorische
Diese Dokumentation ist eine Sammlung von Erfahrungswerten, und in keiner Form von den Produktherstellern (SAP, Oracle, ..) geprüft oder freigegeben worden. Es kann keine Haftung für Schäden übernommen werden, die aus dem (teilweisen oder vollständigen) Befolgen dieser Dokumentation entstehen.
Selbstverständlich freue ich mich über Fragen, Anmerkungen oder Ergänzungen.
