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/4HANA, SAP NetWeaver AS ABAP/Java, HANA, BTP, and hybrid SaaS) concentrate both crown‑jewel data and process authority (payments, vendor master, pricing, HR actions). A modern security architecture must therefore be identity-led, segmented by trust boundaries, and observable by default—not “Basis hardening plus a firewall.”

This report proposes a practitioner-grade reference architecture organized into five planes: Identity, Access, Application, Data, and Detection/Response. The key strategic moves are: (1) shift authentication to an enterprise IdP (SAML/OIDC) with conditional access and MFA; (2) aggressively reduce attack surface (ICF/RFC/services), especially for “internal” traffic; (3) adopt least-privilege role engineering with controlled SU24 proposal governance; (4) standardize integration identity patterns and secret rotation; and (5) onboard SAP telemetry into the SOC with SAP-specific detections and playbooks.

Technical Foundation (≈400–500 words)

1) Threat model: why SAP is different

SAP is not “just another app server.” SAP systems often have:

• High-impact business actions: creating payments, changing bank accounts, releasing production orders.
• Multiple protocols and stacks: SAP GUI/RFC, ICM/HTTP(S), OData, SOAP, IDoc, background jobs, HANA native interfaces.
• Powerful internal integration paths (RFC trust, technical users, batch).
• A dual security model: authentication (who are you?) + ABAP authorization (what are you allowed to do?), where the latter is typically the real risk driver.

2) The five-plane security architecture

Plane 1 — Identity (control plane)
Central IdP becomes authoritative for authentication and conditional access (MFA, device posture, geo/risk). SAP systems become relying parties (SAML/OIDC) while continuing to enforce ABAP/HANA authorizations.

Plane 2 — Access (trust boundary plane)
All access is mediated:

• Web: WAF / reverse proxy → (optional) SAP Web Dispatcher → ICM
• GUI/RFC: SNC (Kerberos/X.509) + strict SAP Gateway ACLs
• API: OAuth2/OIDC tokens, mTLS where appropriate, throttling and schema validation

Plane 3 — Application (authorization plane)
ABAP role design (PFCG), org-level derived roles, controlled SU24 proposal maintenance, secure configuration (ICF/RFC/trust), and secure development checks.

Plane 4 — Data (confidentiality & integrity plane)
HANA encryption, backup encryption, TLS everywhere, key lifecycle, masking/anonymization for non-prod.

Plane 5 — Detection/Response (operability plane)
Security logs are centrally collected and correlated; playbooks can disable identities, revoke tokens/certs, lock RFC destinations, and rotate secrets quickly.

3) Reference architecture diagram (trust boundaries)

flowchart LR
  subgraph Users
    U1[Business Users]
    U2[Admins / Basis]
    U3[Integration Clients]
  end

  subgraph Identity
    IDP[Enterprise IdP\nSAML/OIDC + MFA + Conditional Access]
    PAM[PAM Vault / Session Mgmt]
    IPS[Provisioning\nHR→IAM→SAP]
  end

  subgraph Edge["Access Edge / DMZ"]
    WAF[WAF / Reverse Proxy]
    WD[SAP Web Dispatcher\n(optional)]
  end

  subgraph SAP["SAP Landscape (Trusted Zone)"]
    ABAP[AS ABAP\nS/4HANA, ECC, BW]
    JAVA[AS Java\n(legacy where present)]
    HANA[(SAP HANA)]
    GW[SAP Gateway / ICM]
  end

  subgraph SOC["Detection & Response"]
    SIEM[SIEM/SOAR]
    IR[Incident Runbooks]
  end

  U1 -->|Browser| IDP -->|SAML| WAF --> WD --> GW --> ABAP
  U2 -->|Privileged| PAM --> ABAP
  U3 -->|OAuth2/mTLS| WAF --> GW

  IPS --> ABAP
  ABAP --> HANA

  ABAP -->|Audit Logs| SIEM
  HANA -->|Audit Logs| SIEM
  WAF -->|Access Logs| SIEM
  SIEM --> IR

4) SAP-specific primitives you must design around

