Critical authorizations
PROGRAM START IN BATCH
The direct consequences are overauthorized users, a lack of overview and dangerous security gaps. In order to get the system back on track in the long term, a redesign is usually the most efficient solution. Depending on the requirements and project framework, we also rely on proven software solutions from our partners.
The most important security services regarding permissions are the EarlyWatch Alert (EWA) and the SAP Security Optimisation Service (SOS). You compare the settings in your SAP systems with the recommendations of SAP. Both services are delivered as partially automated remote services; You can also use the SOS as a fully automated self-service. The EWA and SOS shall carry out eligibility tests, the results of which shall always be as follows: The heading indicates the check in question. A short text describes the importance of the audited entitlement and the risk of unnecessary award. A list indicates the number of users with the validated permission in the different clients of the analysed SAP system. The SOS also allows you to list the users. In the SOS, a recommendation is made for each check to minimise the identified risk. A final formal description represents the checked permissions. However, not only the explicitly mentioned transactions are evaluated, but also equivalent parameter or variant transactions.
Assignment of roles
In the event that such conflicts nevertheless arise, regular checks should be established as part of an internal control system. Furthermore, the authorization concept includes content such as the integration of the data owner, security-relevant system settings, specifications for maintaining authorization default values (transaction SU24) and documentation requirements.
In the SCC4 transaction, first check whether eCATT is allowed to run. Then start the SECATT transaction. As you get started, you can define and modify test scripts and test configurations. First, create a test script. Think of it as a blueprint or a flow rule for how to create new derived roles. The test script will contain your recording later. Give the script a talking name, such as Z_MASSENGERATION_DERIVATIVES. Then click the Create Object button. You will now go to the Attribute tab, where you specify the general frame data. Then click the Editor tab. Now it goes to the recording, in the eCATT language called patterns. Click the Pattern button and specify that you want to record the PFCG transaction by selecting the UIAncontrol and TCD (Record) settings. The system will propose to call the interface "PFCG_1"; You can simply confirm this. Confirmation of the dialogue will immediately start the recording; They therefore end up in the PFCG transaction. We want to record the creation of a single role derived from a reference role. Complete the appropriate steps in the PFCG transaction and try to avoid unnecessary steps - every step you take will make your recording bigger and less cluttered. Enter the name of the derived role - we can influence it later when playing with eCATT - and specify the role. Now assign the reference role. Note that the PFCG transaction is actually executed, so the role is actually created in the system! Now maintain the permissions and organisation levels. If possible, use organisational level values in the note, which you can find well in other numbers later on, i.e. about 9999 or 1234. After generating and saving the role, you will be returned to eCATT. There you will be asked if you want to accept the data and confirm with Yes.
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.
If the note is not implemented, use the USOBT_CD and USOBX_CD tables.
Dynamic configuration will remain active until the next boot.