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 architecture has shifted from “ABAP users + authorizations” to a multi-plane model: identity, application, platform, data, and security operations, spanning on‑prem, hyperscaler, and SAP BTP. The most resilient programs standardize interactive authentication through a single corporate IdP with MFA, keep authorizations local (ABAP PFCG, HANA roles, BTP role collections), and enforce least privilege via engineered business roles with SoD governance. Internet exposure should be eliminated for backends: adopt a DMZ front door (WAF/reverse proxy + SAP Web Dispatcher) and publish only whitelisted Fiori/OData paths. Integrations are the dominant risk driver; modernize from shared technical users toward OAuth2/mTLS + API gateways, and strictly govern RFC trust and destinations. Finally, operational excellence—SAP Security Notes cadence, centralized logging to SIEM, and measurable configuration drift controls—determines audit outcomes more than any single product choice. This guide provides reference architecture, concrete configuration baselines, and advanced patterns for hybrid SAP landscapes.

Technical Foundation (400–500 words)

1) Reference architecture: planes and trust boundaries

A durable SAP security architecture is built around explicit trust boundaries and enforcement points—not around individual systems. Use five planes:

1. Identity plane: corporate IdP (Azure AD/Okta/ADFS), MFA/Conditional Access, PAM, identity provisioning (IGA/GRC).
2. Access plane (“front door”): WAF/reverse proxy + SAP Web Dispatcher (or equivalent) as the primary ingress for SAP HTTP/S; admin access via hardened jump hosts.
3. Application plane: SAP S/4HANA (AS ABAP), SAP Gateway/Fiori, Java stacks (if present), custom ABAP and side-by-side extensions.
4. Data plane: SAP HANA (or other DB), encryption/key management, data classification, audit policies.
5. Operations plane: logging/SIEM, vulnerability management (Security Notes), configuration compliance, incident response.

Zone model (minimum viable segmentation)

• Internet/Partner zone → DMZ (WAF + Web Dispatcher) → App zone (AS ABAP/Gateway) → DB zone (HANA)
• Separate Management zone for SAProuter, monitoring agents, backup, and admin jump hosts.

This aligns with SAP’s component hardening approach (product security guides and configuration recommendations), and makes it easier to prove control ownership in hybrid deployments. Start with SAP’s security guidance for AS ABAP and SAP HANA and treat these as normative baselines:

• SAP NetWeaver AS ABAP Security Guide (Help Portal)
• SAP HANA Platform Security Guide (Help Portal)

2) SAP-specific control primitives you must design around

• ABAP authorization checks are runtime AUTHORITY-CHECK evaluations against authorization objects populated by PFCG roles. Design quality depends heavily on authorization defaults (SU24) and disciplined role engineering.
  • Authorization Concept (AS ABAP)
• Fiori and OData increase attack surface (HTTP endpoints, CSRF, service publication). Security is primarily about service minimization and front-door enforcement.
• Interfaces (RFC/HTTP/IDoc/file) are where enterprise controls often degrade—shared accounts, broad permissions, implicit trust, and weak monitoring.
• Cloud identity shifts authentication to SAML/OIDC and service-to-service to OAuth2/mTLS; authorization still remains local per target (ABAP vs BTP).
  • SAP BTP Security (Help Portal)

3) Security operations is architecture, not an afterthought

If you cannot produce evidence (logs, approvals, role changes, patch status) on demand, you do not have an enterprise security architecture—you have best intentions. Build around:

• Monthly patch intake aligned to SAP’s Security Patch Day and emergency patch paths.
  • SAP Security Patch Day and Security Notes (Support Portal)
• Centralized, normalized audit logs from ABAP, Web Dispatcher/ICM, and HANA.
  • Security Audit Log (AS ABAP)

Implementation Deep Dive (800–1000 words)

1) Identity & authentication: standardize by channel

A. Browser (Fiori/UI5, web apps): SAML 2.0 with corporate IdP

Target: S/4HANA 2021+ / 2023, AS ABAP 7.50+ with SAML2 support.

Key implementation steps (ABAP-side):

