Hana - legally compliant logging

As far as legally compliant logging and retention of logs is concerned, SAP customers can rest easy in the Abap stack. Due to the automatically generated change documents, a large part of the logs requiring retention are already generated there.

If you then activate table logging for customizing, combined with an archiving concept for the logs, you can sit back and relax. Retention periods, such as those of §257 of the German Commercial Code (HGB), can thus be complied with.

In the Hana database, this is different. As is usual with databases, there is no logging by default (the only exception is versioning within the development environment). Since Hana is not operated as a pure database, but takes over parts of the application layer, logging is essential here. Before a Hana database is used productively, a logging concept must be created and technically implemented.

The first step is to determine where the logs should be written. Besides the possibility to write them to a Hana table (Sys.Audit_Log), the SysLog of the Unix server can also be used.

The latter offers the advantage that a separation of functions between log configuration and evaluation/retention can be implemented. In particular, the use of a central SysLog server, to which the logs are forwarded and from where they are archived, lends itself here.

The next step is to define what is to be logged. To comply with legal requirements, this should at least include: user administration (creation/modification/deletion of users and user groups), authorization assignment (assignment/withdrawal of roles and privileges), changes to the configuration of encryptions (persistent data, root keys, redo logs), system configuration (changes to system parameters), configuration of interfaces, changes to schemas and to certificates (creation, modification, deletion).

If an SAP ERP or S/4 Hana is operated on the Hana database, it may also be useful to log any accesses to its data that are not made via the owner (SAP).

In Hana, in addition to modifying accesses, read accesses to the data can also be logged. This is particularly useful for data that is sensitive from a data protection point of view (e.g., employee data) and for business-critical data (conditions, production data).

The logging is technically implemented with the Hana AuditLog. Various policies can be defined here, to which log actions are assigned in each case. These are to be set up based on the specifications.

It should be borne in mind that not only production systems are subject to the logging obligation, but also development systems in some cases. Once the AuditLog has been set up in accordance with the specifications, the authorization to change the configuration (System Privilege Audit Admin) should, if possible, only be used on the basis of the dual control principle.

If the logs are stored in the Hana DB, the authorization to delete the logs (System Privilege Audit Operator) must also not be assigned.

In addition, the Hana AuditLog must be integrated into the company-specific overall concept for logging, in which topics such as configuration specifications, responsibilities, evaluation cycles and retention periods are regulated.

This includes legal requirements and company-specific requirements for logging, retention periods for the various logs, archiving concepts for the logs, specifications and responsibilities for regular evaluation, as well as documentation requirements for evaluation and escalation levels in the event of findings.

The operation of Hana databases thus presents new challenges with regard to retention obligations. In contrast to the Abap stack, here the company is asked to set up logging in accordance with legal and internal guidelines.