Enterprise Security Architecture for SAP Landscapes: Complete Technical Guide

Sarah Chen, Lead SAP Architect — SAPExpert.AI Weekly Deep Research Series

Executive Summary (≈150 words)

SAP landscapes concentrate an organization’s highest-value data and most powerful business actions behind a uniquely complex blend of protocols (RFC, ICM/HTTP, OData), authorization models (ABAP auth objects, CDS/DCL, HANA privileges), and operational pathways (transports, background processing, technical users). Modern “good” security is no longer a single control; it is an architecture: identity-centric access (SAML/OIDC + MFA), least-privilege authorizations (especially RFC/service users), single controlled ingress for web workloads, strong cryptographic posture (TLS everywhere; SNC where feasible), and evidence-ready operations (Security Notes SLAs, configuration drift detection, and SOC-grade logging).

This guide provides an enterprise reference architecture with trust boundaries, detailed implementation patterns (SSO, RFC hardening, Fiori/Gateway exposure, PAM, change control), and advanced techniques often missed: bypass-path elimination, correlation-ID telemetry, transport-level security scanning, and continuous compliance baselines for ABAP/HANA/BTP. It closes with implementation checklists, a pragmatic roadmap, and a curated set of official SAP documentation links.

Technical Foundation (≈400–500 words)

1) Security domains and why SAP is different

An enterprise SAP security architecture must treat the landscape as multiple security domains with explicit trust boundaries:

• Identity & Access: human and non-human identities; federation; lifecycle; privileged access.
• Application: ABAP/Java runtime hardening, ICF services, Gateway/OData, RFC authorizations.
• Database: SAP HANA roles/privileges, encryption, audit, tenant isolation.
• Network/Perimeter: segmentation, DMZ ingress, east-west restrictions, admin access paths.
• Integration: RFC, IDoc, HTTP APIs, middleware (PI/PO, CPI), eventing, partners.
• Operations/Governance: patching (Security Notes), logging/monitoring, SoD, change control.

SAP’s risk profile is amplified by:

• High-impact technical users (RFC/batch/service) that can quietly become “super users”.
• Protocol richness (RFC + HTTP + native DB) that creates bypass paths if not governed.
• Authorization sprawl (PFCG roles + Fiori catalogs + CDS/DCL + HANA grants).
• Implicit trust inside the landscape (e.g., “it’s internal so it’s safe”)—often false in modern threat models.

A practical rule: every time you add a new access method (Fiori, RFC, OData, direct HANA SQL, third-party connector), you must answer two questions:

1. What is the single authentication control plane for this method (IdP, SNC/Kerberos, OAuth, X.509)?
2. How do you guarantee there is no bypass path that avoids that control plane?

2) Identity, authentication, authorization (SAP framing)

• Identity is a principal (ABAP user in SU01, IAS user, technical client/service principal).
• Authentication proves identity (SAML 2.0, Kerberos/SNC, X.509, OAuth2/OIDC).
• Authorization determines “what can be done”:
  • ABAP: authorization objects + roles (PFCG), enforced via AUTHORITY-CHECK.
  • Fiori: spaces/pages/catalogs (UI exposure) + OData service authorization + backend auth.
  • HANA: system/object/analytic privileges, roles, and SQL grants; ABAP CDS/DCL adds data-level rules.

Two architecture clarifications that prevent many real incidents:

• A Fiori catalog is not authorization. It is UI exposure. Backend authorization objects and OData/ICF authorizations still decide what happens.
• “Can call RFC” is often equivalent to “can run code” in the target system. Treat S_RFC like a privileged permission, not a normal integration detail.

For SAP NetWeaver AS ABAP SSO and federation patterns, baseline your approach on SAP’s SAML 2.0 and AS ABAP security documentation (for example, start from the AS ABAP security topics at https://help.sap.com/docs/SAP_NETWEAVER_AS_ABAP) and the SAP Security Notes area (https://support.sap.com/en/my-support/knowledge-base/security-notes-news.html) for patch governance.

3) Reference architecture: zones and trust boundaries

