Gateway Access Control Lists

Source:http://wiki.scn.sap.com/wiki/display/SI/Gateway+Access+Control+Lists

 

Purpose

Help with the understanding of the Gateway ACLs (Access Control Lists) and the Simulation Mode, in order to help prepare production systems to have these security features enabled without disruptions.

Overview

This page contains information about the Gateway ACLs (reginfo and secinfo files), the Simulation Mode, as well as the workflow showing how the Gateway works with regards to the ACLs versus the Simulation Mode.

Observation: in emergency situations, follow these steps in order to disable the gateway security.

Gateway ACLs (reginfo and secinfo)

This section contains information about the Gateway ACLs, and examples of landscapes and rules.

The reginfo file have ALCs (rules) related to the registration of external programs (systems) to the local SAP instance. For example: an SAP SLD system registering the SLD_UC and SLD_NUC programs at an ABAP system.

The secinfo file has rules related to the start of programs by the local SAP instance. In other words, the SAP instance would run an operating system level command. For example: the RFC destination (transaction SM59) “CALL_TP_<operating system>” starts the “tp” program, which is used by the SAP Transport System (transaction STMS).

Before jumping to the ACLs themselves, here are a few general tips:
 

• The very first line of the reginfo/secinfo file must be "#VERSION=2";
• Each line must be a complete rule (you cannot break the rule into two or more lines);
• The gateway will apply the rules in the same order as they appear in the file, and only the first matching rule will be used (similar to the behavior of a network firewall). All subsequent rules are not even checked. This means that the order of the rules is very important, especially when general definitions are being used (“TP=*”);
• Each instance should have its own security files, with their own rules, as the rules are applied by the Gateway process of the local instance. However, if in your scenario the same rules apply to all instances of the system, you can use a central file (see the SAP note 1425765);
• The first letter of the rule can be either P (for Permit) or D (for Deny). You don’t need to define a “deny all” rule at the end, as this is already implicit (if there is no matching Permit rule, and the Gateway already checked all the rules, the result will be Deny – except when the Simulation Mode is active, see below).
  
  The syntax of the rules is documented at the SAP note 1408081. There are other SAP notes that help to understand the syntax (refer to the “Related notes” section below).
   

A general reginfo rule definition would be (note that the rule was split into multiple lines for explanation purposes, so it is more easily understood):
 

P TP=<program name>
  HOST=<comma separated list of hosts that can register the program>
  ACCESS=<comma separated list of hosts that can communicate with the program>
  CANCEL=<comma separated list of hosts that can cancel this registration>

 

Usually, ACCESS is a list with at least all SAP servers from this SAP system. This can be replaced by the keyword "internal" (see examples below). It might be needed to add additional servers from other systems (for an SLD program – SLD_UC, SLD_NUC, for example).


CANCEL is usually a list with all SAP servers from this system (or the keyword "internal"), and also the same servers as in HOSTS (as you must allow the program to de-register itself).


A general secinfo rule definition would be (note that the rule was split into multiple lines for explanation purposes, so it is more easily understood):

 

P USER=<username that is allowed to start the program>
/* read the explanation for USER at the SAP note 614971 for more details */
  USER-HOST=<comma separated list of hosts from where the users can start the program>
  HOST=<comma separated list of hosts where the program can be started>
  TP=<program name>

Reginfo – Landscape and Example

You have a Solution Manager system (dual-stack) that you will use as the SLD system. The Solution Manager (“SolMan”) system has only one instance, running at the host “sapsmci”.

You have configured the SLD at the Java-stack of the SolMan system, using the Gateway of the SolMan’s ABAP-stack.

There is an SAP PI system that needs to communicate with the SLD. The PI system has one Central Instance (CI) running at the server “sappici”, and one application instance (running at the server “sappiapp1”). The RFC destination “SLD_UC” looks like the following, at the PI system:

 

 

No reginfo file from the PI system is relevant. Since the SLD programs are being registered at the SolMan’s CI, only the reginfo file from the SolMan’s CI is relevant, and it would look like the following:
 

#VERSION=2
P TP=SLD_UC HOST=local ACCESS=internal,sappici,sappiapp1 CANCEL=local
(…OTHER REGINFO RULES…)
# This must always be the last rule on the file – see SAP note 1408081
P TP=* HOST=internal CANCEL=internal ACCESS=internal

 

The keyword “local” means “the local server”. The keyword “internal” means “all servers that are part of this SAP system” (in this case, the SolMan system).

Another example: you have a non-SAP tax system that will register a program at the CI of an SAP ECC system. The name of the registered program will be “TAXSYS”. The tax system is running on the server “taxserver”. The reginfo rule from the ECC’s CI would be:

P TP=TAXSYS HOST=taxserver ACCESS=internal CANCEL=local,taxserver

 

The rule above allows any instance from the ECC system to communicate with the tax system. If other SAP systems also need to communicate with it, using the ECC system, the rule need to be adjusted, adding the hostnames from the other systems to the ACCESS option. For example:

 

P TP=TAXSYS HOST=taxserver ACCESS=internal,host1,host2 CANCEL=local,taxserver

 

The SAP KBAs 1850230 and 2075799 might be helpful. They also have a video (the same video on both KBAs) illustrating how the reginfo rules work.

Secinfo – Landscape and Example

You have a non-SAP tax system that needs to be integrated with SAP. Such third party system is to be started on demand by the SAP system.

Only the (SAP level) user IDs “BOB” and “JOHN” can start this program, and they will be logged on to one of the instances from this SAP system.

