How to secure database connection from certain users?

Our client has some sensitive databases that not all designers should have access to…

Does anyone know how to restrict database access in Ignition?

I know that one can disable database manupulation in Vision, through project settings. But for Perspective this is not possible. ( anyhow, the database query browser will always be “unsecured”)

No. Cannot be restricted from the designer.

Should I put a request in the “new ideas” section or is this just unfeasible for the platform

A user of the designer can create gateway message handlers and then run them. So, can run arbitrary code on the gateway. Which can therefore run anything, including undocumented IA interfaces, in an identity-less environment. I can’t imagine any way to make your desired restrictions feasible.

1 Like

If you want some data of the database to be accessible to some designers but not others - what’s the end goal? Are you going to want different users to only be able to see certain data based on certain user roles? That’s fine and you could get manage getting that done using roles and having separate database connection strings with different privileges and different containers (or even whole windows if you use roles to change navigation) available to the user based on their role - but a Designer can (and imo SHOULD) be able to utilize all database connections in the Designer.

Even if it was feasible being a designer, trying to design an application, against tables you cannot see - this is going to really put a dent in productivity.

1 Like

One option would be using version control with Ignition in combination with different development environments. Each environment would have its own instance of the database(s). You then restrict access to the environment tier, rather than to the database connection within Ignition.

To @bkarabinchak.psi’s point, you would want a Dev/Test version of the Production database you are looking to restrict (you can empty the tables or fill with mock data if the data is sensitive). This way the “restricted” developers can still develop without interacting with your production database instance.

Using this option, you would also want to version control your database structure and avoid making any one off, manual changes, that aren’t tracked. Makes it next to impossible to keep development tiers in sync and know exactly what exists in each DB instance. We version control our DB’s by adding a db_version schema with related meta data tables and only make changes to the DB via “SQL change scripts” that we keep in git (each script has it’s own DB version that it updates the db_version meta data tables with).

Edit - Should have pointed out that this would all be a huge undertaking for a system that is already being used in production. Setting up version control for a DB already in use is time consuming and, if you are interacting with PLCs, it will take a lot of effort to simulate them in your various environments (along with making sure your environments stay up to date with PLC tag changes).

3 Likes

Thank you all for your valuable input.

A dev/prod environment as suggested by @WillMT10, seems like the only valid configuration to get the necessary segregation.

Do keep in mind that a gateway backup includes the credentials Ignition uses for all of its outbound connections, including databases. Be sure to use a secure process to move backups from production to dev to avoid exposing these. (The passwords are reversibly encrypted in the internal database.)

2 Likes