Report or be notified when ACL are updated on the platform

[Beno_t Proulx]

Hi.

We want to allow some developers to be able to create and modify ACLs (with the security_admin role) in our Dev instance. Even though we don't grant the "security_admin" role in our other instances, developers are able to deploy those ACLs created in Dev using UpdateSets to our other instances.

We have a business process where we ask developers to have the ACL updates reviewed by Security Admins before migrating them in other instances, but we'd like to find a way to enforce that by notifying Security Admins (either through a notification or a scheduled report perhaps) when ACL updates occurred in the other instances, either through directly or through a committed updateset that contained an ACL update.

In the end, what we want is to monitor/review changes to ACLs in other non-Dev instances without preventing or blocking the developers from developing the ACLs in the Dev instance in the first place

I thought about adding an notification on updates to the "Access control" table, but I don't think notifications are executed during the committing of an update set.

I also thought about a daily scheduled report, but it seems ServiceNow does not allow reporting on the Access Control table. I created a Report Source to fetch data from the Access Control table and used it in a report but I'm unable to save it: I get "Permission Denied".

What would be the best approach or your recommendation?

[Allen Andreas]

Hello,

You'd need to give more information for us to best help you.

1. Why is this being done? (is there a reason you're not trusting them with ACL changes, etc.?)
2. You reviewing it in the next instance is already "too late" as far what #1 would be about. If your goal is to review them due to 'x'...then your delay in doing so in another instance could be missed
3. Why wouldn't you conduct this review in Dev, itself?

This is a bit of an odd question that you have as there are many unanswered questions here.

Please give more context so that the appropriate information can be relayed to you.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Beno_t Proulx]

Thanks for reaching out

1. Our organization is relatively new to the platform and we have onboarded many new developers with different level of experiences. We want to let most of them manage ACLs for their applications without bottleneck during the development phase. As mentioned, we ask them to have their designs/updates reviewed before deploying to the other environments, but we realized some "bad things" have sometimes slipped through without proper review. It's not just about trust, but also learning opportunity: Developers need to get their hands dirty to learn which involves mistakes will be made. We don't have a team dedicated only to Manage security for all applications being developed. 
   
   
2. We have 4 instances in our DevOps, Dev>DevTest>ProdTest>Prod. Catching an issue related to ACL in any of the other instances than Prod will be better than for them making their way up to Prod. And that's what we're trying to automate: reporting on changes to ACLs in sub-Prod instances to those type of changes can be brought forth. We're especially concerned about new/updated ACLs related to Base out of the box tables that have the potential of having overreaching consequences.
   
   
3. Ideally, yes, we want to review in Dev, that is the point, but we still want to raise awareness to the Security Admins about changes occurring in the other environments, either directly or though updates. To my knowledge (and maybe I'm wrong), it's not possible to prevent a developer with permissions to commit update sets in an instance from committing updatesets containing ACLs (?). Hence to wish here to be able to monitor updates to ACL made in other environments than Dev.