Enterprise Security Architecture for SAP Landscapes: Complete Technical Guide

Executive Summary (≈150 words)

Enterprise SAP security succeeds when you treat SAP as a multi-plane architecture—identity, authorization, connectivity, workload hardening, and operations—rather than a set of isolated controls. The highest-impact risks in real SAP breaches remain consistent: over-privileged RFC/service users, “trusted RFC” sprawl, exposed web services (ICF/OData), weak credential and certificate lifecycle, and slow security-note patching.

This guide presents a practitioner-grade reference architecture for modern SAP landscapes spanning S/4HANA (2022/2023), SAP NetWeaver AS ABAP (7.50–7.52), SAP HANA 2.0 SPS06+, SAP Web Dispatcher (7.81+), and SAP BTP with IAS/IPS. It emphasizes actionable configuration patterns: enforcing SSO + phishing-resistant MFA for privileged paths, building least-privilege ABAP roles with SU24 governance, hardening ICM/TLS and SICF service inventory, constraining RFC with UCON and allowlists, encrypting and auditing on HANA, and instrumenting SAP-native signals into SIEM with incident-ready runbooks.

Technical Foundation (≈450 words)

1) The SAP Security Stack as Five Planes

Think in planes that map cleanly to ownership and failure modes:

1. Identity plane (who/what)

   • Corporate IdP (Entra ID/ADFS/Okta/Ping) and/or SAP Cloud Identity Services (IAS/IPS) for SSO, MFA, lifecycle.
   • Web SSO via SAML2/OIDC; SAP GUI/RFC via SNC (Kerberos/X.509).
   • Reference: SAP Cloud Identity Services documentation for IAS/IPS concepts and integration patterns:
     • SAP Identity Authentication – Administration
     • SAP Identity Provisioning – Connectors & Provisioning

2. Authorization plane (what they can do)

   • ABAP: PFCG roles → authorization profiles → AUTHORITY-CHECK.
   • HANA: roles/privileges, analytic privileges, audit policies.
   • Key governance anchor: SU24 as the “default proposal” control point for role engineering drift.

3. Connectivity plane (how it’s reached)

   • DMZ, reverse proxy/WAF, SAP Web Dispatcher, SAProuter, API gateways.
   • Hybrid: SAP BTP Cloud Connector with explicit mapping and minimal exposure.
   • Reference: SAP BTP Cloud Connector – Documentation

4. Workload plane (how it runs securely)

   • AS ABAP: kernel/ICM/Gateway hardening, ICF minimization, secure profile parameters, patching.
   • HANA: encryption (in transit/at rest), audit, least privilege, tenant isolation (MDC).

5. Operations plane (how it is observed and defended)

   • Security Audit Log, ICM/HTTP access logs, Gateway/RFC telemetry, HANA audit logs → SIEM.
   • Continuous controls monitoring and drift detection; incident response with SAP-specific runbooks.

2) Reference Architecture (Text Diagram)

[Users/Devices] 
   |  (SAML/OIDC + MFA, Conditional Access)
[Corporate IdP / IAS] 
   |-----------------------|
   |                       |
(Web)                  (SAP GUI/RFC)
   | TLS                   | SNC (Kerberos/X.509)
[WAF/Reverse Proxy]        |
   |                       |
[Web Dispatcher in DMZ]    |
   | TLS/mTLS              |
[AS ABAP (App Zone)] <----> [Integrations: RFC/HTTP/API Gateway/BTP CC]
   | TLS to DB
[HANA (DB Zone, MDC)]
   |
[Central SIEM/SOAR + PAM + Vault + GRC/IGA]

3) Core Prerequisites (Non-Negotiables)

• Single authoritative identity (consistent person identifiers across systems) to prevent audit discontinuities in principal propagation.
• Cryptographic hygiene: NTP everywhere, certificate inventory, and documented chain-of-trust.
• Segmentation: DMZ entry points and a privileged admin path (bastion + PAM).
• Patch governance: defined SLA for SAP Security Notes and component revisions. SAP publishes security notes and guidance via SAP Support Portal:
  • SAP Security Notes and Updates (overview)

Implementation Deep Dive (≈950 words)

1) Identity & Authentication: SSO-by-Default, MFA for Privileged

A. Web/Fiori: SAML2 or OIDC with Corporate IdP (and IAS where needed)

Recommended pattern

• External users and modern access: SAML2/OIDC at reverse proxy/Web Dispatcher, backed by corporate IdP (or IAS as broker).
• Enforce phishing-resistant MFA (FIDO2/passkeys) for privileged groups and step-up for sensitive apps.

Key controls

