Skip to Content
Technical Articles

Well-Controlled (SAP): What are the HANA Audit Policies you can configure to meet your regulators & business needs? (Design specification guide)

Key Highlights – SAP HANA Audit Policies

  • Audit logs in HANA enables management to monitor and record selected actions performed at the database level. Many important audit policies, including HANA user level activities, need to be manually turned on. Without HANA audit logging, actions compromising security or data integrity may go unnoticed.
  • HANA audit policies should be configured with the following few guiding principles in mind: (1) should be only configured if it addresses a specific requirement, (2) should only be targeting relevant objects or users, (3) should not be duplicate and should be concise (e.g. not configuring an audit policy for already monitored activities).
  • Minimum audit policies can be classified into 5 main areas: User & Role Management, Authorization Management, Data Manipulation, Object Maintenance and System Management. Each of these policies need to be manually configured in the HANA database.
  • Bonus tables at the end of the article: An example of the design output is posted within this article; the tables at the end outline the audit policies and the technical configurations for each policy (i.e. what policies need to be configured). Please remember, it is important to go through your change management process & to test and tweak the design tables per your environment.

Why HANA audit policies are important to be designed and configured as part of the system design phase?

SAP S4 implementations are ramping up and IT departments (and their consultants) continue to be accountable for implementing and deploying HANA level security. HANA requires management to place additional IT controls to effectively mitigate the new risks introduced by S4 HANA technology.

Specifically, management needs to design controls to address the risks around: access management, change management, data backup & recovery and development activities (e.g. data driven applications developed on the HANA level).

Below in this post, we are going to discuss an example of the design specifications needed to record user level activities in the HANA database and here is why:

  • Audit policies supports the monitoring & testing activities performed by security operators, internal auditors and external auditors. As such, audit policies should be configured to support each of the stakeholders requirements, while taking into consideration any regulation and system performance impact.
  • Auditing the user level activities in HANA is not enabled by default. User-level auditing can be customized per management requirement and its maintenance is subject to each company policy.

What Audit Policies are enabled by default? (SAP-enabled audit policies)

As mentioned, user level auditing by default is not enabled. SAP left it to each company to configure whatever they deem appropriate. This is like the Security Audit Logs – SM20 reports on the SAP application layer.

However, to maintain the integrity of the audit policies, SAP configured HANA with specific actions that are monitored by default. These actions are always audited and recorded. It is important to understand that these audited actions are not comprehensive to the needs of the different stakeholders, thus, additional policies need to be manually designed and configured.

Here are the details of these actions enabled by default:

  • Maintenance of auditing HANA configuration (Audit Activation Configuration): Changes to auditing configuration (i.e. enabling or disabling auditing), Changing the audit trail target, Changing the location of the audit trail target, Changing the maximum length of a statement that is audited completely, and Changing enabled authentication methods.
  • Maintenance of User-defined audit policies (Audit Policies Configuration): Creation, modification, or deletion of audit policies that are configured by the database administrator. Audit policies are the “what” activities monitored in the HANA database.
  • Deletion of the audit logs (Actual User Recorded Activities): Deletion of audit entries from the audit trail. This only applies to the audit trail written to an internal database table. It is not possible to delete audit entries from the syslog audit trail target.
  • Password change of the SYSTEM account (SAP HANA SAP*-like account): Changing the password of the SYSTEM user of a tenant database from the system database. An audit entry is written to the audit trail of both the system database and the tenant database.

What this means to you: For these actions outlined, SAP recommends that management should not create audit policies for these actions because they are automatically audite). It is important to know these still to be able to articulate them to anyone who wants to understand what policies you have enabled on HANA.

What Audit Policies need to be configured in the HANA database? (Manually configured audit policies)

After going through the default policies, below are the policies needed to be configured at minimum for a typical environment.