You have an RFC destination named “TAX_SYSTEM”. It is configured to start the tax calculation program at the CI of the SAP system, as the tax system is installed only there. The RFC destination would look like:

 

 

The secinfo files from the application instances are not relevant. Only the secinfo from the CI is applicable, as it is the Gateway from the CI that will be used to start the program (check the “Gateway Options” at the screenshot above).
 

Note: depending on the system’s settings, it will not be the Gateway itself that will start the program. However, the Gateway would still be involved, and it would still be the process to enforce the security rules.
 

The secinfo file from the CI would look like the below:

#VERSION=2
P USER=BOB USER-HOST=internal HOST=local TP=/usr/taxsys/taxcalc
P USER=JOHN USER-HOST=internal HOST=local TP=/usr/taxsys/taxcalc
(…OTHER SECINFO RULES…)
# These must always be the last rules on the file – see SAP note 1408081
P USER=* USER-HOST=local  HOST=local  TP=*
P USER=* USER-HOST=internal HOST=internal TP=*

In case you don’t want to use the keywords “local” and “internal”, you’ll have to manually specify the hostnames. For example: the system has the CI (hostname “sapci”) and two application instances (hostnames “appsrv1” and “appsrv2”). The rules would be:

 

P USER=BOB USER-HOST=sapci,appsrv1,appsrv2 HOST=sapci TP=/usr/taxsys/taxcalc
P USER=JOHN USER-HOST=sapci,appsrv1,appsrv2 HOST=sapci TP=/usr/taxsys/taxcalc

Another example: let’s say that the tax system is installed / available on all servers from this SAP system, the RFC destination is set to “Start on application server”, and the “Gateway options” are blank. This way, each instance will use the locally available tax system.

In this case, the secinfo from all instances is relevant as the system will use the local Gateway of the instance the user is logged on to start the tax program. The secinfo file would look like:
 

#VERSION=2
P USER=BOB USER-HOST=local HOST=local TP=/usr/taxsys/taxcalc
P USER=JOHN USER-HOST=local HOST=local TP=/usr/taxsys/taxcalc
(…OTHER SECINFO RULES…)
# These must always be the last rules on the file – see SAP note 1408081
P USER=* USER-HOST=local  HOST=local  TP=*
P USER=* USER-HOST=internal HOST=internal TP=*

 

The usage of the keyword “local” helps to copy the rule to all secinfo files, as it means “the local server”. In case you don’t want to use the keyword, each instance would need a specific rule. Here are some examples:
 

• At the application server #1, with hostname “appsrv1”:
  
  

  P USER=BOB USER-HOST=appsrv1 HOST= appsrv1 TP=/usr/taxsys/taxcalc
  P USER=JOHN USER-HOST=appsrv1 HOST= appsrv1 TP=/usr/taxsys/taxcalc

• At the application server #2, with hostname “appsrv2”:
  
  

  P USER=BOB USER-HOST=appsrv2 HOST= appsrv2 TP=/usr/taxsys/taxcalc
  P USER=JOHN USER-HOST=appsrv2 HOST= appsrv2 TP=/usr/taxsys/taxcalc

The SAP KBA 2145145 has a video illustrating how the secinfo rules work.

Simulation Mode

To avoid disruptions when applying the ACLs on production systems, the Gateway has a Simulation Mode. The SAP note 1689663 has the information about this topic.

In summary, if the Simulation Mode is deactivated (parameter “gw/sim_mode = 0”; default value), the last implicit rule from the gateway will be “Deny all” as mentioned above, at the “Gateway ACLs (reginfo and secinfo)” section.

If the Simulation Mode is active (parameter “gw/sim_mode = 1”), the last implicit rule will be changed to “Allow all”. In addition, the Gateway logging (see the SAP note 910919) can be used to log that an external program was registered, but no “Permit” rule existed.

It is important to mention that the Simulation Mode applies to the registration action only. After the external program was registered, the ACCESS and CANCEL options will be followed as defined in the rule, if a rule existed.

In addition, the existing rules on the reginfo/secinfo file will be applied, even on Simulation Mode. Thus, if an explicit Deny rule exists and it matches the request being analyzed by the Gateway, the Gateway will deny the request.

Gateway behavior versus Gateway parameters

There are two parameters that control the behavior of the gateway with regards to the security rules. They are:

• gw/acl_mode: this parameter controls the value of the default internal rules that the Gateway will use, in case the reginfo/secinfo file is not maintained. In case the files are maintained, the value of this parameter is irrelevant;
• gw/sim_mode: activates/deactivates the simulation mode (see the previous section of this WIKI page).

The diagram below shows the workflow of how the Gateway works with the security rules and the involved parameters, like the Simulation Mode.

 

 

Changes to the reginfo rules

Changes to the reginfo rules are not immediately effective, even after having reloaded the file (transaction SMGW, menu Goto -> Expert functions -> External security -> Reread / Read again).

After reloading the file, it is necessary to de-register all registrations of the affected program, and re-register it again. This is required because the Gateway copies the related rule to the memory area of the specific registration. If you have a program registered twice, and you restart only one of the registrations, one of the registrations will continue to run with the old rule (the one that was not restarted after the changes), and another will be running with the current rule (the recently restarted registration). This would cause "odd behaviors" with regards to the particular RFC destination.

For example: you have changed to the rule related to the SLD_UC program, allowing a new server to communicate with it (you added the new server to the ACCESS option). You have already reloaded the reginfo file. However, you still receive the "Access to registered program denied" / "return code 748" error. The solution is to stop the SLD program, and start it again (in other words, de-register the program, and re-register it).