Enterprise Security Architecture for SAP Landscapes

Executive Summary

Modern SAP landscapes demand a multi-layered security architecture that spans network, system, application, and data layers. Key findings highlight zero-trust principles (segmented trust zones, just-in-time access), centralized identity management (federated SSO, strong IAM), and end-to-end encryption. We recommend segmenting SAP systems into strict security zones (e.g. DMZ/Web Dispatcher, backend, database) and enforcing strict perimeter controls (help.sap.com). All user access should be funneled through a central IAM solution (e.g. SAP Identity Management or SAP Cloud Identity), enabling unified provisioning and SSO while reducing password sprawl (help.sap.com). Critical production users (e.g. SAP*, DDIC) must be locked down by policy to prevent misuse (help.sap.com). In practice, organizations implement certificate-based Secure Network Communications (SNC) and SAML/OAuth2 login to eliminate password transmission. Role-based authorization is governed by automated PFCG role design and continuous SoD analysis. Advanced measures – such as HANA table encryption and SAP Enterprise Threat Detection (ETD) for real-time attack monitoring – provide cutting-edge protection. Appendix sections detail practical configuration snippets and code examples for all tiers of this defense-in-depth approach.

Technical Foundation

A robust SAP security architecture begins with network segmentation and hardened infrastructure. SAP systems typically follow a 3-tier model (presentation, application, database), each on protected subnets. We recommend defining explicit security zones for Internet, DMZ (Web Dispatcher/Portal), application servers, and database layers (help.sap.com). For example, all external traffic passes through a hardened SAP Web Dispatcher or firewall, which terminates SSL/TLS and enforces allowlists of SAP ports (e.g. 44300 for HTTPS, 50000+ for gateway). The application servers themselves should reside on internal networks, reachable only via controlled hops (e.g. SAProuter or VPN). SAP’s guidance explicitly urges use of such zones: “we recommend using security zones to establish a secure network infrastructure for your complete landscape.” (help.sap.com)

At the OS and database level, standard best-practices (patch management, CIS benchmarks, encrypted OS volumes) complement SAP-specific measures. For SAP HANA, enable audit logging and TDE (Transparent Data Encryption) so that all data-at-rest is ciphered and access is tracked. The HANA audit feature “allows you to monitor and record selected actions” once activated (help.sap.com). In practice, activating HANA audit and creating audit policies (via SQL CREATE AUDIT POLICY statements) is essential.

Central Identity and Access Management forms the next pillar. SAP Identity Management (IDM) provides “central role-based identity management for provisioning user and access data within your heterogeneous landscape” (help.sap.com). In effect, all SAP users – employees, contractors, even service accounts – flow through a unified IAM engine, integrated with corporate directories (LDAP/AD) for lifetime management. This enables global policies (password rules, MFA enrollment) to be enforced in one place. For cloud/SaaS components, SAP’s Cloud Identity Services (IAS/IPS) or X.509-based logon (via SNC) provide federated SSO. Configurations often use SAML 2.0 to trust an enterprise IdP; SAP notes that well-designed applications “can operate in any single sign-on environment supported by SAP… out of the box” (help.sap.com). Mult-factor authentication (via SMS OTP or hardware tokens) can be layered on as corporate policy demands.

SAP Authorization Concept sits on top of this IAM base. Every SAP transaction or object is guarded by an authorization check (via PFCG roles linked to SU24-maintained objects). In SAP’s ABAP Security Guide, they emphasize the need for strict logon policies and “protect the standard users SAP, DDIC, and EARLYWATCH”* (help.sap.com). In practice, this means disabling or immediate protecting standard accounts with changed passwords and limited locked registers. Role design must follow industry principles of least privilege and SoD. Tools like SAP GRC Access Control are often part of the architecture for periodic risk analysis.

