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 succeeds when treated as architecture, not a collection of Basis “hardening tasks.” In modern hybrid landscapes (S/4HANA on-prem or RISE Private Cloud + BTP + SaaS), the dominant risks are consistent: over-privilege, uncontrolled technical users/interfaces, weak trust boundaries, certificate/crypto lifecycle failures, and incomplete monitoring.

This guide presents a layered reference architecture spanning IAM, network segmentation, ABAP authorization engineering, HANA data protection, BTP authorization, and SecOps, with implementation patterns you can standardize across ABAP, Java, HANA, Fiori, integration middleware, and SAP cloud services.

Key recommendations:

1. Make identity federated by default (SAML/OIDC) and enforce MFA + conditional access at the IdP; eliminate SAP-local passwords wherever possible.
2. Redesign authorization around clean SU24, consistent org-level strategy, and privileged access containment (Firefighter/break-glass).
3. Apply explicit SAP security zones (DMZ/app/db/admin) with default-deny east-west traffic and hardened RFC/Gateway controls.
4. Treat interfaces as products: per-interface service identities, secret rotation, OAuth scopes, and continuous detection.

Technical Foundation (≈400–500 words)

1) The core distinction: Identity vs. Authorization (and why SAP breaks teams)

SAP landscapes frequently centralize authentication but leave authorization fragmented. Architecturally, treat these as separate planes:

• Identity (AuthN): Corporate IdP (Microsoft Entra ID/Azure AD, Ping, Okta, ADFS) and/or SAP Identity Authentication (IAS) as broker for SAP cloud. IAS commonly terminates SAML/OIDC and delegates to the corporate IdP. See: SAP Identity Authentication – Documentation.
• Authorization (AuthZ):
  • ABAP: PFCG roles → authorization objects/fields checked at runtime (e.g., AUTHORITY-CHECK). Baseline concepts are covered in AS ABAP Authorization Concept.
  • HANA: database roles, privileges, analytic privileges, audit policies. See SAP HANA Security Guide.
  • BTP: scopes/roles/role collections mapped into JWT claims via XSUAA (Cloud Foundry) or equivalent services. See SAP BTP Security.

Architectural implication: Your enterprise security model must define “who you are” once (IdP + lifecycle), but “what you can do” is enforced inside each runtime (ABAP kernel checks, HANA engine privileges, BTP scopes).

2) The SAP security “blast radius” problem

SAP is a high-trust platform by design: broad data reach, powerful technical tooling, and deep integration. Small misconfigurations can create disproportionate impact:

• Over-privileged RFC users enable lateral movement across systems.
• Missing AUTHORITY-CHECK in custom RFCs can bypass role design entirely.
• Excessive table authorizations (S_TABU_*) often become “silent data exfiltration.”

3) Reference architecture: Layers + zones + trust boundaries

Layer model (practical for standards and control objectives)

1. IAM (identity lifecycle, federation, PAM)
2. Network & connectivity security (zones, proxy, firewall, VPN, Cloud Connector)
3. Application & authorization security (ABAP roles, Fiori catalogs, gateway, custom code controls)
4. Data & platform security (HANA encryption/audit, OS hardening, virtualization/cloud controls)
5. Security operations (logging, SIEM, vulnerability mgmt, incident response)
6. GRC (SoD, ITGC, evidence, continuous controls)

Zone model (what “good” looks like in hybrid SAP)

flowchart LR
  Internet((Internet)) --> WAF[WAF / Edge Proxy]
  WAF --> WD[SAP Web Dispatcher<br/>DMZ]
  WD --> FES[S/4HANA Fiori Front-End<br/>(if separate)]
  WD --> ICM[ABAP ICM (HTTPS)]
  ICM --> APP[ABAP App Servers<br/>PAS/AAS]
  APP --> ASCS[ASCS/ERS<br/>Central Services]
  APP --> DB[(SAP HANA<br/>DB Zone)]
  APP --> SIEM[(SIEM/SOC)]
  Admin[Admin Jump Host<br/>Privileged Access Zone] --> APP
  Admin --> DB
  APP --> BTP[SAP BTP Services<br/>XSUAA/Destinations]
  BTP --> SaaS[SAP SaaS (e.g., Ariba/SuccessFactors)]

Rule of thumb: treat connectivity components (Cloud Connector, VPNs, RFC trusts, integration runtimes) as privileged infrastructure with tight admin access, change control, and monitoring.

