Access Control in ServiceNow with 'Deny Unless' ACLs

[Sonam_Tiwari]

This article is around deny ACLs released in X Release. If you’re scratching your head, wondering what that means - let’s break it down in a way that makes sense.

What’s the Big Deal with Deny ACLs?

So, first off, what exactly is an ACL? Well, ACL stands for Access Control List, and it’s basically a list that tells our system who can access what. Traditionally, we’ve been working with allow ACLs, which let users in if they meet just one condition. But here’s where deny ACLs come into play—they’re flipping the script and saying, “Not so fast! You can’t just waltz in unless all the conditions are checked off!”

Why Deny?

Why do we need this? Think of it like this: with deny ACLs, we’re setting a stricter security standard. Instead of letting users in on a technicality, we’re ensuring that only those who truly meet the criteria can access sensitive information. This is a huge step toward tightening our security and simplifying access management. 

Its all ANDed and not ORed.

How Do Deny ACLs Work?

Here’s where it gets interesting. Deny ACLs act as the first line of defense. They check users before any allow ACLs come into play. If a user doesn’t meet the criteria in the deny ACL, they’re denied access right away—no questions asked.

For example, let’s say you have a deny ACL that requires a specific user role and a certain set of conditions, security attributes and a little script to access certain data. If a user doesn’t have any of these, they won’t get a chance to hit the allow ACL. This ensures that the only people getting through the gates are those who are truly supposed to be there.

Flexibility

One of the aspects of deny ACLs is their flexibility. There aren’t any out-of-the-box deny ACLs, meaning you can customize them to fit your organization’s needs. They work with various ACL types and operations, including table inheritance. This means that if you set a deny ACL on a parent table, it automatically applies to any child tables. 

Real-World Scenarios

Let’s break this down with some real-world examples. Picture this: you have a Change Request table with a couple of deny ACLs and one allow ACL. If a user tries to access this table, they need to pass those deny ACLs first.

Say there’s a deny ACL that says only users with the Change Manager role can read Change Requests marked as priority one. If a regular ITIL user tries to access it, they’re out of luck. However, if they switch to a Change Manager role, they can breeze right in because they meet all the deny ACL requirements.

And it’s not just about read access. Deny ACLs can apply to field-level security too. Imagine a scenario where you have a deny ACL on the assignment group field which says the access won't be granted on this field unless user possesses the change manager role.

The Bottom Line

So, what’s the takeaway? Deny ACLs are a powerful addition to our security toolkit, helping us maintain stricter control over who gets access to what. By requiring all conditions to be met, they simplify the process and clear up any confusion in access management.

In a world where security is more important than ever, deny ACLs are here to stay, making our systems safer. Start with Deny and then go on towards the allow if permissive ACLs. 

Thanks for tuning in, and happy securing!

Here's a link with a walkthrough - https://www.youtube.com/watch?v=ZzMsd1Q7Zkk

[Shrinivas Koppa]

When would one use Deny Unless ACLs versus Data Filtration?
Exploring Data filtration
Deny-Unless ACL

[Guilherme Mazie]

And for administrators this is also done? Because I added the admin override = false and he can still see it


Is there any explanation for this scenario?