Designing, configuring, and implementing SAP Security is a complex and resource-intensive task. Hence, companies should identify the right approach before building authorizations. This is also important when it comes to SAP HANA privilege-based roles. I have personally experienced and helped a few organizations with the design of the role definition approach. With this, I can say that identifying the proper security requirements during the system build helps in avoiding the need for redesigning at a later stage. Before we move on, please note that the SAP HANA platform has its own role model, which is more complex than the SAP NetWeaver ABAP authorization model. The SAP HANA has:
- Analytic Privileges that will restrict user authorization on data
- System Privileges that will control the authorization on administrative tasks
- Object Privileges that allows various authorizations such as SELECT, DELETE, EXECUTE and more, on database objects
- Package Privileges are used for providing read/write authorization on repositories
- Application Privileges, used for managing HANA applications, mostly the XS Engine based.
Rule # 1 – Never assign privileges to the user directly – If you are already doing this, just reread this sentence. It is highly recommended, both by the SAP and the Industry experts, to completely avoid assignment of privileges directly to the users. This is due to the OWNERSHIP restrictions and the complexity in managing the authorizations.
Rule # 2 – Never create roles as catalog objects – Roles that are created as catalog objects can’t be transported. Further, the OWNERSHIP always lies with the Creator and when the creator ID is deleted, the catalog objects created by him/her will also be deleted. Hence, it is always recommended to create them as Design time (Repository) objects. These objects are owned by _SYS_REPO and the users with privileges GRANT_ACTIVATED_ROLES & REVOKE_ACTIVATED_ROLES can assign/revoke them. They are further transportable.
Rule # 3 – Never mix admin with end-user roles – While designing the roles, it is always recommended to do so based on the user community. If you are designing roles for end users, remember to give only the Package Privileges (REPO.READ) + Object Privileges (Tables or the right objects) + Analytic Privileges.
Administrators, the HANA Modelers, and the HANA Admins should get access to SYSTEM PRIVILEGES as well.
Rule # 4 – Use Role extends – It is always suggested to keep a low role count. HANA brings a new feature called ROLE EXTENDS using which, one can include an existing role with the new role without adding the privileges again. In another way, it can be used to group access (composite access) so that the user will only have a few roles assigned. This will also further ease maintenance.
Rule # 5 – Enable the Audit logs – As like in ECC or S/4 HANA, the changelogs are not available by default in SAP HANA. Ensure that you enable the audit logs for activities such as Role Management and User Management which can be done with the Security console.