Introduction to the HANA Database

This is the first of a new series of posts on the security concepts for the HANA database (we would be using HANA DB in short to refer to this solution). The first version of the solution, HANA 1.0 was released by SAP in 2011. The current version SAP HANA 2.0 was released in 2017, with a variety of updated and new features. SAP continues to add new features through service packs at regular intervals. Most of the latest versions of its SAP ERP solutions like S/4 HANA need HANA as their database layer. HANA is a high-performance, in-memory database solution that combines an ACID-compliant database (ACID is an acronym for Atomicity, Consistency, Isolation and Durability) with advanced data processing, application services, and flexible data integration services. The HANA database can act as a standard SQL-based relational database. In this role, it can serve as either the data provider for classical transactional applications (OLTP) and/or as the data source for analytical requests (OLAP). Although the SAP HANA database holds the bulk of its data in memory for maximum performance, it still uses persistent storage to support system restart and recovery. Since our website is geared toward security, we would not really be discussing the application features and general configuration options for HANA DB, but confining us to only those features which directly impact security. While HANA DB also uses Role Based Access Control (RBAC) for application security, and as such shares the concept of users and roles similar to other ERP components, the tools used for managing application security are very different.

HANA DB can be implemented both in a two-tier or three-tier architecture and the choice of the implemented architecture determines the security configurations needed in HANA. We will briefly discuss these two architectures below with two common examples.

Two-Tier Architecture for HANA DB (HANA as a Datamart)

In a data mart scenario, data is replicated from a source system such as SAP Business Suite into the SAP HANA database. Reporting is then carried out on the data in SAP HANA (for example, using read-only views, dashboards, and so on). Different architectures can be used in this scenario.
For example, SAP HANA can be integrated into the SAP Business Objects Business Intelligence (BI) platform as a relational database. The source data can then be analyzed and reported on by SAP Business Objects Business Intelligence Suite products. Alternatively, SAP HANA can be accessed directly by BI clients such as Microsoft Excel.The architecture can be represented by the graphic below.

In this case, end-user clients connect directly to the database and as such need to be created as individual users in the database. To use different HANA features, authorizations are provided to the users through different types of privileges directly assigned to their user accounts or through roles (which contain privileges). Most of the application security concepts for HANA DB that I plan to discuss in subsequent posts are mainly relevant when users directly access the database as in this scenario.

Three-Tier Architecture for HANA DB (HANA as database for S/4 HANA or SAP BW)

In this example, HANA is used as the database underlying SAP solutions like S/4 HANA or SAP BW. These solutions provide an application server which communicate with the HANA database through technical or system users. End-users access the application server services through standard SAP UI clients like Logonpad or Fiori. This architecture can be represented by the graphic below.

Since the users, do not directly access the underlying database, end users do not need to be created in the database. Rather, users are created on the application server and the standard concepts of creating roles in PFCG and assigning authorization objects in the role are used to control authorization to the application server functions. As such, much of the security concepts we have covered in this blog through the various posts still remain perfectly valid while using the newer SAP products like S/4 HANA or SAP BW even though the underlying database has switched to HANA.

Traditionally (in HANA 1.0) the main tool used for managing HANA DB (and application security for the platform) was the “HANA Studio” application. While HANA Studio is very much in use even now, SAP has also introduced a web-based application in HANA 2.0, called “HANA Cockpit” which would be the primary tool for managing application security going forward. In fact, SAP plans to retire HANA Studio completely in the next major release of HANA. While we would certainly introduce HANA Studio, the emphasis will be on HANA Cockpit. Many of the security concepts in HANA remain same across HANA 2.0 and HANA 1.0, so much of what we learn will remain valid for the next few years at least.