Governance and Oversight in S/4HANA Databases: Key Controls and Best Practices

Unlike traditional ERP environments, where direct, live access to the database was an infrequent and highly restricted practice, the evolution toward an S/4HANA architecture has increased this type of access for, among other tasks, leveraging its real-time analytical capabilities. While this opens up a world of possibilities for data exploitation, it also expands the scope and the level of detail that monitoring teams must address.

This article will cover the key points and best practices aimed at controlling and mitigating the main security risks in SAP HANA databases, primarily data integrity, availability, and confidentiality.

Below, the most relevant security validations at this layer are detailed, along with what we can expect from them and which recommendations can be followed to harden the control environment.

The Main Schema: The Core of the System

At the center of the database is the so-called “main schema,” whose default technical name is SAPHANADB for RISE systems or SAPABAP1 for on-premise systems. Its importance lies in its content: all transactional and business information of the system, as well as the main technical and functional configuration tables.

This means that direct modification of this schema represents one of the most critical threats to both data and system integrity. In addition, if such practices are detected by SAP, they may lead to the loss of contractual technical support.

For this control, an example is provided with the key points:

As a relevant point, it should be noted that write access to the main schema must be exclusive to the application user, that is, the account used by the SAP system from the application layer to persist changes in the database layer. No other user should perform this type of change, nor should dialog-type access be allowed for this user. (In the case of RISE, this is no longer possible due to infrastructure restrictions).

System Permissions: Generic Users and Critical Privileges

Database access and permissions must be managed under the principle of least privilege, clearly differentiating the following types of users:

• Read-only users: Accounts with viewing permissions intended for real-time data consumption. This information is later processed in other satellite systems for dashboards or reporting.
• Administrator users: Accounts with the highest privileges and, therefore, the greatest associated potential risk.
  • Standard users (SYSTEM & _SYS_REPO): These are the most powerful users in the database. Best practice, recommended by SAP, is to use them only for initial configuration (creating the first administrator users with the minimum required privileges) and then deactivate them. They should only be temporarily reactivated for emergency tasks, which implies having controls in place to ensure these accounts are not activated or used without authorization.
  • Local users: After the initial configuration, these local database users are created for maintenance purposes. They should not have write access to the main schema, and it must be controlled which employees have access to them, along with periodic validation of this superuser list.

On the other hand, as in the application layer, there is a set of critical privileges that, in productive environments, should not be assigned except in exceptional cases, and always to the minimum extent possible. The most critical are:

• DATA ADMIN: Authorizes the execution of all data definition (DDL) commands, allowing modification of the database structure.
• AUDIT ADMIN: Allows users to administer and manage audit configurations within the database.
• USER ADMIN & ROLE ADMIN: Allows users to manage database users and roles, enabling potential privilege escalation..

The Audit Trail

The audit trail is key for incident detection and control compliance. It must be proactively configured, as it is not enabled by default with the full available policy. At a minimum, it is recommended that it logs the following:

• User and role management commands (CREATE/DROP USER/ROLE).
• Changes to privileges and/or authorizations (GRANT/REVOKE).
• Changes to the audit configuration itself that may have compromised its integrity.
• Failed user access attempts, for the purpose of detecting brute-force attacks.
• Changes to system configuration.

Regarding the storage of these logs, it is recommended to store them in an external location, making them inaccessible and immutable even for a database administrator. Integrating these logs with the company’s corporate SIEM (Security Information and Event Management) is also a widely adopted practice.

Monitoring

It is essential to have monitoring and periodic review processes for users, their activity, and the permissions they hold:

• Periodic Privilege Review: Quarterly or semiannual reviews of all HANA database users, paying special attention to those with system privileges.
• Audit Trail Monitoring: Establish a process, preferably automated, to analyze logs for anomalous activity. Integrating HANA logs with the SIEM tool is common practice and facilitates this task.
• Access Governance: Define a formal process for requesting, approving, and revoking database access, documenting the business justification for each request.

Key Takeaways

• Direct modification of standard tables in the main HANA schema entails a serious integrity risk and the potential loss of SAP support.
• Write access to the main schema must be exclusive to the application user.
• The management of privileged users must be extremely restrictive, starting with the deactivation of standard users and the limitation of critical privileges for local administrators.
• Enabling and properly configuring the audit trail, together with its integration with the corporate SIEM, provides a robust control system.
• Defining a periodic access and user review process, along with active monitoring of audit logs, is key.