Professional Documents
Culture Documents
Security
4 Introduction
34 Summary
35 Appendix
2 / 38
Securing Remote Function Calls
3 / 38
Securing Remote Function Calls
Introduction
Remote function call (RFC) is a communication scenario. The RFC client initiates the com
protocol proprietary to SAP. The network service munication using connection data stored
that manages RFC communication is provided in RFC destinations to access RFC servers.
by the RFC gateway.1 Thousands of RFC function RFC function modules are executed on the
modules are included in SAP® software systems. RFC server side. RFC clients are often referred
SAP technologies such as the BAPI® program- to as the calling system and RFC servers as
ming interface and the application link enabling the called system.
(ALE) interface technology use RFC as the under-
lying communication protocol. RFC communi External RFC clients and external RFC servers
cation is required for all software systems using can be implemented using connectors available
the ABAP version of SAP NetWeaver Application for different programming languages. Those
Server (SAP NetWeaver AS) and is the most connectors include the SAP Java Connector,
powerful and most frequently used integration SAP Connector for Microsoft .NET, and the
technology for these software systems. SAP NetWeaver RFC software development
kit (SAP NetWeaver RFC SDK), as well as the
In many cases the RFC client and RFC server classic SAP RFC SDK.2 RFC communication
are implemented using the ABAP programming can use S ecure Network Communication (SNC)
language. ABAP software serves as both RFC client to encrypt communication. Figure 1 depicts
and RFC server, depending on the integration the different clients and servers.
SAP NetWeaver® Application Server for ABAP® RFC client SAP NetWeaver Application Server for ABAP RFC server
4 / 38
Securing Remote Function Calls
RFC function modules provide, for example, This document does not describe every imple-
functionality to create or change business mentation detail of the controls mentioned.
partners and contracts, to post financial docu- However, it does reference detailed documen
ments to the general ledger, and much more. tation and provides links to that documentation
The tremendous business functionality exposed in the appendix.
through RFC function modules is a huge asset
for system integration but also constitutes a The baseline for secure configuration of SAP
large attack surface that must be protected NetWeaver AS for ABAP3 is covered in an earlier
from unauthorized access. SAP white paper.4 It includes topics like network
filtering, password management, and manage-
This document focuses on the secure configura- ment of security patches. These are prerequisites
tion, secure authorization management, and pro- for the RFC security controls described in this
cess of monitoring RFC security. Its main focus document. The baseline document includes
is on software that uses SAP NetWeaver AS for sections covering aspects of RFC security. This
ABAP 7.0 and higher. It provides an overview of paper expands on those sections.
the aspects that must be considered in order to
ensure the required access control for all RFC This document discusses the following aspects
communication. Included are recommendations concerning the protection of RFC communication:
that should be considered for SAP software •• The “Securing RFC Destination Configuration”
running at the customer site. section covers guidelines that need to be con-
sidered for a secure setup. RFC destinations
store connection information and often include
user credentials to access RFC server systems.
They also define whether communication is
encrypted or not.
•• The “Securing RFC Communication on the
Server” section focuses on RFC function mod-
ules implemented in the ABAP programming
language. Access is protected through user
logon and authorization checks, but due to the
Most SAP customers run business- large number of RFC function modules, main-
critical system communication using taining user authorizations is a complex task.
RFC technology, with thousands of How to block remote access to RFC function
modules not used in a software system is
RFC function modules accessible described. I mproved solutions to perform RFC
over the network. authorization management are mentioned.
And how to activate switchable authorization
checks that were added in RFC function
modules is explained.
5 / 38
Securing Remote Function Calls
•• The “Securing RFC Communication on the •• The “Securing the RFC Gateway” section covers
Client” section provides information on secur- access control for registered and started exter-
ing RFC communication outbound from ABAP- nal RFC servers developed by SAP, partners,
based software and going to RFC function or customers using the SAP Java Connector,
modules in other software systems. It explains the SAP Connector for Microsoft .NET, or the
how to control who is authorized to use RFC SAP NetWeaver RFC software development
destinations that contain user credentials. kit. They typically do not perform user authen
•• The “Securing RFC Callback” section discusses tication or authorization checks. Access must
how to protect systems from malicious RFC be protected through access control lists. This
callback. RFC function modules running in the section also explains access control for RFC
RFC server of synchronous RFC connections proxy requests.
can call back to the RFC client. The RFC server •• The “RFC Security Monitoring” section includes
performs user logon and authorization checks. tips on monitoring RFC security.
The RFC client that receives the callback does
not perform user logon. The RFC callback runs RFC communication is required for all software
under the privileges of the user that initiated systems based on SAP NetWeaver AS for ABAP.
the RFC communication in the RFC client. All customers should therefore follow the recom-
Authorization checks are performed on that mendations provided in this paper to protect
user. their business data.
6 / 38
Securing Remote Function Calls
RFC connections between software systems are 2. Destinations with a technical connectivity
configured using RFC destinations and maintained configuration using stored credentials
in transaction SM59 in RFC client systems. Inad- (such as client, user, and password)
equate management of RFC destinations could 3. Destinations with a technical connectivity
lead to privilege escalation – unintended elevation configuration using trusted system logon
of user access. For example, SAP_ALL access in (trusted/trusting RFC)
production systems could be gained using im-
properly configured RFC destinations in develop- All three categories of RFC destination are rec-
ment systems. The following recommendations ommended for use between software systems
focus primarily on ABAP connections (type 3 RFC of the same security classification, for example,
destinations in transaction SM59). from one production system to another. They
are also recommended for use from systems of
To manage RFC destinations securely, three higher security classification to systems of lower
different categories are considered: security classification, for example, from a test
1. Destinations storing a technical connectivity system to a development system (see Figure 2).
configuration without stored credentials Access control for RFC callbacks is discussed
and without trust relationships between the for these destinations in the “Securing RFC
systems, which require user authentication Callback” section.
for each access
OK: RFC destinations from system of higher security classification to same or lower security classification
Check: RFC destinations of category 2 and 3 as security risks to be used only after risk analysis
7 / 38
Securing Remote Function Calls
As a general guideline, destinations from systems for should be documented. RFC destinations no
of lower security classification to systems of longer required should be removed. To determine
higher security classification should not store whether an RFC destination is used, an analysis
user credentials or use a trusted system logon. can be performed using the RFC runtime monitor
For example, a development system should not transaction SRTM6 or the workload monitor
be a trusted system for a production system. transaction ST03N.
These destinations are only to store technical
connectivity configuration data and authenticate Users stored in RFC destinations should be of type
the user for each access. RFC destinations for SYSTEM.7 Particularly in production environments,
the transport management system are excep- these users should be assigned the minimum
tions to this general guideline as long as minimal authorization required for executing the business
authorizations are used for the users stored in scenario from that destination in the target system.
these destinations.5 If other such destinations are It is recommended that dedicated users be used
required, they should be used only after perform- per RFC destination wherever possible. The report
ing a thorough risk analysis. The access control RSRFCCHK can be used in all systems locally to
recommendations provided in this document analyze RFC destinations that have stored user
could provide acceptable mitigations for some names and passwords. For centralized monitoring,
scenarios. see “RFC Security Monitoring.”
RFC destinations should be regularly reviewed It is strongly advised that authorization to main-
to determine if they are required for running tain RFC destinations in transaction SM59 be
business processes. Each RFC destination should restricted to authorized administrators. This
be assigned to an owner responsible for the des- is controlled primarily through authorization
tination and what each RFC destination is needed object S_RFC_ADM.8
8 / 38
Securing Remote Function Calls
9 / 38
Securing Remote Function Calls
Access to that table should be restricted (SAP The S_RFCACL field for the trusted user name
Note 1562697).13 The table should be assigned contains the allowed user name from the trust-
to table authorization group TTRL. This can be ed system (field RFC_USER = USERNAME).
checked and maintained using transaction SE54.
Users should not have S_TABU_DIS or S_TABU_ The field for the user name should never contain
NAM authorization to display or change the data * (the wild card). Any user from the trusted system
of that table. could impersonate a user having that authoriza-
tion. Wild cards should also not be used for the
The authorization for trusted system logon must fields holding the system ID and the client of the
be limited in the trusting system using authoriza- trusted system (fields RFC_SYSID, RFC_CLIENT).15
tion object S_RFCACL.14 There are two typical use A warning is displayed during role maintenance
cases for using trusted system logon: in transaction PFCG if administrators maintain a
•• Often users have the same user name in the wild card for any of these fields.16 The installation
trusted and trusting system. This is controlled number of the trusted system can be included in
using the S_RFCACL field for the same user the S_RFCACL authorization as of SAP NetWeaver
(field RFC_EQUSER = Y). The S_RFCACL field AS for ABAP 7.0 that includes enhancement
for the trusted user name should be left blank package 2 (field RFC_INFO = 1234567890).
when logging in under the same user name If a trusted system logon fails, a short dump is
(field RFC_USER = ‘ ’). created in the trusting system.
•• In some cases users in the trusted system
should be allowed to log on with a different user Authorization object S_RFCACL is not included
name in the trusting system. The S_RFCACL in the authorization profile SAP_ALL unless the
field for the same user documents the use of default configuration is changed in the customiz-
different user names (field RFC_EQUSER = N). ing table PRGN_CUST with key ADD_S_RFCACL.
This default configuration should not be changed.
10 / 38
Securing Remote Function Calls
SECURE NETWORK COMMUNICATION SNC for RFC communication between SAP servers17
RFC does not authenticate client and server crypto- is available to all SAP NetWeaver c
ustomers.18
graphically, nor does it encrypt network commu- RFC communication between client and server
nication. Passwords transmitted over the network should be protected using an SNC product,
can be “sniffed.” Due to missing mutual authen- such as the SAP Single Sign-On application (see
tication, rogue systems could intercept network Figure 3).19 Blocking unencrypted communication
traffic, manipulate content, and forward it to is to be considered after implementing SNC.20
legitimate servers (“man in the middle” attacks).
Strict access control to transaction STRUST is
Secure network communication (SNC) provides required in order to protect access to cryptographic
cryptographically strong mutual authentication, keys when using SAP Single Sign-On. The table
integrity protection of transmitted data, and SSF_PSE_D should be assigned to t able authori
encryption of network traffic. Its use is highly zation group SPSE.21 End users are not to have
recommended for all RFC communication display or change access for this table authoriza-
traversing untrusted networks to mitigate tion group. File system access from ABAP programs
these risks. to personal security environment (PSE) files holding
cryptographic keys should be restricted.22
Corporate network
Firewall
Firewall
WAN
clients
DB DB DB
DB = Database
11 / 38
Securing Remote Function Calls
Recent releases of SAP ERP application software RFC f unction modules on the server from
expose over 40,000 RFC function modules to the other systems, other clients, or other users.
network. In a typical customer software system, Exceptions are RFC function modules in func-
however, only a few hundred RFC function modules tion group SRFC, which can be accessed anony-
need to be called remotely. mously. Additional profile parameter values
are a
vailable to further restrict access to that
Remote access to RFC function modules is function group.24
protected by user logon and at least the technical
authorization check performed through the S_RFC authorization checks (see Figure 4) are
authorization object S_RFC. Additional functional also performed for internal RFC when profile
authorization checks are performed by many parameter auth/rfc_authority_check is set to
RFC function modules. Wild card authorizations value 9. An internal RFC is used for asynchronous
for object S_RFC are very risky since the check processing and for dynamic load distribution
on object S_RFC is the main access control for to other work processes or application servers.
RFC function modules. Internal RFC does not change the user; it main-
tains the same user context in the same system
The profile parameter auth/rfc_authority_check23 and the same client. SAP does not recommend
controls technical authorization checks on this setting for most customer software systems.
object S_RFC. Do not use the value 0 because It requires that you include in S_RFC authorizations
it deactivates S_RFC authorization checks. The RFC function modules that are used internally
default value 1 is recommended for most sys- in the system but which should not be accessed
tems. It requires user authentication and at least remotely. It also complicates authorization
S_RFC authorization for any remote access to maintenance for object S_RFC.
Yes Remote call Different system or different client or different user Is performed
Internal call Same system and same client and same user Is not performed
No Local call
12 / 38
Securing Remote Function Calls
Each function module is assigned to a function The system trace transaction ST01 has been
group. The authorization check on object S_RFC used for many years for role maintenance for
provides access control on two levels of granu- RFC communication. This approach has proven
larity25 as of SAP NetWeaver AS for ABAP 7.0 with to be difficult for many customers. Many RFC
enhancement package 2. Systems running SAP scenarios use highly privileged technical users.
enhancement package 1 for SAP NetWeaver 7.0 Also end users often have S_RFC wild card autho-
and lower perform checks on the function group rization, allowing them to call all RFC function
level only. Access is granted to execute all RFC modules in a system. A cleanup of these autho
function modules assigned to function groups rizations using ST01 traces is difficult.
included in the S_RFC authorization. The kernel
correction provided in SAP Note 1785761 should Improved solutions are available to simplify access
be implemented in these systems.26 Systems control of RFC communication on the server.
using SAP enhancement package 2 for SAP They are covered in the remainder of this section.
NetWeaver 7.0 and higher perform authorization
checks on the function module level as well. Most
roles delivered by SAP and created by customers
use access control on the function group level.
The “Authorization Maintenance for RFC Com-
munication” section covers how to maintain
access on the RFC function module level.
13 / 38
Securing Remote Function Calls
14 / 38
Securing Remote Function Calls
The first phase is the logging phase. Data is col- called remotely, when it was last called, and how
lected without disrupting RFC communication. often. After the logging phase, the UCON default
It is recommended that the UCON data collection CA should include all RFC function modules that
be activated as early as possible. The default will be called remotely.
logging phase is three months, but this can be
adjusted to customer needs. It should cover all The second phase is the evaluation phase, which
typical RFC communication, month-end, quarter- simulates the UCON runtime checks. Calls to RFC
end, year-end, and system management activi- function modules that have not been white-listed
ties. Most customers have test systems where are allowed but they trigger alerts. Administrators
most of the RFC integration scenarios can be review the alerts and assign the RFC function
tested. However, there are some RFC connec- modules to the UCON default CA if appropriate.
tions that are only used in production systems.
For that reason, it is also advisable to activate the Runtime checks are active in the third phase,
UCON data collection in production systems and which is the final phase. Access to RFC function
to use that data to maintain the UCON default modules that have not been white-listed is
CA. All RFC function modules called remotely in blocked regardless of authorization.
the logging phase need to be evaluated, and a
decision must be made as to whether these RFC With UCON, it is possible to manage every sys-
function modules should be added to the UCON tem individually or to transport UCON default CA
default CA. Additional information on the RFC and phase information in software system land-
scenario is available, which supports the analysis. scapes from development systems to production
For every RFC function module, it can be deter- systems. New RFC function modules developed
mined from which RFC client system it was called, by customers or created through support pack-
which user initiated the RFC communication, ages a
fter finalizing the initial implementation of
over which RFC destination the communication UCON are assigned to the logging phase. Further
took place, and which user executed the RFC information on implementation is available in
function module within the RFC server. It can also “UCON RFC Basic Scenario – Guide to Setup
be determined when the RFC function was first and Operations.”31
15 / 38
Securing Remote Function Calls
Analyze Build
Activity Monitor RFC function Monitor authorization Document authorization Build roles
modules called by user checks by RFC function checks by RFC function
module module
UCONCOCKPIT STUSOBTRACE
STRFCTRACE
16 / 38
Securing Remote Function Calls
Short-Term Analysis of Specific for RFC function modules as well as ALE scenarios
RFC Communication (SAP Note 1868691).36 Additional information on
Short-term analysis of authorization requirements this is available in the online documentation.37
for specific RFC communication scenarios is
performed using the transaction STAUTHTRACE The authorization default values maintained in
(SAP Note 1718059).33 The analysis through transaction SU24 can be used for role maintenance
transaction ST01 has been deprecated. The trace in transaction PFCG if they are part of the role
includes authorization checks for every RFC menu. To accomplish this, RFC function modules
function module instead of function groups if included in the trace results of STAUTHTRACE
S_RFC authorization of the analyzed user is set must be added to the role menu (SAP Note
to function module level authorization (field 1631929).38 The required S_RFC authorizations
RFC_TYPE = FUNC). A systemwide trace should are then automatically calculated and all autho
be activated in the transaction STAUTHTRACE rization defaults for the RFC function modules
if the RFC communication uses load balancing are added to the role (SAP Note 1640733).39
(SAP Note 1707841).34 The trace results show all As a result, all authorizations in such roles have
RFC function modules that were called remotely either the status “standard” or “maintained” and
as well as all authorization checks that were they reference the RFC function modules that
performed during the execution of these RFC require that authorization. This makes it unnec-
function modules. Additional information on essary to add authorizations manually. Manually
authorization requirements for RFC commu added authorizations do not reference the RFC
nication using external RFC clients created using function module that requires them, which
connectors is available in SAP Note 460089.35 means tracing must be performed again the
next time that RFC function module is used in
The trace results of the transaction STAUTHTRACE other RFC scenarios.
can be used in transaction SU24 to maintain
authorization default values for RFC function The short-term system trace analysis can be
modules (SAP Note 1707841). This will document used to maintain roles for specific RFC scenarios.
which authorization is required to execute which Additional tools are available for long-term analysis
RFC function module. This information can be to reduce privileges that have grown excessive
reused for all roles that include these RFC func- over time.
tion modules. This concept has traditionally been
used for roles granting access to transactions. Long-Term Monitoring of All RFC Communication
SAP provides authorization default values for in a System
transactions in transaction SU22. Customers A long-term authorization trace can be activated
maintain authorization default values in transac- using the profile parameter auth/authorization_
tion SU24. Initial setup and consolidation of SAP trace in test and production systems. It is con-
and customer data after system upgrade is done figured using transaction STUSOBTRACE (SAP
in transaction SU25. The same process of main- Note 1854561)40 and based on the same process
taining authorization proposals can also be used used by SAP to maintain authorization default
17 / 38
Securing Remote Function Calls
values (SAP Note 543164).41 The authorization should be set to 1 in order to record all RFC function
trace records all programmed authorization module names at least once per RFC communi-
checks once per application. The authorization cation.43 The statistical data is presented in trans-
trace can be filtered, for example, to record only action ST03N. A custom program can be used to
authorization checks performed for remote RFC extract RFC calls from the statistical data.44 This
calls (SAP Note 1847663).42 The trace results are data includes external RFC calls and internal RFC
used in transaction SU24 to maintain authoriza- calls, so it must be filtered for the external RFC
tion default values for RFC function modules. calls. Systems with SAP Note 2080378 can use
transaction STRFCTRACE to analyze the remote
The long-term authorization trace in transaction RFC communication in a similar way to that
STUSOBTRACE documents authorization require- provided by UCON in later releases.45
ments for RFC function modules. It does not
document which users require access to these Transactions STAUTHTRACE and STUSOBTRACE
function modules. This information is available are often used in test systems or production sys-
in transaction UCONCOCKPIT described in the tems to analyze authorization checks. Transactions
previous section. SU24 and PFCG should be used in development
systems in order to maintain authorization
Systems without UCON can extract which users defaults and roles, which are transported to test
require access to which function modules from and production systems. Transactions SU24 and
the statistical data collected by default in all PFCG make it possible to analyze trace data from
ABAP-based systems. The kernel version from remote systems (SAP Note 1861370).46 An RFC
SAP Note 1964997 should be used in these sys- destination without stored user credentials can
tems, and the profile parameter stat/rfc/distinct be used for this.
18 / 38
Securing Remote Function Calls
19 / 38
Securing Remote Function Calls
authorization checks. The event DUQ logs changes Productive authorization scenarios are never
to productive authorization scenarios. The security delivered by SAP. They are always created in
audit log should be active, and these events should customer development systems and transported
be included in an active static filter for all users in the customer software system landscape. If
in all clients in order to enable the logging. More partners or customers need to implement switch-
information on security audit log settings is avail- able authorization checks, they can implement
able in SAP Note 539404.48 Analysis of the security authorization scenario definitions in the customer
audit log events in the transaction SM20 or in the name space. Figure 7 shows how authorization
report RSAU_SELECT_EVENTS makes it possible scenario definitions, productive authorization
to adjust the roles of affected users before the scenarios, and programmed switchable autho
productive authorization scenario is set to active. rization checks based on these scenarios work.
The earlier the logging is activated, the better
it is for the data quality.
systems
SACF SACF
Scenario definition Scenario Productive
Transports
definition scenario
Development Configuration
Workbench for ABAP® Runtime
Switchable authorization check Switchable authorization check
in ABAP programming language in ABAP code
Switchable check defined (inactive) Switchable check configured (logging only, active check, inactive)
Developers create scenario definitions Administrators create productive scenarios that are used for
and implement switchable checks. authorization checks at runtime.
20 / 38
Securing Remote Function Calls
SACF integrates seamlessly into the authoriza- individual SAP Notes. Security notes from SAP
tion upgrade activities in transaction SU25 in sys- indicate in the note title that they provide new
tems based on SAP NetWeaver AS for ABAP 7.3 switchable authorization checks. Switchable
with enhancement package 1.49 Transaction authorization checks are also used by SAP for
SACF_COMPARE can be used in all other systems functionality unrelated to RFC. Additional infor-
in standard maintenance to configure multiple mation on SACF is available in SAP Note 1922808.51
authorization scenarios after the software is
installed or upgraded. With transaction SACF, Changes to the authorization concept are typically
authorization scenarios are maintained individually. not part of the regular patch management and
must be planned. The security notes providing new
The switchable authorization check framework switchable authorization checks in RFC function
is typically installed through support packages. modules should be reviewed together with S_RFC
SAP Note 205452250 lists all other required SAP authorizations in one project and revisited for
Notes if installation is to be performed through upgrades and new system installations.
21 / 38
Securing Remote Function Calls
RFC destinations stored in RFC client systems the RFC runtime environment at the kernel level.
often contain logon data for RFC server systems. It verifies that the user in the RFC client system is
The RFC destinations that should contain no authorized to use RFC destinations of a given autho-
logon data were mentioned in the “Securing rization group. By default, RFC destinations are not
RFC Destination Configuration” section. assigned to authorization groups. The authorization
check on object S_ICF does not take place until an
All users in the client system use the same RFC authorization group is assigned. Systems running
user stored in the RFC destination to execute RFC central user administration (CUA)54 can, for example,
function modules in the server. They do not need to assign RFC connections to managed systems to an
have the authorizations in the server themselves, authorization group. Authorizations to use these RFC
nor do they require a user in the RFC server system, destinations can be limited to CUA administrators.
strictly speaking.
RFC destinations are configured per system and
Misuse of RFC destinations with stored credentials can be used by users in any client of the system
of highly privileged users is known as RFC hopping. if they are not properly protected by authorization
Insecure setup of RFC destinations could allow groups. One example is using RFC destinations
access to be made to a development system, in transaction SE37 for test execution of function
which could enable access to a test system, and modules. Transaction SE37 can start function
finally to a business-critical production system. modules through an RFC destination or in the same
system and client locally. During test execution
Access control for RFC communication on the of function modules, an authorization check is
RFC client side is provided by authorization performed on authorization object S_DEVELOP.
objects S_ICF and S_DEVELOP.
52 53 An additional check on authorization object S_ICF
is performed if the test execution uses an RFC
RFC destinations in RFC client systems with stored destination that is assigned to an authorization
access credentials for business-critical systems group. Test execution should be strictly controlled
should be categorized in authorization groups. This in systems that have RFC destinations with stored
is maintained for each RFC destination in transaction access credentials to business-critical systems.
SM59 in the “Logon & Security” tab. RFC destinations Access to transaction SE37 should generally not
can be assigned to these authorization groups. In the be granted to end users in production systems.
RFC client system, a technical authorization check Emergency procedures should exist for support
on authorization object S_ICF is then performed by processes that may require test execution.
22 / 38
Securing Remote Function Calls
So far this document has covered RFC communi- RFC callback can pose risks to business-critical
cation, where RFC clients execute functionality in systems when initiating RFC communication
RFC servers but not the other way around. How- using highly privileged users to other systems
ever, the server can perform an RFC callback to with a lower trust level. For example, batch jobs
the client during synchronous RFC calls. It uses are in many cases executed by highly privileged
the open RFC connection to the RFC client and system users. These batch jobs could perform
does not require another user logon. This is done RFC communication to remote systems. Malicious
using the predefined destination BACK55 which remote systems could misuse the high privileges
exists in all ABAP-based software systems. RFC of the batch user using the RFC callback. For this
callback can also be performed by external RFC reason, it is advised that the following access control
servers created with any connector or received be implemented for all business-critical systems.
by external RFC clients created with the SAP
NetWeaver RFC SDK. RFC callback executes RFC callback always performs S_RFC authoriza-
RFC function modules on the client in the context tion checks and potentially additional functional
of the user that initiated the synchronous RFC authorization checks on the user that initiated
communication. All RFC function modules that the RFC communication. The authorization
this user is authorized to execute in the RFC management for users initiating RFC communi-
client can be executed by the server through cation should therefore follow the same guide-
RFC callback. Asynchronous RFC, transactional lines as outlined in the “Authorization Mainte-
RFC, queued RFC, and background RFC do not nance for RFC Communication” section on
support RFC callback (see Figure 8). authorization management.
23 / 38
Securing Remote Function Calls
RFC callback white lists improve access control connecting to systems of lower security classi
for RFC callback. They are maintained for RFC fication. Logging of RFC callbacks should be
destinations in systems that initiate RFC com- activated in all systems to provide traceability.
munication and which might receive RFC call-
backs. The white lists are maintained for RFC RFC callback white lists are provided in SAP Note
destinations of connection types ABAP and 1686632.56 The checks are controlled through the
TCP/IP. One white list for the RFC destination profile parameter rfc/callback_security_method,
DYNAMIC_DEST_CALLBACK_WHITELIST can which has by default the value 1. This setting is
be maintained for dynamic RFC destinations. nondisruptive as long as there is no active RFC
For many RFC destinations, RFC callback is not callback white list and it can be used to log RFC
needed. If RFC callback is needed, only a few callbacks to the security audit log. The security
RFC function modules are typically called back. audit log should be active and events DUI, DUJ,
White-list entries define tuples of RFC function and DUK should be included in an active static
modules called in the target of an RFC destination filter for all users in all clients to enable the
and RFC function modules that are allowed to logging.57 The events DUI and DUJ provide infor-
be called back. A learning and simulation phase mation of which RFC callbacks were executed
supports maintenance of RFC callback white lists successfully and which were rejected. The event
for existing RFC destinations. It is recommended DUK is used for the simulation phase. It logs RFC
that white lists be configured at least for RFC callbacks that would be rejected after activation
destinations in business-critical systems when of inactive white lists.
24 / 38
Securing Remote Function Calls
RFC callback white lists are maintained in trans- is not covered by an inactive white list is alerted
action SM59 in systems based on SAP NetWeaver using the security audit log event DUK. All these
AS for ABAP 7.3 with enhancement package 1 events must be reviewed and added to the
with SAP Note 1686632.58 The logged RFC call- white list if appropriate.
backs stored in the security audit log are ana- •• After the simulation phase, RFC callback white
lyzed programmatically and RFC callback white lists are activated. RFC callbacks that are not
lists are generated from the logs. The white list is included in the white lists are rejected after
then displayed in the “Logon & Security” tab of activation. DUJ events are written to the security
RFC destinations. SAP Note 2058946 explains audit log for rejected callbacks.
the maintenance of RFC callback white lists in
other systems in standard maintenance.59 The profile parameter rfc/callback_security_
method value 3 can be used once white lists have
Creating an RFC callback white list is performed been fully maintained for all RFC destinations
in three phases: of connection types ABAP and TCP/IP. With this
•• In the logging phase, the profile parameter parameter setting, all active and inactive white
rfc/callback_security_method is set to 1. lists are actively evaluated.
Security audit log is configured and DUI events
are written for all successful RFC callbacks. In addition to using white lists, RFC callback can
The RFC callback white lists are created using be prevented programmatically before initiating
these logs in transaction SM59 or as explained synchronous RFC communication. This is done
in SAP Note 2058946. The white lists are not by calling function module RFC_CALLBACK_
yet set to active. REJECTED locally in the RFC client before
•• In the simulation phase, the profile parameter performing the RFC call.60 A programmatically
rfc/callback_security_method is set to 2 and rejected RFC callback always has precedence
inactive white lists are tested. RFC callback that over the white list.
25 / 38
Securing Remote Function Calls
ACCESS CONTROL FOR EXTERNAL RFC SERVERS these external RFC servers provide RFC function
The “Securing RFC Communication on the Server” modules to all RFC clients that can access the
section focused on controlling access to RFC RFC gateway.
function modules implemented in the ABAP
programming language. This requires a logon External RFC servers typically do not have any
to the ABAP-based software system and at user management. They could identify RFC
the least S_RFC authorization. clients using SNC,61 but in most cases they do
not perform any authentication and, for that
As mentioned earlier, external RFC servers can reason, cannot perform authorization checks.
be implemented using connectors such as the The access control for registered and started
SAP NetWeaver RFC SDK. Those external RFC RFC servers is provided by access control lists
servers can register at an RFC gateway or they (ACLs) managed by the RFC gateway. Figure 9
can be started by an RFC gateway. The RFC shows the different types of RFC servers – RFC
gateway is the technical component of the appli- function modules implemented in ABAP as well
cation server that runs the network services as registered or started external RFC servers.
managing all RFC communication. By default,
Figure 9: ABAP RFC Function Modules Versus Started and Registered RFC Servers
SAP NetWeaver® Application Server for ABAP® RFC client SAP NetWeaver Application Server for ABAP RFC server
S_RFC
Registered external RFC server and other
secinfo
reginfo
authorization
RFC function module checks
26 / 38
Securing Remote Function Calls
RFC gateway ACLs for external RFC servers Registered external RFC servers are used far more
should be maintained for all systems based on often than started external RFC servers. These
SAP NetWeaver AS for ABAP and SAP NetWeaver RFC servers often run in their own environment
AS for Java as well as stand-alone RFC gateway and register at a remote RFC gateway. They keep
installations. If RFC gateway access control is not the connection to the RFC gateway open. RFC
maintained, malicious RFC clients could start ex- clients access these servers through this open
ternal RFC servers without a logon and execute connection. Very often the only RFC client is the
operating system commands on the server, down- ABAP-based software system where the external
load files from the server, manipulate files on the RFC server is registered. This is configured in
server, or access the database of the application transaction SM59 in TCP/IP connections with the
server. Malicious external RFC servers could regis- technical setting “Registered Server Program.”
ter at remote RFC gateways to receive RFC calls One example for this use case is the search and
intended for legitimate external RFC servers or classification engine TREX of the SAP NetWeaver
to perform a malicious RFC callback to the RFC technology platform. Registered external RFC
client. servers are a very common integration technology
and are being developed by SAP and partner
There are two RFC gateway access control lists companies.
that must be maintained for external RFC servers.
Maintaining these ACL files has no impact on RFC Started external RFC servers are executables on
communication to RFC function modules in the the server and are started by the RFC gateway
ABAP server. upon request by RFC clients. Typically RFC clients
•• ACL file reginfo controls the registration of are the application servers of a system. External
external RFC servers and the accessing of RFC servers are not started in most systems by
registered external RFC servers. remote RFC clients. One example is the start of
•• ACL file secinfo controls the starting of external the external RFC server SAPXPG, which is used
RFC servers. through transaction SM49 to execute operating
system commands on the same application server.
Accessing started external RFC servers is config-
ured in transaction SM59 in TCP/IP connections
with the technical setting “Start on Explicit Host”
and RFC gateway options that point to a remote
RFC gateway.
27 / 38
Securing Remote Function Calls
RFC gateway ACL files secinfo and reginfo do not r estore the registration if the connection is lost.
exist after system installation. Unless the profile RFC gateway logging should be enabled and used
parameter gw/acl_mode is set to 1, there are to identify registered external RFC servers that
no restrictions to register or start external RFC are not identified at initial setup. The logs need to
servers. New system installations add this setting be reviewed regularly, and ACL files need to be
to the default profile (DEFAULT.PFL). It restricts adjusted if necessary.
registration and starting external RFC servers
to the application servers of a system. ACL files The generated ACL controls registration of external
must be adjusted in case additional remote RFC servers. It does not limit access of remote
connections are required. RFC clients to registered RFC servers. The ABAP-
based software system where the external RFC
Systems that were installed before gw/acl_mode server is registered is in many cases the only
was introduced must be configured to ensure legitimate RFC client accessing that registered
security. A system upgrade does not automatically RFC server. RFC client access is logged for regis-
enable the settings. Guidelines for maintaining tered external RFC servers, with reginfo entries
ACL files secinfo and reginfo are available on the containing ACCESS restrictions. Again, the RFC
SAP Help Portal site62 and in SAP Note 1408081.63 gateway logging can be used to identify RFC
A tool for the initial ACL setup is available through clients accessing registered RFC servers.
transaction SMGW (menu Goto, Expert Functions,
External Security).64 Gateway logging actions S and s are used for
starting, registering, or accessing external RFC
Secinfo ACL entries generated by the tool for servers.
started external RFC servers block remote RFC
clients. Only internal access from application Uninterrupted business operation is as important
servers of the same system is granted. In most as security. ACL simulation is available to test
customer systems, there are no other ACL the ACL settings in a nondisruptive way before
entries needed. RFC gateway logging should activating them. The simulation mode is available
be enabled at least for rejected RFC clients. as of version 7.21 of the kernel of SAP NetWeaver
AS for ABAP and is configured through the profile
On the other hand, registered external RFC parameter gw/sim_mode (SAP Note 1689663).
servers typically register from remote systems. Entries that are missing in the ACL are not rejected
The tool evaluates all external RFC servers that but logged using an RFC gateway logging action Z.
are registered on RFC gateways of all application
servers of the current system. It also evaluates all After initial generation, ACL changes are per-
local TCP/IP connections that access registered formed directly in the files. ACL changes do not
RFC servers. It adds these external RFC servers to require a system restart. They can be activated
the ACL file reginfo and grants access to register dynamically either for individual application
from remote systems. Most registered external servers or globally for all application servers
RFC servers are always registered, and they in transaction SMGW.
28 / 38
Securing Remote Function Calls
In summary, the following profile parameters •• gw/sim_mode69 (SAP Note 1689663) can
should be set: temporarily be set to 1 to test ACL files, but
•• gw/logging65 (SAP Note 910919) should be should not be used indefinitely. The simulation
activated. Log files of multiple systems with mode does not deny access, but it logs access
multiple application servers can be stored that is not included in the ACL using logging
on a network share when using variables like action Z. The log files must be analyzed and
$(SAPSYSTEMNAME) and $(SAPLOCALHOST) missing entries added to the ACLs.
in the file names. The logging action should •• gw/monitor70 (SAP Note 64016) should be
include actions SsMPXZ. External RFC server set to 1 to restrict RFC gateway monitoring
communication is logged using action S if to local access (gw/monitor = 1). This is the
simulation is off and action Z if simulation is on. default configuration setting and should not
Logging is limited to rejected requests if the be changed to 2 for remote access.
lowercase s is included in the logging actions.
•• gw/acl_mode66 (SAP Note 1480644) should Once RFC gateway access control is configured
be set to 1 for security by default in case of and active, it should be monitored in order to
nonexistent ACL files. make sure that restrictions remain in place.
•• gw/sec_info and gw/reg_info (SAP Note Monitoring can be performed using the SAP
1408081) hold the path to the ACL files. It is EarlyWatch® Alert service,71 which includes a
recommended that those settings be changed section on RFC gateway security settings as
to a path on the global directory that can explained in SAP Note 863362. In addition,
be accessed by all application servers. This the configuration validation functionality of
eliminates the need to maintain the files for the SAP Solution Manager application manage-
all application servers individually. ment solution72 can be used to monitor the
•• gw/reg_no_conn_info67 (SAP Note 1444282) RFC gateway security settings. This is covered
must be set to 1 or higher odd numbers in the “RFC Security Monitoring” section.
explained in the SAP Note. This ensures
that bypass of ACL files as described in
SAP Note 1298433 is not possible.68
29 / 38
Securing Remote Function Calls
ACCESS CONTROL FOR RFC PROXY REQUESTS Proxy requests should be restricted if RFC com-
RFC gateways can proxy requests to RFC function munication is filtered between network segments.
modules in other ABAP-based software systems. Most RFC gateways do not have to proxy RFC
Requests to registered or started RFC servers requests from external RFC clients.
cannot use RFC gateway in proxy mode. Using
an intermediate RFC gateway as proxy can be Access control for RFC proxy requests is config-
configured on the RFC client side in transaction ured in the ACL file prxyinfo. The file location is
SM59 for all ABAP connections by setting RFC set using profile parameter gw/prxy_info. A single
gateway options in the technical settings. Also, ACL entry is sufficient for most customer systems:
external RFC clients created with the SAP Java P SOURCE=local,internal DEST=*
Connector or the classic SAP RFC SDK can use
an intermediate RFC gateway as proxy to call RFC This configuration permits all application servers
function modules in other ABAP-based software of a system to proxy requests of other application
systems. servers of the same system. All remote proxy
requests are blocked.
Many customers segment networks and restrict
RFC communication between networks using fire- The ACL settings in file prxyinfo can be tested
walls. For example, the RFC gateway of an SAP using the simulation mode that is configured
ERP software system might be accessible to the through profile parameter gw/sim_mode. It logs
end-user network. The SAP ERP software could proxy requests that are not included in prxyinfo
have RFC connections to other ABAP-based soft- instead of rejecting them.
ware systems. Access to those systems might be
blocked from the end-user network by a firewall.
Malicious users could try to access the other
ABAP system by using the RFC gateway of the
SAP ERP software system in proxy mode.
30 / 38
Securing Remote Function Calls
31 / 38
Securing Remote Function Calls
32 / 38
Securing Remote Function Calls
RFC destinations can be analyzed in every system Configuration validation functionality is part of
using transaction SM59 or report RSRFCCHK. the work center for root cause analysis of SAP
However, complex software system landscapes Solution Manager.77 The following checks should
typically have hundreds of RFC destinations in be used to monitor RFC security:
dozens of systems. Monitoring individual RFC •• RFCDES_TYPE_3_CHECK checks ABAP con-
destinations in each system is effort intensive. nections to see if user names and passwords
However, central RFC security monitoring func- are stored in the destination, if a trusted system
tionality can provide an overview of the security logon is used, which authorizations RFC users
status of the entire RFC integration landscape. have in target systems, and whether secure
network communication is used.
Functionality for monitoring RFC destination •• ABAP_INSTANCE_PAHI verifies required profile
settings is available through the configuration parameter settings.
validation functionality of SAP Solution Manager.76 •• GW_REGINFO and GW_SECINFO checks RFC
The monitoring function periodically collects gateway access control lists.
all RFC destination details of managed systems
through diagnostic agents. Relevant system An overview of the current security status can
profile parameters and access control lists are be provided in a security dashboard78 and alerts
also collected. Predefined RFC security templates on noncompliance can be collected in the alert
are available, which can be adjusted to customer in-box.79
needs. The data from managed systems is com-
pared against the template, and noncompliant
settings are identified and reported in dashboards.
33 / 38
Securing Remote Function Calls
Summary
Well-configured RFC access control is essential to Central monitoring tools provide customers with
maintain the security of business data in systems insight into the current RFC security status and
based on SAP NetWeaver AS for ABAP. SAP advises help keep required access controls in place over
all customers with these software systems to time.
determine whether the security recommendations
provided in this document have been implemented If you have questions concerning any material
in their software system landscapes and to take discussed in this document or would like to
action in cases where access controls are missing. request RFC security consulting, please use
the contact information provided in SAP Note
Several sections discuss the configuration for 1682316.80
logging RFC communication. These logs serve
as audit trails and should be activated at least
in all business-critical production systems. The
logging data is analyzed by tools, which simplifies
the work of maintaining access controls. The
earlier logging is activated, the better the data
quality for these tools. Some controls provide
simulation modes to test controls nondisruptively
before they are activated.
34 / 38
Securing Remote Function Calls
Appendix
1. SAP Help Portal site – Ports of SAP NetWeaver Application Server for ABAP
https://help.sap.com/saphelp_nw74/helpdata/en/4e/c26cdc58e968b9e10000000a42189e/frameset.htm
2. SAP Service Marketplace extranet – Connectors: Communication between SAP Systems and other SAP or non-SAP Systems
https://service.sap.com/connectors
3. SAP Community Network – Secure Configuration of SAP NetWeaver Application Server Using ABAP
https://scn.sap.com/docs/DOC-17149
4. SAP Service Marketplace – White papers providing security recommendations from SAP
https://service.sap.com/securitywp
5. SAP Help Portal – CTS User Administration and Authentication
https://help.sap.com/saphelp_nw74/helpdata/en/de/6b0d99f34d11d3a6510000e835363f/frameset.htm
6. SAP Note 1150764 – Where-used list for RFC destinations
https://service.sap.com/sap/support/notes/1150764
7. SAP Note 622464 – Change: Password change req. entry for “SYSTEM“ user type
https://service.sap.com/sap/support/notes/622464
8. SAP Help Portal – Authorization Object S_RFC_ADM
https://help.sap.com/saphelp_nw74/helpdata/en/48/8d1c05ae444e6ee10000000a421937/frameset.htm
9. SAP Help Portal – Maintaining Trust Relationships between SAP Systems
https://help.sap.com/saphelp_nw74/helpdata/en/48/956eb194cc73e9e10000000a42189b/frameset.htm
10. SAP Help Portal – Authorization Object S_RFC_TT
https://help.sap.com/saphelp_nw74/helpdata/en/48/8d1c39ae444e6ee10000000a421937/frameset.htm
11. SAP Note 1491645 – Unauthenticated system access via RFC or HTTP
https://service.sap.com/sap/support/notes/1491645
12. SAP Note 1498973 – Renewing trust relationships to a system
https://service.sap.com/sap/support/notes/1498973
13. SAP Note 1562697 – Authorization group for trust relationship
https://service.sap.com/sap/support/notes/1562697
14. SAP Help Portal – Authorization Object S_RFCACL
https://help.sap.com/saphelp_nw74/helpdata/en/48/8d1c6eae444e6ee10000000a421937/frameset.htm
15. SAP Note 128447 – Trusted/trusting systems
https://service.sap.com/sap/support/notes/128447
16. SAP Note 1416085 – PFCG: Authorization maintenance for object S_RFCACL
https://service.sap.com/sap/support/notes/1416085
17. SAP Help Portal – Configuring SNC: Using RFC from AS ABAP
https://help.sap.com/saphelp_nw74/helpdata/en/b2/cadb21ecd949d0a1ff84ff18e4032b/frameset.htm
18. SAP Knowledge Base Article 2057374 – Using SNC Client Encryption (SCE) for encrypting SAP GUI Connection
https://service.sap.com/sap/support/notes/2057374
19. SAP Help Portal – SAP NetWeaver Single Sign-On 2.0
https://help.sap.com/sso
20. SAP Note 1690662 – Option: Blocking unencrypted SAPGUI/RFC connections
https://service.sap.com/sap/support/notes/1690662
21. SAP Note 1485029 – Protect read access to key tables
https://service.sap.com/sap/support/notes/1485029
22. SAP Note 1497104 – Protect access to PSE files by additional AUTHORITY-CHECK
https://service.sap.com/sap/support/notes/1497104
23. SAP Note 931252 – Security Note: Authority Check for Function Group SRFC
https://service.sap.com/sap/support/notes/931252
24. SAP Note 1769064 – Additional values for auth/rfc_authority_check
https://service.sap.com/sap/support/notes/1769064
35 / 38
Securing Remote Function Calls
25. SAP Note 931251 – Security Note: Authority Check for Function Modules
https://service.sap.com/sap/support/notes/931251
26. SAP Note 1785761 – Missing authorization check in RFC
https://service.sap.com/sap/support/notes/1785761
27. SAP Community Network – Unified Connectivity (UCON)
https://scn.sap.com/docs/DOC-53844
28. SAP Help Portal – Unified Connectivity
https://help.sap.com/saphelp_nw74/helpdata/en/ab/35e1c69f744d69a4fcf4ca93284e0c/frameset.htm
29. SAP Community Network – SAP Insider: Secure Your System Communications with Unified Connectivity
https://scn.sap.com/docs/DOC-51003
30. SAP Note 1904562 – Unified Connectivity Logging Prerequisites
https://service.sap.com/sap/support/notes/1904562
31. SAP Community Network – UCON RFC Basic Scenario – Guide to Setup and Operations
https://scn.sap.com/docs/DOC-57565
32. SAP Help Portal – Creating an Authorization Concept for RFC
https://help.sap.com/saphelp_nw74/helpdata/en/48/8d1a3cae444e6ee10000000a421937/frameset.htm
33. SAP Note 1718059 – New functions for the trace evaluation
https://service.sap.com/sap/support/notes/1718059
34. SAP Note 1707841 – STAUTHTRACE: System-wide trace evaluation
https://service.sap.com/sap/support/notes/1707841
35. SAP Note 460089 – Minimum authorization profile for external RFC programs
https://service.sap.com/sap/support/notes/460089
36. SAP Note 1868691 – ALE: Creating authorizations for system users
https://service.sap.com/sap/support/notes/1868691
37. SAP Help Portal – From the Programmed Authorization Check to a Role
https://help.sap.com/saphelp_nw74/helpdata/en/fc/27cdec46fa4f77b8ac6b3d5169b72e/frameset.htm
38. SAP Note 1631929 – Using trace evaluation to maintain menus and authorizations
https://service.sap.com/sap/support/notes/1631929
39. SAP Note 1640733 – PFCG: Additional S_RFC authorization
https://service.sap.com/sap/support/notes/1640733
40. SAP Note 1854561 – Authorization trace with filter (auth/authorization_trace)
https://service.sap.com/sap/support/notes/1854561
41. SAP Note 543164 – Significance of auth/authorization_trace values
https://service.sap.com/sap/support/notes/543164
42. SAP Note 1847663 – STUSOBTRACE: Filter for authorization trace
https://service.sap.com/sap/support/notes/1847663
43. SAP Note 1964997 – ST: Enhancement of kernel statistics for RFC subrecords
https://service.sap.com/sap/support/notes/1964997
44. SAP Community Network – How to get RFC call traces to build authorizations for S_RFC for free!
https://scn.sap.com/community/security/blog/2010/12/05
/how-to-get-rfc-call-traces-to-build-authorizations-for-srfc-for-free
45. SAP Note 2080378 – STRFCTRACE
https://service.sap.com/sap/support/notes/2080378
46. SAP Note 1861370 – PFCG: Menu maintenance via authorization trace
https://service.sap.com/sap/support/notes/1861370
47. SAP Help Portal – Performing Authorization Checks Based on Scenarios
https://help.sap.com/saphelp_nw74/helpdata/en/a9/a721a34a4b4e2fa5c12947022c7d76/frameset.htm
48. SAP Note 539404 – FAQ: Answers to questions about the Security Audit Log
https://service.sap.com/sap/support/notes/539404
36 / 38
Securing Remote Function Calls
37 / 38
Securing Remote Function Calls
No part of this publication may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for
additional trademark information and notices. Some software products marketed by SAP SE and its
distributors contain proprietary software components of other software vendors.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only,
without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable for
errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company
products and services are those that are set forth in the express warranty statements accompanying such
products and services, if any. Nothing herein should be construed as constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business
outlined in this document or any related presentation, or to develop or release any functionality mentioned
therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy
and possible future developments, products, and/or platform directions and functionality are all subject
to change and may be changed by SAP SE or its affiliated companies at any time for any reason without
notice. The information in this document is not a commitment, promise, or legal obligation to deliver
any material, code, or functionality. All forward-looking statements are subject to various risks and
uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned
not to place undue reliance on these forward-looking statements, which speak only as of their dates, and
they should not be relied upon in making purchasing decisions.