Implementation Deep Dive (≈800–1000 words)

1) Identity & SSO: “central IdP everywhere” without breaking SAP realities

Pattern A1: IAS as broker + corporate IdP as source of truth (hybrid standard)

• Corporate IdP: MFA, conditional access, device posture
• IAS: SAP cloud federation hub and application SSO front door

Implementation notes:

• Standardize identifiers: use an immutable enterprise key (e.g., employeeID) and map to SAP user (BNAME) or email/UPN only as a display attribute.
• Plan certificate rollover: SAML signing/encryption cert rotation is a frequent outage source—treat it like patching with a runbook.

Concrete configuration steps (recommended baseline)

1. Decide the canonical user ID

   • If your ABAP systems have strict naming rules (e.g., 12-char BNAME), define a transform policy early (e.g., EMP<employeeID>).
   • Document mapping: subjectNameId (SAML) / sub (OIDC) → IAS user → ABAP BNAME.

2. Corporate IdP → IAS trust (SAML 2.0 is the most common)

   • In IAS: Applications & Resources → Trust Configuration
     • Add Corporate IdP as Trusted Identity Provider
     • Upload IdP metadata (XML)
     • Set NameID format: typically urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified or emailAddress based on strategy
     • Configure Default Assertion Attributes (examples):
       • mail → mail
       • given_name → firstName
       • family_name → lastName
       • employeeID → custom attribute (recommended)
   • In Corporate IdP: configure Enterprise App for IAS
     • Sign SAML assertions using SHA-256
     • Set Assertion validity (e.g., 5–10 minutes) to reduce replay window
     • Enforce MFA and conditional access policies (device compliance, geolocation, risk)

3. IAS → SAP cloud application (S/4HANA Cloud, BTP, Ariba, etc.)

   • Use IAS as the application’s IdP; download IAS metadata and import to the target service.
   • Maintain a certificate rollover calendar:
     • T-30 days: publish upcoming cert in “secondary” slot (if supported)
     • T-7: test in non-prod
     • T-0: switch; monitor login error rates

4. Joiner/Mover/Leaver controls

   • Ensure the authoritative HR source disables the identity, then IdP blocks authentication immediately.
   • In parallel, run SAP deprovisioning to remove roles and lock users (SU01 lock or IDM job).
   • Operational KPI: time-to-disable access across IdP + SAP systems.

Reference: IAS – Configure Trust with Corporate Identity Provider

Pattern A2: ABAP Fiori SSO with SAML2 (ABAP as Service Provider)

Even in on-prem S/4HANA, a common target state is browser SSO for Fiori using SAML2.

Step-by-step (ABAP)

1. Enable HTTPS and validate certificates

   • Transaction: STRUST
     • Ensure SSL Server PSE exists (e.g., SSL Server Standard)
     • Import full chain (root + intermediate) of issuing CA
   • Transaction: SMICM
     • Verify HTTPS is active; check ICM parameters in instance profile (examples):
       • icm/server_port_1 = PROT=HTTPS,PORT=443$$,TIMEOUT=600,PROCTIMEOUT=600
       • ssl/client_ciphersuites = 135:PFS:HIGH::EC_P256:EC_HIGH
     • Validate with browser/openssl from client network.

2. Configure SAML2

   • Transaction: SAML2 (ABAP SAML 2.0 Configuration)
     • Create local Provider (SP) if not present
     • Import IdP metadata (IAS or corporate IdP)
     • Maintain Trusted Providers and enable Assertion Consumer Service endpoints
     • Set Subject NameID mapping (align with BNAME strategy)
     • Configure User ID mapping:
       • Option: “E-Mail” → SU01 email field (works only if unique + maintained)
       • Option: “Logon ID” via custom attribute (preferred for stability)

3. Enforce SSO for ICF services

   • Transaction: SICF
     • For /sap/bc/ui2/flp and OData services, set Logon Data to SAML2 where appropriate.
   • Transaction: RZ10 (or profiles)
     • Consider restricting fallback mechanisms:
       • login/password_downwards_compatibility = 0 (where feasible)
       • login/min_password_lng = 12 and login/min_password_digits = 1 etc. (if passwords remain)

4. Test and monitor

   • Validate SP-initiated and IdP-initiated flows
   • Enable security logging for authentication events (see SecOps section).

SAP GUI/RFC SSO with SNC (Kerberos/X.509)

For classic SAP GUI access, remove password reliance via SNC:

