Technical Articles
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.
|
- Scenarios [part I]
- Client & HANA Cockpit communication
- SolMan Communication
- AS ABAP
- JDBC/ODBC/SQLDBC [part I]
- Term clarification [part I]
- Create and sign certificate [part II]
- Import certificate to HANA Cockpit (for client communication) [part II]
- Import certificate to HANA resource(s) [part II]
- Configure clients (AS ABAP, ODBC, etc.) to use SSL [part II]
- Configure HDB parameters for high security [part II]
- Import certificate to host agent [part II]
- 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:
- User => (HTTPS) => XSA/HANA Cockpit
- HANA Cockpit (HTTPS)=> sapcontrol (SAP Start Service / sapstartsrv)
- HANA Cockpit (JDBC) => Database Explorer / Monitoring => Resources
- HANA Studio (JDBC) => HANA DB
- Host Agent / DAA (HTTPS) => SolMan
- SLD (HTTPS) => SolMan
- Native Client Connection (ODBC/JDBC) => HANA
- AS ABAP => HANA (SQLDBC)
1.1 Client & HANA Cockpit communication
- User => (HTTPS) => XSA/HANA Cockpit
- HANA Cockpit (HTTPS)=> sapcontrol (SAP Start Service / sapstartsrv)
- HANA Cockpit (JDBC) => Database Explorer / Monitoring => Resources
- 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
- Host Agent / DAA => SolMan
- 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
###########
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), as (for hotplug PCI-E slots), ando (for onboard cards)
it’s key to remember the hex conversion of network cards
From Redhats Major Haydenhttps://major.io/2015/08/21/understanding-systemds-predictable-network-device-names/
Dear Jens,
exactly the type of article I was looking for.
Kind regards
Mario.