Enterprise Security Architecture for SAP Landscapes: Complete Technical Guide

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

Executive Summary (≈150 words)

Enterprise SAP landscapes (S/4HANA, BW/4, ERP satellites, BTP, and SAP SaaS) are high-value control planes for finance, procurement, HR, and manufacturing execution—so the security architecture must assume targeted adversaries, not incidental noise. The most damaging breaches still originate from predictable weaknesses: over-privileged roles, unmanaged technical users, excessive RFC trust, exposed ICF/OData services, and lagging SAP Security Notes/kernel crypto updates.

A modern SAP security architecture should standardize on: (1) central identity with MFA and minimal local passwords, (2) least-privilege ABAP authorization engineering governed by SoD workflows, (3) hardened ingress and connectivity (WAF/Reverse Proxy → Web Dispatcher → ICM; tight reginfo/secinfo, Gateway allowlisting, minimal trusted RFC), (4) secure operations as a product—continuous patching, drift control, and supply-chain controls for transports, and (5) SAP-first detection engineering by forwarding ABAP/HANA/Web logs into SIEM with tested response playbooks.

Technical Foundation (≈450 words)

1) The SAP security model is multi-layer by design

SAP landscapes don’t fail “in one place.” They fail at boundaries—identity boundaries, client boundaries, trust relationships, transport paths, and integration endpoints. Your architecture must explicitly define control objectives per layer:

• Identity & Access Management (IAM): authentication (SAML/OIDC/Kerberos), MFA, lifecycle provisioning, privileged access management (PAM).
• Application security (ABAP-centric): PFCG roles, authorization objects, SU24 defaults, table auth groups, hardening of RFC/Gateway/ICF, and audit logging. SAP’s ABAP platform security guidance is foundational for hardening and audit baselines (SAP NetWeaver AS ABAP — Security).
• Database security (SAP HANA): users/roles, encryption, auditing, tenant isolation, backup protection—aligned to the official HANA security model (SAP HANA Platform — Security Guide).
• Network/transport security: TLS for HTTP(S), SNC for RFC/DIAG, SAProuter/Web Dispatcher patterns, and strict zoning.
• Operations security: SAP Security Notes cadence, kernel and crypto library currency, monitoring, and incident response. Use SAP’s Secure Operations guidance as the operational backbone (SAP Secure Operations Map) and formal Security Note handling (SAP Security Notes & News).

2) Trust boundaries that matter in real incidents

In most enterprises, these are the boundaries attackers exploit:

• Client scope (MANDT): many controls are client-dependent; security baselines must be client-aware (especially in shared systems).
• Technical users: interface/service/system users routinely outlive their original purpose and become persistent footholds.
• RFC trust: “trusted systems” can enable lateral movement if broadly granted.
• Gateway/OData exposure: standard APIs increase internet exposure; governance must be service-level, not system-level.
• CTS/transports: your “code supply chain” for ABAP changes—roles, RFC destinations, ICF services—must be controlled like source code promotion.

3) A reference security architecture mindset (reduce snowflakes)

A mature security posture comes from standardization:

• One ingress pattern (WAF/Proxy → Web Dispatcher → SAP ICM).
• One identity pattern (enterprise IdP + SAP Cloud Identity Services bridge where needed).
• One logging pattern (ABAP SAL + HANA audit + Web logs → SIEM).
• One change-control pattern (transport approvals + segregation + reconciliation).

For hybrid identity and SAP cloud integration, SAP Cloud Identity Services (IAS/IPS) is the common federation/provisioning bridge (SAP Cloud Identity Services — Documentation).

Implementation Deep Dive (≈950 words)

1) Identity, authentication, and session security

1.1 Browser SSO for Fiori (SAML 2.0) with step-up MFA

Goal: eliminate passwords for human users, enforce MFA centrally, and keep SAP user authorizations authoritative in ABAP.

Architecture

• Enterprise IdP (e.g., Entra ID) → SAML assertion → AS ABAP (Fiori Launchpad)
• Optional: IdP → IAS → ABAP when bridging to SAP SaaS/BTP (SAP Cloud Identity Services).

Implementation checklist (ABAP)

• Configure SAML trust (transaction typically SAML2) and maintain signing/encryption certificates in Trust Manager (STRUST).
• Map NameID/claims to SAP user (SU01) consistently (UPN vs. SAP user ID). Decide upfront:
  • Option A: SAP user = enterprise UPN (easier mapping, may require longer user IDs / naming rules)
  • Option B: SAP user = legacy (requires mapping table/logic; higher ops cost)

Hardening

