Hana Security - New Dimensions
Previously, the data management level and the application level were clearly separated from each other. In the database itself, only the database administrators were created as users. The developers and end users were in the Abap stack, where all the authorization assignment also took place.
New user distribution
Even if a large part of the applications in the ERP successor S/4 Hana is still mapped via the Abap stack, many developments are already taking place in the Hana database itself.
BW/4 Hana, officially not declared as a successor to SAP BW but as a new product, is already fully mapped in the Hana database. Therefore, not only database administrators are now active as users in the Hana database, but also developers and, in the future, increasingly end users.
Security
The security layers involved in running a Hana DB are many, as they include DB and application security. This starts with the security of the servers on which Hana is installed.
It can only be installed on certain Unix derivatives. The SSFS (Secure Store in the File System) is stored in the file system, where, among other things, the root keys for the encryptions are stored.
Likewise, the persistent data is stored in the file system. For recovery purposes, Hana stores images of the DB at regular intervals (savepoints) on the hard disk of the Hana server (persistent storage).
By default, the persistent data is written to disk unencrypted. Encryption must be explicitly enabled.
Communication is also unencrypted in the default installation. The Transport Layer Security (TLS)/Secure Sockets Layer (SSL) protocol can be used to encrypt internal and external communication. Unencrypted connections are also accepted by default.
For the system security the configuration of the security relevant system parameters is substantial. These are also stored in text files in Unix. Comparable to the system parameters of the Abap stack, these control components such as authentication, encryption and logging.
Access control
With regard to the users set up in the Hana DB, the key distinction is whether they are only to run applications (end users) or require access to the database itself (admins, developers, auditors).
End users are defined as restricted users. This ensures that a direct login to the database via ODBC/JDBC (e.g. using Eclipse) is not possible.
In addition, they must be explicitly assigned permissions for their applications, while normal user accounts are assigned a role with basic permissions by default when they are created (Public catalog role).
Logging must also be configured on a company-specific basis. If a large number of logs requiring retention are generated automatically in the Abap stack, this must be set up individually in the Hana DB.
For example, logging of user maintenance and role assignment must be explicitly enabled. This also applies to changes to the system parameters and the settings for encryption.
Only for changes within the repository, i.e. the development environment, logs (versions) are generated automatically.
Another important point is, of course, the authorization concept. Its functionality is mapped very transparently in the Hana database, so that the authorizations of end users can be separated clearly and in a structured manner from those of administrators and developers.
Back to the roots?
Checking the security of a Hana DB is currently still a bit of a challenge for auditors, as there are no tools for checking in the Hana standard - apart from the SQL editor. Here, it is "back to the roots" with checks directly at the table level.
Fortunately, at least setting up the permissions required for auditors is considerably easier than it was in the Abap stack.