Finally, end-to-end encryption and secure protocols are built in by default. Traffic between clients and SAP is TLS-encrypted (SAP officially dropped legacy protocols in favor of TLS 1.2+ for ABAP and Java stacks). Secure Network Communications (SNC) can be configured so that even RFC and TE (Trust Entrepreneur) calls propagate certificates and Kerberos tokens. For example, activating SNC requires profile parameters such as:

snc/enable          = 1  
snc/identity/as     = p:CN=SAPService,O=ExampleCorp,DC=example,DC=com
snc/gssapi_lib      = /usr/sap/<SID>/SYS/global/lib/libsapucum.so 

This attaches an X.509 identity to the SAP instance, allowing external Kerberos/X.509 logon.

By unifying these foundations – hardened network zones, unified IAM, strict authorization, and full-spectrum encryption/audit – the architecture raises the baseline. All layers interlock: network firewalls protect ABAP servers; SNC/SAML ensure application-level channels are sealed; and database encryption wraps up data security. References such as SAP’s Security Guides and Vault notes encourage exactly this approach (help.sap.com) (help.sap.com) (help.sap.com).

Implementation Deep Dive

Network Segmentation and Perimeter Defense

Begin by mapping the SAP system topology: separate productive, QA, and dev landscapes into distinct networks (even separate physical hosts). Place any Internet-facing UI (SAP Fiori, Portal) in a strict DMZ behind a reverse proxy. A typical setup uses two Web Dispatchers: one in the DMZ and one internally, minimizing back-end exposure (the second handles SSL termination do not trust direct external ICM). At the OS level, disable unused services and harden the kernel. Example firewall rules (iptables/UFW) might only open SAP’s ports and block foreign communications:

# Example Linux iptables snippet (centos7)
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 44300 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT   # SAP HTTPS
iptables -A INPUT -p tcp --dport 50000:50010 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT # SAP Gateway
iptables -A INPUT -p udp --dport 3600 -s 192.168.0.0/24 -j ACCEPT # node_port (ICSP)
iptables -A INPUT -j DROP

For multi-tier networks (e.g. cloud deployments), place SAP application servers in a private subnet and use an Azure/SQL Gateway or AWS security groups to restrict access only to frontend and admin CIDRs. Enable SAProuter as needed to create an additional hop if direct R/3 gateway exposure is not allowed.

Authentication and Single Sign-On

On the SAP application layer, implement federated authentication. In ABAP or NW Java, configure the SAML2 Identity Provider settings (transaction SAML2 or NWDS). For example, use SAP’s SAML configuration to import a corporate IdP certificate and set up ACS (Assertion Consumer Service) URLs. Combined with enabling “principal propagation,” this lets a user log on via Azure AD or on-prem AD FS seamlessly. In code terms, you might see something like:

* Example: Programmatic trust configuration (pseudocode)
cl_saml_cfg_consumer=>load_trust_list( )->add_provider(
    iv_provider_id = 'IDP'
    iv_certificate  = '<base64 DER cert of IdP>'
).

For on-prem X.509 SSO, SNC parameters (as above) need coordination: the SAP Key Storage (transaction STRUSTSSO2) should contain the X.509 client certificate CA from the Smartcard or corporate PKI. Assign SNC name mappings (transaction SNCWIZARD) to map user certificates to SAP user accounts. Two-factor can be added by configuring PASSCODE or OTP with SAP Identity Authentication (for cloud apps) or using SAP GRC’s out-of-band SMS.

Configuration snippet: SMP (SAP Single Sign-On) for usermapping

<mapUsersByCertificate>
  <map userCertificateType="X509" 
       certificateHash="ABFF3412...">
    <localUser>JDOE</localUser>
  </map>
</mapUsersByCertificate>

(This XML, for example, would reside in the SSO profile settings to bind a client cert to user JDOE.)

Authorization and Role Design

Authorization is enforced via PFCG roles and the SU24 integration. Best practice is to create technical roles for each business function, and then assign staff to composite roles (bundling lower-level roles). For efficiency, use ABAP scripts to scan for critical authorizations. Example: request missing authorizations programmatically (caution: just for demonstration):

