Direkt zum Seiteninhalt
Permission implementation
Standard users such as SAP* or DDIC should also be implemented correctly in accordance with the authorization concept or SAP's recommendations. An important preparatory action here is to check whether the passwords have been changed for all standard users.

The first line defines that access to all files is forbidden unless other settings have been made for them in the other lines. The asterisk (*) is in the first place here and in this case for all files and paths. If the asterisk is in a different position, it is interpreted as part of the file name, which is not allowed in Microsoft Windows, for example. In our example table, setting the switches FS_NOREAD = X and FS_NOWRITE = X for all paths prohibits reading and writing. This makes the table a white list. This is preferable to a black list for security reasons. SPTH, on the other hand, becomes a Black List if you remove the first line with PATH = * in our example or if you do not set any of the switches FS_NOREAD, FS_NOWRITE or FS_BRGRU. The second line with PATH = /tmp allows read and write access for all files starting with /tmp, similar to a permission value /tmp*, as an exception to the access ban defined in the first line for all files and paths. This setting is not limited to subdirectories, but includes, for example, all files whose name starts with /tmp-xy. The third line with PATH = /tmp/myfiles defines a permission group with FS_BRGRU = FILE, triggering the subsequent permission check on the S_PATH object. The SAVEFLAG = X switch defines that these files will be included in a backup procedure; however, this is not relevant for the permission award.
Automatically pre-document user master data
When defining the development policy, you should ensure that the appropriate attention is paid to access security. Customised programmes or customisations in the SAP Code Inspector ensure that all developers working in the company comply with these guidelines. Verification of compliance with the development directives should be an essential part of quality assurance before the programmes are used productively. The SE38 and SA38 transactions should not be allocated in the productive system and custom programmes should be included in own transaction codes. Permissions are then set up only for these transactions.

You assign a reference user to a dialogue user by registering the reference user for additional rights in the SU01 transaction on the Roles tab in the Reference User field. If you are using Central User Administration (ZBV), the assignment applies to all connected systems. If the reference user does not exist in one of the systems, the mapping is ignored. However, the use of reference users also creates risks. This makes it easier to summarise permissions because it is difficult to keep track of the assigned permissions. In SAP NetWeaver AS ABAP 7.0 and above, reference users are considered in the reports of the user information system.

The possibility of assigning authorizations during the go-live can be additionally secured by using "Shortcut for SAP systems".

If archive parameters are passed when scheduling a step, a check is performed on the object S_WFAR_PRI.

Without generic table logging, certain changes in the system are not traceable.
Zurück zum Seiteninhalt