The Importance of SAP HANA Auditing in Strengthening SAP Security
Chapters
Share Article
Let's Talk SAP Security
Have questions about SAP Security? We’re here to help. Contact Us
SAP HANA plays a crucial role in both cloud and on-premise SAP offerings. As a database platform, it serves as the core foundation, with S/4 HANA being a prime example. With SAP Business Suite’s and NetWeaver’s end-of-maintenance on the horizon, it is no surprise that many SAP-running organizations are transitioning to SAP HANA – a trend well underway for several years. This shift places greater emphasis on the security aspects of the HANA database, particularly audit logging. This article outlines several key technical considerations for configuring audit settings in SAP HANA.
1. Activate HANA auditing
Surprisingly, SAP HANA’s auditing feature is disabled by default. Much like the ABAP Security Audit Log, it’s up to each organization to enable it when deemed necessary for their security concept — as advised in the SAP HANA Security Checklists and Recommendations.
We strongly believe that auditing should be activated on every HANA database, at least for a baseline set of actions — especially when handling sensitive or business-critical data. Whether used independently or as a runtime for an SAP application, logging is essential for detecting risks, monitoring for suspicious activities, and conducting investigations. Without audit logging, effective security and forensics are not possible. Interestingly, SAP’s Security Baseline recommends enabling audit logging, although it remains disabled by default.
Administrator action:
Activate HANA auditing by setting parameter ‘global_auditing_state’ to ‘true’.
- For the SYSTEM database: set this in nameserver.ini
- For a TENANT database: set it in global.ini
2. What to audit?
Once auditing is enabled, the next question is: What should be audited?
In SAP HANA, auditing is configured using audit policies. By default, once auditing is turned on, a policy called ‘MandatoryAuditPolicy’ becomes active. This built-in policy captures only the essential events that concern audit-related configurations and policies.
However, aside from this default policy, nothing else is logged automatically with audit policies. Organizations must define and create audit policies in the system to capture additional activities beyond those mentioned above. This process can be complex, especially when aligning with regulatory or organizational compliance requirements.
A helpful starting point is SAP’s Best Practices and Recommendations for Creating Audit Policies. These include example policies that can be directly implemented or tailored. SAP also offers sample configurations via GitHub — links are provided at the end of this article.
Administrator actions:
- Use SAP’s best practice templates to create additional policies
- Tailor audit policies to meet your organization’s specific standards
3. Where to store audit data?
While this may seem straightforward, storing audit data in SAP HANA
can be more complicated than expected. The platform supports multiple priority levels and target destinations, allowing for granular control — but also introducing complexity.
Audit Priority Levels
There are five severity levels for audit events:
- EMERGENCY
- ALERT
- CRITICAL
- WARNING
- INFO
These can be defined for each audit policy.
Audit Targets (Locations)
SAP HANA offers four possible audit targets:
- SYSLOGPROTOCOL: OS-level logging (e.g., /var/log/messages)
- CSTABLE: Internal database table
- CSVTEXTFILE and KERNELTRACE.
Only SYSLOGPROTOCOL and CSTABLE are suitable for production environments.
Configuring Storage Behavior
Audit locations are controlled using several parameters:
- default_audit_trail_type: Sets the system-wide default.
- alert_audit_trail_type, critical_audit_trail_type, etc.: these override the system-wide default for specific priority levels.
- Audit policies themselves can override both system and level-specific settings.
As you can see, the configuration can become quite complex. Let’s clarify this with an example:
Let’s assume we want to log any event that removes a database user. For this, we create an audit policy called ‘drop_user’ on a TENANT database that logs the ‘DROP USER’ action with audit level ALERT. To make sure the data for this audit policy is written in the internal database (CSTABLE), there are three options to achieve this:
1. Create the audit policy ‘drop_user’ with specification TRAIL TYPE TABLE.
This will write any audit data for this policy (DROP USER) in the internal database table, regardless of any other parameters.
2. Create the audit policy ‘drop_user’ without TRAIL TYPE specification. But with parameter ‘alert_audit_trail_type’ set to ‘CSTABLE’.
This will write any audit data with ALERT level to the internal database table, including the ‘drop_user’ policy.
3. Same as 2, but with parameter ‘default_audit_trail_type’ set to ‘CSTABLE’, while making sure ‘alert_audit_trail_type’ is not set. This will write any audit data to the internal database table unless otherwise overruled. Because the parameter ‘alert_audit_trail_type’ is not set, this includes the ‘drop_user’ policy.
Administrator actions:
- Keep audit level and trail type settings simple and consistent
- Prefer centralizing logs in the internal database table (CSTABLE) for easier access, retention, and to ensure that sensitive data is securely stored.
4. How Long Should Audit Data Be Retained?
Retention policies depend on organizational requirements. When using the internal database (CSTABLE), the system uses the parameter ‘minimal_retention_period’ to define default retention.
You can also set a specific retention period at the audit policy level. For example, 180 days for a given policy.
Logs can be manually cleared using the ALTER SYSTEM CLEAR AUDIT LOG command or exported externally. Note: retention settings only apply when using the internal database as the audit target.
Using SecurityBridge for HANA auditing
HANA auditing isn’t just about deciding what to audit — it’s also about configuring several parameters that determine how auditing behaves in the database. Setting up and maintaining a consistent, effective HANA audit configuration can be complex. And that’s before you even start analysing the collected audit data — a critical step, because logging without analysis delivers no real security value.
This is where SecurityBridge makes a real difference for administrators and auditors.
Let’s break it down into two key areas:
1. Consistently configure HANA auditing
With SecurityBridge Vulnerability Management, you can validate your HANA audit configuration in several ways:
Parameter and Settings Validation
SecurityBridge checks all required parameters to ensure correct audit behaviour—for example, confirming that auditing is activated, the default audit trail type is set, and other critical settings are properly configured.
Audit Policy Validation
You can define exactly which audit policies should exist, and SecurityBridge validates these against the HANA database. This provides fine-grained control, ensuring that required policies are present and correctly configured.
Note: A best-practice set of SAP audit policies is included out of the box, so you can get started immediately. This set can be fully customised to meet your organisation’s specific needs.
2. Generation and analysis of HANA audit events
With SecurityBridge Threat Detection, audit log data can be retrieved and processed into actionable security events. These events can be analysed directly in SecurityBridge or forwarded to a SIEM for centralised monitoring.
Example:
Looking at our ‘drop_user’ policy, see example below:
Policy Validation: The ‘DROP USER’ policy is missing in the database, while another policy (validating the CONNECT action) exists.
Event Generation: Whenever a user is deleted, SecurityBridge generates a Medium-severity event containing detailed information such as the affected user, terminal, and program used. In our example, the deletion was performed via HANA Database Studio.
Conclusion
SAP HANA auditing isn’t just a compliance checkbox — it’s a core component of a solid SAP security posture. Proper technical configuration is key, and we’ve outlined several important areas to focus on. While manual configuration and validation are possible, the SecurityBridge platform offers comprehensive capabilities to manage settings effectively and analyse the logged data.
Are you interested in how SecurityBridge can help safeguard your SAP landscape? Get in touch — we’re happy to provide more insights and demonstrate how our platform can support your security objectives.
Additional References
- SAP Help – Recommendations for Auditing Configuration
- SAP Help – Auditing Activity in SAP HANA
- SAP Note 3027477 – General information about auditing activity in SAP HANA
- SAP Note 3252238 – Audit log table CS_AUDIT_LOG_ grows very fast suddenly
- Github – SAP samples for HANA audit policies