• Token lifetime: short (e.g., 5–15 minutes access token) + refresh token policies.
• Group/role claims: avoid “role explosion”—prefer stable group claims mapped to business roles.

References:

• SAP Single Sign-On – Overview and Secure Login Concepts
• SAP BTP Security – OAuth2/OIDC Concepts

B. SAP GUI and RFC: SNC with Kerberos or X.509

Target: eliminate password-based SAP GUI logons for workforce access.

ABAP profile parameters (illustrative baseline)

# Enforce SNC for SAP GUI (plan carefully; rollout with pilot groups)
snc/enable = 1
snc/accept_insecure_gui = 0
snc/accept_insecure_cpic = 0

# SNC identity mapping (example)
snc/identity/as = p:CN=SAPPRD, OU=SAP, O=ExampleCorp, C=US

Operational insight (often missed): SNC failures are frequently time skew + SPN/cert mapping drift, not “SAP being flaky.” Put NTP drift alarms on SAP app servers, IdP components, and domain controllers.

Reference:

• AS ABAP Security Guide – Secure Network Communications (SNC)

2) ABAP Authorization Architecture: Role Engineering as Code

A. Role model that scales (and survives audits)

Use a layered model:

• Business roles (job-based): “AP Accountant,” “Warehouse Picker,” “Plant Maintenance Supervisor”
• Technical roles: printing, specific Fiori app catalogs, background processing, integration endpoints
• Privilege roles: tightly controlled admin capabilities (Basis/Security/DevOps separation)

Anti-pattern to eliminate: composite roles that accumulate “just in case” access until they become de facto SAP_ALL.

B. SU24 governance (the control that prevents entropy)

Treat SU24 changes as security-sensitive configuration, moved only by transport and peer reviewed.

Practical workflow

1. In DEV, update SU24 proposals only with a documented reason (new T-code usage, new Fiori app, etc.).
2. Generate roles in DEV, test in QAS, then transport to PRD.
3. Continuously compare role/profile deltas across clients and systems (drift detection).

Reference:

• AS ABAP Authorization Concept – Roles and Authorizations

C. ABAP authorization checks: verify, don’t assume

In custom ABAP, enforce checks that align with your authorization design:

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 practice (not common enough): build an internal “authorization test harness” that runs ATC + executes representative transactions/OData calls under test users to catch missing checks before production.

Reference:

• ABAP Security – Secure Programming Recommendations

3) Fiori/Gateway/OData: Control Service Exposure + Enforce Backend Authorization

A. Service activation is an attack surface decision

• Maintain an inventory of active SICF nodes and OData services; changes require change tickets and approvals.
• Disable unused services aggressively; default-on is not your friend.

Reference:

• SAP Gateway – Security Guide

B. Authorization is end-to-end

Fiori catalog assignment only exposes tiles; real security is:

• Gateway service authorization objects
• Backend business authorizations
• Data-level filters (org levels/analytic privileges)

Practical test: validate a tile under a minimal role user; confirm no over-broad S_SERVICE / generic access patterns.

4) Interface Security: RFC, Trusted RFC, UCON, API Gateways

A. RFC: least privilege by design

Controls to standardize

• Separate technical users per interface (no shared “RFC_USER”).
• Restrict S_RFC to explicit function groups/modules; avoid wildcards.
• Lock down who can maintain RFC destinations (SM59) and monitor changes.

Trusted RFC
Use only with formal justification. If unavoidable:

• Restrict trust to specific systems, clients, and destinations.
• Add monitoring for trust changes and high-risk calls.

B. UCON (Unified Connectivity): reduce callable surface area

Use UCON to explicitly control remote-enabled function modules and track callers. UCON becomes your “default deny” for RFC exposure without rewriting integrations.

Reference:

• AS ABAP Security Guide – Unified Connectivity (UCON)

C. HTTP/API: treat SAP as an API producer

For internet and partner exposure:

• Put APIs behind an API gateway (rate limiting, threat protection, JWT validation).
• Prefer OAuth2 with scoped access over technical passwords.
• Consider mTLS for system-to-system in high assurance zones.

Reference:

• SAP BTP API Management – Security and Policies

5) Platform Hardening: ICM/TLS, Web Dispatcher, SAProuter

A. TLS configuration and certificate lifecycle

• Terminate TLS in a controlled tier (reverse proxy/WAF and/or Web Dispatcher).
• Enforce modern TLS and cipher suites; remove legacy protocols.
• Centralize certificate ownership with expiry alarms.

ABAP certificate management is performed in STRUST; standardize:

• Separate PSEs per usage where appropriate (SSL server vs client).
• Document chain-of-trust and renewal runbook.

Reference:

• AS ABAP Security Guide – TLS/SSL and PSE Management

