Centrally view user favourites
Perform Risk Analysis with the Critical Permissions Report
The SU10 transaction, as the user administrator, helps you maintain bulk user master records. You can now also select the user data by login data. You're probably familiar with this. You have blocked users, for example, so that a support package can be included. Some users, such as administrators, are not affected. For collective unlocking, you only want to select users with an administrator lock. The mass maintenance tool for users in the transaction SU10 is available for this purpose. This transaction allows you to select by user and then perform an action on all selected users. Until now, users could only be selected by address data and permission data.
First, the Web application developers must implement appropriate permission checks and make PFCG available for use in role maintenance in the transaction. This includes the maintenance of proposed values in the transaction SU22. The SAP Note 1413012 (new reusable startup authorisation check) provides all the necessary details.
RS_ABAP_SOURCE_SCAN
SOS reports can be very comprehensive. In particular, if the Whitelists are not yet maintained, reporting volumes of up to 200 pages are not uncommon. Do not be discouraged in such a case, but start by cleaning up a manageable amount of critical SOS results. You can then edit the further results in several rounds. The AGS recommends which critical SOS results you should consider first; You can find these in the AGS Security Services Master slide set in the SAP Service Marketplace Media Library.
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.
"Shortcut for SAP systems" is a tool that enables the assignment of authorizations even if the IdM system fails.
You must clean up these entries before you declare a field as an organisation level.
You are aware that certain authorization objects have now been modified and others have even been completely removed, but can't all changes at the value level be replicated? Thanks to new features, this uncertainty is now over.