However, before we go into details, let us level set some key terminologies:

  • Audit Policy: This is a user-defined name in the HANA system. An audit policy is configured with the actions that will be relevant to it (e.g. User Management policy will record activities like creating a user). The Audit Policy is the “report” the company will generate out of the HANA database to view the actions audited.
  • Audited Action/Event: Actions or events are the actual activity performed or statements executed by a user at the database level (e.g. Create or Drop statements). These are specific to HANA and would not be different from one HANA database to another, at least same HANA database versions.
  • Audit Level: For each action configured in a policy, an audit level can be configured (e.g. Info, Warning, and Critical). These serve only informational purposes. It does not impact what SAP HANA records in the audit log. However, it may have a process impact on how you treat the audited action if they are manually/automatically monitored (i.e. a company would not treat Critical events in the same weight as Info events)
  • Audit Status: This defines whether successful, unsuccessful or all executions of the specified audit actions are audited.
  • Targeted/Excluded User: These are user-defined fields in an audit policy. Obviously, these are the specific users that HANA would monitor from a specific action.
  • Targeted/Excluded Object: These are user-defined fields in an audit policy. Similar to user level, these are the specific objects (e.g. tables or schemas) that that HANA would monitor from a specific action.

Now, that we went through these quick terminologies, let’s go into the details of each policy that usually are configured in a HANA environment. Generally, I like to classify audit policies into five (5) main areas:

(Area 1) User & Role Management

  • These are the set of HANA audit policies covering granting and revoking of privileges to end users and roles as well as creating and deleting roles & users.
  • Overall, these audit policies should be configured across all objects and all users. System performance generally are not impacted by these policies.
Audit Policy Name Audit Action Name SAP HANA Audit Action Audit Status Targeted Users
User and Role Management ALTER ROLE Altering roles Successful All Users
ALTER USER Altering users Successful All Users
ALTER USER GROUP Administering user groups Successful All Users
CREATE ROLE Creating roles Successful All Users
CREATE USER Creating users Successful All Users
CREATE USER GROUP Creating user groups Successful All Users
DROP ROLE Dropping roles Successful All Users
DROP USER Dropping users Successful All Users
DROP USER GROUP Dropping user groups Successful All Users
Granting and Revoking of Authorization GRANT ANY Granting of privileges, structured privileges or roles to users or roles Successful All Users
REVOKE ANY Revoking of privileges, structured privileges or roles from users or roles Successful All Users

(Area 2) Authorization Management

  • These are the set of HANA audit policies that includes changes related to the maintenance of structured and repository privileges.
  • Overall, these audit policies should be configured across all objects and all users. System performance generally are not impacted by these policies.
Audit Policy Name Audit Action Name SAP HANA Audit Action Audit Status Targeted Users
Structured Privilege Management ALTER STRUCTURED PRIVILEGE Altering structured/analytical privilege Successful All Users
CREATE STRUCTURED PRIVILEGE Creating structured/analytical privileges Successful All Users
DROP STRUCTURED PRIVILEGE Dropping structured/analytical privilege Successful All Users
Repository Privilege Management ACTIVATE REPOSITORY CONTENT Activating repository design time objects Successful All Users
EXPORT REPOSITORY CONTENT Exporting repository design time objects Successful All Users
IMPORT REPOSITORY CONTENT Importing repository design time objects Successful All Users

(Area 3) Data Manipulation

  • These are the set of HANA audit policies that includes direct database changes updates. This policy is a key hot topic for many regulators and frameworks; specifically, I see that this a main area of concern for SOX compliance activities.
  • This audit policy needs rigorous testing. These audit policies would generate huge amount of data if not configured appropriately. Some generic or technical IDs would generate tons of data within few hours (e.g. Schema IDs). When configuring this audit policy, the main focus should be the users who directly connect to the database and have the potential to update, insert, delete data in tables.
Audit Policy Name Audit Action Name SAP HANA Audit Action Audit Status Excluded Users
Data Query and Manipulation DELETE Deleting rows from tables/views and truncating tables. Allows specification of target objects. Successful Schema IDs and any technical generic accounts
INSERT Using insert/replace/upsert statements on tables and views. Allows specification of target objects. Successful Schema IDs and any technical generic accounts
UPDATE Using UPDATE/REPLACE/UPSERT statements on tables and views. Allows specification of target objects. Successful Schema IDs and any technical generic accounts

(Area 4) Object Maintenance

  • These are the set of HANA audit policies that includes maintaining database objects including: functions, tables, views, etc.
  • Overall, these audit policies should be configured across all objects and all users. System performance generally are not impacted by these policies. Again, the focus should be the end users who directly access the HANA database for development or support activities.
