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 security is no longer a “Basis hardening + roles” problem. Modern S/4HANA and hybrid landscapes (on‑prem, RISE private cloud, BTP, SaaS) create a security control plane where identity is the new perimeter, interfaces are the dominant attack surface, and authorization drift is the most persistent risk.

This report provides a practitioner-grade reference architecture built on five planes (Identity, Access/Authorization, Application & Interface, Data, Operations) and translates it into actionable implementation patterns: enterprise IdP + MFA, SNC for SAP GUI/RFC, TLS everywhere for HTTP(S), standardized role engineering with SU24 governance, SoD with GRC/IAG + emergency access, and SAP-specific detections in SIEM.

Key recommendations: treat SAP as a set of explicit trust boundaries, minimize “trusted RFC”, implement continuous controls monitoring (configuration + authorization drift), and design privileged access separation (PAM + Firefighter) as a first-class architecture component—not an audit afterthought.

Technical Foundation (400–500 words)

1) What “enterprise security architecture” means for SAP

SAP landscapes concentrate the organization’s most valuable business actions (payments, vendor/bank changes, pricing, batch release) in application-layer transactions. Security architecture must therefore coordinate controls across:

• Identity & Authentication: who is allowed to log on, from where, and under what conditions (MFA/conditional access).

  • Web/Fiori commonly uses SAML 2.0 to AS ABAP via an enterprise IdP; see SAP’s SAML 2.0 guidance for AS ABAP (SAML 2.0 Authentication).
  • SAP GUI/RFC should be protected with SNC (Kerberos/X.509) rather than “internal network trust” (Secure Network Communications (SNC)).

• Authorization & Governance: what the identity can do (PFCG roles, authorization objects, CDS DCL, org levels) and how access is approved/recertified.

  • Authorization concepts and PFCG remain foundational (AS ABAP Authorization Concept).
  • Fiori catalogs/spaces/pages are UI navigation, not a substitute for backend checks.

• Secure Communications: protect every hop (TLS, SNC, mTLS), and govern certificates end-to-end.

  • TLS configuration is centered around PSEs and the trust store in AS ABAP (SSL/TLS in AS ABAP).
  • Internet-facing components (e.g., Web Dispatcher) must be treated as Tier-0 security infrastructure (SAP Web Dispatcher Security).

• Monitoring & Response: convert SAP telemetry into SOC detections (privileged access, auth changes, RFC misuse).

  • Enable and forward the Security Audit Log (Security Audit Log).

• Vulnerability & Patch Discipline: follow SAP’s monthly security cadence and hardening guidance, prioritizing internet-facing components.

  • Track SAP’s security updates and SAP Notes via the official Security Patch Day entry points (SAP Security Patch Day).

2) Reference architecture: five planes + explicit trust zones

A durable model is five planes mapped onto network zones (User → DMZ → App → DB → Management), with policy enforcement at the boundaries.

flowchart LR
  U[Users\nBrowser / SAP GUI] -->|SAML/OIDC + MFA| IDP[Enterprise IdP\nEntra/ADFS/Okta + IAS]
  U -->|SNC (Kerberos/X.509)| SAPGUI[SAP GUI]

  subgraph DMZ
    WDP[SAP Web Dispatcher / Reverse Proxy\nTLS termination, WAF, allowlists]
  end

  subgraph APP[Application Zone]
    ABAP[AS ABAP (S/4HANA)\nICM, Gateway, RFC]
    GRC[SAP GRC / IAG\nSoD + Access Requests]
  end

  subgraph DB[Database Zone]
    HANA[SAP HANA 2.0\nEncryption, auditing]
  end

  subgraph OPS[Operations Plane]
    SIEM[SIEM/SOAR\nDetections + IR]
    PAM[PAM Vault\nJIT elevation + session recording]
  end

  IDP --> WDP --> ABAP --> HANA
  ABAP --> SIEM
  PAM --> ABAP
  PAM --> HANA
  GRC --> ABAP

Implementation Deep Dive (800–1000 words)

1) Identity plane: standardize authentication (SSO) and lifecycle

A. Web/Fiori SSO: SAML 2.0 to AS ABAP (S/4HANA 2022/2023)

Target pattern

• Browser → Web Dispatcher (TLS) → AS ABAP (SAML SP) → Enterprise IdP (SAML IdP) → assertion back to ABAP.