1. Enable HTTPS end-to-end (Web Dispatcher ↔ ICM ↔ browser).
2. Configure SAML 2.0 service provider and trust to IdP (metadata exchange, signing/encryption policy, NameID mapping).
3. Enforce MFA/Conditional Access at IdP (especially for privileged business roles and admins).

Authoritative setup details:

• SAML 2.0 Authentication (AS ABAP)

Novel but practical tip: choose an immutable user key strategy early. If your enterprise uses email as login, map it consistently across ABAP (SU01), BTP, and analytics. Avoid landscape-specific usernames—this is where SoD blind spots come from.

B. SAP GUI: SNC (Kerberos or X.509) + “no passwords by default”

For SAP GUI traffic, design for SNC to avoid password-based GUI logons and reduce credential replay risk.

• Use Kerberos for domain-joined corporate endpoints; use X.509 for high-assurance admin access and non-domain scenarios.
• Keep a minimal number of emergency local users with vaulted credentials and step-up monitoring.

Reference:

• Secure Network Communications (SNC) in AS ABAP (Help Portal)

Configuration baseline (ABAP profile parameters example)
Tune to your policy, but explicitly set password and session controls (examples commonly used in regulated estates):

# Password policy (examples; adjust to your standard)
login/min_password_lng = 14
login/min_password_digits = 2
login/min_password_letters = 2
login/min_password_specials = 2
login/password_expiration_time = 90

# Lockout / brute-force controls
login/fails_to_user_lock = 5
login/failed_user_auto_unlock = 0

# Session hardening
rdisp/gui_auto_logout = 900
login/password_max_idle_productive = 30

Use SAP’s hardening guidance per release to validate parameter semantics and defaults (don’t rely on tribal memory).

• AS ABAP Security Recommendations (Help Portal)

2) Authorization & access governance: engineer roles, don’t “grow” them

A. ABAP role engineering that survives S/4 + Fiori

Principles that prevent role explosion:

• Model business capabilities (e.g., “AP Invoice Processor”) and map to tasks/apps, not to legacy transactions.
• Keep single roles composable; use composites for job functions.
• Use derived roles for org-level variance (company code/plant/purchasing org).
• Treat SU24 as lifecycle configuration, not as a one-time project task.

Practical ABAP snippet: defend with explicit authorization checks

Even in well-governed environments, custom code often becomes an authorization bypass. Require peer review for any code touching sensitive business objects.

DATA: lv_bukrs TYPE bukrs VALUE '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 to display company code data'.
ENDIF.

Reference concepts:

• Authorization Checks and Authorization Objects (AS ABAP)

B. SoD governance: prevent at request time, not after audit

• Use IGA/GRC workflow to enforce SoD rules before provisioning.
• Make “temporary access” time-bound and auto-expiring.
• Reconcile technical users into the same governance model: every interface identity needs an owner, a purpose, and a review cadence.

If you run SAP GRC Access Control, architect it as part of IAM—not as a separate SAP island.

• SAP Access Control (GRC) Product Documentation (Help Portal)

3) Front door & network controls: DMZ routing is a security control

A. Web Dispatcher as the SAP-aware reverse proxy (in DMZ)

Place Web Dispatcher behind a WAF when internet-facing, and expose only approved endpoints.

Reference:

• SAP Web Dispatcher (Help Portal)

Sample Web Dispatcher profile pattern (whitelist exposure)

# TLS termination (example; ensure modern ciphers per policy)
icm/server_port_0 = PROT=HTTPS,PORT=443,TIMEOUT=60,PROCTIMEOUT=600

# Backend system registration
wdisp/system_0 = SID=S4P, MSHOST=s4p-msg.internal.corp, MSPORT=3601, GROUP=PUBLIC

# Security posture: do not “open proxy”
wdisp/trace = 1
wdisp/add_client_protocol_header = true

# Prefer explicit routing rules (illustrative concept)
# Route only /sap/bc/ui5_ui5 and selected OData; deny everything else at proxy/WAF

