SAP Security for S/4HANA

Why S/4HANA changes the security model

S/4HANA changes the security model in three ways that matter to the customer. The user interface shifts from classic SAP GUI transactions to Fiori applications grouped into catalogs. The database shifts from the traditional Oracle or DB2 footprint to HANA with its own authorization layer. The integration shifts from native point to point to BTP brokered services with OAuth and API key. The three shifts mean that the classic role design rooted in transaction codes is no longer sufficient. The customer must redesign the role catalog around Fiori catalogs, HANA roles, and BTP service authorization.

This article documents the Fiori catalog model, the HANA database controls, the BTP integration security, and the audit defensible S/4HANA security posture. Reference the SAP security audit pillar, the S/4HANA licensing pillar, and the S/4HANA expertise.

Fiori catalog model

The Fiori catalog model organizes user access by business role rather than by transaction code. The catalog contains the tiles that the user sees on the Fiori launchpad. The catalog assignment is granted through a PFCG role with the SAP_UI_FLP_ADMIN object and the catalog identifier. The customer position is to design one catalog per business process and one launchpad group per persona. The discipline keeps the catalog count manageable and supports the audit walkthrough of who can do what.

Reference the Fiori security analysis, the role design methodology, and the authorization concepts analysis.

HANA database controls

The HANA database controls operate on a separate authorization layer from the ABAP front end. HANA users are distinct from ABAP users. HANA roles control direct database access through SQL and through analytic privileges. The customer position is to keep HANA users limited to the ABAP technical user and a handful of named database administrators. End users must never connect directly to HANA. End user access to HANA backed objects goes through the ABAP authorization layer or through Fiori. The discipline closes the back door that would otherwise allow a SQL aware end user to bypass the front end authorization model.

Reference the basis security analysis, the privileged access analysis, and the license audit pillar (cross cluster reference for the HANA database access licensing implication).

One catalog per business process and one launchpad group per persona is the single most leveraged Fiori design control. The discipline keeps the catalog count manageable and supports the audit walkthrough of who can do what.

BTP integration security

The BTP integration security covers the authentication and authorization of services that consume S/4HANA data through the BTP. The model uses OAuth client credentials for service to service traffic and SAML for user delegated traffic. The customer position is to maintain a service catalog of BTP destinations, to rotate OAuth client secrets quarterly, and to enforce least privilege on the destination service user. Every BTP destination is documented in the service catalog with the data scope, the OAuth client identifier, the rotation schedule, and the application owner. Reference the cybersecurity analysis, the RFC security analysis, and the identity management analysis.

Audit defensible S/4HANA security posture

The audit defensible S/4HANA security posture has five components. First, the Fiori catalog model designed one catalog per business process. Second, the HANA database controls that limit direct database access to administrators only. Third, the BTP integration security with documented service catalog and quarterly secret rotation. Fourth, the integration of S/4HANA roles into the GRC access control workflow. Fifth, the periodic role recertification that covers Fiori catalogs, HANA roles, and BTP authorizations together. The five components together survive external auditor walkthrough and SoX testing.

The implementation detail is in our GRC implementation analysis, the user access review process, the SoX ITGC analysis, and the compliance framework pillar. The GRC and security expertise documents the full senior advisor methodology.