Based on personal experience, very few organizations have implemented a “best practices” security model to protect their SAP HANA system and data. I can only guess why this is the case. One thing that is clear is that most security teams struggle to understand how to develop roles blended with the various catalog, package, analytic, system and application privileges. This is understandable for a few reasons:
- The SAP HANA platform is more than just a database. Traditional DBAs are great at securing catalog objects but often they are not experienced with items such as application privileges and package privileges. Such privileges required some knowledge of SAP HANA application development environment based on the classic XSC engine and its repository.
- SAP HANA System Privileges require deep knowledge of the SAP HANA platform, its capabilities and how everything works together. System Privileges tie back to specific functionality within the platform. In some cases, that functionality is separated into tiers of System Privileges. Needless to say, it can be difficult to decipher even for experienced admins.
- Teams great at managing SAP ABAP layer security are not an automatic best fit to manage SAP HANA platform security. Lets face it, its just very different. If you don’t understand the SAP HANA platform and have never worked in database security, you will likely face a steep learning curve. Often, an organization’s leaders give this task to their existing SAP security team without understanding just how different it is. As a result, the security model never really gets implemented correctly.
- Historically, the database running a SAP application was just a dumb box that only the application accessed. Users never accessed it and most clients only used a single logon to administer that database. However, I would argue that this was never a best practice but a bad practice employed by too many organizations. All databases need a basic security model regardless of how they are used. Auditors should be checking both the application server and database as both pose equal risk.
While these items are understandable, most organizations are still obligated to secure their SAP HANA Platform and its data. With that in mind, below are a few recommended security settings that all organizations should have addressed in their SAP HANA platform. This is by no means a complete list, and organizations should consult their security teams when adopting any recommendations in this posting.
Password Authentication Settings
SAP HANA provides an internal user and password authentication mechanism. Any user with an enabled password should comply with industry and organization password standards, so now, let’s review recommendations related to standard user password policies and service accounts.
Password Lifetime
Passwords should be configured so that they expire after a specified number of days; in SAP HANA, the default is 182 days. Depending on the required password complexity and length, this number might need to be changed. For example, many organizations require passwords to expire every 90 days, because they only require eight characters and limited complexity. Consult with your organization’s security team for a policy appropriate for your situation.
In addition to the maximum password lifetime, a minimum password lifetime should be implemented to prevent the user from conducting frequent, consecutive password changes. For example, a user might try to change his password several consecutive times, attempting to circumvent the password reuse policy. The default value of one day will generally discourage users from circumventing the reuse policy, but the value should be increased if users frequently abuse the policy.
Password Complexity
Passwords should require a minimum number of character types to decrease the likelihood that both software programs and other users might guess them. By default, passwords require an uppercase letter, lowercase letter, and numeric digit in SAP HANA. They also default to a minimum of eight characters in length. Organizations can increase the complexity requirement for passwords by requiring a special character in addition to the other character types. They can also increase the complexity by increasing the minimum number of required characters and preventing use of common dictionary words in passwords.
Number of Reused Passwords
When changing passwords, based on the maximum lifetime, organizations should prevent users from reusing passwords for a time. The default value for SAP HANA is the five previous passwords. Multiply five times 182 days, and you’ll see that passwords can’t be reused for about 2.5 years by default in SAP HANA. This assumes that users don’t change their passwords before the expiration date.
Organizations should review this setting and increase as needed based on the configured minimum and maximum password lifetime. For example, many organizations increase this value to 12 previous passwords to reduce the likelihood that a password is compromised.
Lockout Policy
When a password is entered incorrectly a specified number of times, the account should be locked out or restricted from use until the owner and administrator can review the cause. SAP HANA defaults to a value of six invalid passwords before an account is locked out. In addition, SAP HANA defaults to 1440 minutes or one day until the system automatically removes the lockout.
Organizations should review these default settings and implement a policy based on their security team’s requirements. For example, many organizations will increase the number of failed attempts from six to 10 but also force an account to remain locked out indefinitely. When locked out indefinitely, only the administrator can remove the account lockout condition. This forces the user and administrator to communicate about the cause of the lockout, helping identify instances in which someone else might be trying to guess the account password.
Initial Password
When an administrator creates an account for a user, she establishes an initial password. SAP HANA defaults to forcing a user to change this initial password the first time they log on. An administrator should never know a user’s password in the long term. Therefore, it’s important that users change this password as soon as possible. SAP HANA also disables an account if this initial password isn’t changed within sevent days of its creation.
These settings are very important, and the default values within SAP HANA are typically acceptable. However, organizations should consult their security policy team about their own required settings. For example, some organizations might increase the initial password lifetime if new users typically don’t access the system within the first 30 days of the account creation. However, when increasing this policy setting, security administrators should choose an initial password that is unique for each user. This will reduce the likelihood of a new user account being compromised.
Disable Password Authentication
Organizations that use third-party authentication, LDAP authentication and SSO with SAP HANA accounts don’t necessarily need password authentication enabled for a given user. The following SQL code will disable password authentication for a given user:
ALTER USER <USER_NAME> DISABLE PASSWORD;
Users configured with a SAML or Kerberos identity can still authenticate using a third-party authentication mechanism without the need to authenticate with SAP HANA via a password managed by SAP HANA. User configured for LDAP authentication can logon with their Active Directory or LDAP credentials. This methodology eliminates the need to manage passwords for a user.
Encrypting your SAP HANA Database and Data at Rest
SAP HANA 2.0 supports communication encryption, data volume encryption, log volume encryption and backup file encryption. Note: SAP HANA 1.0 only supports communication and data volume encryption. Encrypting communication protocols helps to protect information as it’s transmitted between a client application and the SAP HANA server. Data at rest can be found in the “/hana/data”, “/hana/log” volumes and backup file locations. Data volume, log volume and backup media encryption protects the data from individuals with physical access to the SAP HANA file systems. When data this encryption is enabled, data can only be accessed through SAP HANA’s supported authentication and internal authorization mechanism.
Communication encryption should be used anytime information travels over untrusted and insecure networks, which might include an organization’s internal network and definitely includes access over a public network (IE Cloud). For example, if your SAP HANA system is hosted by a cloud provider, the communications protocols should be encrypted using Transport Layer Security (TLS), and clients should be required to connect using TLS.
Data at rest encryption should be used if absolute control over the physical access to the SAP HANA server or storage is in question. For example, if the server’s data center is shared by multiple organizations or hosted with a cloud provider, then data at rest encryption is highly recommended.
Identifying Users with Elevated Privileges
When implementing a security model, organizations should maintain a list of users that have been granted a high level of access to the SAP HANA system. The term high-level access loosely describes having privileges that are inherently risky for a user to possess. Many of the system privileges within SAP HANA are inherently risky to grant to other users, and other types of privileges can also be risky. While they are risky, it is necessary for some users to have them at all times or at least on a per-request basis. However, they should scrutinize and frequently audit their system to ensure that users have the appropriate privileges based on their established job functions and based on the organization’s defined division of duties.
You can easily identify users with high risk privileges by querying the SYS views or System metadata. For example, you can list users with risky System Privileges using the following example SQL:
SELECT *
FROM SYS.EFFECTIVE_PRIVILEGE_GRANTEES
WHERE OBJECT_TYPE = 'SYSTEMPRIVILEGE'
AND PRIVILEGE in ( 'INIFILE ADMIN', 'AUDIT OPERATOR', 'ROLE ADMIN', 'USER ADMIN', 'DATA ADMIN',)
AND GRANTEE NOT IN ('SYSTEM','_SYS_REPO');
You can craft other SQL statement against the SYS.EFFECTIVE_PRIVILEGE_GRANTEES to list other “risky” privileges and the user’s that possess them.
Root Package Privileges
When a grantee has root package privileges, he is assumed to have the granted privileges on all packages within the repository. It’s important to identify users with root package privileges that allow changes to the repository. The following package privileges allow for changes to the repository:
- EDIT_NATIVE_OBJECTS
- ACTIVATE_NATIVE_OBJECTS
- MAINTAIN_NATIVE_PACKAGES
The REPO.READ privilege allows a user to view all repository objects without making changes. At the root level, it should be limited to only grantees that need to view all repository objects. It’s best to limit who can see everything, because such information can be used to construct more sophisticated hacks.
When a grantee has been granted root package privileges, those privileges will be assigned to a special package object named .REPO_PACKAGE_ROOT. Privileges assigned to this object will be inherited by all packages and development artifacts within the repository. We advise that you limit root package access, because the repository often contains repository roles, and users can potentially elevate their own privileges if they can modify a repository role that they’re granted.
To identify grantees with risky root package privileges, execute the SQL code below:
SELECT *
FROM SYS.EFFECTIVE_PRIVILEGE_GRANTEES
WHERE OBJECT_TYPE = 'REPO'
AND (PRIVILEGE = 'REPO.EDIT_NATIVE_OBJECTS' OR PRIVILEGE = 'REPO.ACTIVATE_NATIVE_OBJECTS'
OR PRIVILEGE = 'REPO.MAINTAIN_NATIVE_PACKAGES')
AND OBJECT_NAME = '.REPO_PACKAGE_ROOT'
AND GRANTEE NOT IN ('SYSTEM','_SYS_REPO')
ORDER BY GRANTEE;
Information Views with No Analytic Privilege Checks
As a best practice, all end user consumable views created in the SAP HANA system should be wrapped or protected with an Analytic Privilege. This layer allows organizations to filter data by user profile or to prevent access to data altogether.
To identify information views with no analytic privilege checks enabled, we can query table ACTIVE_OBJECT in the _SYS_REPO schema. For example, to identify information views with disabled analytic privilege checks, we can execute the SQL below:
SELECT *
FROM "_SYS_REPO"."ACTIVE_OBJECT"
WHERE
( UPPER("CDATA") LIKE UPPER('%checkAnalyticPrivileges="false"%') AND
"OBJECT_SUFFIX" IN ('analyticview', 'calculationview', 'attributeview'));
Any information view with its analytic privilege (AP) check disabled can be queried by any grantee assuming they have SELECT on the entire _SYS_BIC schema. In addition, no filter restrictions can be applied to the information view if it does not have an AP check enabled. Therefore, it’s important that organizations maintain a listing of insecure information views and document the reasons for their configured states.
In addition to listing information views without an analytic privilege checks, we can also list those with different analytic privilege check types. To list all information views with either classic XML-based analytic privilege checks or with SQL-based analytic privilege checks, execute the SQL below:
SELECT 'XML BASED AP CHECK' AS AP_TYPE, *
FROM "_SYS_REPO"."ACTIVE_OBJECT"
WHERE
( UPPER("CDATA") LIKE UPPER('%applyPrivilegeType="ANALYTIC_PRIVILEGE"%'))
AND "OBJECT_SUFFIX" IN ('analyticview', 'calculationview', 'attributeview')
UNION ALL
SELECT 'SQL BASED AP CHECK' AS AP_TYPE, *
FROM "_SYS_REPO"."ACTIVE_OBJECT"
WHERE
( UPPER("CDATA") LIKE UPPER('%applyPrivilegeType="SQL_ANALYTIC_PRIVILEGE"%'))
AND "OBJECT_SUFFIX" IN ('analyticview', 'calculationview', 'attributeview');
Disabling the SYSTEM Account
After the system has been set up and a security model is established, I recommend that organizations disable the SYSTEM account. This account should only be enabled under extreme circumstances. When it’s enabled, its actions should be fully audited by a member of the security team.
Disabling the SYSTEM account is important for the following reasons:
- The account has almost complete access to all aspects of the out of the box system. It’s very high risk because of its default capabilities.
- It is a well-known administrative account that’s often exploited by hackers inside and outside the organization. If it’s disabled, then it can’t be exploited.
- The SAP HANA auditing mechanism can’t always identify the actual user executing actions as the SYSTEM account. Therefore, there’s little or no accountability when this account is shared and used by multiple people.
- The account offers no division of duties. It possess all of the available SYSTEM PRIVILEGES allowing it to perform administrative, development and security tasks in many instances.
To disable the SYSTEM account, execute the following SQL code while logged in as a different user with the USER ADMIN system privilege:
ALTER USER SYSTEM DEACTIVATE;
To validate that the SYSTEM account has been disabled, execute the following SQL code:
SELECT * FROM USERS WHERE USER_NAME = 'SYSTEM' AND USER_DEACTIVATED = 'TRUE';
If a record is returned containing the SYSTEM account details, you can assume that it’s been disabled. If you need to reactivate the SYSTEM account, execute the following SQL code:
ALTER USER SYSTEM ACTIVATE;
Create Audit Policies
Auditing is disabled by default, and no audit policies are included with the system. The auditing mechanism should be enabled and audit policies should be created.
To validate that auditing is enabled, execute the following SQL code:
SELECT * FROM "SYS"."M_INIFILE_CONTENTS" WHERE SECTION = 'auditing configuration' AND KEY = 'global_auditing_state';
If the column value returns TRUE, then the audit mechanism is enabled.
In addition to enabling auditing, we must also ensure that specific policies have been defined. Without any active policies, most events aren’t recorded. To validate that active audit polices exists, execute the following SQL code:
SELECT * FROM "SYS"."AUDIT_POLICIES" WHERE "IS_AUDIT_POLICY_ACTIVE" = 'TRUE';
If any polices are listed, we can assume that the listed audit actions are being captured.
There are numerous additional items that should be checked and this is just a sampling of what needs to be investigated. For more information on the SAP HANA Security model, I would highly recommend you read my book titled the SAP HANA Security Guide. I also have a chapter in this book that list even more recommended settings for the purpose of securing your SAP HANA platform.
In summary, to properly secure a SAP HANA system, we must first understand the mechanics of the SAP HANA security model. Often time we must have have a strong understanding of how HANA works. The relationships among users, roles, and privileges are key to this understanding security. However, we must also take time to periodically monitor audit logs and system views to ensure that best practices are being followed.
SAP BI Blog 