This area analyzes the violations of the authorization concept of an SAP system according to the definition of the German-speaking SAP User Group (DSAG). Violations are evaluated according to the following areas:
The recommendations of the DSAG serve as a best practice for checking for possible violations. You can find them in the SAP® S/4HANA guideline (Security chapter).
The aim of these checks is to achieve maximum security while assigning only minimum authorizations for the corresponding task. In addition, the documentation and traceability of the authorization concept is improved by self-documenting references between the objects. A clear procedure for creating, maintaining, assigning and revoking authorizations helps to ensure stability and reliability.
Scenarios
Roles with manual authorizations
These roles are not linked to the required applications and thus make the authorization concept non-transparent and unsustainable. In general, authorizations should be clearly linked to the required applications, which are defined in the role menus and maintained via transaction SU24.
Impact on organizational changes
Changes to processes or system releases are planned and implemented at the application level. As manual authorizations are not linked to applications, authorizations that are no longer required are not automatically removed from roles, and new required authorizations are not included if the list of applications to be authorized changes.
Roles with changed authorizations
Changed authorizations are included in the role via menu applications. Later, the changes will decouple them from the application and the authorization concept becomes non-transparent and unsustainable. In general, authorizations should be clearly linked to the required applications, which are defined in the role menus and maintained via transaction SU24.
Impact on organizational changes
Changes to processes or system releases are planned and implemented at the application level. As manual authorizations are not linked to applications, authorizations that are no longer required are not automatically removed from roles, and new required authorizations are not included if the list of applications to be authorized changes.
Roles with non-current profiles
Role profiles assign authorizations to users. These profiles must always be up to date. Accordingly, obsolete profiles do not assign the latest authorizations.
Impact on organizational changes
It is not possible to predict how large the differences between the role definition and profile will be if no regular synchronization takes place.
Roles with manual menu objects
The initial authorizations of the application (objects S_TCODE, S_RFC, S_SERVICE and S_START) are generated automatically by the applications defined in the role menu.
If an initial authorization is added manually, this results in the following disadvantages:
-
The corresponding application can be started even though it is not transparently defined in the role menu.
-
The corresponding application can be started, but the authorizations required for the application to function are not transferred from transaction SU24.
As a result, an application can be started with the risk that it lacks the necessary functional authorizations.
Impact on organizational changes
Changes to processes or system releases are planned and implemented at the application level. Applications that are activated via manual menu objects instead of the role menu have no authorization. New authorizations that are required by the applications after the change are not automatically included. Obsolete authorizations are not automatically removed. The lack of automatic correction mechanisms poses a major risk to the reliability of the roles.
Roles with interval menu objects
The initial authorizations of the application (objects S_TCODE, S_RFC, S_SERVICE and S_START) are automatically generated by the applications defined in the role menu. If an initial authorization of the application is included as an interval, a non-transparent number of applications can be started. This means that not only the list of applications is non-transparent. Also future changes that fall within the interval cause a lack of transparency. This also completely bypasses the SU24 mechanism, meaning that the executable applications will probably lack application authorizations.
Impact on organizational changes
Changes to processes or system releases are planned and implemented at the application level. As manual authorizations are not linked to applications, authorizations that are no longer required are not automatically removed from roles, and new required authorizations are not included if the list of applications to be authorized changes.
Roles with wildcarded menu objects
The initial authorizations of the application (objects S_TCODE, S_RFC, S_SERVICE and S_START) are generated automatically by the applications defined in the role menu. If an initial authorization of the application is included as a wildcard, a non-transparent number of applications can be started. This means that not only the list of applications is non-transparent. Also future changes that fall within the interval cause a lack of transparency.
Impact on organizational changes
Changes to processes or system releases are planned and implemented at the application level. As manual authorizations are not linked to applications, authorizations that are no longer required are not automatically removed from roles, and new required authorizations are not included if the list of applications to be authorized changes.
Roles with changed org. fields
Functional authorizations and organizational authorizations are separated from each other. This allows for a separate maintenance process if one of the two authorizations is changed. When changing the organizational fields, this separation is removed and the values of the organizational fields are included in the functional authorizations.
Impact on organizational changes
Change activities require roles to be changed. Confusing organizational and non-organizational authorizations can lead to a loss of access rights or the opposite: too many access rights that should actually be removed. The impact ranges from a lack of transparency to serious security risks.
Changed derived roles
Derived roles allow you to create several role variants for different organizational units. All variants or derived roles authorize users to use the same applications and activities within these applications, but restrict their organizational scope. The organizational field values should therefore differ, but not the application authorizations. The SAP standard mechanism ensures that the application authorizations remain unchanged. However, it is technically possible to bypass this mechanism and make manual changes to the derived roles for their application authorizations. The next time the SAP standard mechanism is used, the local changes are overwritten. This means that authorizations can suddenly be lost or introduced unpredictably.
Impact on organizational changes
For change activities, the parent roles must be changed and the derived roles must be recreated. This inevitably overwrites all local changes to the derived roles. This poses a major risk to the reliability of the roles.
Manual profiles assigned to users
User authorizations should exclusively be assigned via roles. The entire mechanism consisting of user, role, menu and authorizations ensures transparency about what is authorized and why, as well as the sustainability of the changes. Change documents for the involved object users, roles and SU24 proposals ensure the transparency and traceability of the authorization concept. Manual profiles bypass this entire process. The impact ranges from a lack of transparency to serious security risks.
Impact on organizational changes
Changes to processes or system releases are planned and implemented at the application level. As manual authorizations are not linked to applications, authorizations that are no longer required are not automatically removed from roles, and new required authorizations are not included if the list of applications to be authorized changes.