Audit Policy Name Audit Action Name SAP HANA Audit Action Audit Status Targeted Users
Data Definition ALTER FUNCTION Altering functions Successful All Users
ALTER PROCEDURE Altering procedures Successful All Users
ALTER TABLE Altering tables Successful All Users
ALTER VIEW Altering views Successful All Users
CREATE FUNCTION Creating functions Successful All Users
CREATE PROCEDURE Creating procedures Successful All Users
CREATE SCHEMA Creating schemas Successful All Users
CREATE TABLE Creating tables Successful All Users
CREATE TRIGGER Creating triggers Successful All Users
CREATE VIEW Creating views Successful All Users
DROP FUNCTION Dropping functions Successful All Users
DROP PROCEDURE Dropping procedures Successful All Users
DROP SCHEMA Dropping schemas Successful All Users
DROP TABLE Dropping of tables Successful All Users
DROP TRIGGER Dropping triggers Successful All Users
DROP VIEW Dropping views Successful All Users

(Area 5) System Management

  • These are the set of HANA audit policies that includes maintaining and supporting different functionalities within the HANA database
  • Overall, these audit policies should be configured across all objects and all users. System performance generally are not impacted by these policies. Again, the focus should be the end users who directly access the HANA database for development or support activities.
  • For policy #9 All Actions (Firefighter), this policy should only be configured to an emergency account used by an end user in critical situations. Also, sometimes this audit policy can be enabled for 3rd party vendor performing ad-hoc maintenance activities, where it is not expected they would create a lot of audit logs data. This policy #9 needs to be configured correctly to limit the data it would generate.
Audit Policy Name Audit Action Name SAP HANA Audit Action Audit Status Targeted Users
User Connection CONNECT Creation of a user connection to the database Unsuccessful All Users
System Configuration Management STOP SERVICE Audits stop of services Successful All Users
SYSTEM CONFIGURATION CHANGE Changes to the system configuration (for example, INIFILE) Successful All Users
All Actions (Firefighter) ACTIONS All user-triggered database actions. Used for specific users Successful N/A – Should only be enabled for a Firefighter account
Backup Deletion BACKUP CATALOG DELETE Deleting entries in the backup catalog Successful All Users
Volume Encryption ALTER APPLICATION ENCRYPTION Altering application encryption keys Successful All Users
ALTER APPLICATION ENCRYPTION ROOT KEY Altering application encryption root keys Successful All Users
ALTER BACKUP ENCRYPTION Altering backup encryption status Successful All Users
ALTER BACKUP ENCRYPTION ROOT KEY Altering backup encryption root keys Successful All Users
ALTER LOG ENCRYPTION Altering log encryption status Successful All Users
ALTER LOG ENCRYPTION ROOT KEY Altering log encryption root keys Successful All Users
ALTER PERSISTENCE ENCRYPTION Altering database persistence encryption status and page encryption keys Successful All Users
ALTER PERSISTENCE ENCRYPTION ROOT KEY Altering database persistence encryption root keys Successful All Users
ALTER ROOT KEYS BACKUP PASSWORD Altering backup password used to protect backup root keys Successful All Users
Client-side Encryption ALTER CLIENTSIDE ENCRYPTION COLUMN KEY Altering a column encryption key (CEK) Successful All Users
CREATE CLIENTSIDE ENCRYPTION COLUMN KEY Creating a CEK Successful All Users
CREATE CLIENTSIDE ENCRYPTION KEYPAIR Creating a client-side encryption key pair Successful All Users
DROP CLIENTSIDE ENCRYPTION COLUMN KEY Dropping a CEK Successful All Users
DROP CLIENTSIDE ENCRYPTION KEYPAIR Dropping a client-side encryption key pair Successful All Users
Application Auditing PERSONAL DATA ACCESS Audit log access to personal data Successful All Users
PERSONAL DATA MODIFICATION Audit log modification of personal data Successful All Users
CONFIGURATION CHANGE Audit log configuration change events Successful All Users
SECURITY EVENT Audit log security events Successful All Users

 

Bringing it all together

Audit policies, including HANA user level activities, are critical to compliance and security frameworks. Audit policies in HANA need to be manually turned on. HANA audit policies should be only configured if it addresses a specific requirement, should be targeting relevant objects or users, and should not be duplicate and should be concise.

In future posts, we can explore how to export and review the audited actions. Please feel free to add/change any of your thoughts via direct messaging me or in the comments below.


The views, information or opinions expressed in this short article are views of my own.  All information in this article is provided “as is”, with no guarantee of completeness, accuracy, timeliness or of the results obtained from the use of this information.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.