1 / 8

A Right Approach for Building SAP HANA Privilege Based Roles

Designing, configuring, and implementing SAP Security is a complex and resource-intensive task. Find the right approaches for designing SAP HANA roles<br>

udayaa
Télécharger la présentation

A Right Approach for Building SAP HANA Privilege Based Roles

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Right Approach for Building SAP HANA Privilege Based Roles

  2. SAP HANA Privilege-based Roles – A deep dive 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.

  3. 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. 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 a 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: It increases the maintenance activity Makes the authorization management weird, and you will have no clue of who has what 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.

  4. So, What Is The Recommended Approach? Simplify 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.

  5. 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 the 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 that 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.

  6. 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.

  7. 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.

  8. Contact us Level 2-4, 49, Shakthi Nilayam, Silicon Valley Society, Madhapur, Hyderabad 500084, India

More Related