Implementation steps (high-signal checklist)

1. Treat AS ABAP as a SAML Service Provider

   • Configure via transaction SAML2. Use signed assertions and validate audience/recipient strictly.
   • Reference: SAML 2.0 Authentication

2. Enforce MFA and conditional access at the IdP

   • Architecturally, SAP should not implement “per-system MFA plugins” unless break-glass requirements demand it.
   • Align conditional access with SAP risk tiers:
     • Tier 0: Basis/PAM/admin jump hosts
     • Tier 1: Finance + vendor/payment functions
     • Tier 2: General business roles

3. Map identity attributes to SAP user master consistently

   • Use immutable identifiers where possible (e.g., employee ID) to avoid collisions during mergers.
   • For provisioning, standardize on SCIM where supported and keep “manual SU01 creation” as an exception process.

B. SAP GUI/RFC: SNC (Kerberos preferred, X.509 acceptable)

SNC is the control that stops “internal network = trusted SAP GUI” thinking.

Key profile parameters (AS ABAP)

snc/enable = 1
snc/accept_insecure_gui = 0
snc/accept_insecure_rfc = 0
snc/data_protection/use = 3
snc/data_protection/min = 2
snc/identity/as = p:CN=SAPPRD01, OU=SAP, O=ExampleCorp, C=US

Notes

• snc/data_protection/use=3 enforces encryption + integrity (recommended for regulated environments).
• For GUI SSO with Kerberos, consider SAP Secure Login options; architect this as a platform service, not a per-system tweak.
• Reference: Secure Network Communications (SNC)

2) Access/Authorization plane: role engineering that survives S/4 + Fiori

A. Build roles from a clean foundation (SU24/SU25 governance)

Problem pattern: role explosion and inconsistent authorization proposals due to uncontrolled SU24 maintenance.

Controls

• Restrict SU24 maintenance to a governed “authorization engineering” group.
• Use SU25 after upgrades as a controlled change with regression tests (critical in S/4HANA upgrades where new checks appear).

B. Job-based business roles → technical roles → derived roles

A scalable approach:

• Business role (job function): “AP Accountant”
• Composite role: bundles several PFCG single roles + Fiori content
• Derived roles: same authorizations, different org levels (BUKRS, VKORG, WERKS)

Practical guidance

• Keep org levels in derived roles only. Keep menu + auth objects stable in the parent role.
• Avoid “wildcards” (*) in high-risk objects (e.g., S_TCODE, S_TABU_DIS) except in tightly controlled firefighter roles.

C. Fiori authorizations: UI content is not security

In S/4HANA Fiori, you must align:

• ICF services (SICF)
• OData services (Gateway)
• Backend authorizations for business objects

Gateway hardening

• Publish only required services; do not expose broad services to “everyone.”
• Reference: SAP Gateway - Security Guide

D. ABAP authorization checks: detect and prevent missing checks in custom code

A common real-world root cause is custom Z code that forgets authorization checks.

ABAP pattern (minimum acceptable)

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.

Advanced hardening (often missed)

• Centralize checks in reusable classes (e.g., ZCL_AUTHZ_*) to prevent inconsistent checks.
• Add automated transport gates (ATC + custom checks) for:
  • AUTHORITY-CHECK absence in sensitive reports
  • RFC destinations usage
  • hardcoded credentials

Reference for ABAP authorization concepts: Authorization Concept

E. Data-level security: CDS DCL for S/4HANA analytics and APIs

CDS access control is increasingly the right layer for “row-level security,” especially for Fiori Elements and analytics.

DCL example (simplified)

@EndUserText.label: 'Sales org restriction'
define role ZR_SALESORG {
  grant select on ZC_SalesOrder
    where SalesOrganization = aspect pfcg_auth( 'V_VBAK_VKO', 'VKORG' );
}

This pattern avoids duplicating logic across UI apps and services, and it survives new consumption channels (OData, embedded analytics).
Reference: CDS Access Control (DCL)

3) Application & interface plane: secure the attack surface (RFC, HTTP, APIs)

A. RFC: eliminate “trusted RFC by convenience”

Rule: trusted RFC relationships should be rare and justified; most can be replaced by:

• Technical RFC users with least privilege
• SNC-protected RFC
• Explicit allowlisting

Operational checks

