Building roles in SAP HANA Database is crucial for ensuring compliant authorization management, which allows for robust security practices while also maintaining efficient user access to necessary data and functions. HANA security role build differs quite a lot from the typical "PFCG" role build that people are familiar with. To get a better understanding of the processes involved, lets take a step back and look at the overall structure of how you should approach your role build.
1: Splitting up role build
Typically the users that would HANA access would be the following:
Security
Basis
Developers
These three areas should all typically fall under the "IT" umbrella thus should form a high node of your package hierarchy.
There would be second node for the business roles, which would again serve as the top branch for your package structure under "Business". Some companies may be spilt into different companies or areas so it will depend on how the customer prefers this but this general rule will help you a lot when it comes to the naming convention. The business roles would be built for customers who are maybe exposing the developed views directly to a front end interface like Tableau, PowerBi, etc.
2: SAP Repository
When building your SAP HANA roles, you must build all production roles in the HANA repository. What is the HANA repository? The repository is an area which allows a developer or a security person to build runtime versions of their objects, which in turn will allow you to keep a nice change/version history and will also allow you to transport your objects upstream to the test, QA and Production systems. If you want to know more about HANA transports, then check out another one of our blogs. All roles intended to be used for production should ALWAYS be built in the repo, there are very few exceptions to this rule, one example can be found here.
So how does one find the HANA repository?
1: Go into HANA Studio.
2: Click on the top navigation bar and go to "Window" and chose "Show View".
3: Find the repository view and enable this.
A quick tip, its more productive to have both the "Systems" and "Repository" views open at the same time as you may need to jump back and forth between the admin console to check indexserver traces during role build and testing. You may also need the SQL console open to for querying GUIDs.
3: Naming convention:
A solid and clear naming convention with SAP Roles is vital to a smooth support structure. The turn over of SAP security people is quite high in our experience, so the naming convention needs to be easy to follow for any new consultants. We would suggest a naming package structure similar to this:
PROD.SECURITY.CORE.IT.<> - This would suffice for all IT roles. You could break this down further if you wish but we have found that this should meet the requirements.
PROD.SECURITY.BUSINESS.<APPLICATION>.<AREA>.<>.<> - You could break down the business roles more granular if you wish to track the roles for certain areas, such as Finance, Supply Chain, Human Resources, etc.
Be sure to check with your customer or colleagues to see what naming convention they use elsewhere as its recommended to try and keep a consistent and familiar convention in all SAP systems.
4: Building Non Production Access for IT
Before you start building non production support access, there are some important questions that first must be answered. When working in non production systems, the general assumption is that customers do not and are not using production data in their development and test systems. Its always best to confirm this first as there are some rare occasions that test systems are refreshed from either QA or production systems and the data has not or is not going to be scrambled. These types of scenarios are not as rare as one would like to think, thus allowing broad access to schemas in these environments can pose a very serious risk which would need business awareness and sign off.
For this example, we will operate under the assumption that the development and test systems are scrambled and all is right with the world....how utopian I hear you say.
Now, when building access for security, developers and basis, there are some important and different points to note for each area. Developers are more schema access heavy, they require full development rights in both studio and the IDE.
DEVELOPER ACCESS - NON PROD Here is an example of a repository role that could be used for a developer working in a non production environment:
SCHEMA ACCESS
As you can see, as the developer will need full access to all Calculation Views. to achieve this, we grant the role _SYS_BIC schema access. We of course would not give this to any users in a Production environment, we will discuss the "why" later.
The Schema access here for SAPHANADB is given as the developer will be developing using tables from this schema. As the data is scrambled there is no risk here with granting full access to the schema. You can of course limit this by table if you wish but I find this methodology not so friendly to your fellow developer who cannot be expected to request a new addition of a table every time they want to create a new view.There may be projects that have more than 1 data schema(source), it could be several. Its always a good idea to check what kind of data is being pulled from the Virtual tables and if this data is sensitive.
The sap.hana.xs* roles will allow the developer to access the needed IDE's in the browser.
PACKAGE ACCESS You can see here that the developers are limited to only the sap package. Its important to keep the Security package at the highest node level so as that no other teams outside of the security team have access to the security roles. The risk here is that someone could escalate their own privileges in the repository, activate and move the role to production, thus elevating their access.
SAP SECURITY - NON PROD
SAP Security Admin Roles do not need as much, if any access to schemas (Expect for the _SYS_REPO of course). Security consultants have very little to no use cases to need access to schemas in the DB, even in Development. For non production access its recommended to allow USER ADMIN and ROLE ADMIN access as its needed for support purposes. Along with these system privileges, it also recommended to grant the sap.hana.xs.roles:Admin role for the IDE side of things. Whilst its good practice to separate the USER ADMIN from the ROLE ADMIN in Production, it would be overkill to work this way in Development and Test.
BASIS - NON PROD
Basis admins require a wide ranging amount of access which differs from business to business. We would recommend speaking with the basis teams and consulting the official SAP HANA Security guide to get a better understanding of what would be needed....and no, SYSTEM is not the answer here.
4: Building Production Access
When building production access, the following best practices are strongly encouraged:
Transports: Always use transports for all runtime objects. Roles should be built in Development and transported through to production. This goes for all admin users who use SAP HANA, and yes, this includes developers. Developers should not develop directly in production, this poses many risks and is strongly discouraged.
Role Granting: Only repository roles should be used in Production, Catalog roles should not be granted to end users directly. Roles also should not be granted directly to users by Security Admins, instead use the CALL _SYS_REPO.GRANT_ACTIVATED_ROLE procedure if you do not have SAP GRC, IDM, etc configured as your IAM system.
Role Naming Conventions: Implement a consistent naming convention for roles. This makes it easier to identify and manage roles in the long run. For example, roles can be named based on function, department, or data access level.
Use SQL Analytic Privileges: Ensure the developers are correctly using Analytical Privileges for restricting access to data at a column and row level. They provide more granular control over data access.
Least Privilege Principle: Assign only the necessary privileges to roles. Users and applications should only have the minimum access required to perform their tasks. This minimizes potential data exposure and security risks. Example, if a role needs access to a calculation view, then you grant that object privilege to the role. You do not grant access to _SYS_BIC as this allows the user to see all calculation views. This should also apply to any service user being used to integrate with other systems, do not grant service users full access. Spend the time to create individual roles for each service ID based on its job function, your developers may not like it but your CIO will when you pass Audit with flying colours.
Use a GRC Rule Set: Regularly review and audit roles and privileges. As business requirements and teams change, the need for specific access might evolve. Audit logs can also help identify any misuse. Ensure that there's a separation of duties by not granting conflicting privileges within the same role. For example, a security admin user shouldn't be able to create a user and also assign a role in production.
Controls: Make sure that any mitigated risks in production have valid and effective controls, work closely with your controls and GRC teams here on this one.
Testing: Before deploying roles in a production environment, thoroughly test them in a development or testing environment to ensure that they provide the expected access without any unforeseen issues or risks.
Audit Logs: SAP HANA Audit Logging is a vital aspect of SAP HANA database security and compliance. It provides a way to track various activities performed in the HANA environment, thus enabling monitoring of critical or sensitive operations, ensuring compliance, and safeguarding against unauthorized or malicious actions. Its strongly recommended to create various policies that allow you to monitor sensitive tables/objects/views so you know that only the correctly authorized people are viewing the data. Audit Logs can help security admins to find holes in their role build. Audit logs are not enabled by default, you have to turn these on or create your own. To enable the auditing you must first global_auditing_state in the global.ini file. ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('auditing configuration', 'global_auditing_state') = 'TRUE' WITH RECONFIGURE;
To create an audit policy you can use the Web interface, SQL or the HANA Cockpit. We prefer SQL, here is an example of query you can use:
CERATE AUDIT POLICY <NAME>
AUDITING <STATUS> <ACTIONS>
ON <CATALOG OBJECTS>
FOR I EXCEP FOR <USER LIST> LEVEL <LEVEL>
TRAIL TYPE <TRAIL>;
Documentation: Maintain clear documentation detailing the purpose, privileges, and rationale for each role. We find its best to document this within the role itself in the repository view in commented text.
By adhering to these best practices, organizations can create a robust, manageable, and efficient authorization framework in SAP HANA, minimizing security risks and maximizing operational efficiency.