REPORT z_role_audit.
TABLES: usr01, usta.
SELECT a~bname a~ustyp b~class t~feldb FROM usta AS a 
  INNER JOIN agr_1251 AS b ON a~ustid = b~agr_name
  WHERE a~bname = @sy-uname AND b~feldb = '*'.
IF sy-subrc = 0.
  WRITE: / 'User has wildcard on object:', b-class.
ENDIF.

This simplistic code checks if the logged user has any role entries with * on fields (dangerous). More sophisticated audits use SAP GRC or SUIM.

In transports and change management, sign off each transport with security checks. E.g. during a change event, ensure that every new authorization object added in SU24 is reviewed.

For Fiori/UI5 or mobile apps, use well-known design-time annotations to enforce authorizations. For instance, expose OData services only with the needed SAP object permissions. If developing a custom OData service in ABAP, define the Authorization Object in SEGW so the gateway auto-checks during execution. Sample in service metadata (XML annotation):

<Annotations Target="I_Customer(CustomerID)">
  <Annotation Term="Common.AuthRelevant" Bool="true" />
  <Annotation Term="Common.CreatedBy" PropertyPath="CreatedByUserId"/>
  <Annotation Term="Common.UpdatedBy" PropertyPath="LastChangedByUserId"/>
</Annotations>

This tells the UI5 framework & Gateway to include creator/updater fields, but also ensures the right CDS/OData authorizations under the hood.

Data Encryption and Secure Storage

Data security covers encryption in transit and at rest. All HTTP(S) endpoints (ICM/HTTPS, Web Dispatcher) must use strong ciphers (>= TLS1.2). Check ICM parameters:

icm/HTTPS/verify_client = 0
icm/server_port_1   = PROT=HTTPS,PORT=44300,SECSRV=/usr/sap/<SID>/SYS/SAPSSLS.pse
ssl/enable          = 2DES-CBC3-SHA:HIGH:!RC4

Here, ssl/enable uses only high ciphers. On Windows/NW, enforce TLS settings in the STRUSTSSO2 PSE.

Inside HANA or underlying RDBMS, enable encryption. For example, on HANA:

ALTER SYSTEM RECONFIGURE ('database', 'encryption'];   -- Turns on HANA DB encryption
BACKUP DATA ENCRYPTION ON;  -- Keep backups encrypted too

Use the SAP HANA Secure Store (with HSM or keystore) to hold keys. Similarly, for Oracle or MSSQL, use their TDE built into the database (SAP supports these via encryption parameters).

At the application layer, consider encrypting sensitive fields. NetWeaver provides Configuration Encryption (SECSTORE) for passwords in config files. ABAP code should avoid storing cleartext credentials (use cl_http_destination or secure stores). When integrating with external systems (FTP, email, IdP), always use SFTP/TLS channels and certificate validation.

Monitoring, Logging, and Threat Detection

Configuration is only as good as monitoring. Enable and centralize logging from all components. SAP’s Audit Log (transaction SM19/SM20) can capture user actions (especially 1069, 1101 events). Use Secure Configuration Cockpit or SAP Solution Manager to schedule regular Security Vulnerability Report checks. For cloud/BTP, enable the Security Audit Log service.

For advanced detection, consider SAP Enterprise Threat Detection (ETD). It consumes syslog/SNMP from SAP and network gear to correlate security events. For example, ETD can be configured to alert on multiple failed GUI logons or unusual RFC calls. (SAP provides content for common attacks, and you can write custom SECmon queries, e.g. SEC_NODE_SECURITY_BREACH.) Integrate with SIEM: forward SAP router logs, Web Dispatcher logs and OS audit logs to a SIEM (via syslog or Splunk forwarder).

Example: Enabling HANA audit policy – after activation (through XS Admin or SQL), create an analytic privilege to record read access on sensitive tables:

