Why SAP HANA Security is required: Part C ?

In this final part series, let’s focus and examine the biggest risk in SAP HANA Database security. In SAP HANA you can design roles and assign privileges (authorizations) and then assign the roles to users using 2 methods: Design Time Roles and Run Time Roles. Roles created in Run Time are granted directly by the HANA database user and can only be revoked by the same user. Additionally, if the HANA database user is deleted, all roles that he or she was granted are revoked.

Unlike roles created in Run Time, roles created as Design Time objects can be transported between systems. Roles created as Design Time objects are not directly associated with a HANA database user. They are created by the technical user _SYS_REPO and granted through the execution of stored procedures. If you create a Run Time role meaning a role created by an actual user ID, if that user ID is ever deleted, all the activities such as user role assignments, roles created etc. will be deleted from the database. To avoid this risk, always use Design Time Roles.

If we pre-configured, task-based SAP HANA Design Time Roles that cover all the activities within the HANA Database. Each of the individual HANA Design Time Roles perform only a single task in HANA and contain all the privileges that can execute this task. This ensures that there are no Segregation of Duty Violations inherent in any HANA Design Time Roles.

The best practice in managing SAP HANA security is to always define the roles and create them in the SAP Web IDE, assign privileges to these roles in the next step and only then create users/grant roles to these users. Using Design Time roles will help you version, transport and avoid the risk as mentioned previously.

SAP HANA has several features which can introduce risks from a compliance perspective. Some of the controls considerations include User Provisioning, Password Management, Privileged User Management, Generic Accounts, Role Maintenance, Authorizations, Audit Logging, User Data Encryption, Policies and Procedures, Audit Logging, Parameters to prevent changes in Production, Table Logging, Specification, Authorization, and Tracking of Change Requests, Approval of Change Requests, Batch Scheduling and Processing and Backup and Problem Management.


Leave a Reply

Your email address will not be published. Required fields are marked *