HANA auditing involves the use of guidelines, activity and change logs and templates to ensure that all accesses and modifications in the SAP HANA environment are traceable, verifiable and documented in accordance with compliance requirements.
SAP HANA Auditing is an essential tool for ensuring security and compliance in an SAP HANA environment. By carefully defining audit policies and configuring audit trails correctly, companies can ensure that all relevant actions in the database are traceable and verifiable. This not only supports compliance with security standards, but also protects against misuse and provides a solid basis for security analyses and assessments.
We are happy to support you in the following areas:
| Auditing Activity in SAP HANA | Auditing in SAP HANA makes it possible to monitor and record selected actions in the database. This can be configured independently for each database. Changes to the audit configuration in one database have no effect on other databases in the SAP HANA system. Although auditing does not directly increase the security of the database, it can help to achieve the following security objectives if designed carefully: Uncover security vulnerabilities when too many authorizations have been granted to certain users. Detect attempts to breach security. Protect the system owner from accusations of security breach and data misuse. Enable the system owner to meet security standards. Typical actions that are audited include changes to user permissions, creation or deletion of database objects, authentication of users, changes to system configuration, and access to or modification of sensitive information. However, there are also events that cannot be audited, such as changes made directly to system configuration files via operating system commands when the system is offline, or changing the SYSTEM user’s password in emergency mode. |
| Audit Policies | An audit policy defines the actions to be audited and the conditions under which these actions are relevant. When an action occurs, the policy is triggered and an audit event is logged in the audit trail. Audit policies are database-specific. Audit actions are actions that are executed by an SQL statement in the database. For example, an audit policy could be created that audits the execution of the SQL statements CREATE USER and DROP USER to track user provisioning in the system. An audit policy can include any number of actions, but not all actions can be combined in the same policy. Important parameters of an audit policy include the status of the action to be audited (successful, unsuccessful or both), the target object (such as tables, views, procedures), the users to be audited and the audit level (EMERGENCY, ALERT, CRITICAL, WARNING, INFO). |
| Audit Trails | When an audit policy is triggered, an audit entry is created in one or more audit trails. Supported audit trail destinations for production systems include internal database tables, the Linux operating system logging system (syslog) and CSV text files. Internal database tables allow audit information to be quickly queried and analyzed and provide secure and tamper-proof storage. The syslog offers a high degree of flexibility and security as it offers numerous storage options and the audit trails can be outsourced to other systems. CSV files are created for each service that executes SQL and are stored in the default trace file directory. It is also possible to configure multiple audit trail destinations for different audit levels. In client databases, the system administrator can change the audit trail targets by configuring the relevant system parameters in the global.ini file. |
| Best Practices und Empfehlungen für die Erstellung von HANA Audit Policies | The following principles and best practices should be observed when creating audit policies: Define audit policies that avoid unnecessary events in the audit log as much as possible. Log all changes to the security configuration and user authorizations. Unexpected events often reveal the most information. Define auditing for all actions and exclude the expected ones. Create as few audit policies as possible. It is usually better to have one complex policy than several simple ones. Use audit actions that combine other actions where possible. For example, audit the GRANT ANY action instead of the GRANT PRIVILEGE and GRANT STRUCTURED PRIVILEGE actions. Recommended audit policies include monitoring unsuccessful connection attempts, changes to permissions, user administration and system configuration as well as backup and restore activities. |
| Patterns of SAP Enterprise Threat Detection | To activate the HANA Audit Trail for SAP Enterprise Threat Detection samples, you must log in with a user who has the AUDIT ADMIN system authorization. Using SAP ETD, you can save the SAP HANA audit logs centrally and evaluate them using forensic methods. These logs are transferred to SAP Enterprise Threat Detection, where they are visible as events and can be analyzed further. You can even extend the logging by expanding the HANA Audit Trail configuration. Create your individual scenarios and learn how you can monitor access to critical assets, such as critical database tables, to be alerted and react in time if suspicious activities are performed on your critical assets. |
| SAP HANA-Auditprotokolle in Microsoft Sentinel sammeln | The logs can also be integrated into the Microsoft Sentinel SIEM solution via the intermediate step of redirecting the HANA audit trails to the Linux SYSLOG. |
| SAP HANA-Auditprotokolle in Splunk sammeln | The logs can also be integrated into the Splunk SIEM solution via the intermediate step of redirecting the HANA audit trails to the Linux SYSLOG using “PowerConnect for SAP Solutions”. |
