Balancing data accessibility and security with Data Filtration

Access Control Lists (ACLs) are an important piece of the puzzle for ensuring data security and preventing access to those who should not have access to it.

It restricts access to data by requiring users to meet a set of criteria before interacting with it.

Every Access Control List rule specifies:

• The table/data being secured.
• The permissions/roles required to access the table/data.

However, ACLs can be a bit confusing at times, and we end up with a huge mess of hierarchical rules that are difficult to debug and can cause problems.

Fortunately, with the Tokyo release, ServiceNow has provided us with a new tool in our environment called Data Filtration that allows us to build out security rules more easily and quickly. Data Filtration simplifies certain requirements while also providing more granular access and security.

Most regulatory auditors do not permit the use of scripting to protect data (like in ACLs). Data Filtration solves this problem because it defines access declaratively, allowing us to define read access to records based on conditional logic rather than scripts.

Data Filtration is used to control access to tables and records based on subject criteria attributes when performing Read queries.

Components of Data Filtration:

It defines the Data Filter and Subject Attribute conditions described below to limit the scope of the rule and the affected users.

• Data Filter: It specifies the table and conditions under which access should be granted/revoked.
• Subject Attribute: It defines the user attributes that will be used to determine whether or not access is granted. The attributes that can be configured are user groups, roles, IP address, or a combination of any of the listings.

Pre-requisites for Data Filtration:

• Activation of Plugins – This is an optional feature that administrators can activate on their instance (com.glide.data_filtration)
• Administrators must enable security admin from elevate roles, like ACLs to build the rules.

 Limitations of using Data Filtration:

• Unlike ACLs, there is no admin override feature which means that data visibility is controlled for all users regardless of admin privileges.
• The enforcement of Data Filtration rules is consistent with that of Read ACLs. Unlike ACL, it does not support Create or Delete operations.
• The visibility conditions are declarative and are limited to groups, roles, IP addresses, or combinations of these three.

Benefits of using Data Filtration:

• Data Filtration works in conjunction with ACLs, however they are executed BEFORE the ACLs
• ACL is a ‘grant’ principle, whereas data filtration is a ‘deny’ principle. By configuring the rules, your instance denies access to records unless they meet the Data Filtration conditions.
• Choosing declarative over scripted option reduces technical debt.
• Data Filtration occurs AFTER the ‘before-query’ business rules have been applied.
• Data Filtration supports session debugging to determine which Data Filtration records apply to a given query. Administrators can use this data to troubleshoot user access to records.