A secure SAP enterprise topology typically enforces:

• Internet → DMZ: WAF / Reverse proxy / SAP Web Dispatcher
• DMZ → App zone: Fiori front-end (if separate), ABAP app servers, central services
• App zone → DB zone: SAP HANA (no direct internet reachability)
• Mgmt zone: jump hosts, admin tools, backup, monitoring, CI/CD runners

A simplified zoning sketch (conceptual):

• Users/Partners (Internet)
  • HTTPS 443
• DMZ
  • WAF / Reverse Proxy
  • SAP Web Dispatcher (inbound 443; outbound to internal HTTPS only)
• App Zone
  • Fiori Front-End / Gateway (HTTPS only; no direct internet)
  • ABAP Backends (RFC/SNC from trusted sources; HTTPS from Gateway/WDisp only)
• DB Zone
  • SAP HANA (SQL only from App Zone; admin only from Mgmt Zone)
• Mgmt Zone
  • Jump host / PAM
  • Monitoring (Focused Run/SolMan/SIEM collectors)
  • Backup infrastructure

Concrete “default deny” network stance (commonly applicable):

• Block direct access from user networks to:
  • ABAP ICM ports like 44300/8443 (only Web Dispatcher/reverse proxy allowed)
  • SAP Gateway ports 33xx from non-approved integration networks
  • Message server ports 36xx from non-SAP hosts
  • HANA SQL 3xx15 from anything except app servers and admin jump hosts
• Allow administrative protocols (SSH/RDP/WinRM) only from jump hosts, never from end-user networks.

Implementation Deep Dive (≈800–1000 words)

1) Identity & SSO: make the IdP the control plane (and eliminate bypass paths)

Web SSO (Fiori, ICF apps, BTP apps)

Target state

• Corporate IdP (e.g., Entra ID / Okta) issues SAML 2.0 assertions for ABAP/Fiori endpoints.
• Enforce MFA + conditional access at the IdP (device compliance, location, risk, client app constraints).
• Disable or tightly restrict local password authentication for internet-facing flows where feasible.

Step-by-step: SAML 2.0 for AS ABAP (Fiori / ICF)

1. Baseline prerequisites

   • Ensure system time is correct (NTP). SAML is time-sensitive.
   • Confirm HTTPS is in place end-to-end (browser → proxy/WDisp → ABAP).

   • Ensure a stable external URL for the service provider (SP), e.g.:

2. Create/verify HTTPS on ABAP (ICM)

   • Transaction: STRUST
     • Create/maintain SSL server PSE (commonly: SSL Server Standard)
     • Import the full certificate chain (server cert + intermediates)
   • Profile parameters (typical examples; validate with your Basis team and SAP guidance):
     • icm/server_port_1 = PROT=HTTPS,PORT=44300,PROCTIMEOUT=600,TIMEOUT=600
     • ssl/client_ciphersuites = 150:PFS:HIGH::EC_P256:EC_HIGH
     • ssl/server_ciphersuites = 150:PFS:HIGH::EC_P256:EC_HIGH
     • ssl/min_protocol = TLSv1.2
   • Operational check:
     • Transaction SMICM → Services (confirm HTTPS active)
     • Validate using openssl s_client from a network vantage point that matches real clients.

3. Configure SAML 2.0

   • Transaction: SAML2 (opens in browser)
   • Local Provider:
     • Set Local Provider Name to a stable identifier (e.g., S4H_PRD_FIORI)
     • Set Supported NameID Formats aligned with the IdP (often emailAddress or unspecified)
     • Set Assertion Consumer Service (ACS) to the externally reachable endpoint behind your proxy/WDisp
   • Trusted Providers:
     • Import IdP metadata XML (from Entra/Okta)
     • Verify IdP signing certificate and validity dates
   • User Mapping
     • Decide your canonical mapping attribute. Common patterns:
       • IdP userPrincipalName → ABAP SU01 user (Logon ID)
       • IdP mail → ABAP user (only if unique and stable)
     • In SAML2, set mapping so that the correct attribute becomes the ABAP user name, or map to an alias and use a mapping table if needed.