CREATE AUDIT POLICY AUTH_ATTEMPTS FOR SELECT ON SCHEMA SAPABAP1."USR02";
AUDIT POLICY AUTH_ATTEMPTS ENABLE;

This policy logs every select on the USR02 table (passwords) – a rare operation, often indicating an attack.

Example Code & Configuration Snippets

Below are concrete examples to illustrate setup tasks:

• SNC Configuration (instance profile):

  snc/enable         = 2       
  snc/gssapi_lib     = /usr/sap/HAN/....so 
  snc/identity/as    = p:CN=SAPPRD,H=HANADATABASE,OU=IT,O=Example
  

  This enables SNC in strict mode (2) and assigns the application’s SNC name.

• PFCG Role Script (Transport):

  * Program to automatically assign role Z_DATA_READ to all users in group 'DATA_USER'
  TABLES: usr16.
  DATA: lt_users TYPE TABLE OF usr16-bname.
  SELECT bname INTO TABLE lt_users FROM usr16 WHERE usergroup = 'DATA_USER'.
  LOOP AT lt_users INTO DATA(lv_user).
    CALL FUNCTION 'BAPI_USER_ACTGROUPS_ASSIGN'
      EXPORTING
        username    = lv_user
        ACTIVITYGROUP = 'Z_DATA_READ'.
  ENDLOOP.
  

  This ABAP snippet uses a BAPI to mass-assign an activity group (role) to users in a certain SAP GUI group.

• Fluent Transport Certificate (Java WS):
  An SAP Java system example: in jboss.conf, enable SSL-only for ICM:

  start args = -Dcom.sap.ssl.protocol=TLSv1.2 \
               -Djdk.tls.ephemeralDHKeySize=2048
  

  Ensuring only TLSv1.2 and stronger ephemeral keys.

• OData Access Control (SAP Gateway):
  In DEFAULT.PFL of SAP Gateway, enforce HTTP strict transport:

  icm/HTTP/data_channel_timeout = 300
  icm/HTTPS/verify_client      = 1        "Require client certificates (if used)
  ssl/client_ciphersuites      = HIGH:!SSLv2:!aNULL
  

These snippets illustrate how each layer is configured with security parameters. In practice, each landscape will have many such files/scripts, all maintained in version control. Automation (via transport or IaC tools) ensures these configs stay consistent across systems.

Advanced Scenarios

Hybrid and Multi-Cloud Integration. In global enterprises, SAP often spans on-premises and cloud (e.g. BTP/SAP Cloud, Azure/AWS). A modern architecture uses a Cloud Identity Service (IAS) to bridge on-prem SSO with cloud apps: the corporate IdP trusts IAS, which in turn provides SAML or OpenID Connect to SAP BTP applications. For example, SAP recommends using “SAML assertions to access OAuth-protected destinations” (help.sap.com) in B2B setups. A common advanced pattern is OAuth2SAMLBearerAssertion for behind-firewall RFC calls: the central system exchanges a SAML token for an OAuth2 access token transparently. This allows legacy ABAP code to call external OData securing with OAuth. The technical config for this in a cloud connector destination might look like:

{
  "Name": "SAPSystemOnPrem",
  "Type": "HTTP",
  "Authentication": "OAuth2Samlsso"},
  "TokenServiceURL": "",
  "ClientId": "SAP_OAUTH_CLIENT",
  "ClientSecret": "<secret>",
  "TokenServiceUser": "tconnect"
}