• ABAP authorization checks are enforced via authorization objects; developers should use AUTHORITY-CHECK consistently (see ABAP language reference: AUTHORITY-CHECK).
• Secure connectivity depends on well-governed crypto stores:
  • ABAP PSE/certs in STRUST
  • HANA secure store / key management
• Security observability depends on enabling platform logs such as the ABAP Security Audit Log (see Security Audit Log (AS ABAP)) and HANA auditing (see SAP HANA Auditing).

Implementation Deep Dive (≈800–1000 words)

This section is intentionally prescriptive. Treat it as a blueprint you can translate into build standards, templates, and QA gates.

1) Identity plane: IdP-first SSO with strong provisioning

1.1 SAML 2.0 for SAP GUI-less web access (Fiori/ICF)

Target: S/4HANA 2022/2023 on AS ABAP 7.56+ (or NW 7.50+), fronted by WAF/reverse proxy.

Design rules

• Authentication at IdP, authorization in SAP (ABAP roles).
• Do not “spray roles” via coarse IdP groups; map to business roles, not “everyone-in-finance = SAP_ALL.”

Key configuration checklist

• Configure SAML trust (IdP metadata import, signing certs, assertion consumer service).
• Enforce:
  • Signed assertions
  • Tight token lifetimes
  • Audience restriction to the SAP relying party
• Choose a stable NameID mapping strategy (UPN/email vs SAP user ID) and standardize it across systems.

Operational controls

• Put SAML signing/encryption certificates under expiry monitoring with a 60/30/14 day alarm policy.
• Maintain a break-glass local admin that is PAM-controlled (no shared credentials, time-bound access).

SAP identity service patterns are typically combined with SAP Cloud Identity Services (IAS/IPS) for hybrid scenarios; use SAP’s product documentation as the authoritative reference:
SAP Cloud Identity Services (IAS/IPS) documentation

1.2 OIDC/OAuth2 for APIs and modern integrations

Where: SAP BTP custom apps, API Management, or external callers to SAP services.

Recommended pattern

• OAuth2 client credentials for system-to-system
• Authorization code + PKCE for interactive apps
• mTLS for high-trust integrations (banking, regulated data flows)

For SAP BTP, standardize on XSUAA where applicable and define scopes/role collections as code (see: SAP BTP Security: Authorization and Trust and developer guidance: SAP BTP tutorial content on security/OAuthExample: xs-security.json (BTP)

{
  "xsappname": "sapext-ai-secure-integration",
  "tenant-mode": "dedicated",
  "scopes": [
    { "name": "$XSAPPNAME.Interface.Read", "description": "Read-only interface access" },
    { "name": "$XSAPPNAME.Interface.Write", "description": "Write interface access" }
  ],
  "role-templates": [
    {
      "name": "InterfaceReader",
      "description": "Least-privileged read",
      "scope-references": ["$XSAPPNAME.Interface.Read"]
    }
  ]
}

Non-obvious hardening (often missed)

• Enforce audience and azp/client_id validation at the API gateway.
• Reject JWTs with:
  • missing exp, iss, aud
  • weak signing algorithms
• Short token lifetimes + automated client secret rotation (vault-driven).

2) Access plane: DMZ, TLS strategy, and SAP protocol controls

2.1 DMZ pattern with reverse proxy + optional Web Dispatcher

Decision point: If you need SAP-aware routing (system aliases, URL rewriting for ICF), use Web Dispatcher; otherwise an enterprise reverse proxy can work if you enforce strict allowlists.

TLS termination

• Preferred: end-to-end TLS (re-encrypt from proxy to ICM) unless security inspection mandates termination.
• Minimum: TLS 1.2+ with hardened cipher suites; disable legacy protocols.

Example: Web Dispatcher profile excerpt (illustrative)

# Bind HTTPS
icm/server_port_1 = PROT=HTTPS,PORT=443,PROCTIMEOUT=600,TIMEOUT=60

# Enforce TLS
ssl/protocols = TLSv1.2,TLSv1.3
ssl/ciphersuites = 135:PFS:HIGH::EC_P256:EC_HIGH

# Client certificate forwarding (if using mTLS upstream)
icm/HTTPS/verify_client = 0