4. Activate SAML authentication for ICF

   • Transaction: SICF
     • For Fiori Launchpad, typical service paths include:
       • /sap/bc/ui5_ui5
       • /sap/bc/ui2/flp
       • /sap/opu/odata (Gateway)
     • Ensure only required services are active.
   • Transaction: RZ10/profile maintenance
     • Many systems enforce logon procedures via ICF settings and SSO configuration; confirm the authentication method selection and avoid mixed insecure fallbacks.

5. Enforce MFA at IdP

   • IdP conditional access examples (conceptual):
     • Require MFA for all cloud apps “SAP Fiori PRD”
     • Block legacy authentication
     • Require compliant device for privileged roles (Basis/Security)

Critical architecture requirement: block bypass paths

If you front Fiori with Web Dispatcher/reverse proxy, ensure users cannot bypass it by hitting:

• backend ICM directly (:44300, :8443)
• message server / direct app server hostnames
• internal Gateway hostnames from semi-trusted networks (e.g., VPN split-tunnel)

Implement this with:

• Firewall rules / security groups
  • Only the Web Dispatcher IP(s) can reach 44300 (or your HTTPS port) on ABAP app servers.
  • Only internal admin networks can reach 32xx/33xx/36xx (SAP GUI/RFC/message server) as required.
• DNS split-horizon
  • External DNS: fiori.company.com → WAF/WDisp
  • Internal DNS: either same (preferred, to force consistent controls) or separate names that still route via the same ingress controls.
• ICM hardening
  • Avoid exposing alternate ICM ports.
  • Restrict and audit ICF services: if it’s not required, deactivate it in SICF.

SAP GUI SSO (Kerberos + SNC)

For SAP GUI, Kerberos-based SSO is often the best balance of user experience and security—if you enforce:

• SNC required for GUI/RFC (no “fallback to plain”)
• hardened policies for password fallback (break-glass only)
• admin access routed through PAM/jump hosts with step-up controls

Step-by-step: enable SNC for SAP GUI logon (high-level)

1. Deploy SAP Cryptographic Library

   • Install SAP CryptoLib on ABAP application servers.
   • Maintain environment variables / instance profile references as required by your OS and SAP kernel level.

2. Set key profile parameters (examples)

   • snc/enable = 1
   • snc/identity/as = p:CN=SAPPRD, OU=SAP, O=Company, C=US (example PSE subject; align to your SNC name)
   • snc/gssapi_lib = $(DIR_EXECUTABLE)/sapcrypto.dll (Windows example) or libsapcrypto.so (Linux)
   • snc/accept_insecure_gui = 0 (prevent downgrade to unsecured GUI where supported)
   • snc/data_protection/min = 3 (integrity+privacy; validate allowed values in your release)
   • snc/data_protection/max = 3

3. Maintain SNC names

   • Transaction SU01 for users:
     • Maintain SNC name for users to allow Kerberos mapping, e.g. p:CN=jdoe@COMPANY.COM
   • Transaction SNCWIZARD (if available) can simplify parts of the configuration.

4. Client-side SAP GUI settings

   • SAP Logon → Connection properties:
     • Enable SNC
     • Set SNC name of server
     • Set “SNC QoP” to highest required

5. Control password fallback

   • Keep emergency accounts, but:
     • restrict to PAM-controlled workflows
     • enforce MFA at PAM
     • time-bound and ticket-bound activation
     • log and review every use

2) ABAP authorization architecture: engineer roles like software

Role design rules that scale

• Decompose by business process (O2C, P2P, R2R) and separate display vs. change.
• Use composite roles to assemble job functions; keep single roles small and testable.
• Enforce strict control of “basis-of-trust” objects:
  • S_USER_* (identity administration)
  • S_RFC (remote execution capability)
  • S_TABU_* / S_TABU_NAM (table access)
  • S_DEVELOP, S_TRANSPRT (change and transport)
  • S_ICF (ICF node authorization)
  • S_SERVICE (service authorization in relevant stacks/use cases)
