SAP HANA Security: Complete Tutorial

โšก Smart Summary

SAP HANA Security protects business data from unauthorized access through authentication, authorization, user and role administration, auditing and encryption, and it applies these controls consistently across every tenant database container running on the system.

  • ๐Ÿ” Authentication: Kerberos, user name and password, SAML, logon tickets and X.509 certificates verify who connects.
  • ๐Ÿ›ก๏ธ Authorization: Six privilege types decide what an authenticated user may read or change.
  • ๐Ÿ‘ฅ User types: Technical, standard and restricted users carry very different default access.
  • ๐Ÿงฉ Roles: A role bundles privileges and is the standard way to grant access at scale.
  • ๐Ÿ“œ Licensing: Permanent keys expire; a 28-day temporary key installs automatically afterwards.
  • ๐Ÿ”Ž Auditing: Auditing must be switched on for the system before any audit policy works.

SAP HANA Security

What is SAP HANA Security?

SAP HANA Security protects business-critical data from unauthorized access and keeps the system aligned with the compliance standards the company adopts.

SAP HANA supports a multitenant database, in which several databases run on a single system. Each one is a tenant database container, and every security feature below applies per container.

SAP HANA provides the following security-related features:

  • User and Role Management
  • Authorization
  • Authentication
  • Encryption of data in the Persistence Layer
  • Encryption of data in the Network Layer

SAP HANA User and Role

SAP HANA user and role management configuration depends on the architecture, as described below.

3-Tier Architecture

SAP HANA can be used as a relational database in a 3-Tier Architecture.

In this architecture, the security features (authorization, authentication, encryption, and auditing) are installed on the application server layers.

The SAP application (ERP, BW, etc.) connects to the database only with the help of a technical user or database administrator (Basis person), as shown below. The end user cannot access the database or the database server directly.

SAP HANA 3-Tier Architecture with security on the application server layer

2-Tier Architecture

SAP HANA Extended Application Services (SAP HANA XS) is based on a 2-Tier Architecture, in which the application server, web server and development environment are embedded in a single system, as shown below.

SAP HANA 2-Tier Architecture with embedded SAP HANA XS application server

SAP HANA Authentication

A database user identifies who is accessing the SAP HANA database, and that identity is verified by “authentication.” SAP HANA supports many authentication methods, and Single Sign-On (SSO) integrates several of them.

SAP HANA supports the following authentication methods:

  • Kerberos: It can be used in the following cases โ€“
    • Directly from a JDBC and ODBC client (SAP HANA Studio).
    • When HTTP is used to access SAP HANA XS.
  • User Name / Password: When the user enters their database user name and password, the SAP HANA database authenticates the user.
  • Security Assertion Markup Language (SAML)

    SAML can authenticate an SAP HANA user accessing the database directly through ODBC/JDBC. It maps an external identity to an internal database user, so the user logs in with the external user ID.

  • SAP Logon and Assertion Tickets

    The user can be authenticated by logon or assertion tickets, which are configured and issued for that purpose.

  • X.509 Client Certificates

    When SAP HANA XS is accessed by HTTP, client certificates signed by a trusted certification authority (CA) authenticate the user.

SAP HANA Authorization

SAP HANA Authorization is required when a user uses a client interface (JDBC, ODBC, or HTTP) to access the SAP HANA database.

Depending on the authorization provided to the user, that user can perform database operations on a database object. This authorization is called a “privilege.”

Privileges can be granted to the user directly or indirectly through roles. All privileges assigned to a user are combined as a single unit.

When a user tries to access any SAP HANA database object, the system checks authorization through user roles and directly granted privileges.

When the requested privileges are found, the system skips further checks and grants access.

SAP HANA offers the following privilege types:

Privileges Types Description
System Privileges Controls normal system activity. System privileges are mainly used for โ€“

  • Creating and deleting a schema in the SAP HANA database
  • Managing users and roles in the SAP HANA database
  • Monitoring and tracing of the SAP HANA database
  • Performing data backups
  • Managing the license
  • Managing versions
  • Managing audits
  • Importing and exporting content
  • Maintaining delivery units
Object Privileges Object privileges are SQL privileges used to grant authorization to read and modify database objects. To access a database object, a user needs object privileges on that object or on the schema in which the object exists. Object privileges can be granted on catalog objects (table, view, etc.) or non-catalog objects (development objects).
Object privileges are as below โ€“

  • CREATE ANY
  • UPDATE, INSERT, SELECT, DELETE, DROP, ALTER, EXECUTE
  • INDEX, TRIGGER, DEBUG, REFERENCES
