S 5.126 Protection of the SAP RFC interface

Initiation responsibility: Head of IT, IT Security Officer

Implementation responsibility: Administrator

The Remote Function Call (RFC) mechanism is the primary communications interface for the system-to-system communication for the ABAP stack. The Java stack also supports RFC communication via the Java Connector (JCo).

References to SAP documentation on RFC communication can be found in S 2.346 Use of the SAP documentation.

Assigning RFC authorisations restrictively

The authorisations allowing a user to call RFC-enabled ABAP programs (which are also referred to as RFC-enabled modules) are controlled using authorisation object S_RFC. Depending on its functionality, every RFC enabled module requires additional authorisations that are checked using additional authorisation objects. Since the programs are usually called using the network, there is a potential risk that the SAP system could be attacked remotely via the RFC interface.

The RFC authorisations must therefore be planned and assigned restrictively. The S_RFC authorisation object may be used to control which RFC function modules a user is allowed to access. This authorisation object has the following important restrictions, though:

• It is only possible to restrict access to the function groups, because only the value RFC_TYPE = "FUGR" is supported.
• The check performed on the RFC_NAME parameter, which contains the list of function groups affected, is limited to eighteen characters. -Longer names can be entered in the list, but only the first eighteen characters are actually checked.

For this reason, access may only be granted to all or none of the function modules in a function group and it is necessary to grant several authorisations under some circumstances.

In general, S_RFC authorisation should not permit access to all RFC modules. Using the RFC_NAME="*" setting should be avoided. There are several thousand RFC-enabled function modules in an SAP system that would be available for access when this setting is used. It would also automatically grant access to the RFC-enabled modules of newly installed applications and modules. Whether the RFC function called executes successfully also depends on the access checks performed by the RFC function itself in this case.

When planning the RFC authorisations, it must be considered that there are different types of RFC (e.g. synchronous, asynchronous, etc.). For this reason, all types of RFC must be taken into consideration when planning.

The S_RFC authorisation does not apply to the Java stack.

Outgoing RFC accesses can be restricted using authorisation object S_ICF, which controls access to the destinations (see S 4.263 Protection of SAP destinations).

Java stack RFC

The Java Connector (JCo) for the Java stack offers RFC capabilities for communication. In this case, though, the system components only use outgoing RFC calls by default (i.e. the Java stack is only used as an RFC client). Access to the internal ABAP stack (e.g. to make the users and roles of the ABAP stack available), to other SAP systems, or to external RFC servers is obtained using destinations.

The following must be noted when using the Java Connector:

• The Java stack uses the (ABAP stack) user SAPJSF to access the ABAP stack. This user account must be assigned a strong password during installation.
• The destinations (Destination service) in the Java stack must be protected against unauthorised access.

The following must be taken into consideration for Java stack RFC server programs:

• RFC servers must be implemented using separate programs. RFC server instances can be created using the JCo programming interface.
• The JCo RFC server implementation only offers functions for pure RFC communication. In particular, the authorisations must be checked and administrated by separate program implementations.

Securing RFC communications with SNC

If the protection requirements determination has determined that communication routes in which RFC is used must be protected, the use of SNC is recommended. Safeguard S 5.125 Protection of communication with SAP systems contains additional information on this subject.

Secure use of "trusted system" relationships

Trust relationships can be established between SAP systems so that users do not need to specify a password when accessing via RFC. When accessing, the trusting SAP system checks if the system requesting access is a trusted SAP system.

The authorisation object S_RFCACL can be used to control which user calls can be executed on the target system without entering a password. It is possible in this case to classify the users by SAP system ID (SAPSID), client, or calling transaction, amongst other information.

In general, the following must be taken into consideration:

• Trusted system relationships should only be used after thorough examination and after performing a risk assessment.
• The authorisation object S_RFCACL should not have any settings containing "*".
• No user information should be stored for RFC destinations that terminate in trusting SAP systems, because otherwise it becomes impossible in the trusting system to differentiate between the calling users.

Additional sources of information on this subject can be found in S 2.346 Use of the SAP documentation.

RFC client programs: Configuration of the sideinfo file

For RFC clients, the "sideinfo" file can be used as a global configuration file for RFC access. Authentication information can also be specified in this file that is then used for RFC access (more precisely: when establishing the underlying CPIC communication). All information is stored in the file as plain text.

It is therefore necessary to consider the following:

• Careful consideration should be given to the use of the sideinfo file.
• The information in the sideinfo file can be used by all local RFC client programs.
• Authentication information should not be stored in the sideinfo file. The client program should prompt the user for login information.
• Users who start RFC client programs must only be granted read access to the sideinfo file. Only authorised administrators should have write access to the file.

The sideinfo file can be used at several locations in an SAP system and is used particularly on the SAP gateway.

References to detailed information on this subject can be found in S 2.346 Use of the SAP documentation.

Securely using external (non-SAP) RFC servers

With the help of the RFC Software Development Kit (RFC SDK), it is possible to create RFC server programs offering their functions via RFC. If external RFC server programs are used, the following must be considered:

• The standard SAP security mechanisms and methods (authentication, authorisation, and administration) are not available for external RFC servers.
• The security mechanisms offered depend only on the implementation of the RFC server program.
• Users and authorisations can be managed by the server program or by external components. This means it is possible to have implementations in which anyone may obtain access to the RFC functions without any further checks.

For this reason, it should be ensured that any software developed in-house or software purchased from third parties meets the desired security requirements.

It must be ensured during the installation of an external RFC server that only the RFC library is installed. In particular, the installation of and ability to access the entire RFC Software Development Kit (RFC SDK), which is used for the development of RFC-based programs, should be avoided. This must be ensured by the software deployment process.

On computers requiring the installation of the RFC SDK (e.g. development computers), access to the programs in the "bin" directory (default path: <installation directory>/Sap/rfcsdk/bin) of the SDK installation should be restricted. These programs can be used for RFC access to SAP systems (startrfc) or to start RFC servers (rfcexec), amongst other things.

The ability of computers the RFC SDK is installed on to access the SAP systems (e.g. production systems) must be restricted at the network level.

Additional information can be found in S 2.346 Use of the SAP documentation.

Configuring the secinfo file for SAP Gateway

External RFC server programs generally register themselves on the SAP gateway system component, which negotiates client access to the external RFC server programs. They can also be started explicitly by the SAP gateway when an external start request is sent.

The access and start capabilities available for external entities requesting access are controlled using the "secinfo" configuration file. This file is not created automatically and must be created manually in all cases. If the file does not exist, no restrictions are implemented, and so anyone with technical access capabilities may start any programs on the SAP gateway computer. It is sufficient at first to create an empty file so that no one has such authorisation. After that, authorisations and access restrictions can be configured in the file. The file must be stored in the "data" directory of the SAP gateway, more precisely, of the gateway instance (default path: /usr/sap/<instance name>/data).

Alternatively, it is also possible to set the "gw/rem_start" profile parameter to the "DISABLED" setting if no external RFC server programs will be used in general.

References to more detailed information on this subject can be found in S 2.346 Use of the SAP documentation.

Review questions:

• Have the RFC authorisations been planned and assigned restrictively in the SAP system?
• Does the sideinfo file of the SAP system store no authentication information?
• Has it been ensured that only authorised SAP administrators are granted write access to the sideinfo file?
• Is the access option regarding SAP systems RFC SDK is installed on restricted at a network level?
• Has the secinfo file been created in the SAP gateway system in order to secure the access and start options?