Our offer
Authorization concept - recertification process
The Security Audit Log (SAL) has ten different filters in the current releases, which control which events are logged. You can configure these filters via the SM19 transaction. The events are categorised as uncritical, serious or critical.
For an up-to-date description of the eligibility tests in the EWA, see SAP Note 863362. Updates to these checks are provided by keeping the ST-SER software component, which contains the definition of checks to be performed, up to date and enabling the automatic content update in the SAP Solution Manager.
System Settings
Access options and authorizations are defined and controlled in the SAP authorization concept. How secure business data is in SAP depends largely on the assignment of authorizations and access options for a company's users.
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.
If you get into the situation that authorizations are required that were not considered in the role concept, "Shortcut for SAP systems" allows you to assign the complete authorization for the respective authorization object.
If your solution is distributed in other system landscapes, the authorisation proposals in the transaction SU22 are maintained.
Companies should therefore ask themselves: how can this be avoided? What requirements must a DSGVO-compliant authorization concept fulfill? How can we remain meaningful regarding the authorizations of specific individuals in the system and the purpose of the authorizations?