One step at a time: How to secure and harden your SAP Gateway

SAST SUITE: INTERFACE MANAGEMENTThe Gateway is a central communication component of an SAP system. As such, it is an attractive target for hacker attacks – and should receive corresponding protections. If the Gateway protections fall short, hacking it becomes child’s play. Despite this, system interfaces are often left out when securing IT systems. Should a cyberattack occur, this will give the perpetrators direct access to your sensitive SAP systems.

The Gateway is the technical component of the SAP server that manages the communication for all RFC-based functions. The network service that, in turn, manages the RFC communication is provided by the RFC Gateway. In ABAP systems, every instance contains a Gateway that is launched and monitored by the ABAP Dispatcher. Even if the system is installed with an ASCS instance (ABAP Central Services comprising the message server and the standalone enqueue server), a Gateway can still be configured on the ASCS instance. The default configuration of an ASCS has no Gateway. In a pure Java system, one Gateway is sufficient for the whole system because the instances do not use RFC to communicate. Here, the Gateway is used for RFC/JCo connections to other systems.

General Gateway guidelines

  • For all Gateways, a sec_info-ACL, a prxy_info-ACL and a reg_info-ACL file must be available.
  • Always document the changes in the ACL files.
  • The first line of the reginfo/secinfo files must be “# VERSION = 2”.
  • Each line must be a complete rule (rules cannot be broken up over two or more lines).
  • The Gateway uses the rules in the same order in which they are displayed in the file. Only the first matching rule is used (similarly to how a network firewall behaves). All subsequent rules are not checked at all. This means that the sequence of the rules is very important, especially when using general definitions.
  • Each instance can have its own security files with its own rules. This is because the rules used are from the Gateway process of the local instance.
  • The first letter of the rule can begin with either P (permit) or D (deny). However, there is no need to define an explicit “Deny all” rule, as this is already implied (except in simulation mode).
  • In production systems, generic rules should not be permitted.
  • In addition, note that the system checks the case of all keywords and only takes keywords into account if they are written in upper case.
  • A LINE with a HOST entry having multiple host names (e.g. HOST = servername, 10. *. 2.20) is taken into account only if every comma-separated entry can be resolved into an IP address.
  • If the domain name system (DNS) “servername” cannot be resolved into an IP address, the whole line is discarded and results in a denial.
  • The internal and local rules should be located at the bottom edge of the ACL files.
  • Use host names instead of the IP address.
  • Check the availability and use SM59 to ping all TP IDs.In the case of an SCS/ASCS instance, it cannot be reloaded via SMGW. Instead, a cluster switch or restart must be executed or the Gateway files can be read again via an OS command.

SAP Gateway hardening 

The following steps usually need to be done manually to secure an SAP Gateway:

  • Activate Gateway logging.
  • Evaluate the Gateway log files and create ACL rules.
  • Configure the Gateway parameters.
  • Save ACL files and restart the system to activate the parameters.

Secure Gateway ACL files, thanks to SAST Interface Management

Our SAST Interface Management module in the SAST SUITE provides support in hardening the SAP Gateway. Specifically, it helps create secure ACL files. Access to the ACL files must be restricted. Based on the original Gateway log files in the system, default values can be determined and generated for the ACL files directly after the evaluation of the data found. This allows default values to be determined for the security control files of the SAP Gateway (Reginfo; Secinfo; Proxyinfo) based on statistical data in the Gateway log. Here, activating Gateway logging and evaluating the log file over an appropriate period (e.g. three months) is necessary to ensure the most precise data possible for the connections used.


Default values can be determined from the aggregated Gateway logging and used to assemble control data, and subsequently leverage the control data content for further use.

Would you like more information on our SAST SUITE or would you like to find out more about ALL ROUND protection of your SAP systems? Check out our SAST SOLUTIONS website or send us an e-mail us at

Matthias Anstötz (SAST SOLUTIONS)
Matthias Anstötz

Related articles in the SAST BLOG

How to guard your SAP Gateway against unauthorized calls

Study shows SAP systems especially prone to insider attacks