Skip to Content
Technical Articles
Author's profile photo Jens Gleichmann
Jens Gleichmann
March 29, 2020 5 minute read

HANA secure network communication – part I

last updated: 2021-12-09

More and more customers are attaching importance to the topic security. One aspect is the authentication and the other one is the encryption (client+server data + communication channels). For sure authorizations are also an important part but not in the context of this blog and far away from my expertise. As you may read between the lines – I’m not a fan of authorization concepts. These are all pretty broad topic and for now we will focus on the x.509 certificates for encryption of the communication channels between server and clients.

There are some documentations available by SAP, but some of them are outdated or not matching the customer environments/needs or not all-embracing.

Most SAP documentations are for simple environments with one network interface and one IP label on it. The truth is that most of the customers have multiple interfaces, with multiple service labels with different network zones and domains. Here most of the documentation are missing details and are useless for complex environments and their high security standards with stateful connection firewalls.

Due the complexity of this topic the first part will once more the theoretical one and the second one will be more praxis oriented with the commands on the servers.

 

  • How you can secure your system with less effort?
  • What scenarios are there?
  • Which communication channels can be secured?
  • How can you achieve this?

 

  1. Scenarios [part I]
    1. Client & HANA Cockpit communication
    2. SolMan Communication
    3. AS ABAP
  2. JDBC/ODBC/SQLDBC [part I]
  3. Term clarification [part I]
  4. Create and sign certificate [part II]
  5. Import certificate to HANA Cockpit (for client communication) [part II]
  6. Import certificate to HANA resource(s) [part II]
  7. Configure clients (AS ABAP, ODBC, etc.) to use SSL [part II]
  8. Configure HDB parameters for high security [part II]
  9. Import certificate to host agent [part II]
  10. Pros and Cons certification collections [part II]

Starting point:
SAP HANA Network and Communication Security
Certificate Management in SAP HANA
How to Configure SSL in SAP HANA 2.0
2478769 – Obtaining certificates with subject Alternative Name (SAN) within STRUST
2487639 – HANA Basic How-To Series – HANA and SSL – MASTER KBA
Darryl Griffiths Blog from 2014 – SAP HANA – SSL Security Essential
SAP HANA Security – Techical whitepaper ( 03 / 2021)

 

1. Scenarios

Different Scenarios:

  1. User => (HTTPS) => XSA/HANA Cockpit
  2. HANA Cockpit (HTTPS)=> sapcontrol (SAP Start Service / sapstartsrv)
  3. HANA Cockpit (JDBC) => Database Explorer / Monitoring => Resources
  4. HANA Studio (JDBC) => HANA DB
  5. Host Agent / DAA (HTTPS) => SolMan
  6. SLD (HTTPS) => SolMan
  7. Native Client Connection (ODBC/JDBC) => HANA
  8. AS ABAP => HANA (SQLDBC)

1.1 Client & HANA Cockpit communication

  1. User => (HTTPS) => XSA/HANA Cockpit
  2. HANA Cockpit (HTTPS)=> sapcontrol (SAP Start Service / sapstartsrv)
  3. HANA Cockpit (JDBC) => Database Explorer / Monitoring => Resources
  4. HANA Studio (JDBC) => HANA DB

HANA XSA port specification via mtaext: SAP note 2389709 – Specifying the port for SAP HANA Cockpit before installation

Needed PSE’s and their usage.

Source: SAP

 

1.2 SolMan communication

  1. Host Agent / DAA => SolMan
  2. SLD (HTTPS) => SolMan

It is now possible to deactivate the SLD and using the LMDB as leading data collection system. You need a minimum SP level of 7.2 SP09 to use this feature. (check SAP note 2834711)

 

1.3 AS ABAP communication

Maybe you are now asking for this two green boxes. Since quite a while SAP recommends using virtual hostnames. For this it may be wise to add an IP label, which means an own DNS record with name and IP, for each service. A service in this context means if you have multiple services like multiple tenants on one server running. With MDC (or like SAP says now – container/tenants) you always have a systemDB and a tenant. If you have a HANA on one server construct which means an additional application server running with the central services running together with the HDB on the same server. For each server you can add an own IP label to be flexible. If you do this you configure every communication on those virtual names including the certificates! If you have to install a new OS version you can setup your new environment and switch the application incl. the IP labels and no client communication has to be adjusted.

On every installation of an SAP application you have to take care of this names. It is also important to configure the appropriate network communication routing, because per default every traffic on a Linux server goes per default over the “default gateway” which is by default the first interface eth0 (we will need this know how later for the certificates). On AS ABAP server this is controlled by ‘is/local_addr parameter’. On HANA you can also configure each interface. Every label should have its own IP.

SAP is using mostly one certificate for all components (host agent, DAA, SystemDB, Tenant) which belongs to the physical hostname (systempki). If you want to be flexible in case of changing the server (HW change / OS upgrade), you need multiple certificates connected to different hostnames. We are not talking about self-signed certificates. We are talk about signed certificates from a trusted root-CA.

One interface => multiple labels (1:n)

Multiple interfaces => one or multiple labels (n:m)

 

2. JDBC/ODBC/SQLDBC

For those who are not familiar with JDBC/ODBC/SQLDBC connections a short excursion:

  • Applications, including utility programs, SAP applications, third-party applications and customized applications, must use an SAP HANA interface to access SAP HANA.
  • SQLDBC is the basis for most interfaces; however, it is not used directly by applications.

Source SAP

Source SAP

3. Term clarification

X.509 a standard defining the format of public key certificates
File based trust store PSE
In memory trust store certification collection
Public key pk / key.pem
Private key *.key / key.pem
Certificate chain (multiple certificates in one file) *.pem
subject alternative name SAN
public-key infrastructure systempki
Certificate signing request CSR
sapgenpse sap tool to manage PSE files (blog)
openssl cryptography toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) network protocols

 

 

This was the first part as preparation for the next part – the practical one.

  • Have you already secured all communication in your HANA environment?
  • Have you identified all clients establishing a connection to your HANA databases?
  • Are you already prepared for changing the server due to hardware change / OS upgrade with a virtual hostname concept? Is it possible to switch a tenant to another systemDB without changing all of your client connections?
  • Are you already prepared with multiple interfaces (incl. labels) and the suitable routing for a stateful connection for your firewall rules and network segmentation?

If you answer one of the questions negative you should wait for the second part of this series 😉

 

###########
# Edit
# 2020/04/14 Insert of links / blogs as starting point, links for part II
# 2021/09/09 updated parameter info: is/local_addr thx @ Matthias Sander for the hint
###########

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Michael Schliebner
      Michael Schliebner

      Good one thank you!

      Curious about Part II

       

      Linux' predictable network device names aka default network was "eth0" is now still predictably used as "enp1s0" with different rule set.

      Wanting to use predictable network device names in a custom way is going

      "Down the udev rabbit hole".

       

      * Two character prefixes based on the type of interface:
      * en -- ethernet
      * sl -- serial line IP (slip)
      * wl -- wlan
      * ww -- wwan

      Ethernet cards will always start with en, but they might be followed by a 

      p (for PCI slots), a 

      s (for hotplug PCI-E slots), and 

      o (for onboard cards)

      it’s key to remember the hex conversion of network cards

      From Redhats Major Hayden

      https://major.io/2015/08/21/understanding-systemds-predictable-network-device-names/

       

      Author's profile photo Mario Wolf
      Mario Wolf

      Dear Jens,

      exactly the type of article I was looking for.

       

      Kind regards

      Mario.