Conclusion
General considerations
The assignment of roles does not include any special features. Therefore, we only deal with the topics of time-space delimitation and logging. Time-space validation is implemented as an additional filter that runs after the usual permission checks. This additional filter logic works as follows: The first step is to check whether the user is entered in the tax verifier table (Table TPCUSERN, Configuration with the transaction TPC2). Only then will the further tests be carried out. If not, no additional checks will be carried out. The programme is then checked to see if it is included in the table of allowed programmes (table TPCPROG, configuration with the transaction TPC4). If the check is negative, the system cancels with a permission error. The time-space check is performed against the valid intervals in the table TPCDATA (configuration with the transaction TPC6). The time-space check works in context: In addition to the supporting documents of the audit period, older supporting documents are also included if they are still relevant for the audit period, such as open items that were booked in previous years but only settled in the audit period. Records that do not fall into the valid period according to the logic described above are filtered out.
To release jobs - own jobs or jobs of other users - a permission for the object S_BTCH_JOB with the expression JOBACTION = RELE is still required. In running operations, scheduled batch jobs may be cancelled because a step user is deleted or locked. With the help of the BTCAUX09 programme, you can check jobs as an administrator to see if they can be cancelled in the future. If you want to run these jobs under another step user, you can change them either with the transaction SM37 or with the report BTC_MASS_JOB_CHANGE.
Maintain transaction start permissions on call CALL TRANSACTION
The user administration process, i.e. user creation, modification and deactivation, should on the one hand be available in written documented form, either as a separate document or as part of the authorization concept documented in writing, and on the other hand also be carried out in accordance with the documentation. Therefore, a reconciliation should be performed on two levels: on the one hand, it should be ensured that the documentation is up to date and, on the other hand, it should be checked whether the process was also followed in the fiscal year to be audited. Possible deviations should already be prepared argumentatively, special cases can always occur that deviate from the actual process. However, these should be documented in a comprehensible manner so that an external auditor, such as the auditor's IT auditor, can check the plausibility. All documentation should be provided with the essential information (creator, date, version, etc.) and be in a format that cannot be changed (usually PDF). Additional documentation can also be output from the ticket system, provided that the process is consistently documented via the ticket system.
Administrative activities are used to control system behavior and make various security-relevant settings. To minimize the risk of a system failure or the creation of a security vulnerability, administrative rights should only be granted to employees in the basic administration. The following list may be supplemented by suggestions from the company's own administration. It contains only the most important authorization objects for each subject area.
Assigning a role for a limited period of time is done in seconds with "Shortcut for SAP systems" and allows you to quickly continue your go-live.
However, with role-based authorizations, SAP provides a very powerful control tool that remains clear with a little help and documentation.
If you use change request management in SAP Solution Manager, you can use the system recommendations in an integrated way.