B. SAP Web Dispatcher in DMZ (recommended baseline)

• Minimal inbound ports; strict backend routing; preserve client IP safely.
• Pair with WAF for customer-facing scenarios.

Reference:

• SAP Web Dispatcher – Administration and Security

C. SAProuter for vendor connectivity

• Restrictive route permissions and time-bound enablement for support.
• Treat it as Tier-0 infrastructure.

Reference:

• SAProuter – Configuration and Security Recommendations

6) HANA Security: Encryption, Audit, Least Privilege

A. Encryption at rest and in transit

• Enable persistence encryption (data + log volumes).
• Use TLS from app servers to HANA; rotate certificates like any other machine identity.

Reference:

• SAP HANA Security Guide – Encryption and Key Management

B. HANA audit policy: make it actionable

Example: enabling audit logging for critical events (illustrative SQL; adapt to your standard):

-- Create an audit policy for privileged changes (example scope)
CREATE AUDIT POLICY AUD_PRIV_CHANGES
  AUDITING ALL
  FOR CREATE USER, DROP USER, ALTER USER,
      CREATE ROLE, DROP ROLE, GRANT, REVOKE
  LEVEL INFO
  TRAIL TYPE SYSLOG;
ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM')
  SET ('auditing configuration','global_auditing_state') = 'true' WITH RECONFIGURE;

Reference:

• SAP HANA Security Guide – Auditing

Advanced practice: stream HANA audit to syslog/SIEM and correlate with ABAP role/profile changes to detect “split-brain privilege escalation” (ABAP role change + HANA grant within a short window).

7) Logging, Monitoring, and Detection: Turn SAP Signals into SOC Outcomes

A. Minimum viable SAP security telemetry

• AS ABAP Security Audit Log (logon, auth failures, user/role changes)
• ICM/Web Dispatcher access logs (auth anomalies, scanning)
• Changes to RFC destinations and trust relationships
• HANA audit logs

Reference:

• AS ABAP Security Guide – Security Audit Log

B. Example SIEM detections (portable logic)

Detection: new RFC destination created/changed + privileged user

title: SAP SM59 RFC Destination Change by Privileged User
logsource:
  product: sap_abap
  category: change
detection:
  selection:
    event.action: ["SM59_CREATE", "SM59_CHANGE"]
    user.role: ["BasisAdmin", "SecurityAdmin"]
  condition: selection
level: high
response:
  - validate change ticket
  - confirm destination owner + credential source (vault)
  - review S_RFC and trust settings

Detection: sudden expansion of table access rights

• Trigger on role changes that add S_TABU_DIS with broad authorization groups or S_TABU_NAM wildcard-like patterns.

Operational rule: every alert must have (1) an owner, (2) an SLA, (3) a runbook, (4) a suppression strategy—otherwise logs become theater.

Advanced Scenarios (≈560 words)

1) Zero-Trust-Inspired SAP: Privileged Paths as Tier-0

Goal: reduce lateral movement and “implicit trust” inside the network.

Concrete design

• Place SAP admin tools (SAP GUI for admins, HANA Studio/DB tools, OS/virtualization consoles) behind:
  • Dedicated privileged access workstations (PAW) or hardened VDI
  • Bastion/jump host with PAM vault + session recording
• Segment:
  • Admin subnet → app servers (restricted ports)
  • App subnet → DB subnet (only DB ports, TLS enforced)

What changes most organizations underestimate

• Your “internal” RFC and HTTP calls become your primary threat path—treat them like external APIs:
  • mTLS for high-value service-to-service paths where feasible
  • strict egress policies from app servers (reduce exfiltration options)

2) Principal Propagation in Hybrid Landscapes (BTP ↔ On-Prem)

Use principal propagation only when you can preserve a trustworthy identity chain.

Common failure mode: different usernames across IdP, IAS, ABAP, and downstream systems break auditability.

Recommended pattern

• Standardize on immutable identifiers (e.g., corporate GUID) mapped to SAP user IDs consistently.
• For SAP BTP connectivity, use Cloud Connector with least-privilege exposure:
  • Only required virtual hosts and resources mapped
  • Tight admin authorization on Cloud Connector
  • Rotate Cloud Connector admin credentials and keep config backed up securely

Reference:

• SAP BTP Cloud Connector – Access Control and Mapping

3) “Authorization as Code” for SAP (Advanced, High-Leverage)

Most SAP programs stop at “roles in transports.” Mature programs add:

• Role/version repository (Git) for:
  • Role design metadata (naming standards, owners, risk rating)
  • SU24 delta documentation
  • Test evidence (automated traces, SoD checks)
