Security
HANA security protects the database and its data through users, roles, privileges, encryption and auditing. Because HANA holds all of S/4HANA’s data, securing it is fundamental, layered beneath application-level (SAP role) security.
In an SAP application context, most end users never touch HANA directly, they go through the ABAP/application layer with its own authorizations.
- HANA has its own users and a rich privilege model: system privileges (administrative actions), object privileges (on…
- HANA’s audit policies log security-relevant actions (logons, privilege use, sensitive access) for detection and compliance.
- Encryption: data-at-rest (data and log volume encryption) and in-transit (TLS).
- Watch out: Over-privileged HANA users (e.g. broad system privileges).
Users and privileges
HANA has its own users and a rich privilege model: system privileges (administrative actions), object privileges (on tables/views/schemas), analytic privileges (row-level data restriction for models), and package privileges. Roles bundle privileges for assignment, following least privilege as always.
Data protection
- Encryption: data-at-rest (data and log volume encryption) and in-transit (TLS).
- Data masking / anonymization for sensitive data.
- Analytic privileges for row-level authorization in models.
Auditing
HANA’s audit policies log security-relevant actions (logons, privilege use, sensitive access) for detection and compliance. Configuring and reviewing auditing is a core control, especially given the sensitivity of the data.
HANA vs application security
In an SAP application context, most end users never touch HANA directly, they go through the ABAP/application layer with its own authorizations. HANA security mainly governs administrators, technical users and direct/native access. Both layers matter and should follow least privilege.
Common pitfalls
- Over-privileged HANA users (e.g. broad system privileges).
- Unencrypted data/log volumes.
- No auditing of sensitive/native access.