cancel
Showing results for 
Search instead for 
Did you mean: 

restrict a HANA accout from logging directly into they database

mhughes2
Participant
0 Kudos

All,


We are about to have an outside audit company that is about to come in and has had some questions about logging/reviewing account log-ins directly into the HANA Application or DB tenants.

Is there a way in HANA to restrict a user as you would in the ABAP environment to be designated as a "SYSTEM" account which would allow the account to be used by outside applications to access as needed but restrict any "direct" log on by a users like it was a dialog account.

I have looked and thought maybe the "ALTER USER" Statement of:

<client_connect_option>


but I am not sure if that would stop the application of the service account from access the system then.

Any help would be appriciated.

Michael

Accepted Solutions (0)

Answers (4)

Answers (4)

jgleichmann
Active Contributor

Hi Michael,

I don't know if I got you right but you can check out the 'restricted user' function. All Alter / create user commands are well documented by SAP. Just have a look.

'Restricted users, which are created with the CREATE RESTRICTED USER statement, initially have no privileges. Restricted users are intended for provisioning users who access SAP HANA through client applications and who are not intended to have full SQL access via an SQL console. If the privileges required to use the application are encapsulated within an application-specific role, then it is necessary to grant the user only this role. In this way, it can be ensured that users have only those privileges that are essential to their work.'

Regards,

Jens

mhughes2
Participant
0 Kudos

Thank you for your reply Jens sorry for the late response had a huge GRC project that was going live that took my time.

For all of my HANA "Service" accounts that we create using the above when extended access is needed to a table or calculation view then I do create roles specific to that access.

PWC had asked specifically whether users could be restricted from even logging on as the account as they are in ABAP so that changes made by the account are done via an appropriate RFC functional call.

Users should not know the password for service accounts, but in a global organization how secure a password is relative to employee turnover and lax attitudes from developers who set up a process in a productive environment and then abuse that password or share it with others.

It's look as if there really isn't a way to do this.

former_member612251
Participant

I would first ask, why are these users logging in? Do they need to be logging in? if not, delete the user, if they need to then there shouldn't be an issue with audit? Are the users accessing views in the DB? If so then you should just create the views on the application, expose it there.

mhughes2
Participant
0 Kudos

Michael,

sorry been busy and hadn't checked my inbox in awhile.

These are specifically "SYSTEM" accounts like we would have in an ABAP system to run an application.

with a SYSTEM account in ABAP you have a set password but no direct GUI log on access so the account is secure. Only an RFC call to the account will validate authentication and then authorization as needed.

In HANA when the account is created, and then you set the password to never expire in order to ensure that the application does not fail due to expired password, but if the password becomes "known" somehow a user can then log onto that account directly to the HANA DB. I wanted to know if there is a way to get a HANA account to act like a SYSTEM account in ABAP.

former_member612251
Participant

If you're trying to de-risk the password leaking, why not use SSO for the users? X.509, SAML, Kerberos, plenty to work with there.

You could create a user with an X.509 cert auth identity. A simple SQL statement would do the trick:

CREATE USER "XXXX" PASSWORD "Password" WITH IDENTITY 'C=US, ST=CA, L=DUBLIN, O=sap.com, CN =XXXX ISSUER '

C=US, ST=CA, L=DUBLIN, O=sap.com, CN=Root CA' FOR X509;

former_member612251
Participant
0 Kudos

If you're trying to de-risk the password leaking, why not use SSO for the users? X.509, SAML, Kerberos, plenty to work with there.

You could create a user with an X.509 cert auth identity. A simple SQL statement would do the trick:

CREATE USER "XXXX" PASSWORD "Password" WITH IDENTITY 'C=US, ST=CA, L=DUBLIN, O=sap.com, CN =XXXX ISSUER 'C=US, ST=CA, L=DUBLIN, O=sap.com, CN=Root CA' FOR X509;

mhughes2
Participant
0 Kudos

Thank you for your reply Jens sorry for the late response had a huge GRC project that was going live that took my time.

This in not related to end users with their own accounts, it is really about what Sankara is referring to in the next reply with security to "Service accounts" in a productive system which SAP has very well controlled criteria on in ABAP.

former_member612251
Participant
0 Kudos

Hi Michael,

I would think this still applies, regardless of user type as they still have to uthenticate.

regards,

Michael

sankar_27
Active Participant
0 Kudos

Hi Michael ,

Integrate SAP HANA into single sign-on environments using Kerberos, SAML 2.0, JSON web tokens, and logon and assertion tickets etc. each mechanism has ts own advantages, you cab choose and implement depends on scenario.

By default all supported authentication mechanisms are enabled, but it is possible and recommended to disable those that are not used in your environment. You do this by configuring the parameter [authentication] authentication_methods in the global.ini configuration file. The value of this parameter specifies all enabled methods as a comma-separated list.

The default value is pbkdf2,password,kerberos,spnego,saml,saplogon,x509xs,jwt,sessioncookie,ldap.

Thanks, Sankar



mhughes2
Participant
0 Kudos

Thank you for your comments Sankara, we are working on getting our SAP HANA systems moved to SSO but are not there yet.

I could see us using AD LDAP ID that are locked to direct log on once we enable the above as a work-around in the future but would need to understand how that would affect our 3rd party connections that required direct access to the HANA DB.