• Treat SU24 proposals as inputs, not truth. Curate them and version-control role changes.

Concrete procedure: role build and regression testing loop

1. Discover required authorizations
   • Use STAUTHTRACE (recommended for modern systems) or ST01 during a test execution.
   • Capture failed checks and build a minimal authorization set.
2. Build single role
   • PFCG → create role Z_<PROCESS>_<ACTIVITY> (e.g., Z_P2P_AP_INV_DISPLAY)
   • Maintain menus only if needed; avoid stuffing roles with unrelated transactions.
3. Generate authorization profile
   • In PFCG Authorization tab:
     • Start with proposals
     • Remove broad objects or wildcard values
4. Run negative tests
   • Confirm that restricted actions fail (e.g., change vs display).
5. Transport and document
   • Ensure roles are transported using controlled routes (STMS) and reviewed like code.

ABAP code example: enforce authorization deliberately

Even in well-designed role models, custom code becomes a backdoor if checks are missing.

DATA: lv_bukrs TYPE bukrs.
lv_bukrs = '1000'.

AUTHORITY-CHECK OBJECT 'F_BKPF_BUK'
  ID 'BUKRS' FIELD lv_bukrs
  ID 'ACTVT' FIELD '03'. "Display

IF sy-subrc <> 0.
  MESSAGE e398(00) WITH 'Not authorized for company code' lv_bukrs.
ENDIF.

For list/reporting scenarios, prefer CDS + DCL so that filtering happens at the data layer. A common anti-pattern is “select everything then filter in UI”—which leaks data through logs, caches, or debug.

Data-layer control example (conceptual DCL)

• Use ABAP CDS Access Control (DCL) to restrict rows by organizational assignments.
• Ensure the same logic applies to OData services and analytical queries.

(Implementation details depend on your data model and release; baseline from ABAP CDS and access control documentation at https://help.sap.com/docs/abap-cloud/abap-data-models/abap-cds.)

3) RFC hardening: treat RFC as a lateral movement highway

Minimum viable “secure RFC” pattern

• One technical RFC user per interface per target (not shared across flows).
• User type: prefer Communication / System as appropriate; disallow interactive logon.
• SNC for RFC wherever feasible (especially cross-network or partner-connected paths).
• Tight S_RFC:
  • avoid broad wildcards by function group
  • allow only specific function modules required
• Monitor and control destination changes (SM59) and authorization drift.

Step-by-step: build a hardened RFC integration

1. Create dedicated technical user

   • Transaction: SU01
   • User type:
     • System user for background/RFC scenarios (commonly used)
     • Communication user where applicable
   • Hardening checklist:
     • “User cannot change password” only if your credential vault manages rotation; otherwise enforce rotation.
     • Restrict validity dates (time-bound) where feasible.
     • Assign only one or two roles, purpose-built for the interface.

2. Create a minimal PFCG role for the RFC user

   • Transaction: PFCG
   • Essential permissions (examples; actual required objects depend on interface):
     • S_RFC with explicit function groups / function modules only
     • S_RFCACL to control who can call via RFC in some scenarios (where used)
     • Application objects (e.g., V_VBAK_AAT, F_BKPF_BUK) as needed, minimized
   • Avoid:
     • SAP_ALL, SAP_NEW
     • broad table access (S_TABU_DIS with DICBERCLS=*)

3. Define RFC destination securely

   • Transaction: SM59
   • Use the correct destination type (3, H, etc.)
   • If using SNC:
     • Maintain “SNC Active”
     • Maintain partner SNC name
     • Choose QoP matching your policy (integrity/privacy)
   • Store secrets securely:
     • Prefer vault integration; if not available, at minimum restrict SM59 access and monitor changes.