• Kerberos (SPNEGO) in Windows-heavy enterprises
• X.509 for cross-platform / high assurance

Concrete SNC parameters (ABAP instance profile examples)

• Enable SNC and enforce it:
  • snc/enable = 1
  • snc/identity/as = p:CN=SAPPRD, OU=SAP, O=ExampleCorp, C=US
  • snc/accept_insecure_gui = 0
  • snc/accept_insecure_rfc = 0
  • snc/data_protection/use = 3 (maximum protection)

SAP GUI client-side

• SAP GUI → Options → SNC
  • Select SNC library (e.g., gsskrb5.dll for Kerberos)
  • Maintain SNC Name (matches directory identity)

Operational guidance

• Enforce “no password login” for user populations where SNC is deployed.
• Monitor fallback authentication (password logon spikes) as an intrusion signal.

Reference: Secure Network Communication (SNC) for AS ABAP

2) ABAP authorization engineering: SU24-first, org-level consistency, and “contain power”

Pattern B1: Build roles from clean SU24 defaults (not from historical role copies)

Why it matters: Role creep often comes from repeated “copy + add missing auth” cycles.

Practical approach:

1. Baseline SU24 for used transactions/services
2. Define org-level policy (which org fields are mandatory vs. derived)
3. Generate roles and remediate deltas via controlled change process

Step-by-step: SU24-first role build

1. Inventory used applications
   • Pull production usage via ST03N / workload, SUIM, or Fiori usage analytics.
2. Adjust SU24 defaults where necessary
   • Transaction: SU24
   • For each transaction (or service), verify:
     • Proposed authorization objects are correct
     • Check indicators (“Check/Maintain”) align with expected behavior
   • Avoid “wildcard defaults” that force broad authorizations into every role.
3. Generate role authorizations
   • Transaction: PFCG
     • Create single role Z_FIN_AP_CLERK
     • Assign transactions / Fiori catalogs as per design
     • Go to Authorizations tab → Change Authorization Data → Generate
   • Maintain organizational levels consistently:
     • Define which org fields are mandatory (e.g., BUKRS, WERKS, VKORG)
     • Use derived roles where strategy requires multi-org assignment without copying auth content
4. Remove noise and enforce least privilege
   • Use SUIM to compare roles and identify “creep” objects:
     • S_DEVELOP, S_TABU_DIS, S_TABU_NAM, S_RFC, S_USER_*, S_ADMI_FCD
   • Where unavoidable, constrain fields (e.g., ACTVT, RFC_TYPE, authorization groups).

Reference: Authorization Defaults (SU24) in AS ABAP

ABAP code example: enforce least privilege in custom development

When custom programs access sensitive data, ensure explicit checks (and log failures meaningfully).

DATA: lv_bukrs TYPE bukrs VALUE p_bukrs.

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.

Hardening guidance (often missed)

• Enforce ATC gates for authorization checks in transport flow (especially for RFC-enabled modules and OData exposures).
• Treat “debug” and “replace” rights as privileged. Developers should not carry production debug authorization by default.

Concrete ATC/quality control

• Create an ATC check variant that includes security-relevant checks (including missing auth checks where applicable).
• Integrate into transport release:
  • Use ATC in central quality system
  • Block release if findings exceed threshold
• Require secure patterns for RFC/OData:
  • Always call AUTHORITY-CHECK in remotely callable function modules
  • Avoid “technical user bypass” flags unless explicitly approved and logged

Reference: ABAP Test Cockpit (ATC) – Quality and Security Checks

Pattern B2: Privileged access containment (Firefighter done correctly)

Permanent admin access is the #1 audit and breach accelerant in SAP.

Implementation checklist:

• No permanent SAP_ALL/SAP_NEW for humans.
• Separate duties: user admin ≠ role admin ≠ transport admin.
• Use time-bound elevation via GRC EAM or enterprise PAM.

Concrete SAP controls to implement

1. Define privileged role sets (and keep them small)

   • Basis admin (system config): S_ADMI_FCD, S_RZL_ADM, S_SMGW_*, S_ICM, etc.
   • Security admin (user/role): S_USER_*, S_USER_GRP, S_ROLE_*
   • Transport admin: S_TRANSPRT, S_CTS_ADMI
   • Table maintenance / data admin: tightly controlled S_TABU_DIS / S_TABU_NAM