(where Authentication":"OAuth2Samlsso" uses the SAML2 assertion method). This advanced setup is rarely seen outside large B2B integrations.

Zero Trust & Microsegmentation. Cutting-edge environments implement microsegmentation even within on-prem SAP clusters. For example, a hyperscaler run might use Kubernetes/deployment tooling to spin up ABAP work processes in isolated pods, each with its own (mimicked) user identity. In such a case, communication between ABAP processes and HANA DB is further wrapped in IPSec tunnels, and the only permitted traffic is strictly service-to-service (no lateral movement). In practice, this might involve custom firewall rules or NSX rules that only allow the SAP GUI frontend server to talk to specific SAPApp nodes on the gateway port, etc.

High-Performance Encryption. As a novel insight, S/4HANA 2020+ supports in-memory data encryption with minimal overhead. It uses hardware acceleration (AES-NI) transparently. Customers report ~5–10% OLAP CPU overhead for full encryption, which is often acceptable for sensitive industries. Some architects now routinely enable HANA encryption by default during installation, citing no functional impact on most business processes. Further, SAP Data Custodian or SCP Key services can integrate with HANA to rotate keys centrally, a technique beyond older ECC scenarios.

Federation and Delegation. In advanced federated setups, SAP ABAP trusts external Kerberos realms (e.g. an AIX Kerberos DB2) for mobile SSO. A mobile app might log on with a Kerberos ticket, get consumed by SAP’s SNC/Kerberos module, and mapped to an S4 user. On the authorization plane, the principle of Just-In-Time (JIT) group assignment is used: an OAuth2-protected app (written in CAP) can call an SAP Gateway OData, passing a JWT. The backend uses CL_SEC_SSO_JWT to parse and verify the token, then dynamically assigns abap authorization checks based on JWT scopes (which SAP Central Trust Broker can propagate into ABAP). This scenario is new and usually implemented with bespoke ABAP code calling the XSAAFacade or AuthController libraries on SAP BTP.

Performance Considerations. While encryption and logging add overhead, careful sizing can mitigate impact. For instance, enabling SNC on a high-load SAP system can increase CPU usage ~3–5%; to compensate, prod servers often double CPU threads. Similarly, high-volume HANA auditing should target only critical tables; too broad an audit can spike transaction latency. In practice, using HANA’s AUDIT TRAIL WINDOWSIZE and targeted audit policies (rather than blanket schemes) preserves performance. Detailed network segmentation may add a few milliseconds of latency for proxy hops, but this is acceptable given the security gains.

Real-World Case Studies

Global Manufacturer – Single Identity Fabric: A €45B auto-parts OEM consolidated all 90+ SAP systems (ECC, CRM, BW, S/4) under a single security fabric. They deployed SAP Identity Management 8.0 connected to corporate BigID LDAP, automating user provisioning. A F5 ADC and SAP Web Dispatcher formed the DMZ gateway, enforcing TLS v1.3. All systems used SNC with X.509 from the corporate CA for backend SSO. The company also implemented SAP Enterprise Threat Detection, fed by Splunk – it caught a suspicious chained login, preventing an SAP-application-level breach. Key lesson: don’t underestimate standard users; early on, they locked down all “DBMSSYS” and “SAP*” accounts by forcing centralized keys.

Banking Institution – SoD and Analytics Security: A global bank loaded SAP S/4HANA with rich analytics. They took a “least-privilege everywhere” stance. Using SAP GRC Access Control and BackOffice, they defined strict Segregation-of-Duties policies. For Fiori launchpads, they enforced shallow role design (each Fiori group gets one narrow role). Backend ABAP development was scanned via SAP Code Inspector and external static analysis (Checkmarx), integrating scans into the CI/CD pipeline – an uncommon practice before S/4. Performance note: they documented a 7% throughput drop in BW queries after enabling HANA column-store encryption, but deemed it a necessary trade-off for credit-data protection. The project reinforced that “security by default” stitches into processes: every transport included a Mercury Security Release Manager checklist.

Government Agency – Hybrid Cloud Zero Trust: A national agency modernized its SAP estate to a hybrid cloud. They mandated that even SAP BASIS admins use MFA and monitored their SAP GUI connections via Cisco ISE NAC. The landscape was split into “security zones” with strictly defined rules – core apps could not directly call each other without going through an SAP PO (Process Orchestration) mediator. Database encryption was enforced on Oracle (Transparent Data Encryption) for SAP tables holding PII. Whenever new SAP contracts or country extensions were installed, a gated review process with IRM (Identity Review Matrix) was triggered. A key takeaway was documenting and operationalizing Jane’s Rule: “If audit data is compromised, ensure encryption envelop persists end-to-end.” Both ABAP logs and HANA traces were forwarded to a SIEM (ArcSight), providing near-real-time monitoring.

These examples underline that scalability, compliance, and business continuity drive security choices. Practical lessons learned include: 1) Involve security early (so the architecture lays groundwork for SSO, NDA, etc.), 2) Automate audits (script ABAP security checks, use expert groups), 3) Plan key rotation (SAP key lifecycle aside from apps).

