Security Privileges and Authorization – Roles
Recently I passed the SAP c_hanatec_1 certification exam. One of the subject areas
for the SAP c_hanatec_1 certification is “Security and Authorization.” This subject
area is one that I am very interested in, not just for the certifications, but because I am
zealous about database security. In fact, I present and write often about database
The material in this series of presentations is not provided from the standpoint of
covering all the security topics covered by the c_hanatec_1 certification exam
(however, you may find it helpful as additional study material). Instead, I offer this as
general information for those who are curious about HANA database security.
The topic covered in this presentation is “ROLES”.
Based on my previous experience, the general concept of Roles in HANA is
very similar to the general concept of Roles in both DB2 and Oracle
HANA database users who have the SYSTEM Privilege ROLE ADMIN can create roles
The SYSTEM privilege ROLE ADMIN is also needed to grant roles to users or other
But every user can grant privileges to an existing role (Example: the owner of an
Analytical Privilege can grant that privilege to roles)
Roles can be useful for “bundling” the privileges required for specific functional
tasks. Think of them as reusable objects.
There are Five Delivered roles (discussed on the following pages):
SAP_INTERNAL_HANA_SUPPORT (previously was named SUPPORT until SPS 06)
The delivered Roles can be used as a template for additional role creation.
The delivered Roles are runtime objects and they are not created in the repository.
Granted implicitly whenever a user is granted
Provides filtered read-only access to system and monitoring views.
Only objects for which the users have access rights are visible.
Provides execute privileges for some procedures.
The above privileges cannot be revoked
However, Public can be granted further privileges.
Those additionally granted privileges can subsequently be revoked.
This role contains all privileges required for using the information
modeler in the SAP HANA studio.
The Modeling Role provides the data modeler the range of database
authorizations needed to create views and analytic privileges
Provides a template role that can be used to create users to work on
CAUTION: The modeling role provides the analytic privilege
_SYS_BI_CP_ALL, which, when coupled with SELECT allows the holder
to access ALL data in ALL activated views. From a security
standpoint, it is unlikely you would want this in any production
environment. A good security best practice is to use the MODELING
role only as a template.
The same privileges as MODELING role.
Provides ability to grant these privileges to other users.
Provides SYSTEM privileges needed to work with imported objects in
Best role template to use for creating roles for content
Review the caution on the preceding slide.
Read-only role which provides content of all system and monitoring
views and data from the statistics server.
Most individuals who use the Administration Editor will benefit from
this role (additional privileges, such as CATALOG READ may be
needed, depending on the task).
This role contains privileges for full read-only access to all
metadata, the current system status in system and monitoring
views, and the data of the statistics server.
Formerly named “Support” but was renamed as of SPS 06
Should never be used for day-to-day tasks
Contains SYSTEM privileges (such as CATALOG READ) and object
privileges (such as SELECT on SYS schema)
Allows access to specific low-level internal system views
Read only access
No access to any customer data
Cannot be granted to a SYSTEM user
How to Create a Role ?
A user with the SYSTEM privilege, Role Admin can create and grant roles
The Role Name must be unique (cannot be the same as an existing user
Syntax is: CREATE ROLE <ROLENAME>
Example: CREATE ROLE HR_SCHEMA;
System and Monitor Views that hold information about Roles:
ROLES: roles, creators and date created
GRANTED_ROLES: roles granted to users or roles.
GRANTED_PRIVILEGES: privileges granted to users or roles
Both roles (which are indirect privileges) and direct privileges are involved (in
other words, they are combined) when considering whether to allow a user to
access an object