4. Enable gateway access control (secinfo/reginfo)

   • Files:
     • secinfo controls which external programs can register/call back
     • reginfo controls program registration
   • Profile parameters (examples; verify exact names/behavior for your release):
     • gw/sec_info = $(DIR_DATA)/secinfo
     • gw/reg_info = $(DIR_DATA)/reginfo
     • gw/acl_mode = 1 (enforce ACL)
   • Example secinfo entries (illustrative; tailor to your landscape):
     • Allow only specific hosts/users to start specific programs
     • Default deny for unknown programs/hosts

5. Adopt RFC allowlisting controls where available

   • Use Unified Connectivity / RFC allowlist concepts (e.g., UCON framework where applicable):
     • Maintain allowlists for RFC function modules
     • Monitor blocked calls and approve only justified ones
   • Treat this like firewall policy: explicit allow, default deny.

6. Detect changes and abuse

   • Log and alert on:
     • SM59 destination changes
     • role changes affecting RFC users
     • new RFC users
     • high-risk S_RFC expansions (wildcards)

Monitoring tip: catch “quiet privilege creep” early

• Schedule periodic reviews:
  • list technical users with last logon / last RFC usage
  • compare role content against a baseline (drift detection)
• If you have SolMan/Focused Run:
  • use configuration validation and Security Notes compliance to enforce baselines.

4) Fiori / Gateway exposure: reduce attack surface and make authorization observable

Concrete hardening steps (FES/Gateway)

1. Activate only required ICF services

   • Transaction: SICF
   • Deactivate unused services aggressively, especially:
     • unused BSP applications
     • legacy admin endpoints not required
   • Track every activated node with:
     • change request
     • owner
     • business justification
     • test evidence

2. Control OData services centrally

   • Transaction: /IWFND/MAINT_SERVICE
     • Activate only required services
     • Remove/disable unused ones
     • Validate system alias mapping (avoid accidental routing to unintended backends)
   • Logging:
     • /IWFND/ERROR_LOG for runtime errors
     • /IWFND/APPS_LOG (if used in your release) for app-specific logs
     • Turn on Gateway error visibility for SOC workflows

3. Enforce CSRF protections

   • Ensure state-changing OData calls require CSRF tokens.
   • Test with a security scanner or manual replay to confirm tokens are enforced for POST/PUT/PATCH/DELETE.

4. Make service authorization explicit

   • Validate that access to ICF nodes is protected by S_ICF (and related objects depending on your architecture).
   • Ensure business authorizations are enforced in backend objects and CDS/DCL, not only by frontend catalogs.

Web Dispatcher: enforce single ingress

Use SAP Web Dispatcher as the controlled entry point for SAP HTTP workloads.

1. Bind Web Dispatcher to DMZ and enforce TLS

   • Only allow inbound 443 from the internet/WAF.
   • Only allow outbound from WDisp to internal FES/Gateway HTTPS ports.

2. Example Web Dispatcher parameters (illustrative)

   • In the Web Dispatcher profile:
     • icm/server_port_0 = PROT=HTTPS,PORT=443
     • ssl/min_protocol = TLSv1.2
     • wdisp/add_client_protocol_header = true (helps apps know original protocol)
     • wdisp/ssl_encrypt = 1 (re-encrypt to backend, not TLS termination only)
   • Set strong cipher suites aligned to your enterprise TLS policy (and validate with your SAP kernel capabilities).

3. Route policy

   • Avoid direct routing to multiple backend systems unless needed.
   • Use explicit backend definitions and remove “catch-all” rules.

5) SAP HANA database security: least privilege, encryption, and audit you can use

Database access model

• Application servers should connect using a technical schema/user with minimal privileges.
• Human DB admin access should be:
  • via named users
  • via PAM/jump host
  • with MFA and session recording where possible
• Avoid shared use of SYSTEM user for operations; lock down and rotate credentials if it must exist for break-glass.

Concrete controls

1. TLS for SQL connections

   • Enable encrypted client/server communication (exact steps depend on HANA version and deployment).
   • Maintain certificates in HANA’s system PKI and rotate per policy.

