Why RFC security matters
Remote Function Call is the SAP integration backbone. RFC carries traffic between ABAP systems, between SAP and non SAP endpoints, and between the gateway and external programs. Every RFC destination is a potential lateral movement path. Without disciplined RFC security the customer accumulates destinations with broad service users, trust relationships that bypass authentication, and gateway rules that permit any program to register.
This article documents the destination inventory, the trust relationship design, the secinfo and reginfo control, and the audit defensible RFC security posture. Reference the SAP security audit pillar, the basis security analysis, and the security hardening expertise.
Destination inventory
The destination inventory captures every RFC destination defined in transaction SM59. The inventory record names the destination, the target system, the service user, the authorization assigned to the service user, the business owner, and the last review date. The customer position is to maintain the inventory continuously rather than to discover destinations through external audit. Destinations without business owner are decommissioned through the quarterly review cycle.
Reference the user access review process, the privileged access analysis, and the basis security analysis.
Trust relationship design
Trust relationships allow one SAP system to call another without re authentication. The trust relationship rests on the calling user, the called user, and the authority check the called system applies. The customer position is to define trust relationships with explicit authority check on the called side, never to grant blanket trust between systems. The audit defensible posture documents each trust relationship with business purpose, calling user mapping, and authority check evidence.
Reference the authorization concepts analysis, the critical authorizations analysis, and the cybersecurity analysis.
Trust relationships without explicit authority check on the called side are the single most common lateral movement vector in compromised SAP landscapes. Explicit authority check at the destination closes the path without breaking the integration.
Gateway secinfo and reginfo
The gateway is the SAP component that handles RFC traffic from external programs. The secinfo file controls which programs may execute through the gateway. The reginfo file controls which programs may register with the gateway. Both files require explicit allow lists. The customer position is to operate both files with documented rules, the rules reviewed quarterly, and any deviation from the recommended baseline approved by the security owner.
The detail is in our license audit pillar (cross cluster reference for the named user implication of RFC service users), the basis security analysis, and the transport security analysis.
Audit defensible RFC posture
The audit defensible RFC security posture has four components. First, the destination inventory continuously maintained with business owner. Second, the trust relationship design with explicit authority check on the called side. Third, the gateway secinfo and reginfo allow lists with quarterly review. Fourth, the RFC service user discipline that scopes authorization to the integration purpose. The four components together survive external auditor walkthrough and SoX testing.
The implementation detail is in our security baseline analysis, the privileged access analysis, the cybersecurity analysis, and the compliance framework pillar. The security hardening expertise documents the full senior advisor methodology.
RFC posture that bounds lateral movement
- RFC destinations are potential lateral movement paths and require continuous inventory
- Destination inventory captures target, service user, authorization, business owner, review date
- Trust relationships use explicit authority check on the called side, never blanket trust
- Gateway secinfo and reginfo files use explicit allow lists with quarterly review
- RFC service users carry scoped authorization tied to the integration purpose only
- Audit defensible posture rests on inventory, trust design, gateway allow lists, scoped service users