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.
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.
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).
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.)
Hi guys, I know this is an old thread, but just curious to know whether we can restrict it from using the auditing table.
Consider that we are using the Auditing in the DB rather than internally because some logic developments require the data from that particular DB, But now I want to restrict this from designers/ consider for necessary roles, if they have a role then only they should have to access the tables. Any ideas on this?
Also, if there is no logic development from the database, what is a good method, so that others can take tamper the data.
The most secure approach is to create a view with the name and columns required by the audit table, but pointing at a real audit table for which access is denied to the Ignition gateway.
Then place DB triggers on the view for insert/modify/delete that examine the operation and only pass on to the real table what is appropriate. You'd presumably allow inserts that aren't in the past, modifications for comments only, and only for recent entries, and no deletes at all. The triggers would need to be set to run with owner permissions instead of user permissions, so that the trigger would have access to the real table.
Ensure that the gateway connection credentials do not have permission to alter the view or the triggers.
{ You cannot restrict what a designer can access versus what the gateway itself can access. Full stop. }