Parameter semantics vary by kernel and component; validate against your component’s security guide and kernel documentation for your exact release line.

2.2 SAP GUI and RFC: SNC + Gateway ACLs (critical)

The uncomfortable truth: Many SAP breaches pivot through “internal” RFC because it’s treated as trusted.

Baseline

• Require SNC for SAP GUI/RFC whenever traversing untrusted networks.
• Restrict SAP Gateway:
  • reginfo / secinfo allowlists
  • explicit denies for external program execution unless required

Example: secinfo (deny-by-default posture)

# Deny everything by default (place explicit permits above)
P USER=* HOST=* TP=* ACCESS=DENY

# Permit specific RFC program registration from known hosts
P USER=sapadm HOST=app01.corp.local TP=Z_RFC_REG_SRV ACCESS=ALLOW
P USER=sapadm HOST=app02.corp.local TP=Z_RFC_REG_SRV ACCESS=ALLOW

Example: reginfo

# Only allow gateway registrations from integration hosts
P TP=Z_RFC_REG_SRV HOST=10.20.30.40 ACCESS=ALLOW
P TP=Z_RFC_REG_SRV HOST=10.20.30.41 ACCESS=ALLOW

# Deny everything else
P TP=* HOST=* ACCESS=DENY

Hard rule for architects

• Minimize “trusted RFC” relationships; treat each as a trust grant equivalent to lateral movement.
• For RFC technical users, build a role that is function-module specific (via S_RFC) and never assign broad authorizations “for convenience.”

3) Application plane: ABAP authorization engineering + secure configuration

3.1 Role design that survives audits and production reality

Recommended structure

• Business role (job function) → derived roles for org-level segmentation (company code, plant, purchasing org).
• Strict separation for:
  • user/role administration
  • configuration vs execution
  • developer vs production operator

Advanced technique: “authorization by evidence” Instead of designing roles purely from workshops:

1. Build a minimum viable role from SU24 proposals (controlled).
2. Use production-like execution traces to prove missing permissions:
   • run with a limited pilot group
   • capture authorization failures
3. Tighten iteratively.

This produces forensic evidence for auditors and reduces “SAP_ALL by week three.”

ABAP coding standard Every custom authorization-sensitive action must use explicit checks; example:

AUTHORITY-CHECK OBJECT 'S_TCODE'
  ID 'TCD' FIELD 'ZFI_PAYRUN'.

IF sy-subrc <> 0.
  MESSAGE e001(zsec) WITH 'Not authorized to execute pay run'.
ENDIF.

(Reference: AUTHORITY-CHECK)

3.2 Secure ICF service posture (attack surface reduction)

Principle: If an ICF node is not required, disable it. If required, protect it with:

• SSO (SAML/OIDC)
• strict authorizations
• network path constraints (only through proxy)
• rate limiting and request size constraints at the edge

Quality gate

• Maintain an “ICF allowlist” for each system role (DEV, QA, PRD, Internet-facing).
• Diff it weekly (drift detection).

3.3 Transport & change security (closing the “backdoor”)

Goal: prevent unauthorized or unreviewed changes from reaching production.

Controls

• Enforce separation:
  • DEV approval ≠ PRD import
• Require ChaRM-style approvals where applicable.
• Monitor for “out-of-band” changes:
  • debug changes
  • table maintenance of security-critical customizing
  • emergency imports outside windows

SAP’s change tooling varies; anchor your control design to your landscape (CTS/TMS, ChaRM, CI/CD) and document evidence sources in a control matrix.

4) Data plane: HANA security, encryption, and non-prod data protection

4.1 HANA encryption and auditing baseline

On SAP HANA 2.0 SPS landscapes, implement:

• encryption at rest (data volumes)
• backup encryption (and controlled key custody)
• audit policies for privileged actions and sensitive object access

Example: enable HANA auditing + create a focused audit policy (illustrative SQL)

-- Enable auditing (requires appropriate privileges)
ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM')
SET ('auditing configuration','global_auditing_state')='true'
WITH RECONFIGURE;

-- Create an audit policy (scope depends on your needs)
CREATE AUDIT POLICY "POLICY_PRIVILEGED_CHANGES"
AUDITING ALL
FOR ALTER SYSTEM, CREATE USER, DROP USER, ALTER USER
LEVEL INFO
TRAIL TYPE DATABASE;