Hard rule: never publish /sap/bc/gui/sap/its/webgui or broad /sap/bc/ paths without an explicit threat model and compensating controls. Most “we only needed Fiori” incidents start with permissive path exposure.

B. Backend protection

• No direct access from user subnets to app servers; only from Web Dispatcher/reverse proxy.
• DB zone reachable only from app zone.
• Admin access only via jump hosts with MFA and session recording (PAM).

4) Fiori/Gateway security: minimize, then protect

Key moves:

1. Activate ICF services by whitelist; implement an approval workflow for SICF activations.
2. Govern OData publication and service catalog.
3. Enforce CSRF protections; block unsafe HTTP methods by default at the front door where possible.

SAP guidance for Gateway and OData security:

• SAP Gateway Security Guide (Help Portal)

Operational control that works: maintain a “published services inventory” (system, service, path, owner, consumer, auth concept). Tie it to change control and scan for drift weekly.

5) Data protection & crypto hygiene: treat certificates like production dependencies

A. HANA auditing and encryption

Implement HANA audit policies for privileged operations and sensitive object access; forward to SIEM.

Reference:

• SAP HANA Auditing (Help Portal)

HANA example: create an audit policy (illustrative)

-- Example only: tailor actions/status/targets to your compliance needs
CREATE AUDIT POLICY "SEC_PRIVILEGED_CHANGES"
  FOR SYSTEM
  ADD ALTER SYSTEM
  ADD CREATE USER
  ADD DROP USER
  ADD ALTER USER
  LEVEL INFO
  TRAIL SYSLOG;
ALTER AUDIT POLICY "SEC_PRIVILEGED_CHANGES" ENABLE;

B. Certificate lifecycle automation (often overlooked)

Novel but high-impact technique: treat PSE/cert rotation as a release pipeline artifact, not a manual Basis task.

• Central inventory of certificates across Web Dispatcher, AS ABAP SSL, HANA SSL, RFC SNC identities.
• Expiry monitoring with thresholds (e.g., 60/30/14 days).
• Controlled rollout plan that includes HA pairs and DR systems (certificate replication is frequently missed).

6) Security operations integration: SAP logs must be first-class SIEM data

At minimum ingest:

• ABAP Security Audit Log
  • Security Audit Log (AS ABAP)
• ICM/HTTP access logs, Web Dispatcher logs
• HANA audit logs
• OS authentication logs on app/DB hosts
• Change and transport events (who changed what, when)

Detection engineering that pays off: build correlation rules specifically for SAP patterns—e.g., emergency user usage, RFC destination changes, mass role assignments, unusual OData error bursts (service probing).

Advanced Scenarios (500–600 words)

1) API-led security: OAuth2/mTLS + gateway policies as the control point

When modernizing integrations, move from “SAP backend exposure” to curated APIs:

• Put SAP API Management or an enterprise gateway in front for OAuth2, rate limits, schema validation, and threat protection.
• Use mTLS for partner/B2B high assurance and certificate-bound tokens where supported.

SAP Integration Suite and API management references:

• SAP Integration Suite – API Management (Help Portal)

Advanced pattern: Token exchange for least-privilege backends

• External client gets OAuth2 access token at IdP/gateway
• Gateway exchanges token for a backend-specific token (audience-restricted), reducing replay value outside the intended target

2) RFC hardening with UCON and trust minimization

RFC remains necessary, but its default trust model is dangerous at scale.

Controls:

• Unique technical users per interface (no sharing).
• Least-privilege authorizations; avoid broad S_RFC* patterns.
• Restrict and monitor SM59 changes; treat RFC destinations as sensitive configuration.
• Where feasible, protect with SNC.
• Apply ABAP controls to reduce lateral movement.

If available in your release, use Unified Connectivity (UCON) to restrict RFC at a more granular level.

• Unified Connectivity (UCON) (AS ABAP)

3) BTP + on-prem: secure connectivity as a product, not a tunnel

For SAP BTP consuming on‑prem SAP, common patterns involve SAP Cloud Connector and Destinations. Architect with:

