Enterprise Security Architecture for SAP Landscapes: Complete Technical Guide

Executive Summary (150 words)

Enterprise SAP security is no longer “ABAP authorizations + a firewall.” Modern landscapes (S/4HANA 2022/2023, HANA 2.0 SPS06+, SAP BTP, hybrid integrations) demand an end-to-end architecture that treats identity as the perimeter, enforces least privilege across humans and interfaces, and operationalizes continuous monitoring + patching.

Key findings:

• The highest-risk attack paths are consistently interfaces (RFC/HTTP/OData), overprivileged technical users, and identity propagation gaps across cloud ↔ on‑prem.
• Security posture improves fastest when you standardize federated authentication (SAML/OIDC), industrialize role engineering (PFCG + SoD), and implement integration guardrails (UCON, mTLS/SNC, API gateway patterns).
• “Zero Trust for SAP” is practical: eliminate implicit trust (network location, trusted RFC), require explicit verification (MFA, device posture), and use short-lived credentials/tokens where feasible.

This guide provides a blueprint, configuration specifics, and implementation patterns with production-grade examples.

Technical Foundation (400–500 words)

1) Layered SAP security architecture (reference model)

A robust enterprise SAP security architecture spans five layers:

1. Identity & Access Layer

   • Central IdP (e.g., Microsoft Entra ID/Okta) and/or SAP Cloud Identity Services – Identity Authentication (IAS) for SAML/OIDC federation and MFA
   • Provisioning via Identity Provisioning (IPS) or enterprise IAM toolchain
   • Access governance via SAP GRC Access Control or SAP Identity Access Governance (IAG)
   • Privileged Access Management (PAM) + emergency access (“firefighter”)

2. Application Security Layer

   • ABAP authorization design (PFCG roles, derived roles, SU24-driven proposals)
   • Secure ICF/OData exposure, strong auth, CSRF protections, hardened configurations
   • Secure development lifecycle (ATC, CVA, transport controls)

3. Integration Security Layer

   • Governed RFC (no unmanaged trusted RFC; strict S_RFC*; UCON allowlisting)
   • API-first security (OAuth2 scopes/claims, gateway throttling, consistent logging)
   • Certificate/secrets lifecycle management

4. Data Security Layer

   • HANA encryption, auditing, key management, secure backups
   • Privacy controls, masking/tokenization where required

5. Operations & Monitoring Layer

   • Patch governance (Security Notes SLAs, HotNews fast-track)
   • Central logging to SIEM (ABAP Security Audit Log, ICM/Web Dispatcher, HANA audit)
   • Incident response runbooks that explicitly cover SAP components

SAP’s official security guides should anchor your control baseline, including:

• SAP NetWeaver AS ABAP Security Guide
• SAP HANA Security Guide
• SAP S/4HANA Security Guide
• SAP Web Dispatcher (Security/Configuration)
• SAP Cloud Identity Services (IAS/IPS) Documentation
• SAP BTP Security

2) SAP-specific primitives you must design around

• ABAP authorization enforcement is runtime RBAC (auth objects + AUTHORITY-CHECK), not policy-based IAM. Your enterprise IAM must integrate without bypassing ABAP controls.
• RFC is powerful and dangerous: broad authorizations + stored credentials + trust relationships often create lateral movement paths.
• Fiori/UI roles are not authorizations: catalogs/spaces/pages drive UX; back-end roles drive permission. Mixing them causes role explosion and audit confusion.
• Audit completeness is non-trivial: SAP logs are high-signal but fragmented; centralization and normalization are architectural requirements, not “SOC nice-to-have.”

Implementation Deep Dive (800–1000 words)

1) Identity & authentication: standardize, then harden

Target state

• Browser access (Fiori, WebGUI, BSP): SAML 2.0 to a central IdP/IAS
• API access: OAuth 2.0 / OIDC with short-lived tokens and scoped access
• SAP GUI & RFC: SNC (Kerberos/SPNEGO) and/or X.509 where feasible
• MFA: required for privileged operations and remote access; conditional access for device posture and risky sign-ins

SAP references:

• AS ABAP Authentication and Single Sign-On (Security Guide)
• SAP Cloud Identity Services – IAS (SAML/OIDC concepts)