Analytic Privileges Analytic privileges allow read access to the data of an SAP HANA information model (attribute view, analytic view, calculation view).
This privilege is evaluated during query processing.
Analytic privileges grant different users access to different parts of the data in the same information view, based on the user role.
They are used in the SAP HANA database to provide row-level control over the data individual users can see in the same view.
Package Privileges Package privileges authorize actions on individual packages in the SAP HANA repository. The repository and XS classic are deprecated as of SAP HANA 2.0 SPS 02, so new work uses HDI-based roles.
Application Privileges Application privileges are required in SAP HANA Extended Application Services (SAP HANA XS) to access an application.
Application privileges are granted and revoked through the procedures GRANT_APPLICATION_PRIVILEGE and REVOKE_APPLICATION_PRIVILEGE in the _SYS_REPO schema.
Privileges on User This is an SQL privilege that a user can grant on their own user. ATTACH DEBUGGER is the only privilege that can be granted to a user in this way.

SAP HANA User Administration and Role Management

Accessing the SAP HANA database requires a user. Depending on the security policy, there are two user types in SAP HANA.

1. Technical User (DBA User) โ€“ a user who works directly with the SAP HANA database with the necessary privileges. Normally, these users are not deleted from the database.

These users are created for administrative tasks such as creating an object and granting privileges on a database object or on the application.

The SAP HANA database system provides the following users by default as standard users:

  • SYSTEM
  • SYS
  • _SYS_REPO

2. Database or Real User โ€“ each person who wants to work on the SAP HANA database needs a database user. A database user represents a real person who works on SAP HANA.

There are two types of database user, as compared below.

User Type Description Role assigned
Standard User This user can create objects in an own schema and read data in system views. A standard user is created with the “CREATE USER” statement. The PUBLIC role is assigned for reading system views.
Restricted User A restricted user has no full SQL access through an SQL console and is created with the “CREATE RESTRICTED USER” statement. If privileges are required to use an application, they are provided through a role.

  • A restricted user cannot create database objects.
  • A restricted user cannot view data in the database until a role grants it.
  • A restricted user connects to the database through HTTP only.
  • ODBC/JDBC access for a client connection must be enabled with an SQL statement.
The RESTRICTED_USER_ODBC_ACCESS or RESTRICTED_USER_JDBC_ACCESS role is required for full ODBC/JDBC functionality.

An SAP HANA user administrator has access to the following activities:

  1. Create or delete a user.
  2. Define and create a role.
  3. Grant a role to the user.
  4. Reset a user password.
  5. Re-activate or de-activate a user as required.

1. Create User in SAP HANA

Only a database user with the ROLE ADMIN privilege can create users and roles in SAP HANA.

Step 1) To create a new user in SAP HANA Studio, go to the Security tab as shown below and follow these steps:

  1. Go to the Security node.
  2. Select Users (right-click) -> New User.

Right-click context menu to create a New User under the Security node

Step 2) A user creation screen appears, as shown below.

  1. Enter the user name.
  2. Enter a password for the user.
  3. These are the authentication mechanisms; by default, user name and password authentication is used.

SAP HANA Studio user creation screen showing user name and password fields

Clicking the Deploy button shown below creates the user.

Deploy button in the SAP HANA Studio user editor toolbar

2. Define and Create Role

A role is a collection of privileges that can be granted to other users or roles. It includes privileges for database objects and applications, depending on the nature of the job.

It is the standard mechanism for granting privileges, although privileges can also be granted directly. Many standard roles (for example MODELLING and MONITORING) ship with the SAP HANA database.

A standard role can be used as a template for creating a custom role.

A role can contain the following privileges:

  • System privileges for administrative and development tasks (CATALOG READ, AUDIT ADMIN, etc.)
  • Object privileges for database objects (SELECT, INSERT, DELETE, etc.)
  • Analytic privileges for an SAP HANA information view
  • Package privileges on repository packages (REPO.READ, REPO.EDIT_NATIVE_OBJECTS, etc.)
  • Application privileges for SAP HANA XS applications
  • Privileges on the user (for debugging a procedure)

Role Creation

Step 1) Use the Security node as shown below.

  1. Go to the Security node in the SAP HANA system.
  2. Select the Role node (right-click) and select New Role.

Right-click context menu to create a New Role under the Security node

Step 2) A role creation screen is displayed, as shown below.

SAP HANA Studio role creation screen with the Granted Roles tab open

  1. Give the role a name under the New Role block.
  2. Select the Granted Roles tab, and click the “+” icon to add a standard or existing role.
  3. Select the desired role (for example MODELLING or MONITORING).