• Separate subaccounts per environment (DEV/TEST/PRD) and per trust boundary.
• Strict destination governance: who can create/modify destinations and which principals they run as.
• Prefer short-lived credentials and OAuth-based flows when supported.

References:

• SAP BTP Connectivity: Cloud Connector (Help Portal)
• SAP BTP Destination Service (Help Portal)

Advanced control: “Destination drift detection”
Export destination configurations (where APIs allow), store in git, and alert on unauthorized change. This is one of the fastest ways to stop silent privilege escalation in hybrid landscapes.

4) Zero Trust alignment without breaking SAP

You rarely implement “pure” Zero Trust inside ABAP authorization. Instead:

• Enforce device posture, location, and risk signals at IdP (Conditional Access) for all interactive logons.
• Enforce session controls at reverse proxy/WAF (timeouts, method restrictions, geo/rate rules).
• Use PAM for privileged sessions (recording + approval).
• Keep SAP authorizations clean and stable; avoid embedding volatile conditions into PFCG.

Real-World Case Studies (300–400 words)

Case 1: Global manufacturer — RFC sprawl to governed integration identities

Problem: Hundreds of SM59 RFC destinations with shared technical users and broad authorizations; periodic audit failures and an incident involving unauthorized master data changes.

Architecture change:

• Classified every interface by business impact and protocol.
• Replaced shared RFC users with named technical identities per interface and per environment.
• Introduced SNC for high-value RFC channels; disabled trusted RFC except for explicitly approved system pairs.
• Implemented monitoring for RFC destination maintenance and technical user logons; forwarded ABAP Security Audit Log events to SIEM.

Outcome: Measurable reduction in privileged authorizations, faster incident triage (clear ownership), and audit closure because evidence became reproducible.

Case 2: Retailer — internet-facing Fiori stabilized by DMZ “front door” discipline

Problem: Fiori launchpad exposed with permissive URL routing; multiple unused ICF services active “from earlier projects.”

Architecture change:

• WAF + Web Dispatcher in DMZ; backend systems unreachable from the internet.
• Whitelisted only required /sap/bc/ui5_ui5/ and specific OData paths; blocked broad /sap/bc/ patterns.
• Instituted service publication governance: any new SICF activation required a ticket, security review, and owner assignment.

Outcome: Attack surface dropped materially; pen-test findings shifted from “critical exposure” to “hardening improvements,” and production outages from malicious scanning decreased.

Strategic Recommendations (200–300 words)

1. Adopt a single enterprise identity standard per channel

   • SAML2 for browser SSO, SNC for SAP GUI, OAuth2/OIDC for APIs. Document “approved protocols by use case” to reduce architecture drift.

2. Treat interfaces as Tier‑0 security scope

   • Inventory technical users, destinations, certificates, and trust links. Assign owners and review cycles. Modernize high-risk flows to OAuth2/mTLS behind an API gateway.

3. Institutionalize role engineering and SoD governance

   • Move from transaction-driven roles to process capability roles; use derived roles for org variance; embed SoD checks in access requests, not as quarterly detective controls.

4. Make DMZ routing and service whitelisting non-negotiable

   • A secure SAP landscape is one where only intentional endpoints exist. Enforce this at Web Dispatcher/WAF and validate continuously.

5. Operationalize security like an SRE discipline

   • Monthly SAP Security Notes cadence with emergency patch path, configuration baselines with drift detection, and SIEM detections built for SAP-specific behaviors.

Resources & Next Steps (150 words)

Start with authoritative SAP documentation baselines:

• SAP NetWeaver AS ABAP Security Guide
• Security Audit Log (AS ABAP)
• SAML 2.0 Authentication (AS ABAP)
• SAP HANA Platform Security Guide
• SAP HANA Auditing
• SAP Web Dispatcher
• SAP Security Patch Day (Support Portal)
• SAP BTP Security

Next steps: document your reference architecture (zones, protocols, trust boundaries), build an endpoint/service inventory (ICF/OData/RFC), and establish three operating cadences: access governance, patching, and continuous configuration compliance.