SAP HANA Privileges and Roles: A Practical Guide to Authorization

01What SAP HANA privileges control

SAP HANA authorization determines which users can connect, which objects they can access, and which operations they can perform. The authorization model combines users, roles, privileges, and object ownership so administrators can grant access without giving every user broad system permissions.

A privilege is an authorization unit. It can allow an action such as SELECT, INSERT, UPDATE, DELETE, EXECUTE, or administrative activity. A role is a named collection of privileges that can be assigned to one or more users or other roles.

02Users, roles, and privileges

A user is an identity that authenticates to the database. A role groups related privileges, while a privilege defines the permitted action and scope. This separation makes it easier to change access centrally when responsibilities change.

For example, a reporting role might provide SELECT on approved views without allowing changes to the underlying tables. A development role might include EXECUTE on procedures in a development schema. A database administrator may need system privileges for tasks that are not limited to individual objects.

The most important distinction is between system privileges and object privileges. System privileges authorize database-wide activities, such as creating users or managing schemas. Object privileges authorize actions on specific database objects, such as tables, views, procedures, or schemas.

03How privilege inheritance works

Privileges can be assigned directly to a user or delivered through a role. Roles can also be granted to other roles, creating a hierarchy. The effective authorization of a user is calculated from the privileges assigned directly and those inherited through active roles.

This hierarchy is useful for separating broad job functions from environment-specific access. For instance, a base reporting role can contain common read privileges, while a production reporting role adds access to production views. Avoid deeply nested role structures that make reviews difficult.

A user may also need an analytic privilege when access depends on rows or data dimensions rather than only on the object itself. Analytic privileges are commonly used to restrict records by organizational unit, region, or another business attribute.

04Granting SAP HANA privileges safely

Grant only the access required for a defined task, and prefer roles over repeated direct grants. A typical object privilege statement follows this pattern:

GRANT SELECT ON SCHEMA_NAME.TABLE_NAME TO REPORTING_ROLE;

A system privilege can be granted with a statement such as:

GRANT CREATE SCHEMA TO PLATFORM_ADMIN_ROLE;

The executing administrator must have sufficient authority to grant the privilege. The exact authority required depends on whether the grant is for a system privilege, an object privilege, or a role, and whether the grantor is allowed to pass that authorization onward.

Use WITH GRANT OPTION only when the recipient genuinely needs to grant the object privilege to others. Passing grant authority increases the impact of an account compromise and makes access ownership harder to track.

05Creating and managing SAP HANA users

Creating a user requires a deliberate identity and lifecycle process. A simplified example is:

CREATE USER analyst_user PASSWORD "InitialPassword1";

In production, follow the organization’s password, authentication, and account lifecycle requirements rather than relying on an example password. Administrators should also assign the appropriate roles, require a password change where applicable, and avoid sharing personal user accounts.

A role can be assigned with:

GRANT REPORTING_ROLE TO analyst_user;

User administration includes disabling inactive accounts, removing access when responsibilities change, reviewing authentication settings, and separating technical users from human users. For SAP HANA Cloud, user administration is performed through the service’s supported tools and workflows; the related SAP HANA Cloud user management guide covers that service context separately.

06Revoking access and reviewing authorization

Revocation should be as intentional as granting. Remove an object privilege with a statement such as:

REVOKE SELECT ON SCHEMA_NAME.TABLE_NAME FROM REPORTING_ROLE;

Remove a role assignment with:

REVOKE REPORTING_ROLE FROM analyst_user;

After changing access, verify both the intended permission and the permissions that remain through other roles. A user can continue to access an object if the same privilege is inherited from another role or assigned directly.

Maintain an access review record that identifies the owner of each role, its business purpose, its included privileges, and the users who receive it. Periodic reviews should look for unused roles, excessive system privileges, direct grants that bypass the role model, and accounts without a current owner.

07Troubleshooting authorization errors

An authorization error does not always mean that a single GRANT statement is missing. Start by confirming the connected user, the target database, the object name, and the operation that failed. A similarly named schema or object in another tenant can produce a misleading diagnosis.

Then check whether the user has the required privilege directly or through an active role. Confirm that the role is granted to the correct user and that the object privilege targets the exact schema and object. For procedures and views, also check dependent objects and the execution context.

When command-line investigation is useful, the hdbsql command-line guide explains a practical way to connect and execute SQL. For deeper diagnostic work, the SAP HANA trace files guide provides context for using traces when an authorization issue is part of a broader runtime problem.

A reliable troubleshooting sequence is: identify the principal, reproduce the failing operation, identify the required privilege, inspect direct and inherited grants, correct the smallest missing authorization, and test again with the affected account.

08Operational practices for SAP HANA authorization

Use separate roles for administration, development, reporting, and application runtime activity. Keep application users focused on application privileges rather than assigning broad administrative roles. This reduces the blast radius of compromised credentials and makes audit reviews more meaningful.

Document why each sensitive privilege exists. System privileges related to user management, schema management, data export, or security administration deserve particular attention. Consider time-limited or controlled access for exceptional maintenance tasks instead of making elevated access permanent.

Authorization changes should be tested in a representative non-production environment before deployment. Include negative tests that confirm a user cannot perform operations outside the intended scope. Pair SQL change control with monitoring and periodic review so that authorization remains aligned with the system’s actual use.

09Key takeaways for SAP HANA authorization

A privilege defines an allowed action, while a role packages privileges for consistent assignment.

Use least-privilege roles for routine work and reserve broad system privileges for accountable administrators.

Inspect inherited access as well as direct grants when investigating an authorization error.

Treat user creation, role assignment, revocation, and access review as one continuous lifecycle.

Test both successful and denied operations after changing authorization.