SU2X_CHECK_CONSISTENCY & SU24_AUTO_REPAIR
Customising User and Permissions Management
The next step is to evaluate the usage data; here the monthly aggregates are typically sufficient. These include the user ID, function block, and number of calls. For an overview of the usage data already stored in the system, see the SWNC_COLLECTOR_GET_DIRECTORY function block (GET_DIR_FROM_CLUSTER = X input parameter). The actual downloading of the usage data is then performed using the function block SWNC_COLLECTOR_GET_AGGREGATES.
The user administration process, i.e. user creation, modification and deactivation, should on the one hand be available in written documented form, either as a separate document or as part of the authorization concept documented in writing, and on the other hand also be carried out in accordance with the documentation. Therefore, a reconciliation should be performed on two levels: on the one hand, it should be ensured that the documentation is up to date and, on the other hand, it should be checked whether the process was also followed in the fiscal year to be audited. Possible deviations should already be prepared argumentatively, special cases can always occur that deviate from the actual process. However, these should be documented in a comprehensible manner so that an external auditor, such as the auditor's IT auditor, can check the plausibility. All documentation should be provided with the essential information (creator, date, version, etc.) and be in a format that cannot be changed (usually PDF). Additional documentation can also be output from the ticket system, provided that the process is consistently documented via the ticket system.
User group can be defined as required field
Access to tables and reports should be restricted. A general grant of permissions, such as for the SE16 or SA38 transaction, is not recommended. Instead, parameter or report transactions can help. These transactions allow you to grant permissions only to specific tables or reports. You can maintain secondary authorization objects, such as S_TABU_NAM, in the Sample Value Care.
You can't keep an eye on everything. Therefore, avoid that your colleagues do not assign users to a user group, and thus ensure that the user master data maintenance permissions check is correct. You do not want a user without a user group to be able to be created in your SAP systems? Users without a user group can be changed by all administrators with permission for any user group. You should also prevent incomplete permission checks when assigning roles and profiles to users without a permission group. Because it is possible to assign roles and permissions to a user first, and then assign a user group that does not have permission to assign roles and profiles. Finally, do you want to change the user group for an existing user without having permission for the new user group? In the following section we will show you how to secure your user master data maintenance.
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.
Before using the system recommendations, we recommend that you implement the corrections in SAP Notes 1554475 and 1577059.
Without a coherent, well thought-out concept, the regulation of accesses and authorizations for the users or key users of an SAP system is a serious security vulnerability.