Authorizations
Error analysis for authorizations (part 1)
As part of identifying authorization problems, it should be documented what the risks are if the current situation is maintained. Often, those responsible in the company do not want to make a correction because it causes costs and work. If the current concept works and security gaps are abstract, many people in charge are reluctant to change anything. For these reasons, the first step should be to document what problems and dangers lurk if the current concept is not corrected: First, the risk of fraud, theft, and data privacy and security breaches increases. Documentation can help identify where dangers lie. There is a fundamental problem of financial damage to the company if action is not taken. Another danger is that users will experiment with their authorizations and cause damage that can be avoided by having a clean authorization structure. Also a problem is the increased administrative overhead of granting and managing permissions. The effort increases if the current role assignments are not transparent and optimally structured.
To help you better find your own tables in the future, check your development policy to see if the storage is adequately described. If the development guidelines are not complete, you should supplement them. For example content for a development policy, see the DSAG Web site under Guides. Now go to https://www.dsag.de/go/leitfäden and search for "Best Practice Guide Development".
Redesign of SAP® Authorizations
The SAP administrator uses the concept to assign users their dedicated authorizations. Behind these is a checking mechanism based on so-called authorization objects, by which the objects or transactions are protected. An authorization object can comprise up to ten authorization fields. This allows complex authorization checks that are bound to several conditions.
Do you also work in a complex system landscape where roles are decentralised? Then, inconsistencies can occur by transporting profiles from different systems to a target system. We'll show you how to prevent that. In the case of decentralised maintenance of eligibility roles, i.e. maintenance of roles in different systems or clients, there is a risk that the number sequences for the generation of eligibility profiles overlap. You can then generate profiles with the same name for different roles in different clients. As soon as you transport these eponymous permission profiles into a common target system, the profile will be overwritten by the newly imported profile and inconsistencies will arise. As a result, you may, for example, assign an ERP Permissions Role an SCM permission profile. This may result in a user assigned the ERP role not obtaining the required permissions or even too many permissions. You also have a problem if you want to use the permission profile to determine the source system and the client in which this profile was generated. This is not possible if the first and third characters of the SAP System ID (SID) and the number sequence for generating the permission profile match.
The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".
Now select the application servers in the list on which you want to run the system trace and start the trace with a click on Trace.
Balance: In the settlement transactions, the user is only presented with the supporting documents for which he or she has permission.