User Management
Maintaining Authorization Objects (Transaction SU21)
In contrast to storing passwords in the form of hash values, the user ID and password are transmitted unencrypted during the login of the client to the application server. The Dynamic Information and Action Gateway (DIAG) protocol is used, which may look somewhat cryptic but does not represent encryption. In addition, there is no cryptographic authentication between the client and the application server. This applies not only to communication between the user interface and the application server, but also to communication between different SAP systems via Remote Function Call (RFC). So, if you want to protect yourself against the access of passwords during the transfer, you have to set up an encryption of this communication yourself.
One way of gaining direct access to downstream systems from the development system and possibly performing unauthorized activities there is to use incorrectly configured interfaces. In principle, interfaces within a transport landscape should be avoided with regard to the criticality of the systems "uphill", i.e. from an "unsafe" to a "safe" system (e.g. E system to Q or P system). However, this cannot always be implemented; for example, such interfaces are needed within the transportation system. Without going too deeply into the subject, however, critical interfaces can be characterized by the following properties. Critical interfaces refer to a critical system and a critical client, contain an interface user with critical authorizations in the target client, contain its deposited password.
Limit character set for user ID
Furthermore, the statistical data of other users (user activities, such as executed reports and transactions) should be classified as sensitive, since it may be possible to draw conclusions about work behavior using this data. This data can be displayed using transaction ST03N, for example. Access authorizations to the two types of data mentioned above should be assigned only very restrictively.
You should archive all document types at the same time intervals; This is especially true for the US_USER and US_PASS archive objects. It is customary to keep the supporting documents between 12 and 18 months, as this corresponds to the retention periods for the revision. For performance reasons, if you want to archive in shorter intervals, you should always archive all archive objects at the same time and store the PFCG and IDENTITY archive object classes in separate archives. In this case, it may be useful to download the archived revision documents back to a shadow database to make them available for faster review. You can use the following reports: RSUSR_LOAD_FROM_ARCH_PROF_AUTH / RSUSR_LOAD_FROM_ARCHIVE. You can also archive the table change logs with the BC_DBLOGS archive object.
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.
Finally, we want to give you some recommendations for securing file access.
For collective unlocking, you only want to select users with an administrator lock.