SAP Authorizations What to do when the auditor comes - Part 2: Authorizations and parameters - SAP Basis

Direkt zum Seiteninhalt
What to do when the auditor comes - Part 2: Authorizations and parameters
Assignment of roles
You should therefore enforce cryptographic authentication and communication encryption by setting up Secure Network Communication (SNC). SNC provides a strong cryptographic authentication mechanism, encrypts data transmission, and preserves the integrity of the transmitted data. For some time now, SNC is freely available without a SSOMechanism (SSO = Single Sign-on) for SAP GUI and the RFC communication of all SAP NetWeaver customers. You should always implement SNC between SAP GUI and application server, as this communication can also run over open networks. For RFC communication, you need an SNC implementation if you think the data transfer could be intercepted.

You should then enable the latest version of the hash algorithms by setting the login/password_downwards_compatibility profile parameter to 0. This is required because SAP systems maintain backward compatibility by default. This means that, depending on your base release, either the new hash algorithms will not be used when storing passwords, or additional outdated hash values of passwords will be stored. You should then check to see if there are any old hash values for passwords in your system and delete them if necessary. Use the report CLEANUP_PASSWORD_HASH_VALUES.
Security within the development system
Historically grown authorization structures can be found especially in system landscapes that have been in operation for a long time. Instead of small, modular, job-specific roles, existing roles are continually expanded and assigned to different employees in different departments. While this leads to less administrative work in the short term, it causes the complexity of the role to increase massively over time. As a result, the efficiency of authorization development is increasingly lost.

If your users are allowed to share their own background jobs, you need the JOBACTION = RELE permission to the S_BTCH_JOB object. In this case, you can start all jobs at the desired time. In many cases, background jobs are used for the professional or technical operation of applications; Therefore, we recommend that you schedule these background jobs under a System-Type technical user (see also Tip 6, "Note the impact of user types on password rules"). The advantage of this is that the permissions can be controlled more accurately and you do not run the risk of a job being lost if the user under whom it was scheduled to leave your company once. You can realise the association with a system user by giving the user who plans the job permission for the S_BTCH_NAM object. In the BTCUNAME field, the name of the step user, i.e. the user under whom the job should run, such as MUSTERMANN, is entered.

For the assignment of existing roles, regular authorization workflows require a certain minimum of turnaround time, and not every approver is available at every go-live. With "Shortcut for SAP systems" you have options to assign urgently needed authorizations anyway and to additionally secure your go-live.

However, you do not want to display security-related tables.

Unsuccessful permission checks are now written to a ring buffer of the application server's Shared Memories.
SAP BASIS
Zurück zum Seiteninhalt