• CI-style checks:
  • ATC security checks on ABAP transports
  • Linting for role changes (detect additions of high-risk objects like S_RFC, S_TABU_*, S_ICF*, broad S_TCODE)

Reference:

• ABAP Test Cockpit (ATC) – Quality and Security Checks

4) Crypto Agility: Prepare for Certificate and Library Transitions

SAP landscapes often fail during certificate renewals due to hidden dependencies:

• Web Dispatcher ↔ ICM ↔ STRUST PSEs ↔ outbound destinations ↔ Cloud Connector ↔ API gateway

Technique: build a “machine identity bill of materials”:

• Endpoint, cert CN/SAN, issuer, expiration, key size, where installed (PSE/path), renewal owner, and test procedure.

This becomes critical as you modernize TLS policies and rotate cryptographic libraries (e.g., aligning CommonCryptoLib versions across estates).

Real-World Case Studies (≈360 words)

Case Study 1 — Manufacturing: RFC Containment Without Breaking MES

Situation: Global manufacturer with ECC coexistence + S/4HANA 2023, heavy MES integrations via RFC. Audit found broad S_RFC and shared technical users across plants.

Implementation

• Introduced per-interface technical users per plant (naming + ownership + vault rotation).
• Implemented UCON allowlists for remotely callable RFC modules; blocked legacy modules no longer required.
• Removed trusted RFC between plant systems except for one justified path; added SIEM detection on trust changes and SM59 modifications.

Outcome

• Reduced RFC callable surface area drastically with minimal interface downtime.
• Audit evidence improved: explicit allowlists + change tracking tied to transports and tickets.

Case Study 2 — Financial Services: “SoD + MFA + Logging” as a Single Program

Situation: SOX-heavy environment; recurring SoD conflicts and weak privileged access controls.

Implementation

• Enforced IdP MFA for privileged users plus step-up policies for sensitive apps.
• Split duties: Basis cannot approve security role changes; security team cannot deploy transports alone.
• Centralized Security Audit Log + HANA audit into SIEM; created “privilege escalation chain” detections.

Outcome

• Fewer emergency access events; faster incident triage with correlated SAP-specific signals.
• Audit cycle time reduced due to repeatable evidence.

Case Study 3 — Retail: Certificate Lifecycle as an Availability Control

Situation: Multiple outages caused by expired TLS certificates across Web Dispatcher, outbound TLS destinations, and Cloud Connector.

Implementation

• Built a certificate inventory with owners and automated expiry notifications.
• Standardized renewal runbooks; tested renewals in pre-prod with synthetic monitoring.

Outcome

• Eliminated certificate-expiry outages; improved change success rate and reduced firefighting.

Strategic Recommendations (≈250 words)

1) Establish Tier-0 SAP Security Baseline (0–90 days)

• Classify Tier-0 assets: S/4, central finance, HR, GRC/IGA, IdP/IAS, Cloud Connector, Web Dispatcher, SAProuter.
• Enforce MFA/conditional access for privileged groups; migrate SAP GUI admins to SNC-based SSO.
• Stand up centralized logging (Audit Log + HANA audit + Web Dispatcher) and define the top 10 detections with runbooks.

2) Reduce the Big Three Attack Paths (90–180 days)

1. RFC exposure: UCON + S_RFC allowlists; eliminate shared technical users; reduce trusted RFC.
2. HTTP/OData sprawl: SICF/OData inventory, change control, TLS hardening, gateway authorization validation.
3. Authorization drift: SU24 governance, role engineering standards, periodic access review with SoD tuning.

3) Operationalize as a Product (180–365 days)

• Treat security notes and config baselines as continuous delivery with SLAs and regression tests.
• Build “authorization as code” discipline: role/versioning, automated checks, consistent org-level patterns.
• Implement machine identity management (certificates/keys) with rotation automation and crypto agility planning.

Decision rule: prioritize controls that simultaneously improve security + auditability + uptime (SSO, certificate lifecycle, logging with runbooks, UCON, and patch governance).

Resources & Next Steps (≈150 words)

Official SAP Documentation (start here)

• AS ABAP Security Guide (NetWeaver AS ABAP)
• SAP HANA Security Guide
• SAP Gateway Foundation – Security Guide
• SAP Cloud Identity Services (IAS) and SAP Identity Provisioning (IPS)
• SAP BTP Cloud Connector
• SAP Security Notes and Updates

Action items for your next architecture review

• Produce a one-page diagram of identity/auth/connectivity planes with owners.
• Inventory: RFC destinations, trusted RFC, active SICF nodes, OData services, certificates, and technical users.
• Define your first 10 SIEM detections and attach runbooks + on-call ownership.