Canonical identity mapping (hybrid “gotcha”)

Pick one canonical identifier and enforce it everywhere:

• Human: immutable person_id (HR-driven), plus UPN/email as login alias
• Technical: non-human naming standard + owner + rotation policy

Implementation rule: your SAML NameID / OIDC sub must map deterministically to ABAP user (SU01) and BTP identity. Avoid “email-only” mapping unless you control email immutability.

ABAP user mapping pattern

• Maintain SU01 user with logon alias (where used)
• Map SAML assertion attribute (e.g., upn) to ABAP username mapping rule in SAML2 configuration (transaction SAML2)

Operational check: test mapping failures as a monitored event (authentication succeeds at IdP but fails in ABAP → creates helpdesk noise and shadow access).

2) ABAP authorization engineering: build a role factory, not artisanal roles

Role methodology (S/4HANA 2022/2023 recommended baseline)

• Business roles (job-based): stable, auditable
• Derived roles: org-level restrictions (company code, plant, sales org) with inherited menus/auth
• Composite roles: bundling only (avoid “megacomposites” without ownership)

Key ABAP mechanisms:

• SU24 proposals drive authorization objects required by transactions/services
• Tracing (STAUTHTRACE, SU53) refines least privilege

SAP references:

• Authorization Concept (AS ABAP Security Guide)
• SAP Identity Access Governance (access request + approvals)

High-risk authorizations to aggressively control

Treat these as “restricted entitlements” requiring approval + periodic recertification:

• SAP_ALL, SAP_NEW
• S_USER_* (user admin), S_DEVELOP (dev), S_TRANSPRT (transport), S_TABU_DIS (table access), S_RFC* (RFC)
• Broad table display/change and debugging in production

Novel, effective control: implement authorization drift detection:

• Track SU24 deltas by support package / feature activation
• Re-run controlled authorization traces after upgrades to catch newly required objects without granting broad wildcards

3) Secure RFC and internal connectivity (where landscapes most often break)

A) Eliminate “trusted RFC” sprawl

Trusted RFC is frequently treated as a convenience feature; attackers treat it as a privilege escalation bridge.

Policy:

• Default = no trusted RFC
• If required, document business justification, apply compensating controls:
  • dedicated technical user per interface
  • strict S_RFC allowlist
  • UCON restrictions (below)
  • monitored usage + anomaly alerts

B) Enforce encryption and strong identities for SAP protocols (SNC)

For ABAP systems using SNC for SAP GUI/RFC, baseline profile parameters (illustrative):

snc/enable = 1
snc/only_encrypted_gui = 1
snc/only_encrypted_rfc = 1
snc/identity/as = p:CN=SAPPRD01, OU=SAP, O=ExampleCorp, C=US
snc/data_protection/use = 3
snc/data_protection/max = 3

Design insight: treat SNC identities as service identities with lifecycle management (issuance, renewal, revocation). Integrate certificate inventory into your enterprise PKI tooling.

SAP reference:

• Secure Network Communications (SNC) in AS ABAP

C) Restrict RFC exposure with UCON (practical allowlisting)

UCON provides an additional enforcement layer beyond classic authorization checks, allowing you to block/allow RFC-enabled function modules.

Implementation approach:

1. Classify RFC-enabled function modules by business criticality
2. Define allowlists per calling system (not global allow)
3. Put “deny by default” on high-risk modules when feasible, then open explicitly

SAP reference:

• Unified Connectivity (UCON) – AS ABAP Security Guide

4) Fiori/ICF/OData security: reduce attack surface and instrument it

A) Service exposure governance

• Activate only required SICF services
• Apply namespace discipline and document service owners
• Treat OData services as APIs with lifecycle management, not “just UI plumbing”

ABAP Gateway hardening principles

• Enforce HTTPS end-to-end
• Ensure CSRF protections are not disabled “to make integrations work”
• Limit service users; avoid shared dialog users for service access

SAP reference:

• SAP NetWeaver Gateway and OData security (AS ABAP)

B) Separate UX roles from authorization roles (stops role explosion)

• One role layer controls Launchpad content (catalogs/spaces/pages)
• A distinct role layer grants back-end authorization objects

