S 4.263 Protection of SAP destinations

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

In addition to assuming the role of a server, in which case the SAP system offers access to its functions, an SAP system may also assume the role of a client when it accesses functions provided by other SAP systems. In this case, the destinations describe the different target systems and contain all information necessary to access the target systems. In general, this information includes the name of the computer or its IP address, the protocol to be used, and the number of the communication port used by the target system to connect to the network.

However, authentication information may also be stored for destinations. When the destination is accessed, this information is then used to log on to the target system. If no authentication information has been stored for a destination, this information must be specified by the user calling the destination. The function called is executed remotely using the authorisations of the specified user. The following terminology is usually used in the context of destinations accessed using RFCs (Remote Function Calls):

• RFC user: A user who possesses certain authorisations and who is currently active in the server system.
• RFC service user: An RFC user is referred to as a service user when the login data (user name and password) is stored on the client.

Destinations are stored in a client-independent table, which means every user has access to all destinations in the SAP system. For this reason, access to the destinations must be secured. The following recommendations must be taken into consideration for destinations:

Storing authentication information

Authentication information should only be stored when this cannot be avoided. Here, it must be determined whether it is more important to protect the password used or to protect the target system from unauthorised access. It must be taken into consideration that authentication information must be stored for the RFC destinations used

• SERVICE: for use of ICF services
• DEST: for use of RFC destinations (in 6.20 and higher)

from programs, provided that the server system is not configured for trusted RFC communication, in which case generally none of the RFC calls from the trusted SAP system need to be authenticated.

If authentication information is stored, only a communication type user should be selected. In particular, no dialogue users should be entered, because otherwise it will be possible to log in interactively through the destination without entering a password.

Passwords should never be stored in unencrypted form.

Access to destinations

Access to the destinations must be restricted so that only authorised users are able to access them.

Access to the destinations can be controlled using authorisation object S_ICF. The following authorisation fields of the authorisation object are defined for the purpose of controlling access:

• ICF_FIELD: The type of object to be protected
  
  This field may contain the following values:
• ICF_VALUE: The value of the to ICF object to be protected
  
  This field contains the value of the corresponding object. The values to be protected are maintained in transaction SICF for ICF services and in transaction SM59 for RFC destinations.

The following must be considered in this case:

• The destinations must be grouped according to their operational scenarios. Users can then be granted access to all destinations needed in the scenario. Problems will arise, however, when destinations are used in more than one scenario, because a destination can only be assigned to exactly one group. If this is necessary, the destinations should be further divided into smaller groups.
• Access to destinations with different potentials for damage must be controlled using separate authorisations.

It must be noted that a destination can be used for many purposes. Therefore, access protection may only serve as an initial hurdle. Ultimately, the protection of the target system must be implemented by the called functions themselves and by assigning authorisations in the target system accordingly.

This applies especially to destinations accessed using trusted RFC (in which case they are also referred to as "trusted destinations"). In this case, the authorisations are controlled using authorisation objects S_RFC and S_RFCACL.

References to detailed information on controlling access to destinations can be found in S 2.346 Use of the SAP documentation.

Securing unused destinations

For unused destinations, it is necessary to decide whether they are only temporarily not in use or whether they will not be used at all any more. In the first case, the unused destinations should be deactivated, and in the latter case, the unused destinations should be deleted.

Transferring destinations to other systems

When destinations are transferred from one system to another system, the authentication data stored in the destinations is also transferred. These destinations can then be used immediately in the system to which they were imported to access the target system specified in the destination. This must be taken into consideration when transferring destinations (e.g. when copying a system).

Restricting access to the destination maintenance tool and tables

The destinations are maintained using transaction SM59. It is recommended to restrict access to this transaction to authorised administrators only (authorisation object S_TCODE).

It must be noted that the RFC destination data is stored in the RFCDES table. The passwords stored are stored in encoded form in this case, but all information necessary to decode the passwords is available in the SAP system. For this reason, direct access to this table must be restricted as well (see S 4.264 Restricting direct table changes in SAP systems).

Securing the THOST table

The THOST table maps the symbolic computer names (SAP names) used in the SAP system to DNS host names (network names). Access to the table maintenance tool (transaction SM55 or transaction SE16) therefore needs to be restricted to authorised administrators only (authorisation object S_TCODE).

Special attention should be paid to the consistency of the SAP name to network name mappings so that the right IT system is accessed.

Review questions:

• Are the destinations in the SAP system secured in such a way that not all users may access all destinations?
• Is user login information only stored for destinations when there is no other solution available?
• Have only communication type users been selected when storing authentication information in the SAP system (and no dialogue type users)?
• Are passwords stored only in an encrypted form in the SAP system?
• Is the access to destinations with different potentials for damage controlled using separate authorisations?
• Is access to transaction SM59 for maintaining destinations only granted to authorised SAP administrators?
• Is direct table access to the RFC destination data restricted to authorised SAP administrators?
• Is direct table access to the symbolic computer names in the THOST table restricted to authorised SAP administrators?
• Was the consistency of SAP names and network names taken into consideration?