In today's cyber-threat landscape, prioritizing data security is more important than ever. Security is one of the key cornerstones of SAP BTP and SAP HANA Cloud strategies.
SAP HANA Cloud takes a comprehensive approach to security, providing a layered defense system encompassing authentication, authorization, encryption, and auditing.
At the heart of this security strategy lies strong credentials management practices, one of which is the credentials rotation. For example, organizations can significantly reduce the risk of unauthorized access and data breaches by enforcing regular password rotation.
Certificate-based credentials are the game-changer
While strong passwords and their rotation are a must, they're no longer enough. We recommend using certificate-based credentials, a robust security practice that adds an extra layer of protection and should be adopted by all SAP HANA users.
Certificate-based credentials offer a far more robust solution. Here's what you get:
- Multi-factor Authentication (MFA): Imagine needing both a certificate and a secondary factor (e.g., PIN, fingerprint) to access your HANA environment. MFA is typically done at identity provider and mainly in combination with short-lived SAML/JWT tokens for the actual database access.
- Rotation: Hackers adore static credentials, but with certificates, they expire regularly, rendering stolen ones useless, and you can no longer use them for login. It's like changing the locks on your house now and then, depending on how often you need it. The benefit of certificates is that you can have multiple certificates for an overlapping time range when changing them.
- Reduced Attack Surface: Fewer passwords to manage mean fewer potential entry points for attackers. It's like having fewer windows to climb through.
In case there is still the need to work with password-based authentication, there are a couple of password rotation tricks on how you can enhance your security and which HANA supports.
How Password Rotation Works in SAP HANA Cloud
Password rotation, also known as password aging, is a security protocol that mandates the periodic change of passwords for user accounts. This practice helps to mitigate the risk of unauthorized access if a password is compromised.
In SAP HANA Cloud, password rotation is controlled by password policies that can be customized to meet specific organizational requirements. These policies can specify a wide range of configuration options like the minimum password length, the required character types, the minimum/maximum password lifetime, and the frequency with which passwords must be updated.
The SAP Cloud HANA database comes with a default password policy. You can change the default password policy of the database in line with your organization’s security requirements.
Disclaimer: from the HANA side there is no difference for password management between on-premise HANA and HANA Cloud.
Scenario 1: "Zero down time password change" for database users
In case your organisation needs to sustain changing passwords for HANA database users without experiencing any interruption in service or accessibility, or in other words, the HANA Cloud DB should remain fully functional and accessible while changing/updating passwords for those users – it is supported by the product.
On the other hand, in case under “zero downtime password change” is also meant changing the password of a user in HANA without having to change the password used to connect to HANA at the same time in their application to avoid failed connect attempts (something like this can be achieved by allowing connect for one user with multiple passwords) – SAP HANA Cloud DB only supports a single password per user at a time.
The proper way to avoid this issue is to use other means of authentication, typically X.509. In that case you would only configure trust to the X.509 issuer in HANA and set a new X.509 certificate in the application before the current one expires. The same can be achieved if the application supports our SAML/JWT authentication.
As a short summary, this is not a limitation on the SAP HANA Cloud DB side but on the application side.
Scenario 2: How to manage technical users with regards to password rotation and their authentication in general?
For technical users, our recommendation remains the same: to use X.509 or SAML/JWT authentication when possible. If password-based authentication is used, this will require any potential password change to be performed simultaneously both in the HANA database and on all clients to avoid failed logins or locking of the technical user due to such failed logins.
Moving all application access of the technical users to X.509-based authentication will also allow them to update the certificates of the services individually without having to coordinate this as it would be required for a central password change.
Individual users could still authenticate using passwords, and this distinction would even allow to differentiate between service access and user access. On top of this, you can still rotate the passwords safely if anyone is leaving.
Important: it is recommended to use dedicated database users and not mix technical and named user access in case you have a technical user that is used by services to access the HANA DB, and they seem to also use that same database user for their real users to access the database.
Additionally, what you can do for password change is to:
1. Suspend the system during the change of the password.
2. Disable on the HANA DB the user lock temporarily by setting User Lock Time to 0 when changing the password. Then, you have time to change the password on the database and the clients.
Important: However, there will almost be a timespan (change of password in user store and change of password on SAP HANA DB) where no application user can work on the system.
Scenario 3: Several teams are working on a project and sharing the same HANA database user across the group
If your concern is that if anyone leaves the project or company, they are still able to access the database through, for example, Database Explorer, or if they have an S-User ID, we recommend the following:
- Presumably, when someone leaves the company, their user will be removed from the identity provider and will no longer be able to log in. As for the database users, it might be possible to setup SSO with a mapping between the user used to sign into the identity provider and the database. In that way, once the user is removed from the identity provider, they would no longer be able to log in to the database.
- Deletion of separate DB users for each person and make sure the DB user is deleted if a person moves off the project team or company.
- Move away from password-based authentication, so another option would be to set up SSO or certificated-based authentication (e.g., X509 or JWT) for created users. Still, you need to delete the respective mapping after the user leaves the project to ensure it has no access like pointed out above for identity provider set up.
- Perform a password rotation in the current setup (if possible) whenever a user is leaving the project if you decide to stay with password-based authentication:
- You can use the 'ALTER USER <user> FORCE PASSWORD CHANGE' syntax to force a password rotation on the next login for any user (including SYSTEM);
No comments:
Post a Comment