Step 3) Confirm the assignment as shown below.

  1. The selected role is added in the Granted Roles tab.
  2. Privileges can be assigned directly by selecting System Privileges, Object Privileges, Analytic Privileges, Package Privileges, etc.
  3. Click the Deploy icon to create the role.

Granted Roles tab listing the selected role before deployment

Tick the option “Grantable to other users and roles” if this role should be assignable to other users and roles.

3. Grant Role to User

Step 1) Assign the role “MODELLING_VIEW” to another user, “ABHI_TEST”, using the dialog below.

  1. Go to the User sub-node under the Security node and double-click it. The User window opens.
  2. Click the Granted Roles “+” icon.
  3. A pop-up appears. Search for the role name that will be assigned to the user.

Role search pop-up used to select MODELLING_VIEW for the user

Step 2) The role “MODELLING_VIEW” is now added under Role, as shown below.

Granted Roles list showing MODELLING_VIEW added to user ABHI_TEST

Step 3) Deploy the change and check the message below.

  1. Click the Deploy button.
  2. The message “User ‘ABHI_TEST’ changed” is displayed.

Status bar confirming user ABHI_TEST changed after granting the role

4. Resetting User Password

To reset a user password, go to the User sub-node under the Security node and double-click it. The User window opens.

Step 1) Enter the new credentials as shown below.

  1. Enter the new password.
  2. Enter the confirm password.

Password and Confirm password fields in the SAP HANA Studio user editor

Step 2) Save the new password as shown below.

  1. Click the Deploy button.
  2. The message “User ‘ABHI_TEST’ changed” is displayed.

Status bar confirming the password change for user ABHI_TEST

5. Re-Activate or De-activate User

Go to the User sub-node under the Security node and double-click it. The User window opens.

The toolbar contains a De-Activate User icon, shown below. Click it.

De-Activate User icon in the SAP HANA Studio user editor toolbar

A confirmation pop-up appears, as shown below. Click the Yes button.

Confirmation pop-up asking whether to deactivate user ABHI_TEST

The message “User ‘ABHI_TEST’ deactivated” is displayed. The De-Activate icon changes to “Activate user”, so the user can be activated again from the same icon.

SAP HANA License Management

A license key is required to use the SAP HANA database. A license key can be installed and deleted using SAP HANA Studio, the SAP HANA HDBSQL command line tool, and the HANA SQL query editor.

The SAP HANA database supports two types of license key:

  • Permanent License Key: Permanent license keys are valid until their expiration date. A new key must be requested and applied before that date. If the key expires, a temporary license key is installed automatically for 28 days.
  • Temporary License Key: This is installed automatically with a new SAP HANA database installation. It is valid for 90 days, after which a permanent key can be requested from SAP.

Authorization for License Management

The “LICENSE ADMIN” privilege is required for license management. SAP HANA Cloud is subscription-managed, so no key is installed manually.

SAP HANA Auditing

SAP HANA auditing features allow you to monitor and record actions performed in the SAP HANA system. Auditing must be activated for the system before an audit policy can be created.

Authorization for SAP HANA Auditing

The “AUDIT ADMIN” system privilege is required for SAP HANA auditing.

FAQs

A catalog role exists only at runtime and is created with SQL. An HDI role is a design-time artifact with the .hdbrole suffix, deployed into a container, so it can be versioned and transported.

A restricted user is created without the PUBLIC role, so it holds no system-view or object privileges. Access arrives only through granted roles, and ODBC or JDBC connectivity must be enabled explicitly.

Persistence-layer encryption protects data volumes, redo logs and backups on disk. Network-layer encryption uses TLS/SSL for client and internal traffic. Root keys sit in the secure store and should be changed after installation.

Yes. Machine-learning models profile normal grant patterns from audit logs and flag outliers such as sudden system-privilege grants, dormant accounts regaining access, or segregation-of-duties conflicts. A reviewer still decides, since the model only ranks risk.

Copilot drafts CREATE ROLE, GRANT and .hdbrole files quickly, which suits repetitive role scaffolding. Review every generated statement against the security guide, because suggestions may over-grant privileges or use deprecated repository syntax.

It is an isolated tenant database on one SAP HANA system. Each tenant keeps its own users, roles, catalog and persistence, while the system database handles installation-wide tasks such as tenant creation and licensing.

No. SAP recommends creating named administrator users holding only the privileges each task needs, then deactivating SYSTEM. A shared superuser removes accountability from the audit trail and widens the impact of a leaked password.

SAP HANA Cloud keeps the same privilege model but removes license-key handling and host-level tasks, which SAP operates. Encryption is on by default, XS classic is gone, and HDI roles replace repository roles.

Summarize this post with: