Rahul Urs discusses how to implement security and controls in SAP HANA and points out potential security flaws and common oversights.
Key Concept
SAP HANA is an in-memory, column-based database management system designed to support real-time analytics and transaction processing. As part of the SAP HANA database, security and controls play an important role to harden the breaches that could exist while implementing the SAP HANA solution, reducing compliance costs and security risks.
SAP HANA as a Three-Tier Architecture (Client, Application Server, and Database)
In this scenario, SAP HANA is used as a database layer in the classic three-tier architecture of systems. The security functions in this scenario are maintained in the application server and the SAP HANA database is primarily used as a data store. Database administrators can have direct access to the database and the applications connect to the database using a technical user account.
From a security and controls perspective, it is important to secure the technical user account. Restricted access controls have to be tested to make sure only the database administrators are allowed to access SAP HANA to meet compliance requirements. SAP HANA provides several standard views, such as GRANTED_PRIVILEGES, which can be queried to review and test restricted access controls. End users should be restricted from accessing SAP HANA directly in this scenario. From an authorization perspective, the existing methods such as authority check and defining roles in transaction code PFCG apply and privileges in SAP HANA do not apply. Examples of this architecture are SAP Business Suite applications such as SAP ERP Central Component (ECC) on SAP HANA, SAP BW on SAP HANA, and applications powered by SAP HANA.
SAP HANA as a Data Mart
In this scenario, data is replicated from the source system into SAP HANA and then reporting is carried out on the data stored in SAP HANA. For example, SAP BusinessObjects Business Intelligence tools can use the data stored in SAP HANA directly to provide end users suitable reports and dashboards for data analysis. End users and administrators require direct access to the SAP HANA database with appropriate privileges to access the right information.
This scenario requires end users to authenticate from the native SAP HANA clients and applications and does not require any authentication directly to the SAP HANA database to access the reports. For example, the SAP HANA database user name/password stored in the BusinessObjects Explorer server securely forwards the user identity to the SAP HANA database. Named user IDs have to be set up in the identity store of the SAP HANA database. From a security and controls perspective, it is important to test restricted access controls to ensure correct access is granted to the end users. Security within SAP HANA should be tested with appropriate privileges granted to the users.
SAP HANA as an Application Server
In the third scenario, SAP HANA XS incorporates an application server embedded within SAP HANA, exposing applications developed in this server to end users. The various security functions for SAP HANA directly apply to these applications and appropriate controls have to be tested accordingly. From a user and role management perspective, the users and roles or privileges are granted in SAP HANA. Users require appropriate application privileges assigned to the SAP HANA roles. Authentication is performed on the application and direct authentication to the SAP HANA database should be restricted to the users of the application.
SAP HANA Authentication
SAP HANA provides direct logon to the SAP HANA database using an Eclipse-based tool called SAP HANA studio via the regular user name and password, the MIT-developed Kerberos, and the XML-based Security Assertion Markup Language (SAML). Indirect logon to the SAP HANA database from applications that run on SAP HANA require named users within the SAP HANA database for authentication purposes. For example, SAP HANA XS users and users who use the BusinessObjects Data Analytic tools such as Web Intelligence only require named users in SAP HANA. No other changes in authentication are required for the application.
SAP HANA User Types
In SAP HANA, users can be classified by two groups: regular users and technical users.
Regular users are named users or real persons who work as data modelers or data administrators. They have the ability to build data models within the SAP HANA database to perform administrative-related functions such as backup or data replication. Named users are used by applications that run on the SAP HANA database for authentication purposes. Technical users are internal users within the SAP HANA database such as _SYS_STATISTICS, _SYS_REPO that cannot be logged in from outside but are technical user IDs used internally for managing the SAP HANA database.
User and Role Management
User and Role Management in SAP HANA can be managed within the SAP HANA studio. Figure 1 shows the user master data for a user with access to SAP HANA.

Figure 1
User master data in SAP HANA with authentication and authorization information
For logon, users must exist in the identity store on the SAP HANA database. The identity store stores user and role information along with privileges assigned to the roles. The actions a user can perform depend on the roles and privileges that were assigned to the user. Similar to the authorization objects in SAP security that provide read and write access, SAP HANA uses privileges to grant authorizations to the roles to perform various activities. Roles in SAP HANA are used to bundle the privileges, allowing you to create sets of privileges for dedicated user groups.
From a security and controls perspective, although privileges can be assigned directly to users, it is a good security practice to always assign privileges to the design time SAP HANA roles and then assign the roles to the users. Roles created in the development SAP HANA database are design time roles when transported to the production SAP HANA database; when activated, they become runtime SAP HANA roles. User and role management can be performed using the SAP HANA studio or SQL commands within the SAP HANA studio tool. Assigning users to the roles using SQL commands is recommended to safeguard the database objects as user and role assignment using the HANA studio can create a risk of losing objects and privileges if the database user is ever deleted.
SAP HANA XS applications are fully integrated with the core SAP HANA user and role management procedures. Figure 2 shows the role master data with the various privileges that can be assigned to the role. Access this screen within the Security folder of the SAP HANA system. Right-click the role icon to go to Figure 2.

Figure 2
Role master data in SAP HANA with the various privileges that can be assigned to a role
SAP HANA Privileges
Access to data and execution of actions by users within the SAP HANA database are controlled by privileges. The following are the key privileges that can be used within the SAP HANA roles.
Object Privileges
SAP HANA provides database schemas in which objects such as tables, indexes, and views are stored. Access to data stored in these objects and the schema that holds these objects are managed using object privileges. It is possible to grant access on an object level and a schema level. Object level security would cause increased implementation and maintenance effort and low transparency of security concept.
When a database user is created in the catalog without using the SQL commands and is deleted, all objects created by the user or privileges granted by the deleted user are also deleted. However, careful considerations should be taken in defining design-time SAP HANA roles and users using appropriate SQL commands to prevent the loss of objects and privileges. From a security and controls perspective, it is important to test restricted access controls to monitor users who have access to certain critical privileges such as DROP or ALTER.
Package Privileges
Packages are individual projects within the SAP HANA database. For example, fixed assets and purchasing are where analytical objects such as attribute views, analytic views, and calculation views are stored. Objects cannot be copied between packages, but new objects can be created within the packages. From a security and controls perspective, it is important to segregate access to packages that could create a risk from a segregation of duties perspective. Users should be restricted to accessing only their areas of responsibility. Businesses should take the responsibility of the ownership of their respective packages.
Analytic Privileges
Analytic privileges provide row level control of what data users can see on the data models. For example, purchasing data for all purchasing groups is contained within one analytic view. However, buyers should only see the data for their purchasing group. In this case, an analytic view could be used which allows users to see the data that they are authorized to see. These privileges are applicable for both analytic and calculation Views. Certain regulations such as the International Traffic in Arms Regulations and Expert Administration Regulations (ITAR/EAR) in particular, require these restrictions in place to allow only certain users to access certain information in the reports. Roles and privileges should be monitored to ensure the right analytic privileges are granted and suitable user restrictions are monitored to ensure effectiveness of the control testing.
System Privileges
System privileges help to monitor execution of administrative actions for the entire SAP HANA database. For example, access to critical system-related activities such as user administration, role creation, backup, and configuration can be managed using system privileges. It is important to test restricted access controls to make sure only certain individuals have access to system privileges.
Application privileges: Application privileges allow security administration of SAP HANA XS application functions.
Audit Logging
SAP HANA provides logging functionality to track critical security events such as changes to role, users, and privileges. The audit logging feature can be configured in the SAP HANA studio using audit policies, configuring the list of activities to track. The audit logs are written to the Linux syslogs, which can be easily accessed using a view within the SAP HANA database. Restricted access controls for users who have access to sensitive activities such as configuration changes and privilege changes can be enforced in the audit policies tested using the audit logging feature of SAP HANA to ensure suitable compliance is in place.
From a control perspective, it is important to monitor the segregation of duties as a reviewer should review the audit logs periodically for the completeness of the activities performed by the SAP HANA administrators. Figure 3 shows the list of auditing activities that can be turned on to collect the activity logs for an administrator to review. To access this screen, click the security icon within the Security folder of the SAP HANA system.

Figure 3
SAP HANA auditing actions
SAP HANA Live Security
SAP HANA Live is SAP's answer to real-time reporting of SAP-delivered content for operational reporting. SAP HANA Live for SAP Business Suite supports direct access to ERP data in SAP HANA using content that is represented by virtual data models. SAP HANA Live comes with predefined content with the flexibility to allow users to create their own custom reports. The SAP HANA Live views consume core ECC tables, and therefore don’t inherit ECC security.
Although security is tightly defined in the application layer, ECC does not define security at the database level. SAP HANA Live Authorization Assistant is a tool used to implement ECC security on the SAP HANA Live Views. Every SAP HANA Live user requires an SAP HANA database user ID with the authorization check happening within the SAP HANA database using appropriate privileges. From a security perspective, it is important to consider testing restricted access controls as this allows direct access to the ECC data for reporting.
SAP HANA Security and Controls
SAP HANA has several features that open doors for risks from a compliance perspective. The list of SAP HANA controls considerations mentioned below can contribute to ensuring the organization has incorporated them and the risks are mitigated.
SAP HANA configuration settings for password management: A company’s IT security policy specifies every software requirement for things such as password length and strength. SAP HANA should follow the same password policies as the other applications. In SAP HANA, these settings are configurable and controlled using the parameters defined in the SAP HANA studio using the indexserver.ini file.
SAP HANA, as with ECC, comes with generic accounts. They are intended for initial installation and setup purposes and the password has to be secured. The most critical user ID is the SYSTEM ID that needs to be used to create dedicated administrator users and assign suitable privileges to the administrative users. It is recommended not to use the SYSTEM ID for day-to-day activities. The operating system user ID <sid>adm should be monitored and the password secured.
From a controls perspective, suitable control around privileged user accounts have to be tested to make sure they are assigned to the appropriate individuals. Access to sensitive functions can be managed using the auditing tool previously discussed in this article. Controls have to be tested to ensure there is restricted access on certain sensitive SAP HANA functions. SAP HANA provides several standard views that allow you to access the restricted access to users based on the privileges assigned to users. GRANTED_PRIVILEGES is one of the several views that you can access to identify and monitor sensitive access.
Change management in SAP HANA can be performed using the Change and Transport System (CTS+), Life Cycle Management, and the HANA studio by creating delivery units and performing an import/export of the delivery units to the production SAP HANA database. Given the various options, it is critical to implement a strong change management strategy to ensure there are suitable controls built to ensure effective change management practices. SAP HANA, when integrated with the CTS+, follows the regular ECC transport path to move SAP HANA objects through development, QA/test, and production environments. Controls have to be defined on users who are allowed to create delivery units within SAP HANA studio. Delivery units are an equivalent of transport requests in ECC. You also need to have controls to manage segregation of duties to define who can deploy them in the production environment including the documentation and testing of all modifications of the SAP HANA objects.
Data replication in SAP HANA using the SAP Landscape Transformation Replication Server, which replicates SAP data to SAP HANA, should be monitored. Effective operational controls on monitoring of background jobs should be considered to make sure the data integrity exists in the SAP HANA database. The extraction, transformation, and loading-based replication using SAP Business Objects Data Services should be considered for testing the monitoring controls periodically, making sure the jobs executed in Data Services are running effectively and that any remediation efforts if necessary have been executed and resolved accordingly.
Security Approaches
It is important to embrace security in SAP HANA from the audit and compliance perspective and not just technical security functions within the database. SAP HANA provides several built-in database security functions that support users in achieving compliance.
The key is to remember that SAP HANA can be used in different scenarios and each scenario requires a different security approach. The database provides several security functions with the flexibility of implementing different security policies. Security implementation depends heavily on the architecture of SAP HANA and the systems surrounding the database.
Rahul Urs
Rahul Urs is an SAP security and GRC solution architect at itelligence leading a wide variety of projects, focusing on streamlining SAP GRC, SAP HANA, and SAP security to support compliance or new technology initiatives. He is an SAP NetWeaver subject matter specialist with special emphasis on SAP security, SAP HANA, GRC solutions. and BW/BOE.
You may contact the author at rahul.urs@itelligencegroup.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.