Fine-grained security for configuration permissions

[BevanWeiss]

We've recently had a customer encounter an issue which destabilised their Geo SCADA Expert system which I can't see a good way to easily overcome.

The issue was:

A user with configuration permissions to the database imported an SDE which should not have been imported.

This SDE contained a database backup object, and associated objects which resulted in the backup running quite frequently, and it had the historical data tick boxes ticked, so it consumed large amounts of disk space (on C:\).

The security settings associated with the objects were also such that within the production system that they were deployed in the objects were not visible to any configured users, nor were the objects able to be deleted by anyone other than the superuser account.

Given the current security configuration of Geo SCADA Expert, I can't see an easy way to prevent this from occurring, whilst still allowing such 'authorised users' to instantiate new sites, and configure outstation objects / points associated with those new sites.  This is not something that we wish to be purely a SCADA Admin task.

So what would be good would be something like one of these options:

1. The ability to only allow certain objects to be created within certain portions of the Database Hierarchy (i.e. we never want anything other than Points / Groups / Outstations / Mimics outside of the !Config / !System groups)

2. The ability to only allow certain objects to be created by certain user groups (i.e. we never want SCADA Integrators to be able to create / configure anything other than Points / Groups / Outstations / Mimics)

I understand the counter argument is that ALL configuration changes should only be performed by people with appropriate trust / experience to make such damaging changes to the database, however for large systems, it is not always practical to ensure all people are sufficiently experienced.  Some of these customers are deploying up to 80 new sites a week, the amount of labour required to do that means that it can't be all driven in-house by SCADA Admins.  So sectioning off security levels becomes a requirement.

[sbeadle]

Thank you. This is particularly noted for larger systems, and because an sde could be imported which is of unknown origin, so could contain unexpected items. It could be needed if a SCADA as a service system was constructed.

[du5tin]

We have similar security risks happening with our systems where we configure emailed reports where the user needs to have the report emailed to themselves or if we want to give users the ability to update their own email address or email to text information. To reduce the admin overhead we basically need to give the user permission to configure entire folders or sets of objects when they should only have permission to edit parts of one object. 

We did some exploration on how to do this with individual users but eventually had to give authenticated users permission to configure user objects so they could edit their contact info or assign redirection user groups on the fly. 

[BevanWeiss]

In the situation where the permission change can be sufficiently isolated I've used logic to do the permission escalation.

i.e. a user executes a piece of Logic that updates their phone number / email address etc.

In this way rules can be put against the action to validate / verify it before making the change, and the user doesn't need permissions to configure the object.  They just need Control permission on the Logic (and then the Logic is configured to require Control permissions to execute).

But it's still annoying... and it results in a lose of change log details (i.e. the Configuration Change entry shows edited by 'Logic' not the user that actually triggered the action).