SAP Authorizations Define security policy for users - SAP Basis

Direkt zum Seiteninhalt
Define security policy for users
What to do when the auditor comes - Part 2: Authorizations and parameters
The general authorizations are quite normal authorization objects in SAP HCM, which regulates the access to PA/PD infotypes (tables PAnnnn / HRPnnnn), clusters for the own person or for other persons. Typical authorization objects are "P_PERNR", "P_ORGIN", "P_ORGXX", "PLOG" and "P_PLCX".

Some queries are also a bit complicated with the SUIM transaction. With SAP Query, you can quickly assemble queries that enable individual and more complex data evaluations. Do you want to know quickly which valid users currently have a modified access to a particular table, or what roles are users granted permission for a particular transaction? The SAP standard tool, the user information system, is an excellent solution for this type of data retrieval. However, at the latest during the next review, targeted queries with data combinations - and thus several SUIM query sequences - must be delivered within a short time. SAP queries can facilitate this task. An SAP Query is essentially a clear way to scan tables for specific data away from the SE16 transaction. There is the possibility to link multiple tables (join), which makes multiple SE16 queries just one SAP query. For example, if you want to know what roles users are entitled to perform the SCC4 transaction, you can use the SUIM transaction to query to determine which users can perform the transaction and view the roles that enable it in another query, but there is no result that shows both.
Transactional and Native or Analytical Tiles in the FIORI Environment
In addition to SAP book recommendations on SAP authorizations, I can also recommend the books from Espresso Tutorials such as "SAP Authorizations for Users and Beginners" by Andreas Prieß * or also the video tutorial "SAP Authorizations Basics - Techniques and Best Practices for More Security in SAP" by Tobias Harmes. Both are, among other media, also included in the Espresso Tutorials Flatrate, which I have also presented in more detail under SAP Know How.

The specific SAP_NEW authorization object imprints are provided via the SAP_BASIS component. Therefore, an SAP_NEW profile is always bound to a specific base release. Proceed as follows: With the transaction SU02, you remove all old, individual profiles from the SAP_NEW composite profile, including the profile that belongs to the start release of your upgrade. Now assign the reduced SAP_NEW permission profile to all users in the upgrade preparation system, ensuring that all users can work as usual. This step can be omitted if you are following another method to identify missing permissions. Now check all permissions in all remaining profiles within the SAP_NEW summary profile that have a higher release level than the SAP_BASIS upgrade start release. Map all required permissions to all productive roles in your permission concept. You can do this for each intermediate release individually. The next step is to adjust the permissions in your productively used roles in the PFCG transaction, and then remove the corresponding permissions from the SAP_NEW profile using the SU02 transaction. Repeat steps 3 through 4 until the SAP_NEW permission profile is empty. Work in a development system during the role adjustment phase and transport the adjustments made to your eligibility roles to your quality assurance system. After successful acceptance test, you transport them to the production system. Now you can remove the SAP_NEW profile from all users. You can then proceed with role follow-up as part of the release change in the SU25 transaction (see also Tip 43, "Customise Permissions After an Upgrade").

However, if your Identity Management system is currently not available or the approval path is interrupted, you can still assign urgently needed authorizations with "Shortcut for SAP systems".

Starting from this organizational unit, the system creates a list of all organizational units that are superior to the organizational unit determined in the first step in the hierarchy.

A corresponding FIORI group is used to make these tiles visually available to the user for access in the Launchpad.
Zurück zum Seiteninhalt