• Restrict fallback password logon for privileged users; use break-glass only.
• Enforce secure session cookies and modern TLS at Web Dispatcher/ICM. Treat TLS as a platform control aligned to SAP’s platform guidance (SAP NetWeaver — Security).

1.2 SAP GUI SSO via SNC (Kerberos or X.509)

Goal: remove password-based SAP GUI logons and protect RFC/DIAG channels.

• Prefer Kerberos SNC in Windows-dominant enterprises.
• Use X.509 SNC for cross-platform or stricter certificate-based authentication.
• Standardize SNC parameters and ensure crypto libraries are current as part of your patch baseline (SAP operational guidance: SAP Secure Operations Map).

2) ABAP authorization engineering (least privilege that survives change)

2.1 Role model: job-based business roles + controlled admin roles

Pattern

• Business roles (job-based) → derived single roles → composite roles
• Separate technical/admin privileges into distinct roles with approvals

Non-negotiables

• No SAP_ALL/SAP_NEW for daily work. Only time-bound emergency access with monitoring.
• Isolate high-risk objects into admin-only roles: S_USER_*, S_RFC, S_SERVICE, S_TABU_DIS, transport/admin objects, and critical basis authorizations.

2.2 SU24-driven maintainability (stop “role copy chaos”)

Make SU24 corrections part of release engineering—not production firefighting.

Operating model

• Dev: adjust SU24 proposals when custom code introduces new auth checks.
• QA: validate role generation/regeneration impact.
• Prod: transport SU24 changes with approvals (treat as security-sensitive).

2.3 Code-level example: enforce authorization checks correctly

ABAP example for an application function that reads sensitive tables:

DATA: lv_auth TYPE c.

" Check business authorization object
AUTHORITY-CHECK OBJECT 'Z_FIN_REP'
  ID 'ACTVT' FIELD '03'
  ID 'BUKRS' FIELD p_bukrs.

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

" Table access should be protected by table authorization group design (S_TABU_DIS),
" not by hardcoding table names everywhere. Keep table groups documented.
SELECT * FROM zfin_sensitive INTO TABLE @DATA(lt_data)
  WHERE bukrs = @p_bukrs.

Architectural insight: the code check is necessary but not sufficient—pair it with:

• table authorization groups + S_TABU_DIS governance
• SoD controls (GRC/IAG) and periodic certifications
  For governance tooling patterns, align with SAP IAG documentation (SAP Identity Access Governance).

3) Interface and integration hardening (where most real risk lives)

3.1 RFC governance: kill implicit trust, allowlist explicitly

Rules

• Avoid broad trusted RFC relationships; prefer explicit technical users with minimal authorizations.
• Lock down program execution via S_RFC and start-authorization objects.
• Implement allowlisting controls and monitor RFC usage spikes.

reginfo/secinfo examples (conceptual baseline) Keep these as controlled artifacts (versioned, reviewed, transported where applicable):

secinfo (program start restrictions — illustrative)

