Sometimes it is required, sometimes it is undesirable – anyone who deals with security audit functions in SAP will encounter different positions on the subject. Either way, it is useful for basic administration, which is why the functions will be presented briefly.
Preparation
If you want to use the Security Audit, you should look at the following parameters :
rsau/enable .. Activate the audit functions
Activating the audit functions at startup sets all filters set in SM19 active.
DIR_AUDIT … Configuration of the audit target directory
The default for DIR_AUDIT is „../DVEBMGS00/log/audit_“, by the way, these files are created even if only the rsau parameter is set, but no filters are defined.
rsau/max_diskspace/local … max. space for audit file
After reaching the size in this parameter the auditing stops. When specifying the value, it is possible to specify M (=MB), K (=KB). No unit stands for specification in bytes.
Static or dynamic?
If you do not need audit functions permanently, you can activate them dynamically (active until the next system start). For example, the audit can also be activated dynamically if rsau/enable is not set.
However, if you have to follow guidelines in which the audit is permanently required, you configure it statically. This starts only with the rsau parameter. It is intended for longer term (mostly mandatory) use.
Configuration
In transaction SM19 the configuration can be done. In order not to have to switch on and off each single event laboriously one has developed audit classes, which represent approximately the information need of tax auditors in structured form.
The detailed display offers interesting background information about the events in the classes:
Too bad : SAP has not yet introduced dynamic list widths here either. Those who like horizontal scrollbars will be happy here.
Reporting
The evaluation is done via the SM20. The corresponding dialog is unsurprisingly designed, and offers all important functions for limiting the partly quite extensive collected data.
Note : SM19 and SM20 are two of the favorite children of the revision, because here you can possibly create detailed evaluations, which can be limited to the user. The motto of all china boxes applies : „Handle with care!“.
The logs can become confusing, depending on how long and how much data you want to record. That’s why transaction SM18 was created, where you can reorganize the logs (at least three days old) on a regular basis. You simply specify the number of days in the dialog, scheduling in the background is possible.
Finally, the tip :
If possible, you should not make business-relevant information dependent on the foresight of SAP developers. Although care is taken to remain downward compatible, to my knowledge SAP does not guarantee that you can definitely still read logs from Release 4.0B with NW 7.3.
It is therefore advisable not to keep the logs (only) in the operating system, but to store them as application-independently as possible for all systems centrally in a protected data store. This way, audit requirements in the distant future will not be a problem.
ST03N, STAD, USMM, please?
In the audit environment, several other functionally or conceptually related transaction colleagues meander through the SAP world, of which I would like to briefly distinguish the most familiar ones from the „SAP Security Audit“.
ST03N Performance Analysis
Here, too, it is possible to trace which user has used which applications. However, the focus here is on the system load. The results can be summarized in particular clearly after time sections (e.g. 14:00 – 15:00 o’clock), and/or also split up after portions of the single steps per dialog step (e.g. 500ms data base access time). Security aspects are not considered at all here.
STAD Application Statistics
A somewhat more application-oriented view, which also lists detailed memory usage statistics and communication steps (RFC). Especially interesting for debugging and development.
USMM System Measurement
With nice regularity, SAP customers receive a request to perform system measurement. In this process, users are listed and evaluated according to their status (active, locked, deleted), according to their activity level (super user, etc.) and according to license type (SU01). In addition, documents and other industry-specific transaction data are measured (patient cases in IS-H, for example).
The result is then transmitted to SAP, which checks the current license contracts and adjusts them if necessary. A small tip: if you want to get rid of users, you should lock them. Short-term deleted users show up in the audit log and sometimes cause head-scratching for the license auditors.
The obligatory
This documentation is a collection of empirical values, and has not been reviewed or approved in any form by the product manufacturers (SAP, Oracle, ..). No liability can be assumed for damages resulting from following this documentation (partially or completely).
Of course I am happy about questions, comments or additions.