2. Implement Emergency Access Management (EAM)

   • SAP GRC Access Control (common) or external PAM with named elevation.
   • Mandatory features:
     • Reason code required
     • Time window (e.g., 2 hours)
     • Session logging (commands + SAP transactions)
     • Post-approval review workflow
   • Process control: every Firefighter session must be reviewed within 24–48 hours.

3. Lock down “backdoors”

   • Restrict who can assign profiles directly (avoid S_USER_PRO)
   • Protect role maintenance:
     • Only a small group has PFCG change with transport controls
   • Restrict debug in production:
     • S_DEVELOP with DEBUG should be granted only via EAM

Reference: SAP GRC Access Control – Emergency Access Management

Pattern B3: Technical users and interfaces—least privilege with traceable intent

Interfaces are where SAP estates quietly become “flat networks.” Treat every interface as a governed asset.

ABAP technical user standards

• Use dedicated Communication or System users (not Dialog).
• Set:
  • Password policy aligned with corporate standard
  • Validity period (if process allows) and documented owner
  • Disable interactive logon (where possible) by policy and monitoring
• Assign only interface-specific roles (avoid “integration catch-all” roles).

Harden RFC usage

• Transaction: SM59
  • Use Trusted RFC only with strict controls; avoid broad trust.
  • Prefer SNC-protected RFC (Kerberos/X.509) rather than stored passwords.
• Transaction: SMGW (Gateway Monitor)
  • Enforce Gateway security files:
    • reginfo (registered programs)
    • secinfo (external connections)
  • Set profile parameters (example pattern; confirm for your release and design):
    • gw/reg_info = <path>/reginfo
    • gw/sec_info = <path>/secinfo
  • Implement default-deny with explicit allow rules.

Example reginfo/secinfo approach (principle)

• Allow only known program IDs and known source hosts/subnets.
• Deny everything else and log denies for SOC review.

Protect RFC-enabled custom function modules

• If a function module is RFC-enabled, assume it will be attacked.
• Add authorization checks and input validation; reject “*” wildcards and unbounded selections.
• Add application logging (SLG1) for sensitive actions.

3) Network & connectivity security: zones, default-deny east-west, and SAP-specific controls

Pattern C1: SAP Web Dispatcher and TLS termination in DMZ (with hardening)

Your Web Dispatcher (or reverse proxy) is your Fiori blast shield—treat it like an internet-facing tier even if “internal only.”

Concrete hardening checklist

1. TLS configuration
   • Use modern TLS policies (TLS 1.2+; consider TLS 1.3 where supported by your proxy layer).
   • Enforce strong cipher suites (organization standard).
2. Header and request protection
   • Restrict HTTP methods to what you need.
   • Add request size limits to reduce DoS risk.
3. Route control
   • Only forward to required ICM endpoints.
   • Remove legacy admin endpoints from reachable paths.

SAP Web Dispatcher profile examples (illustrative)

• Define HTTPS port:
  • icm/server_port_1 = PROT=HTTPS,PORT=443,TIMEOUT=600
• Limit request size (set based on your usage; example):
  • icm/HTTP/max_request_size_KB = 10240
• Logging:
  • icm/HTTP/logging_0 = PREFIX=/usr/sap/<SID>/W00/log/httplog, LOGFORMAT=...

(Exact parameters vary by version; standardize via a golden profile and validate against SAP notes for your release.)

Pattern C2: Protect ABAP ICM/ICF services—reduce attack surface

• Transaction: SICF
  • Deactivate unused services (common offenders are legacy or test endpoints).
  • Require SSO where possible; avoid “Basic Authentication” for browsers.
• Transaction: SMICM
  • Monitor ICM errors and suspicious spikes.

Practical step-by-step

1. Export ICF service list and classify:
   • Business-critical (keep)
   • Needed for tech (keep, but restrict)
   • Not used (deactivate)
2. For OData:
   • Validate every activated service has an assigned authorization concept (IWSG/IWSV objects depending on architecture).
3. Implement change control: no new SICF activations without security review.

Pattern C3: Admin access via jump host + segmented management plane

• No direct admin from user LAN to DB zone.
• Admin access requires:
  • Jump host
  • MFA
  • Session recording (PAM)
  • Separate admin identities

Ports and flows to document (minimum)

• User → Web Dispatcher (443)
• Web Dispatcher → ABAP ICM (443)
• ABAP app → HANA (3xx15, e.g., 30115) only from app subnet
• Admin jump → ABAP (32xx, 33xx, 36xx, 443 as needed)
• Admin jump → HANA (3xx15/3xx13) only for DB admins