P USER=*, HOST=internal-app-servers, USER-HOST=*, TP=/usr/sap/*, ACCESS=*
P USER=*, HOST=*, TP=*, ACCESS=DENY

reginfo (registered server programs — illustrative)

TP=Z_IDOC_GATEWAY, HOST=10.10.20.0/24, ACCESS=*
TP=*, HOST=*, ACCESS=DENY

Why this matters: attackers abuse overly permissive registrations to pivot from a compromised host into SAP via trusted channels.

3.2 UCON (Unified Connectivity) for ABAP RFC/function module exposure

Where supported, use UCON to restrict callable function modules and reduce “internal API sprawl.” Operationalize it like a firewall rulebase:

• start in logging-only mode
• build allowlists per calling system/user
• enforce and monitor blocks

Reference SAP ABAP platform documentation for connectivity/security controls (SAP NetWeaver AS ABAP — Documentation).

3.3 Gateway/OData: service allowlisting + strong AuthN + detection

Controls

• Activate only required services; review activation drift periodically.
• Disallow shared dialog users for API access; use named users or tightly scoped service identities.
• Enforce OAuth/token-based access where available for API consumers.

For BTP-centric API security and OAuth patterns, align with SAP BTP security guidance (SAP BTP — Security) and developer guidance for OAuth/XSUAA scenarios (SAP Developers — Secure Applications on BTP (XSUAA)Detection engineering (practical) Alert on:

• enumeration patterns (many services hit rapidly)
• high 401/403 rates (credential stuffing)
• new/rare endpoints for a user/service
• spikes in HTTP 500 (probing, deserialization attempts, backend stress)

4) Ingress architecture: WAF/Reverse Proxy → Web Dispatcher → ICM

4.1 Web Dispatcher baseline (example)

A hardened pattern:

• WAF terminates external TLS and inspects traffic
• Web Dispatcher performs SAP-aware routing and optionally re-encrypts to ICM
• ABAP ICM endpoints are never directly internet-facing

Example (illustrative) Web Dispatcher profile snippets:

# Listener (terminate TLS at Web Dispatcher if WAF passes-through)
icm/server_port_0 = PROT=HTTPS,PORT=443,TIMEOUT=600,PROCTIMEOUT=600

# Only forward to defined backends
wdisp/system_0 = SID=S4P, MSHOST=s4p-msg.internal, MSPORT=3601, \
                 SRCSRV=*, SSL_ENCRYPT=2

# Reduce information leakage
icm/HTTP/server_header = SAP

Use SAP Web Dispatcher guidance as your reference for supported parameters and secure deployment patterns (SAP Web Dispatcher — Documentation).

4.2 TLS and certificate lifecycle engineering (often neglected)

Advanced but pragmatic:

• Maintain a certificate inventory with owners, CN/SAN, expiration, and rotation runbooks.
• Automate renewal where possible (enterprise PKI/ACME gateway), but always validate SAP supportability and crypto library dependencies.
• Standardize protocol/cipher policy at the perimeter; keep SAP crypto libraries current via kernel/crypto updates.

5) Secure change & transport management (SAP’s code supply chain)

Treat CTS as a supply chain:

• Restrict who can import to production (basis-only, with approvals).
• Require peer review for security-sensitive objects:
  • roles/profiles (PFCG)
  • RFC destinations
  • ICF services activation
  • Gateway services
  • auth objects/SU24 changes
• Reconcile imports to change tickets (ITSM) and keep an evidence trail.

Segregation principle: never allow one person to (a) develop, (b) transport, and (c) self-assign privileges—this is where fraud and persistence appear.

6) Logging, SIEM integration, and response readiness

6.1 What to forward (minimum viable “SAP-first SOC”)

• ABAP Security Audit Log (SAL) (Security Audit Log — ABAP)
• HANA audit logs (SAP HANA Auditing)
• Web Dispatcher + ICM access/error/TLS logs
• Role/user change events, firefighter activations, transport/import logs

6.2 Detection content (examples)

Build SIEM rules for:

• brute force / password spray (if passwords remain)
• new privileged role assignment or profile generation
• RFC destination changes + immediate unusual RFC traffic
• new ICF/OData service activation
• emergency access activation outside change window

6.3 Incident response runbooks (SAP-specific containment)

Pre-approve actions that won’t break operations:

• disable a user vs locking technical RFC user (risk of integration outage)
• block specific OData services vs shutting down ICM entirely
• isolate app servers while preserving ASCS/ERS availability
• validate HANA backup integrity and restore readiness (ransomware resilience)

Advanced Scenarios (≈560 words)

1) Hybrid identity hub: IAS/IPS + enterprise IdP + on-prem ABAP

Problem: enterprises accumulate multiple identities (SAP user IDs, UPNs, email) and inconsistent lifecycle rules.

Advanced architecture pattern

• Enterprise IdP is the primary AuthN authority (MFA, conditional access).
• IAS acts as a federation hub for SAP SaaS/BTP and optionally for on-prem bridging.
• IPS/IGA provisions lifecycle changes into SAP targets with approvals and periodic recertification.

Key design decisions:

• Immutable identity key (employee ID or GUID) vs mutable identifiers (email/UPN).
• Mapping strategy per SAP system/client.
• Outage mode: define break-glass accounts when IdP/IAS is unavailable (stored in PAM, monitored, tested quarterly).

Reference: SAP Cloud Identity Services docs for federation/provisioning patterns (SAP Cloud Identity Services — Documentation).

2) “Zero Trust-aligned” admin access without breaking Basis operations

Common failure mode: admins have broad VPN reach into SAP zones, so a compromised endpoint becomes a launchpad.

Modern pattern

• ZTNA to admin jump hosts only (no network-wide access)
• Session recording for privileged actions (PAM)
• Strong device posture checks
• Separate admin identities (no email browsing on admin accounts)

Operational twist (often missed): define “break glass networking” to recover from IdP/PAM outages without permanently weakening controls.

3) Protecting SAP HANA beyond “roles and passwords”

Threat model: credential theft, misuse of powerful DB roles, backup theft, and persistence via audit tampering.

Implementation anchors

• Use HANA auditing with immutable forwarding to SIEM.
• Encrypt data at rest and protect backups (separate keys/roles; restricted backup operators).
• Separate schema ownership from runtime access patterns in native HANA development models.

Example: HANA auditing policy (illustrative SQL)

-- Enable auditing (conceptual; align to your HANA version and policy design)
CREATE AUDIT POLICY "SECURITY_CRITICAL"
  AUDITING ALL
  LEVEL INFO
  TRAIL SYSLOG;

ALTER AUDIT POLICY "SECURITY_CRITICAL" ENABLE;

Reference: HANA auditing and security controls (SAP HANA Platform — Security Guide).

4) Continuous controls monitoring (CCM) for SAP configuration drift

Novel but high-impact: treat critical SAP security settings as “desired state” and detect drift:

• ICM TLS parameters
• SAL configuration
• activated ICF services
• RFC trust relationships
• reginfo/secinfo content
• role changes and SU24 deltas

Implement drift detection by:

• scheduled exports + hashing + change tickets
• SIEM alerts on unexpected deltas
• forced review/approval workflow for security-sensitive parameter changes

This bridges the gap between “hardening once” and “staying hardened.”

Real-World Case Studies (≈360 words)

Case 1: Manufacturing — RFC sprawl and plant-to-corporate segmentation

Situation: ECC/S/4 core with MES/PLM and many plant interfaces. RFC trusts accumulated over a decade; shared technical users were common.

What worked

• Replaced trusted RFC with explicit technical users and minimal S_RFC.
• Introduced strict allowlisting (reginfo/secinfo) and phased UCON rollout in log-then-enforce mode.
• Segmented plant networks from corporate IT; only integration brokers could reach SAP app servers.
• Built SIEM detections around RFC destination changes + spikes in RFC calls.

Outcome: lateral movement paths collapsed; audit findings reduced; outages decreased because integration identities became explicit and managed.

Case 2: Utilities — SoD and firefighter as an engineered service

Situation: strong audit requirements; historically, “emergency access” became permanent admin.

What worked

• Implemented time-bound firefighter with mandatory ticket linkage and post-session review evidence.
• Enforced MFA at IdP for any privileged elevation.
• Automated periodic certifications for high-risk roles and technical users.
• Alerted on role generation and user master changes.

Outcome: audit evidence became repeatable; privileged access shrank; emergency access became measurable (KPIs: duration, frequency, violations).

Case 3: Pharma — validated change control meets SAP transport supply chain

Situation: GxP validation demanded strict separation of duties and traceable changes.

What worked

• Classified SAP objects into risk tiers; security-sensitive objects required dual approval.
• Transport imports to production were basis-only with reconciliation to validated change records.
• Drift monitoring ensured profile parameters and service activation remained consistent post-release.

Outcome: fewer validation deviations; faster audits; reduced “shadow changes” in production.

Strategic Recommendations (≈250 words)

1. Standardize a reference security architecture for all SAP systems: zones, ingress, identity flow, logging flow, and change-control. Snowflakes are the enemy of security at scale.

2. Make IAM the anchor:

• Central IdP + MFA for privileged and remote access
• Automated provisioning via IGA/IPS with approvals and deprovisioning SLAs
  Reference: SAP Cloud Identity Services and SAP Identity Access Governance.

3. Treat ABAP authorizations as engineering:

• SU24 lifecycle discipline
• elimination roadmap for SAP_ALL culture
• segregated admin roles + emergency access that is time-bound and monitored

4. Prioritize interface governance as your highest ROI risk reducer:

• remove broad trusted RFC
• lock down reginfo/secinfo and Gateway services
• enforce WAF/Proxy → Web Dispatcher → ICM with no direct exposure

5. Operationalize security:

• recurring SAP Security Notes and kernel/crypto cadence (SAP Security Notes & News)
• SIEM detections with tested runbooks
• ransomware resilience: immutable backups and restore drills for HANA and application tiers

Resources & Next Steps (≈150 words)

Official SAP documentation (start here)

• SAP Secure Operations Map
• SAP Security Notes & News
• SAP NetWeaver AS ABAP — Documentation
• SAP HANA Platform — Documentation
• SAP Web Dispatcher — Documentation
• SAP Cloud Identity Services — Documentation
• SAP BTP — Security
• SAP Developers — Secure Applications on BTP (XSUAA)### Next steps (practitioner action list)
• Publish a one-page reference architecture with zones, trust boundaries, and allowed flows.
• Build a 90-day plan: remove top trusted RFC links, inventory technical users, forward SAL/HANA audit to SIEM.
• Implement drift monitoring for ICF/Gateway activation, reginfo/secinfo, and role changes.