How can we secure In-database connections on the server?

[archana986]

Hi,

I have a security concern with the In-database files and need some solution to tackle this issue. 

We currently manage database security for individual users via roles tagged to Individual user ID's.  All Alteryx In-database connection files are placed in a common secured share folder that is accessible to members in a specific studio.

Assume User A and User B are a part of the studio named "DepartmentZ" and have secure access to "SharefolderZ". User A wants to use the In-DB connection he has created , via a connection file that is placed in "SharefolderZ" to run a job on the Alteryx gallery. User A has access to schema 'xyz'.

User B who has access to schema 'abc' will also have access to use the same file as they are mapped to the same studio "DepartmentZ" and have secure access to "SharefolderZ". Now User B can view the schemas that UserA has access to via Alteryx In-DB connection file, although, he is authorized only to have access to schema 'abc' and not schema 'xyz'. The credentials in the file are that of User A but User B can run them too. How can we secure these In-database files and allow specific users to run using the specific connections via the gallery?

I am able to do this with the regular data connections in the gallery, by adding only users who have approved access to a connection , but they only work for input tools.

How can we maintain similar security for in-database connections as they allow for faster data processing but are not in-sync with the data governance processes.

Please advise.

Thanks,

Archana

[AnupD]

Hi,

One way I can think of is letting users create the In DB connection file locally on their machine and then having them package the workflow before publishing it on to the Gallery. This way nobody else on the server will have access to In DB file and the connection as such. Also, since database security is set up at their individual ID level, they won't be able to access (or configure) anybody else's permissions. Plus, less overhead for Curators.

Hope this helps.

Thanks,

Anup