Use the product documentation as the definitive reference for supported audit actions and syntax:
SAP HANA Platform documentation

4.2 Non-production refresh: treat it as a data exfiltration event

Non-obvious but high-impact: most SAP data leaks occur through non-prod clones with weak controls.

Standard “secure refresh” pattern

1. Refresh completes into isolated network segment.
2. Immediately rotate:
   • RFC destinations
   • interface credentials
   • communication users
3. Apply masking/anonymization for regulated fields.
4. Validate that outbound integrations are disabled until explicitly re-approved.
5. Re-enable only via checklist + evidence.

5) Detection/response plane: SOC-grade telemetry and playbooks

5.1 Minimum viable SAP security telemetry

Forward and normalize:

• ABAP Security Audit Log events (logon failures, user changes, role changes)
• ICM/HTTP access logs (suspicious URLs, admin endpoints)
• HANA audit logs (user/privilege changes, unusual reads)
• Edge logs (WAF/proxy), plus IdP sign-in risk events

SIEM use cases that catch real incidents

• Creation/assignment of highly privileged roles outside change window
• RFC spikes to high-risk function groups
• New trusted RFC relationships
• Mass reads from sensitive tables
• “Service user used interactively” anomalies (type mismatch)
• Geographically impossible logins (IdP-driven)

5.2 Incident playbooks (SAP-specific actions)

Pre-authorize the SOC to execute reversible containment steps:

• Lock user in SU01 (interactive compromise)
• Disable SAML trust / rotate signing cert (assertion compromise scenario)
• Disable RFC destination(s) / revoke technical user
• Remove role assignment (privilege escalation)
• Rotate interface secrets from the vault and force reconnection

Advanced Scenarios (≈500–600 words)

Scenario A — Hybrid SSO: SAML for web + SNC/Kerberos for SAP GUI

This is still the most common enterprise reality.

Architecture pattern

• Web users: IdP SAML → reverse proxy → ICM
• GUI users (corporate network): Kerberos via SNC
• Remote GUI: enforce MFA via VPN/ZTNA + device posture (because SAP GUI MFA is not uniformly available)

Advanced hardening that’s rarely documented

• Identity unification contract: define an immutable mapping rule (e.g., UPN → SAP User ID) and enforce it in provisioning. Mapping drift causes:
  • duplicate users
  • orphaned authorizations
  • broken audit trails
• Protocol-tier separation:
  • keep GUI/RFC ports off Internet paths entirely
  • require jump hosts for admin GUI access
• PAM for Basis and security admins:
  • credential injection (no password knowledge)
  • session recording for high-risk transactions

Scenario B — Secure RFC pattern (least privilege + traceability)

RFC is necessary in many ECC/S/4 integration chains, but it must be designed like an API.

Pattern

• One technical user per interface (no shared “RFCUSER”)
• One role template per interface type:
  • Z_RFC_READONLY_*
  • Z_RFC_POSTING_*
• Authorizations:
  • S_RFC restricted to required function groups/modules only
  • S_RFCACL carefully managed (especially with trusted scenarios)
• Destination governance:
  • destinations are configuration items with owners and expiry review

Performance + security optimization

• For high-volume RFC, resist the temptation to widen authorizations to fix dumps quickly. Instead:
  • instrument the target function modules with explicit checks
  • tune payload size and commit behavior
  • add queueing where appropriate
    Security and performance failures often share the same root cause: “unbounded design.”

Scenario C — API security for OData/Fiori beyond “just TLS”

Cutting-edge practice

• Use an API gateway to enforce:
  • JWT validation, audience, issuer pinning
  • schema validation (block over-posting)
  • rate limiting by client/app identity
• Apply authorization at the business object level, not just endpoint:
  • prevent “read all vendors” even if the service is callable
    This often requires tightening ABAP authorizations for Gateway services and removing broad table access used as shortcuts.

Scenario D — Continuous controls: baseline drift and security as code (SAP reality)

Even if SAP isn’t fully “DevSecOps,” you can still implement continuous controls:

• Weekly drift checks on:
  • profile parameters (hardening)
  • enabled ICF nodes
  • RFC destinations, trusted systems
  • critical role assignments
• Gate transports using automated checks (ATC + configuration checks) before PRD import.

Anchor your automation guidance on SAP’s ABAP tooling documentation and ATC references:
ABAP Test Cockpit (ATC) documentation

Real-World Case Studies (≈300–400 words)

Case 1 — Financial services: stopping “silent privilege creep”

Starting point

• Central IdP existed, but SAP still allowed passwords for many dialog users.
• GRC reviews were quarterly; role changes between reviews went unnoticed.
• Shared interface users existed “because the vendor asked.”

What we implemented

• Enforced IdP-first authentication for all web access; restricted password logon for privileged users.
• Introduced a role engineering lifecycle:
  • business role ownership
  • SU24 proposal governance
  • evidence-based trace tightening
• Rebuilt interfaces:
  • one technical user per interface
  • vault-managed credentials + rotation
• SOC onboarding:
  • alerts on new privileged role assignment
  • alerts on trusted RFC creation

Outcome

• Audit findings shifted from “systemic” to “operational tuning.”
• Incident response time dropped because containment actions were defined and rehearsed.

Case 2 — Manufacturing: reducing RFC blast radius without breaking plants

Starting point

• Plants depended on legacy RFC calls to core ECC/S/4.
• Gateway ACLs were permissive to avoid downtime.
• Network segmentation existed but “internal equals trusted.”

What we implemented

• Segmented by integration zone: plant → integration tier → SAP core.
• Introduced secinfo/reginfo deny-by-default with explicit allow rules.
• Built interface-specific PFCG roles restricting S_RFC to required modules only.
• Added monitoring for:
  • RFC call volume anomalies
  • new program registrations

Outcome

• Availability improved because failures became diagnosable (clear allowlists and ownership).
• Security improved because lateral movement paths were reduced.

Strategic Recommendations (≈200–300 words)

A pragmatic roadmap (90 / 180 / 365 days)

0–90 days: stabilize and observe

• Enforce edge-only access (WAF/proxy) for web entry points.
• Enable and forward logs (ABAP Security Audit Log, HANA audit, proxy/WAF logs).
• Inventory: RFC trusts, technical users, ICF exposure, certificates and expiries.

90–180 days: identity modernization + privilege reduction

• IdP-first SSO rollout (SAML/OIDC) with MFA/conditional access.
• PAM for privileged SAP and OS/DB accounts; implement emergency access with review.
• Begin role redesign for the highest-risk areas (finance posting, vendor master, user admin).

180–365 days: integration and continuous control

• Standardize interface security patterns (RFC/OData/event/file) with enforced templates.
• Vault-based secret management + rotation SLAs.
• Implement drift detection and transport quality gates (ATC/config checks).
• Mature SOC content: SAP-specific detections mapped to incident playbooks.

Ownership model (make it real)

Assign named owners for each plane:

• IAM team owns authentication policy and provisioning
• SAP Security owns role model, SoD, and SAP authorization governance
• Basis/Platform owns hardening, patching, TLS, cert lifecycle execution
• SOC owns detection content and response automation
• App owners own interface risk acceptance and data exposure decisions

Resources & Next Steps (≈150 words)

Official SAP documentation (starting points)

• ABAP authorization check reference: AUTHORITY-CHECK (ABAP)
• ABAP platform and security-relevant tooling landing: ABAP Platform documentation
• SAP HANA security, auditing, and encryption guidance: SAP HANA Platform documentation
• SAP Cloud Identity Services (IAS/IPS) patterns for hybrid identity: SAP Cloud Identity Services documentation
• SAP BTP security and trust concepts: SAP BTP documentation
• SAP developer tutorials for BTP security building blocks: SAP Developers tutorials### Immediate action items

1. Produce a one-page landscape trust boundary diagram (web, GUI/RFC, APIs, admin paths).
2. Stand up a certificate inventory with expiry alerting and owners.
3. Pick three SIEM detections (privileged role assignment, new RFC trust, suspicious ICF admin access) and operationalize runbooks.