by Team ToggleNow - 27 Jul, 2018
A Right Approach for Building SAP HANA Privilege Based Roles
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. From this experience, 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 SAP HANA platform has its own role model, which is more complex than SAP NetWeaver ABAP authorization model. 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 etc., on database objects
- Package Privileges are used for providing read/write authorization on repositories
- Application Privileges are used for managing HANA applications, mostly XS Engine based
These privileges can be assigned to the users directly from the HANA Studio, or Web IDE if the administrator has USER ADMIN privilege assigned to him. However, before designing the authorization approach, I would also like to highlight a few points that should be considered:
– Assigning privileges directly is not a recommended approach as:
o It increases the maintenance activity
o Makes the authorization management weird, and you will have no clue of who has what
o Unnecessary access has to be provided to the administrators due to the GRANT authorization limitation.
– Issues with ownership as objects are owned by the creator and not by the repository owner.
So, What Is The Recommended Approach?
The mantra for any successful role design is to simplify. Always keep the authorization structure easy. This makes the maintenance hassle-free and provides complete visibility of the authorizations at any given point in time.
Always Create the Roles as Repository (Design-Time) Objects
You might ask me here why SAP has provided the option of creating the roles as Catalog objects. Let me explain this – every role that we are assigning to the users should be a part of the HANA Catalog. Unless the run-time version is available, you can’t assign it to the users. When a role is created as a run-time object, the owner of the role is the ‘Creator’ who can decide which user should have authorization to it. Further, when the creator is dropped, the role will be deleted and the assignments will be revoked automatically.
Hence, it is recommended to create the role as a design-time object. When a design-time role is activated, the run-time version is automatically created with owner as “_SYS_REPO” – the global activation guy who owns the HANA repository. The role creation and assignment activities are de-coupled with this approach and the user with “GRANT_ACTIVATED_ROLE” and “REVOKE_ACTIVATED_ROLE” privileges can take care of the assignment/revoking of roles without being an owner of the actual role.
Keeping this in mind, the industry and SMEs/experts always recommend assigning the privileges through the roles that are created as database artifacts i.e. repository or design-time roles which will have the .hdbrole extension.
Have a Proper Role Naming Convention
A proper role naming convention will help you classify the roles correctly and also easily segregate and identify the criticality while assigning them to the users. The roles should be intuitive not only for the ease of security experts but also to enable business approvers and reviewers to know the role kind and type quickly before taking a go or no-go decision.
Here is an example:
Keep the Role Assignment Simple By Using The ‘Extends’ Option
SAP HANA has a great option where you can call other roles into the current role instead of assigning the same authorizations. The ‘extends’ option can be used to group the associated roles that are required for a user to perform any specific activity. For example, a role that contains authorizations of a specific package can have the relevant object privileges and analytic privileges in it.
Don’t give too much
Last but not the least, limit the authorization of every user. Do you remember the tagline of Spiderman movie? It says, “After greater power, comes greater responsibility,” which is 100% right when it comes to authorizations. Not just HANA or S/4 HANA, this is applicable to all the applications or databases. Remember, if you are giving the user a greater power, he should know that he has a greater responsibility too. Any access that is not relevant or not required should not be given, as it can be easily misused. Identify what is required for your user and limit the authorization.
Never Delete a User, De-Activate Instead
When it comes to user deletion, you are dealing with a database and not the application. Just like the other databases, it is not recommended to delete the user in HANA database too. Instead, de-activate the user.
When you delete the user, HANA will give an option of cascade deletion which will delete all the objects that were created by the user and revoke any authorization provided. Hence, it is strictly advised to de-activate the user.
How ToggleNow can help?
Please note, your SAP system handles the most sensitive data. A bad security design can seriously damage an organization’s reputation with customers, resulting in legal liability for the company, executives, and board members. ToggleNow is an international provider of SAP security solutions & services with an innovative approach. ToggleNow is a group of highly technical SAP security & GRC experts with decades of industry experience including designing and delivering of Security strategies. We deliver actionable, accurate assessments that produce tangible improvements and also deliver quality results while decreasing your operational & recurring costs.
Need Help?+91 40 48523135 email@example.com