Field-proven technique: standardize naming and ownership:

• Z_FLP_* roles (UX content)
• Z_AUTH_* roles (back-end permissions)
• Composites bind them per job

This makes SoD analysis and access reviews materially easier.

5) Web entry and DMZ: enforce modern TLS and verifiable client identity

Reference deployment pattern (internet-facing Fiori)

flowchart LR
  U[User Browser] --> WAF[WAF / Reverse Proxy]
  WAF --> WD[SAP Web Dispatcher\n(TLS termination or pass-through)]
  WD --> ICM[S/4HANA ICM\n(HTTPS)]
  ICM --> ABAP[ABAP App Servers]
  ABAP --> HANA[(HANA DB)]

Web Dispatcher (7.89/7.93+) hardened configuration highlights

• Enforce modern TLS policies and disable weak ciphers
• Enable strict header handling and request logging (aligned to SIEM needs)
• Prefer end-to-end TLS (WAF→Web Dispatcher→ICM) for defense-in-depth

SAP reference:

• SAP Web Dispatcher documentation

6) Data security: HANA encryption, auditing, and ransomware-aware recovery

For SAP HANA 2.0 SPS06+:

• Enable auditing for privileged operations and sensitive schema access
• Protect audit trails (write-once / restricted admin)
• Ensure backups are immutable/offline with separation of duties

Example: HANA audit policy (illustrative)

-- Create an audit policy for critical actions (adapt to your needs)
CREATE AUDIT POLICY "POLICY_PRIVILEGED_ACTIVITY"
AUDITING ALL
FOR CREATE USER, ALTER USER, DROP USER, CREATE ROLE, DROP ROLE,
    GRANT, REVOKE, CREATE SCHEMA, DROP SCHEMA
LEVEL INFO TRAIL TYPE SYSLOG;

ALTER AUDIT POLICY "POLICY_PRIVILEGED_ACTIVITY" ENABLE;

SAP reference:

• SAP HANA Auditing

7) Logging & monitoring: make SAP visible to the SOC

Minimum viable SAP telemetry

• ABAP: Security Audit Log (SM19/SM20), auth failures, RFC logons, critical changes
• Web: ICM + Web Dispatcher access/error logs, SSO events correlation
• HANA: audit log + security-relevant traces

ABAP Security Audit Log enabling (typical baseline)

rsau/enable = 1
rsau/selection_slots = 10

Then configure SM19 filters to avoid noise while capturing:

• logon/logoff, failed logons
• RFC logons and RFC starts for critical destinations
• user and role maintenance
• table access to sensitive tables (where feasible)

SAP reference:

• Security Audit Log (AS ABAP)

Novel SOC integration technique: propagate a correlation ID

• Require WAF/reverse proxy to inject a request ID header
• Preserve it through Web Dispatcher/ICM logs
• Correlate to IdP sign-in logs and backend change/audit events
  This materially reduces mean-time-to-investigation in hybrid identity incidents.

Advanced Scenarios (500–600 words)

1) Hybrid identity propagation: choose auditable patterns intentionally

You must decide, per integration, whether you need:

• System-to-system identity (technical user): simplest and often sufficient
• End-user principal propagation: required for non-repudiation/audit in regulated flows

Rule of thumb: only propagate end-user identity when the business process must attribute actions to the individual across systems, and you can preserve evidence end-to-end.

Common hybrid patterns:

• BTP app → on-prem S/4 via Cloud Connector using a technical user + application-layer audit (often acceptable)
• BTP app → on-prem S/4 with principal propagation using certificate-based mapping where supported and governed tightly

SAP reference:

• SAP Cloud Connector documentation

2) OAuth2/OIDC for APIs: bridge token claims to SAP authorization safely

For BTP-native apps, use OAuth2/OIDC and scopes; for ABAP, avoid “token-to-SAP_ALL” anti-patterns.

Advanced approach: implement a claims-to-role mapping strategy:

• IdP/IAS group claims drive BTP authorizations (XSUAA/Role Collections)
• For ABAP APIs, map identity attributes to ABAP users and keep authorization enforcement in ABAP (PFCG), not in the API gateway alone

SAP reference:

• SAP BTP Security: Authentication and Authorization