4) Data & platform security: SAP HANA, encryption, and auditable configuration

Pattern D1: HANA encryption (at rest) + secure key management

For regulated environments, treat encryption as mandatory—not optional.

HANA encryption targets

• Data volumes (persistence)
• Log volumes
• Backups (and backup transport)
• Key management process (rotation, storage, access)

Concrete procedures (high level; adapt to your ops model)

1. Decide key management:
   • Native HANA encryption keys (managed in HANA)
   • External key manager (where required by policy)
2. Enable encryption and verify status:
   • Use HANA cockpit / SQL to verify persistence encryption state.
3. Ensure backups are encrypted and stored securely:
   • If using file-based backups, ensure filesystem + transport encryption.
   • If using third-party backup tools, validate end-to-end encryption and access controls.

Pattern D2: HANA roles and least privilege (avoid “everyone is DBADMIN”)

• Separate schema owners from runtime users.
• Applications should connect with least-privileged technical users.
• Use analytic privileges for data-level restrictions in calculation views where relevant.

Example: create a dedicated technical user and grant minimal roles (illustrative SQL)

CREATE USER APP_S4_RUNTIME PASSWORD "UseASecretFromVault!";
ALTER USER APP_S4_RUNTIME DISABLE PASSWORD LIFETIME;

-- Grant only what is required (example placeholders)
GRANT SELECT ON SCHEMA S4H TO APP_S4_RUNTIME;
-- Prefer granting via roles, not direct object grants:
CREATE ROLE ROLE_S4_APP_READ;
GRANT SELECT ON SCHEMA S4H TO ROLE_S4_APP_READ;
GRANT ROLE ROLE_S4_APP_READ TO APP_S4_RUNTIME;

Key operational rule: credentials for DB technical users must be stored in a secrets vault and rotated on a defined schedule (e.g., 60–90 days) or immediately after staff changes.

Pattern D3: HANA auditing—turn logs into detections

Enable HANA audit policies aligned to your threat model:

• Logon/logoff
• Failed logons
• Privilege changes
• User/role creation
• Critical configuration changes

Implementation approach

1. Define audit policy set (baseline + high-risk).
2. Forward to SIEM:
   • Use your logging pipeline (agent/connector) to centralize.
3. Create SOC detections:
   • Multiple failed logons for privileged accounts
   • New user creation outside change window
   • Granting powerful roles (e.g., system-wide privileges)

5) BTP authorization & service-to-service security: scopes, role collections, and secrets hygiene

Pattern E1: XSUAA scopes mapped to business roles (not “everyone gets Administrator”)

In BTP (Cloud Foundry) applications, authorization is typically enforced via OAuth scopes in JWTs.

Practical design

• Define scopes per API capability (e.g., ReadInvoices, PostPayments, Admin)
• Map scopes → role templates → role collections
• Assign role collections to users/groups from IAS/IdP

Example (conceptual) XSUAA security descriptor snippet

• Scopes:
  • $XSAPPNAME.Read
  • $XSAPPNAME.Write
  • $XSAPPNAME.Admin
• Role templates:
  • InvoiceViewer → Read
  • InvoiceClerk → Read + Write
  • SecurityAdmin → Admin

Operational controls

• Assign role collections to IdP groups, not individuals.
• Require change approval for:
  • Adding users to admin role collections
  • Expanding scopes

Pattern E2: Destinations + Cloud Connector as privileged connectivity

Treat BTP Destination service and Cloud Connector as sensitive because they bridge networks.

Controls to standardize

• Each destination has:
  • Named owner
  • Purpose and data classification
  • Auth method explicitly justified (OAuth preferred)
• Rotate secrets:
  • If basic auth is unavoidable, store credentials in a vault and rotate.
• Restrict Cloud Connector mappings:
  • Expose only required internal hosts and ports
  • Use separate Cloud Connector instances or subaccounts for segmentation when warranted

6) Security operations: logging, monitoring, vulnerability management, and incident readiness

Pattern F1: Turn on the right SAP logs (and forward them)

“Logging exists” is not the same as “logging is useful.” Define a minimum telemetry baseline.

ABAP (core sources)

