Hana Security - three scenarios

Hana can be used as a database in a traditional architecture, another option is to use Hana as a platform, or to integrate Hana as a data mart in a BW landscape.

The three different scenarios have a direct influence on the Hana security concept.

First: Database in a traditional 3-tier architecture: In this scenario, the database located under the application server is replaced by Hana.

Second: Hana as a platform: In this scenario, the database is also replaced by Hana, but the applications are also provided on the Hana platform.

Third: Hana as a data mart in a BW landscape: In this deployment scenario, Hana is used in parallel with an existing database. The data can then be replicated from various source systems, for example from an SAP or third-party system, into the SAP Hana database.

Hana has also introduced a new terminology to the topic of security. In Hana, a distinction is made between catalog roles and repository roles. Catalog roles contain runtime objects (schemas, tables, views and roles), while repository roles contain design-time objects (package, views, authorizations and roles).

Another feature is that repository roles - like any other object in the Hana Repository - are transportable, while this is not applicable to catalog roles.

The repository roles have the _SYS_REPO user as owner, while catalog roles have the developer as owner, which means that if the developer user is deleted, the content of the catalog roles is also deleted.

The roles in the Hana container for access authorizations are similar to those in Abap. The authorizations (privileges) are grouped in a structured manner in a role.

Roles in Hana are objects and access is controlled accordingly via the object privileges. However, roles can also contain other roles in addition to authorizations.

Security Model

The Hana Security Model provides for various authorization types (privilege types):

Object Privileges: Object privileges are used to control access to objects. In Hana, for example, these are tables/views, roles, stored procedures and synonyms. In the case of tables or views, the "Object Privileges" could be compared with the S_TABU_NAM object in the Abap world.

Analytic Privileges: Access to the Hana data model is controlled via the Analytic Privileges. While Object Privileges control access to the object (table, view), Analytic Privileges control access to specific data from the object at a granular level.

The counterpart to this in Abap would be the authorization object S_TABU_LIN, which can also be used to control access to certain rows accordingly. However, Analytic Privileges are intended for read-only access to the Hana information models (Attribute View, Analytic Views, Calculation Views).

Master data is modeled in a Hana attribute view and an attribute view can perform similar tasks to linked universes in SAP BO. A fact table with its associated attributes is modeled in a Hana Analytic View.

An Analytic View can be compared to an SAP-BO universe with exactly one fact table. The Hana Calculation Views are used to map multiple facts or calculated joins and allow the connection of multiple fact tables, comparable to SAP BO contexts in universes.

System Privileges: Access to the administrative functions is controlled via the system privileges.

Package Privileges: Packages are used in Hana to structure the repository content. Package privileges are used to control access to the package and all associated sub-packages. The structure of the packages is not specified by SAP and is left to the customer.

Application Privileges: Access to the Hana XS application and functionality is controlled via the application privileges. This controls, for example, which applications can be started and which functions and screens are displayed.

Roles - Good Practices: For the reasons already mentioned, priority should be given to repository roles when creating roles. SAP itself recommends the use of repository roles.

More and more, the integrated applications - which are delivered with Hana - are also being provided with predefined repository roles. In any case, the security requirements should be taken into account in good time during the design phase and the development process.

Subsequent adaptation can involve considerable effort. When designing the package structure, it is advisable to also consider the corresponding controls (package privileges), for example HR, Non-HR/Sensitive, Non-Sensitive.