Communicate securely with Hana

The architectures of SAP landscapes have changed fundamentally with the introduction of SAP Hana. Hana was initially developed as a relational database for SAP systems based on in-memory technology.

All data processing and storage takes place in the main memory of the system environment, which results in an enormous performance boost compared to conventional database systems.

However, Hana also opens up new possibilities in business use and is thus increasingly becoming a development platform on which Java and HTML5 applications are run in runtime environments.

The focus here is now on web-based applications that communicate using HTTP.

However, the SAP core under Hana can no longer be modified programmatically by the user himself; Hana is thus seen as a closed system and makes its functions available via a large number of connectors and interfaces, which can then be accessed by self-developed application programs.

Currently, more than 2000 such connectors and interfaces are implemented in the Hana core - the tendency is strongly increasing, because more and more new application areas are to be covered. In general, the following communication paths can be distinguished on this platform:

Connections to Hana via the database client: They are mainly used to manage the database system - for example, Hana Cockpit or Hana Studio - or for classic database queries, for example, with business intelligence tools or even quite simply with Excel. Communication takes place by using the SQLDBC protocol, which is a derivative of ODBC/JDBC.

Connections from so-called web clients. These can be, for example, applications that run in the Java runtime of Hana XS and are embedded directly in the database environment.

The XS extension is required for this; the mostly web-based communication (HTTP/HTTPS) usually runs via TCP ports 3xx33, where xx stands for the respective instance number. XS provides the Java Runtime Machine and the web server in this configuration.

This results in a number of problems for the security of the platform and the applications: Within the platform, communication is "plain text," which means that all data is exchanged unencrypted; this applies to both the database and web clients.

The respective components must authenticate each other. Basic Auth (username/password), SAML assertions and X.509 certificates are possible here. However, Basic Auth is generally regarded as insecure; SAML and X.509 in turn require appropriate certificate management, which is, however, only available to a limited extent within the Hana landscape.

The topic of "data protection" is thus coming into sharper focus. What exactly happens, for example, when compromised applications access data via the connectors?

Currently, the Hana platform does not provide RAM encryption. Therefore, an attacker could install an app that gains access to the entire unencrypted data.

The obvious solution here would be RAM encryption, but this is only available with the latest processor generation and the corresponding modules in the operating system.

Validation challenge

This puts the topic of secure application development more and more in the security focus, which, for example, gives very high priority to the validation and authorization of data and data streams.

In the past, when an SAP environment was still an open system, the majority of functions were created by Abap development itself and then integrated into the SAP core.

Although security vulnerabilities could arise here as well, the impact remained limited because the SAP core provided a certain level of protection; in any case, it was not possible to compromise an entire infrastructure this way.

Now the developer works on another level, where the system no longer protects him; his application accesses the connectors and interfaces, and if he makes a security-critical error here, in the worst case the entire infrastructure is open to attackers, who can then also access the connectors in question.

Application developers must ensure, for example, that their XML streams are correctly validated so that an attacker does not gain complete access to the application via corresponding vulnerabilities, then modify it and in turn gain access to all the data in RAM.

Consideration and specification of security requirements in the design and conception phase, as well as investments in testing - for example, static application security testing (SAST), dynamic application security testing and penetration testing - must now also be taken into account.

In large SAP landscapes, users also need to increasingly address infrastructure issues such as web application firewalls (WAFs) and XML firewalls.

For example, developers are increasingly using microservices based on REST APIs to exchange data - such as with SAP Leonardo, the platform for exchanging and analyzing IoT information.

This data must be transferred quickly and securely, and compromise of the data must be prevented at all costs. For this purpose, digital signatures, transport encryption using 2-way SSL handshakes, XML validation, for example, are the means of choice.

Many developers still refrain from implementing such security measures in their applications themselves because they fear a reduction in the overall performance of their systems, but on the other hand systems are sometimes also unable to support such measures at the application level.

Therefore, the aforementioned infrastructure components are essential for secure operation in a Hana environment.

In principle, more attention must be paid to security at the application level in the future when using Hana, paradoxically precisely because Hana is a programmatically closed system and precisely because of this the topic of communication paths and communication partners must be focused on.

In the event of a successful attack on Hana applications, the platform could become a gateway for attackers to gain access to any mission-critical data.