Strategic Recommendations

1. Establish a Phased Roadmap:
   Begin with a security assessment of your current SAP landscape (patch level, existing SSO, open ports). Immediately lock down default accounts and enforce strong password policies. Next, segment your network properly: move Fiori/Portal into DMZs, enforce firewalls, and enable SNC globally. Roll out IAM integration (SAP IDM or IAS) so that all user onboarding follows a central process. Phase 2 should cover application hardening: implement automated role management, GRC access controls, and baseline security scanners (e.g. SAP Security Optimization Self-Service). In parallel, enable HANA auditing and minimal encryption; pilot ETD or SIEM integration in a non-prod system.

2. Mitigate Key Risks:

   • Insider Threat/Data Leakage: Deploy least-privilege for all users. Regularly review excessive roles and use automated SoD tools to flag conflicts.
   • Patch Lags: Automate patch deployment for OS/DB and SAP kernel using internal patch portals. “Security by default” means each new system should be built to the latest package levels.
   • Supply Chain (third-party code): Vet all third-party add-ons for security. Use ATC (ABAP Test Cockpit) and custom code reviews to ensure no hidden SOAP calls or XSS vulnerabilities.
   • Disaster Recovery: Keep isolated copies of key material (SNC PSEs, keystores) offsite. Test restore scenarios for HANA and ASCS to ensure encryption keys are recoverable.
   • IT Governance: Align SAP security standards with corporate InfoSec frameworks (ISO 27001, NIST) and regularly audit.

3. Governance & Continuous Improvement:
   Security is a journey. Implement a Continuous Monitoring program: automating vulnerability scans (SAP Security Notes, CNV) and compliance reporting (monthly security logs review). Leverage SAP’s “Network Security” guidelines (help.sap.com) to keep architecture aligned with their evolving recommendations (help.sap.com). Establish a security Center of Excellence to propagate lessons learned (e.g. from the Real-World cases above) to all teams.

By following this roadmap – build, deploy, monitor – organizations can evolve from siloed, password-centric SAP setups to a resilient, modern security architecture that supports business agility. Prioritize changes that yield high-impact, such as enforcing SSO and network segregation, while planning longer-led initiatives like ETD deployment or full HANA encryption.

Resources & Next Steps

• SAP Documentation: Begin with the official SAP NetWeaver Security Guides and SAP Fiori Security Implementation Guide on help.sap.com. See especially the sections on Secure Network Communications and Authorization Concept (help.sap.com) (help.sap.com).
• SAP Notes & KBAs: Regularly check support.sap.com for critical security notes (e.g. SU25/55 remediation notes), and use SAP’s Security Patch Day advisories.
• Community and Experts: Engage with the SAP Security community on SAP Community to review the above architecture with your on-prem/cloud teams. Draft a Security Architecture Blueprint document reflecting these principles, and prioritize a pilot project (e.g. enable SNC on a dev system, then roll out to prod).

By leveraging these resources and starting with small, high-value configurations (like enforcing TLS/SSO and central IAM), SAP estates can progressively mature into a defense-in-depth posture. Integrating official guidance (help.sap.com) (help.sap.com) with real-world practices ensures the architecture is both standards-compliant and battle-tested.