• Inventory destinations (SM59) and classify: business critical, legacy, removable.
• Monitor changes to RFC destinations as a high-fidelity detection.

B. HTTP(S) hardening: ICM, Web Dispatcher, admin endpoints

Minimum baseline

• TLS 1.2+ (prefer 1.3 where supported by component and policy)
• Strong cipher suites aligned with enterprise crypto standard
• Disable unused ICF services (SICF), especially admin/test endpoints

Reference: SSL/TLS Configuration and SAP Web Dispatcher Security

C. BTP/API security: OAuth2 scopes, mTLS, and workload identity

For SAP BTP applications, OAuth2 is typically implemented via XSUAA and service bindings; this shifts security from “user + role” to token + scope + audience.

• Use short-lived tokens, narrow scopes, and rotate credentials via bindings—not stored secrets.
• Reference: Authorization and Trust Management (XSUAA) - Developer Guide---

4) Operations plane: logging, detection engineering, patching, drift control

A. Security Audit Log → SIEM: make it detection-ready

Enable SAP Security Audit Log and forward events. The high value is correlation with IdP and network telemetry.

Detections that consistently work in SAP

1. Privileged logon (Basis/admin roles) outside approved windows
2. Role change (PFCG) followed by sensitive transaction within 30 minutes
3. New/changed RFC destination or trusted system settings
4. Mass user unlocks / password resets
5. Repeated failed logons from new geographies (correlate IdP “impossible travel”)

Reference: Security Audit Log

B. Patch cadence: institutionalize Security Patch Day

Pattern

• Monthly triage (internet-facing first: Web Dispatcher, ICM, Gateway)
• SLA tiers (e.g., Critical: 7–14 days; High: 30 days)
• Regression automation (especially for validated environments)

Official entry point: SAP Security Patch Day

C. Continuous Controls Monitoring (CCM): detect drift, not just incidents (advanced)

CCM is where mature SAP security programs differentiate:

• Baseline and detect drift for:
  • profile parameters (RZ10)
  • SNC/TLS settings (STRUST)
  • trust relationships / RFC changes (SM59)
  • critical authorizations (S_TABU_DIS, S_RFC, S_USER_*, S_DEVELOP)
• Tie drift to workflow: raise a ticket automatically, require approval, enforce rollback windows.

Advanced Scenarios (500–600 words)

1) “Zero Trust-ish” segmentation for SAP (practical, not ideological)

Most SAP compromises spread via lateral movement: a foothold in user subnet → app servers → DB. The goal is to make each hop explicit and monitored.

Zone model

• User Zone: end-user devices, SAP GUI front-end
• DMZ: Web Dispatcher / reverse proxy, WAF, strict inbound allowlists
• App Zone: AS ABAP application servers, message server access restricted
• DB Zone: HANA only accessible from app servers, no direct user access
• Management Zone: admin jump hosts, monitoring, backup, PAM

Controls often overlooked

• Message server exposure: restrict to SAP GUI paths that require it; prefer SAProuter only where needed.
• East-west restrictions: only required ports from specific sources; block workstation-to-app direct admin ports.
• Dedicated admin identities and devices: no “Basis from laptop via VPN.”

2) Privileged Access Management (PAM) + Firefighter: two layers, different threats

PAM controls OS/DB and infrastructure-level elevation; Firefighter controls application-layer emergency execution.

Best-practice architecture

• Separate identities:
  • Named user (daily work)
  • Privileged admin (time-bound, approved)
  • Break-glass (vaulted, monitored, rare)
• Require session recording for:
  • HANA OS admin
  • SAP instance OS users
  • HANA DB admin access

For application emergency access, implement workflows and logging with SAP governance tooling:

• SAP Access Control (GRC) - Product Documentation
• SAP Cloud Identity Access Governance (IAG)

Novel operational insight Treat emergency access as a designed user journey:

• “I need access now” is inevitable; you either make it auditable and safe—or you get shadow admin accounts.

3) Hybrid connectivity: Cloud Connector as a trust bridge (minimize blast radius)

When using SAP Cloud Connector, assume it is a high-value target because it bridges BTP to internal systems.

Hardening approach

• Map only required internal resources; avoid broad wildcards.
• Separate connectors by sensitivity (finance vs general) rather than one shared connector.
• Tight admin RBAC and audit for connector configuration changes.

