Permissions with Maintenance Status Used
Retain the values of the permission trace to the role menu
Depending on the transaction invoked, the application can be more granular checked by this additional permission check. Therefore, transactions that are called with additional parameters might require more than one authorization object and must be protected programmatically. The following listing shows an example of a permission check that ensures that the logged-in user has the permission to start the SU24 transaction.
Certain SAP authorizations, including those for table maintenance (S_TABU_*) require special attention for data protection reasons. These are known as critical authorizations. In the course of authorization planning, a company should determine which authorizations are to be considered critical, which roles may receive which critical authorizations or values for critical authorization fields, and so on. The German Federal Office for Information Security has compiled detailed information on defining critical authorizations.
Data ownership concept
In principle, all eligibility fields can be upgraded to the organisational level; there are, however, technical exceptions and fields where this is not useful. Technically, the fields that are in the context of testing the startup capability of an application are excluded, i.e. the fields of the S_TCODE, S_START, S_USER_STA, S_SERVICE, S_RFC, S_PROGRAM and S_USER_VAL authorization objects. In addition, you cannot elevate the ACTVT field to the organisation level. Only the fields that can be assigned a value range within a role are meaningful. This must of course be considered across the board for the authorisation concept. For example, fields that have more than one meaning, such as the Authorisation Group (BEGRU), are not suitable for material management. The PFCG_ORGFIELD_CREATE report allows you to define a permission field as an organisation level. The report enters the field in the USORG table, changes the permission proposal values to that field, and performs all the roles that have a shape in the field.
Configuration validation uses the CCDB's configuration data to reconcile settings. To do this, you define your customer-specific security settings technically in a target system. This contains the specifications for the configuration of SAP systems. You can also define a target system based on the settings of an existing system and adapt it to your requirements. Then you compare the settings of your SAP systems with this target system on a daily basis and get an overview of the deviations. Since there may of course be different security requirements for the systems in your landscape (e.g. development and production systems), you can define different target systems with the appropriate settings. You then start the comparison with a target system for the relevant systems. Alternatively, you can compare to an actual system; For example, this is a useful function in the context of a roll-out.
Secure your go-live additionally with "Shortcut for SAP systems". You can assign necessary SAP authorizations quickly and easily directly in the system.
The website www.sap-corner.de offers a lot of useful information about SAP authorizations.
Developer authorizations for original SAP objects should therefore only be granted here upon request in order to avoid unauthorized modifications.
This includes the password status, a lock flag, the reasons for the lock, the number of false logins, the user validity periods and the security policies associated with the users.