on 2023 Aug 22 11:27 AM
Hi All,
I am looking for some clarity on the best practices when utilizing a UPS with XSA.
I understand the UPS user is used to execute the .hdbgrants file which grants auths to the object_owner, application users, etc but I want to know if the UPS should actually be used in querying data directly itself to the schemas in the DB?
In my scenario, the UPS user is being used to access virtual schemas on the underlying DB, so in order to allow the container access, we used a UPS user to grant the auths to the object_owner so it can view the tables in the schema. My understanding is a bit unclear when it comes to the process around querying the data then, as the UPS has already granted the ability to the #OO user and to application users via synonyms, should the UPS ever be the one who then querying the data from the schema? I would expect the answer to be no but I have been receiving conflicting information and would really appreciate a simplfoed answer to this.
Many thanks,
Michael
Request clarification before answering.
Hello
the UPS user should only be used to grant access to object owner and runtime user. It is even more secured to use a grantor procedure like described here https://www.sap.com/documents/2018/04/fe086f0d-fa7c-0010-87a3-c30de2ffd8ff.html
regards,
Michael
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you for the response Michael. Would you say that once the UPS user has granted the access, it could be deactivated? I really don't like the idea of a UPS user existing with a plain text password that is open to be used by developers when ever they see fit. What is the best practice here on this approach?
yes, it could be deactivated with no effect as long as you do not perform any new deployment of the hdi containers referring to this UPS. Nevertheless, I would not recommend to do it as it a bit heavy process having to reactivate it each time you want to deploy a new version of your hdi containers. Instead, you should take care that this user is only authorized to CALL the grantor procedure and nothing else. In the grantor procedure, you can add some SQLScript logic to check the procedure is not called out of expected context. In addition, you could add an audit policy to trace all actions done by the UPS user. Note also that developers are supposed to be member of dev space only and so, are only able to get UPS user credentials for this non-productive space.
Thank you Michael, that is really good to know, and very informative. One last question if you would be so kind, the #OO user in production, my thinking is this user is not used or initiated when application users are in production? The users are granted roles in production, so the authentiucation is done on their ID and the auths are gained from their role collection, so there is no need for a UPS in production as roles are transported from DEV to production, is this thinking correct?
The role collections do not contain any database privileges. The XSA business users are accessing the database using runtime technical users that db privileges are granted via hdbgrant files that may refer to UPS. So, UPS are also required in Prod at deployment time.
| User | Count |
|---|---|
| 17 | |
| 8 | |
| 8 | |
| 6 | |
| 4 | |
| 4 | |
| 4 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.