Reference: SAP Cloud Connector - Documentation

4) Cryptography & key management: certificate lifecycle as an enterprise service

SAP security fails quietly when certificates expire or private keys are copied into scripts.

Controls

• Central inventory of PSEs (ABAP), Web Dispatcher certs, integration certs
• Rotation runbooks and emergency renewal
• Where required, integrate with enterprise PKI processes and HSM-backed key protection (pattern depends on platform and compliance)

HANA encryption at rest should be enabled and tested (including restore procedures):

• SAP HANA Encryption

Real-World Case Studies (300–400 words)

Case 1: Financial services — stopping fraud paths, not just vulnerabilities

A Tier-1 bank running S/4HANA 2022 found that “clean patching” didn’t address audit findings because the dominant risk was toxic access combinations and undetected privilege creep.

What worked

• Rebuilt access model around job-based business roles and derived roles for org levels.
• Implemented SoD policies in GRC/IAG with compensating controls for legitimate exceptions.
• Integrated SAP Security Audit Log + IdP conditional access logs into SIEM and built detections for:
  • vendor master/bank changes
  • role changes + sensitive execution bursts
• Added PAM session recording for OS/HANA admins and removed shared admin IDs.

Lesson SoD programs succeed when role engineering, process controls, and monitoring are built together—tooling alone is not governance.

Case 2: Pharma — validated landscape without patch paralysis

A life sciences company on S/4HANA had change-validation overhead that delayed security notes.

What worked

• Pre-approved monthly patch playbooks with defined test packs and automated smoke tests.
• “Risk-based” patching: internet-facing (Web Dispatcher/ICM/Gateway) always prioritized.
• Emergency access redesigned: Firefighter with mandatory reason codes and post-review, reducing unsafe “temporary admin” workarounds.

Lesson Validated environments need industrialized testing and pre-approvals, not exceptions that normalize risk.

Case 3: Manufacturing — legacy RFC/IDoc at scale

A manufacturer with heavy plant integration had weakly authenticated RFC flows.

What worked

• Introduced network segmentation and strict allowlists for RFC sources.
• Migrated the riskiest partner interfaces behind middleware where stronger auth (mTLS/OAuth) was possible.
• Reduced “trusted RFC” to a minimal, documented set and monitored it as critical configuration.

Lesson When you can’t modernize endpoints quickly, wrapping legacy protocols with stronger controls and segmentation delivers immediate risk reduction.

Strategic Recommendations (200–300 words)

1. Adopt the five-plane reference model as your governance structure
   Build ownership and controls per plane (Identity, Access, Interface, Data, Operations). This eliminates “security falls between teams.”

2. Identity-first baseline in 90 days

   • Central IdP federation for S/4 Fiori (SAML 2.0) and consistent MFA/conditional access
   • SNC rollout plan for SAP GUI/RFC (start with privileged + high-risk users)

3. Authorization sustainability over authorization heroics

   • SU24 governance + job-based roles + derived roles
   • Quarterly access recertification focused on high-risk roles
   • Expand row-level controls with CDS DCL where analytics/API consumption is growing

4. Reduce attack surface deliberately

   • Inventory and rationalize RFC destinations, trusted relationships, exposed OData services
   • Harden Web Dispatcher/ICM and disable unused services

5. Operationalize security

   • Security Patch Day as a recurring operational rhythm with defined SLAs
   • SAP-specific SIEM detections and incident playbooks
   • Continuous controls monitoring to detect drift in parameters, trust settings, and privileged access

Resources & Next Steps (150 words)

Official SAP documentation (start here)

• AS ABAP Security (SAML, SNC, TLS, Audit):
  • SAML 2.0 Authentication
  • Secure Network Communications (SNC)
  • SSL/TLS Configuration
  • Security Audit Log
• Gateway/API security: SAP Gateway Security Guide
• HANA encryption: Data Volume Encryption
• Cloud connectivity: SAP Cloud Connector
• Patch governance: SAP Security Patch Day

Next actions (practical)

• Produce a system-by-system trust boundary map (who authenticates, where TLS/SNC terminates, what interfaces exist).
• Stand up 10–15 high-confidence SIEM detections specific to SAP privileged activity and change events.
• Launch a role engineering program with SU24 governance and a decommission plan for unused interfaces.