3) Zero Trust interpretation for SAP (practical, implementable)

Replace implicit trust with explicit controls:

• Network location ≠ trust: micro-segment app↔db, restrict admin paths via bastions
• Short-lived credentials: rotate interface secrets; prefer certificates where possible
• Eliminate over-broad trust bridges: minimize trusted RFC, restrict RFC function exposure (UCON), tighten S_RFCACL

Continuous verification

• Conditional access at IdP for risky sign-ins
• Continuous monitoring for anomalous RFC usage, unusual table access, privilege escalations

4) Patch management at enterprise scale: SLAs + test packs + KPIs

Operational maturity hinges on applying SAP Security Notes predictably:

• Define SLAs by system criticality (Prod internet-facing ≠ internal sandbox)
• HotNews: fast-track with a pre-approved emergency change path
• Maintain a regression test pack focused on security note blast radius (auth, interfaces, custom code)

SAP reference:

• SAP Security Notes and Updates (Security Patch Day)

Real-World Case Studies (300–400 words)

Case Study 1 — Manufacturing: RFC sprawl causing audit failures and lateral-movement risk

Context: ECC/S/4 co-existence, hundreds of RFC destinations to MES and shop-floor systems, shared technical users, multiple trusted RFC links.

What changed:

• Introduced an Interface Governance Board: every RFC destination has an owner, data classification, and recertification schedule.
• Replaced shared technical users with per-interface system/communication users, rotated credentials, and enforced naming/ownership.
• Implemented UCON allowlisting for high-risk RFC-enabled function modules and removed “blanket” RFC authorizations.
• SOC visibility: added targeted ABAP audit log categories and normalized RFC events into SIEM.

Outcome: Significant reduction in “unknown” RFC calls, fewer audit findings (SoD + technical access), and improved incident response because interface ownership and logs became actionable.

Case Study 2 — Financial services: “Identity-as-perimeter” rollout for S/4 Fiori + BTP extensions

Context: S/4HANA 2022 with Fiori, BTP side-by-side apps, strict MFA/conditional access requirements, strong SOC.

What changed:

• Standardized SAML for Fiori through corporate IdP with step-up MFA for privileged actions.
• Implemented separation of UX vs authorization roles to stop role explosion and make access reviews meaningful.
• Enforced end-to-end TLS through WAF → Web Dispatcher → ICM, hardened cipher policies, and centralized correlation IDs.

Outcome: Lower operational friction (fewer “mystery” access issues), measurable reduction in privileged account exposure, and faster investigations due to correlated identity + web + ABAP audit trails.

Strategic Recommendations (200–300 words)

1. Adopt a single enterprise IAM strategy with SAP-specific enforcement

   • Federate authentication (SAML/OIDC), centralize MFA/conditional access, and standardize identity attributes.
   • Keep authorization decisions in ABAP (PFCG/auth objects) for ABAP workloads; don’t outsource authorization to the perimeter alone.

2. Treat integrations as first-class security assets

   • Ban unmanaged trusted RFC.
   • Require per-interface identities, documented owners, and recertification.
   • Use UCON and strict S_RFC* governance to reduce blast radius.

3. Operationalize “continuous SAP security”

   • Patch SLAs (HotNews fast lane), measurable KPIs, and a security regression test pack.
   • Central logging to SIEM with correlation IDs and SAP-specific detection content (RFC anomalies, privilege escalation, sensitive table access).

4. Invest early in role engineering and access governance

   • Build a role factory (templates, derived roles, naming standards).
   • Integrate SoD and firefighter/PAM with evidence automation for auditors.

Resources & Next Steps (150 words)

Start by aligning your blueprint to SAP’s security guides and then translating controls into build tickets:

• Core SAP guides:

  • SAP NetWeaver AS ABAP Security Guide
  • SAP S/4HANA Security Guide
  • SAP HANA Security Guide
  • SAP Cloud Identity Services (IAS/IPS)
  • SAP BTP Security

• Patch governance:

  • SAP Security Notes and Updates

Next steps: produce a landscape-specific reference architecture (on‑prem/RISE/hybrid), a control-to-technology mapping (ISO/NIST → SAP mechanisms), and a 90‑day hardening backlog prioritized by interface risk and privileged access exposure.