2. Encryption at rest

   • Ensure data and log volume encryption is enabled (especially on cloud/IaaS).
   • Verify key management model:
     • internal HANA secure store vs external KMS (where supported in your hyperscaler design)

3. HANA auditing (actionable setup)

   • Create an audit policy that captures:

     • user and role administration
     • privilege grants/revokes
     • failed logons
     • changes to audit configuration

   • Example SQL (illustrative; adjust for your needs and syntax support):

     CREATE AUDIT POLICY AUDIT_SECURITY_ADMIN AUDITING ALL FOR CREATE USER, DROP USER, ALTER USER, CREATE ROLE, DROP ROLE, GRANT, REVOKE, ALTER SYSTEM LEVEL INFO TRAIL SYSLOG;

   • Forward audit events to SIEM (syslog agent or HANA-supported target) and validate parsing.

4. HANA least privilege

   • Avoid granting broad system privileges like USER ADMIN, ROLE ADMIN, CATALOG READ unless required.
   • Prefer task-specific admin roles and time-bound elevation using PAM workflows.

6) Operations and governance: make security continuous (not quarterly)

Security Notes and patch SLAs

A workable enterprise policy:

• Hot News: implement or mitigate within 72 hours (or per risk acceptance)
• High: within 7–14 days
• Medium: within 30 days
• Low: within 90 days

Execution pattern:

1. Weekly: review new SAP Security Notes (Basis + Security)
2. Triage: applicability per system (ECC/S4, BW, Gateway, Web Dispatcher, HANA)
3. Implement in DEV, regression test, transport to QA/PRD
4. Evidence: retain implementation logs, test results, and change approvals

If using SAP Solution Manager / Focused Run:

• Use System Recommendations and Configuration Validation to detect missing notes and drift.

Logging & monitoring (SOC-grade)

1. ABAP Security Audit Log

   • Transactions: SM19 (config), SM20 (analysis)
   • Log events to include:
     • user logons/logoffs (success and failure)
     • RFC logons
     • role/profile changes
     • user master changes
     • transaction starts for critical T-codes (e.g., SU01, PFCG, SE38, SM59, RZ10, STMS)
   • Forwarding:
     • Export or collect logs to SIEM via agent or connectors.
   • Retention:
     • Align with your compliance requirements (often 90 days hot + 1 year archive, depending on policy).

2. ICM / Web Dispatcher access logs

   • Enable and retain HTTP access logs with enough detail to investigate:
     • source IP (taking X-Forwarded-For into account)
     • URL path (ICF service)
     • response codes
     • request IDs if present

3. HANA audit logs

   • Forward to SIEM and create detection rules:
     • repeated failed logons
     • privilege escalation
     • creation of new high-privilege users/roles

Correlation ID telemetry (often missed, high value)

Goal: trace a user action from WAF → Web Dispatcher → ABAP ICM → Gateway → Backend → HANA (where feasible).

Practical approach:

• Ensure the reverse proxy injects a header such as X-Request-ID.
• In ABAP ICF handlers (custom services), capture and log it.

Example ABAP snippet (conceptual, for ICF-based handlers):

DATA(lv_reqid) = server->request->get_header_field( name = 'X-Request-ID' ).
IF lv_reqid IS NOT INITIAL.
  "Persist in application log (SLG1) or custom log table
ENDIF.

Even if you cannot propagate into every layer, having a stable request ID at the HTTP edge and in ABAP application logs drastically reduces incident response time.

Case Studies (practical patterns seen in the field)

Case 1: “Fiori is secured, but backend is wide open”

Symptoms

• SAML + MFA works on “
• Attackers later access “ directly from VPN or compromised host
• Bypass of WAF rules, no conditional access, weaker authentication path

Fix pattern

• Firewall: allow 44300 only from Web Dispatcher/reverse proxy IPs
• DNS: ensure internal users also resolve fiori.company.com to the controlled ingress
• Disable/deactivate unused ICF services
• Validate with a “bypass test”: attempt direct access from multiple networks and confirm it fails

