SAP HANA

​

What Oleria discovers

• Accounts - every database user, with sign-in methods (password, LDAP, SAML, JWT, X.509 certificate, Kerberos), status, validity period, last successful sign-in, and e-mail address when the user has one. Users holding an administrative system privilege, such as USER ADMIN or ROLE ADMIN, are marked as administrators.
• Non-human identities - technical users, users created by HDI containers and SAP BTP service bindings, and SAP’s own users such as SYSTEM and the _SYS_* and _SAP_* users. Each one appears as a service account. Credentials stored in the SAP HANA secure store appear as secrets, linked to the user that holds them.
• User groups - every user group and its members. Users with the OPERATOR privilege on a group are shown as able to administer its users.
• Roles - global and schema-local roles, which roles contain other roles, and which users hold each role, including whether they can grant it to others.
• Resources - the database, its schemas, remote sources, and every table, view, procedure, or other object granted directly to someone. Oleria shows each object’s owner.
• Access - every system, schema, object, and remote-source privilege granted to a user or a role.
• Administrative access from SAP BTP - on SAP HANA Cloud, anyone with the SAP HANA Cloud Administrator role collection in SAP BTP can reset the DBADMIN password. Oleria shows this as a group named SAP HANA Cloud administrators (SAP BTP, synthesized) that can act as DBADMIN. The group has no members in Oleria, because SAP BTP manages them. Review who holds the role collection in your SAP BTP subaccount.
• Activity - sign-ins, failed sign-ins, user and role changes, grants and revokes, credential changes, and other events recorded by your SAP HANA audit policies.

​

Prerequisites

• An SAP HANA Cloud instance, or an SAP HANA 2.0 tenant database.
• A user that can create users and grant privileges in the database, such as DBADMIN on SAP HANA Cloud.
• Admin access to the Oleria workspace.
• For SAP HANA Cloud: permission to edit the instance’s allowed connections in SAP HANA Cloud Central.

​

Create the connector user in SAP HANA

CREATE USER OLERIA_CONNECTOR PASSWORD "<password>" NO FORCE_FIRST_PASSWORD_CHANGE;
ALTER USER OLERIA_CONNECTOR DISABLE PASSWORD LIFETIME;

GRANT CATALOG READ, AUDIT READ TO OLERIA_CONNECTOR;

GRANT ROLE ADMIN TO OLERIA_CONNECTOR;
GRANT OPERATOR ON USERGROUP DEFAULT TO OLERIA_CONNECTOR;
GRANT CREATE USERGROUP TO OLERIA_CONNECTOR;
GRANT SESSION ADMIN TO OLERIA_CONNECTOR;

GRANT ROLE ADMIN TO OLERIA_CONNECTOR;
GRANT USER ADMIN TO OLERIA_CONNECTOR;
GRANT SESSION ADMIN TO OLERIA_CONNECTOR;

​

Turn on audit policies for activity

CREATE AUDIT POLICY OLERIA_CONNECT_AUDIT AUDITING ALL CONNECT LEVEL INFO;
CREATE AUDIT POLICY OLERIA_USER_ROLE_MGMT_AUDIT AUDITING ALL CREATE USER, ALTER USER, DROP USER,
  CREATE ROLE, ALTER ROLE, DROP ROLE, CREATE USERGROUP, ALTER USERGROUP, DROP USERGROUP LEVEL INFO;
CREATE AUDIT POLICY OLERIA_GRANT_AUDIT AUDITING ALL GRANT ANY, REVOKE ANY LEVEL INFO;
CREATE AUDIT POLICY OLERIA_CREDENTIAL_AUDIT AUDITING ALL CREATE CREDENTIAL, ALTER CREDENTIAL,
  DROP CREDENTIAL LEVEL INFO;
ALTER AUDIT POLICY OLERIA_CONNECT_AUDIT ENABLE;
ALTER AUDIT POLICY OLERIA_USER_ROLE_MGMT_AUDIT ENABLE;
ALTER AUDIT POLICY OLERIA_GRANT_AUDIT ENABLE;
ALTER AUDIT POLICY OLERIA_CREDENTIAL_AUDIT ENABLE;

​

Allow Oleria to connect

​

Connect SAP HANA to Oleria

​

Verify the integration

​

Remediation actions

• Deactivate a user and reactivate a user. This includes disabling technical and other service-account users from the non-human identity inventory.
• Grant a role to a user and revoke a role from a user. Revoking removes the role however many users granted it.
• Move a user into a user group, and remove a user from a user group. On SAP HANA Cloud, every user belongs to one user group, so removing a user moves them to the DEFAULT group. On SAP HANA 2.0, removing a user leaves them in no user group.
• Revoke a user’s privileges on a resource. This removes the privileges granted directly to the user on a schema, object, or remote source.
• Create a user in a user group, with an e-mail address. The new user must change the password at first sign-in, and stays deactivated unless you activate it. Reverting deletes the user only if Oleria created it.
• Create a user group. Reverting deletes the group only while it has no users.

• Delete a user. SAP HANA refuses to delete a user who owns objects other than their own empty schema, so no data is deleted with the user.
• End a user’s sessions. This disconnects every open session. SAP HANA has no session tokens, so a user can sign in again; deactivate the user to keep them out.

• Oleria won’t act on the connector user itself or on SAP-managed users, and it won’t deactivate or delete DBADMIN.
• SAP HANA lets only the user who granted a privilege revoke it. Oleria can revoke only privileges that the connector user granted, and it tells you who granted any others.
• Access a user gets through a role isn’t changed by a privilege revocation. Revoke the role instead.
• SAP HANA can create, deactivate, move, or delete only users whose names contain just letters A–Z, digits, _, #, and $. Users created with SQL always qualify.
• Oleria doesn’t disable stored credentials, because SAP HANA can’t restore a dropped secret.

​

Known limitations

• Oleria doesn’t import structured (analytic) privileges or column masks yet.
• Each connection reads one database. Oleria doesn’t enumerate the tenants of an SAP HANA 2.0 system from its system database.
• Activity depends on your audit policies. Events that no enabled policy covers aren’t recorded by SAP HANA.
• SAP HANA has no second sign-in factor of its own. Multi-factor authentication for single sign-on users is enforced by your identity provider.

​

Contact us