• Security Audit Log (SAL): logon attempts, RFC logons, user changes (configure to your policy)
• SM20: review SAL entries
• STAD / ST03N: usage and workload (helpful for anomalies)
• SM21: system log (kernel-level)
• SLG1: application logs (make custom code write meaningful events)
• SMGW / Gateway logs: blocked connections (critical when using secinfo/reginfo)
• ICM HTTP logs: unusual requests to OData/Fiori endpoints

HANA

• Audit logs (as defined earlier)
• Expensive statement trace (use carefully) for suspicious data extraction patterns

BTP

• Cloud logs (application/router)
• XSUAA access logs (where available)
• Audit logs for role collection changes

Step-by-step: operationalizing SAP logs

1. Define an event taxonomy:
   • Auth events, privilege changes, interface failures, data extraction anomalies
2. Forward to SIEM:
   • Decide transport (agent, syslog, API connector)
3. Build detections:
   • “New RFC destination created” (SM59 change)
   • “Gateway secinfo deny spikes”
   • “Firefighter session started outside business hours”
4. Create playbooks:
   • What to do when an alert fires (containment + evidence + escalation)

Pattern F2: Vulnerability management—SAP Notes, kernel updates, and crypto libraries

SAP landscapes require disciplined patching across multiple layers:

• ABAP/Java stack patches (SPs/SPS)
• Kernel patches
• DB patches (HANA revisions)
• 3rd party components (OpenSSL where applicable, OS libs)
• SAP crypto library updates (CommonCryptoLib)

Concrete process (monthly cadence recommended)

1. Collect security updates
   • Review SAP Security Notes (weekly release)
   • Track relevant CVEs for OS/DB layers
2. Assess applicability
   • Map notes to your components/versions
3. Patch pipeline
   • Sandbox → Dev → QA → Prod with rollback plan
4. Verify
   • Confirm note implementation and regression tests
   • Re-run vulnerability scans and configuration checks

Operational guardrails

• Do not let kernel/crypto library drift for years—certificate issues and TLS weaknesses often trace back to outdated libs.
• Maintain a certificate inventory (ABAP STRUST, Web Dispatcher PSEs, Java keystores, proxies).

Pattern F3: Incident readiness—what to pre-build for SAP

When SAP is involved, investigations fail without preparation.

Pre-build checklist

• Ensure time sync (NTP) across SAP, DB, proxy, SIEM (for forensic timeline integrity)
• Ensure you can quickly answer:
  • Who did what? (user + role + transaction/service)
  • From where? (source IP/device if available)
  • Through which interface? (RFC destination, OData service, CPI iFlow)
• Maintain emergency runbooks:
  • Lock user (SU01) and invalidate sessions
  • Disable RFC destination (SM59)
  • Block gateway access (update secinfo/reginfo)
  • Temporarily disable an ICF service (SICF) if exploited

Implementation Deep Dive (≈800–1000 words)

1) Identity & SSO: “central IdP everywhere” without breaking SAP realities

(See Patterns A1–A2 above; ensure your program includes certificate lifecycle, fallback monitoring, and deprovisioning SLAs.)

2) ABAP authorization engineering: SU24-first, org-level consistency, and “contain power”

(See Patterns B1–B3 above; treat custom code authorization as engineering quality, not a security afterthought.)

Closing Checklist: What to Standardize Across the Enterprise (practical “golden controls”)

1. Identity

   • Federation by default (SAML/OIDC), MFA enforced at IdP
   • Immutable identifier strategy mapped consistently to SAP users
   • Certificate rollover runbooks tested in non-prod

2. Authorization

   • SU24 governance and periodic review
   • Org-level policy documented (mandatory vs optional)
   • Privileged access via EAM/PAM only, with mandatory review

3. Connectivity

   • Defined SAP security zones (DMZ/app/db/admin)
   • Default-deny east-west; explicit allowlists for RFC/gateway
   • Cloud Connector and destinations treated as privileged

4. Data protection

   • HANA encryption (at rest) and auditable key management
   • HANA auditing + SIEM forwarding

5. Operations

   • Minimum logging baseline enabled and centralized
   • Monthly security patch cycle across SAP + OS + DB + crypto
   • Incident runbooks for identity lock, interface containment, and evidence capture

References (selected)

• SAP Identity Authentication – Documentation
• Secure Network Communication (SNC) for AS ABAP
• AS ABAP Authorization Concept
• Authorization Defaults (SU24) in AS ABAP
• ABAP Test Cockpit (ATC)
• SAP HANA Security Guide
• SAP BTP Security
• SAP GRC Access Control – Documentation