Case 2: “RFC technical user becomes an invisible superuser”

Symptoms

• One shared RFC user used by many interfaces
• Role gradually accumulates broad S_RFC and table access “to fix issues”
• Eventually used for lateral movement and data extraction

Fix pattern

• Split into one user per interface
• Apply allowlisted S_RFC values (no wildcards)
• Enable gateway ACL (secinfo/reginfo) and UCON controls where applicable
• Monitor role changes and alert on expansions

Case 3: “HANA audit exists, but no one watches it”

Symptoms

• Audit configured, but logs not forwarded
• Privilege escalation occurs without detection

Fix pattern

• Forward HANA audit to SIEM
• Add detection content:
  • GRANT on high-impact privileges
  • new user creation
  • changes to audit configuration
• Run quarterly tabletop exercises to validate that alerts produce real investigations

Pragmatic Roadmap (90 days to durable architecture)

Phase 1 (Weeks 1–3): Stop the bleeding

• Enforce single ingress for HTTP (WAF/WDisp) and block bypass paths
• Turn on ABAP Security Audit Log and forward to SIEM
• Inventory technical users; remove/disable unused; rotate credentials
• Implement Security Notes SLA process (even if manual)

Phase 2 (Weeks 4–8): Standardize identity and integrations

• Implement SAML SSO for Fiori with MFA and conditional access
• Implement SNC/Kerberos for SAP GUI where feasible
• Harden RFC:
  • per-interface users
  • minimal roles
  • gateway ACL
  • monitoring on SM59 and role changes

Phase 3 (Weeks 9–12): Continuous compliance

• Configuration baselines (ABAP profile params, ICF activation list, HANA audit/encryption settings)
• Drift detection via Focused Run/SolMan or scripted checks
• Correlation IDs and incident response playbooks
• Regular access reviews (especially for Basis/security and technical users)

Curated Official Reference Starting Points (SAP)

• SAP Security Notes & News: https://support.sap.com/en/my-support/knowledge-base/security-notes-news.html
• SAP NetWeaver AS ABAP Security / Identity topics: https://help.sap.com/docs/SAP_NETWEAVER_AS_ABAP
• SAP NetWeaver (incl. Web Dispatcher) documentation collection: https://help.sap.com/docs/SAP_NETWEAVER
• ABAP CDS and Access Control concepts: https://help.sap.com/docs/abap-cloud/abap-data-models/abap-cds

Implementation Checklists (quick verification)

Bypass-path elimination (HTTP)

• External and internal users both reach SAP via WAF/WDisp URL
• Firewalls block direct access to ABAP ICM HTTPS ports from user networks
• Only required ICF services active (SICF controlled list)
• Web Dispatcher re-encrypts to backend; TLS 1.2+ enforced

RFC hardening

• One RFC user per interface
• S_RFC allowlisted (no broad wildcards)
• Gateway ACL (secinfo/reginfo) enforced
• SM59 changes monitored and reviewed

Logging and audit

• ABAP Security Audit Log configured for admin + auth events
• Web Dispatcher/ICM access logs retained and searchable
• HANA audit enabled and forwarded to SIEM
• Detection rules exist for privilege escalation and config changes

Patch governance

• Security Notes SLAs defined and met
• Evidence retained (change tickets, tests, implementation logs)
• Quarterly review of exceptions and risk acceptances

---

References

• https://help.sap.com/docs/SAP_NETWEAVER_AS_ABAP
• https://help.sap.com/docs/SAP_NETWEAVER
• https://help.sap.com/docs/abap-cloud/abap-data-models/abap-cds
• https://help.sap.com/docs/SAP_HANA_PLATFORM/sap-hana-security-guide/sap-hana-security-guide
• https://help.sap.com/docs/SAP_HANA_PLATFORM/sap-hana-security-guide/auditing-in-the-sap-hana-database