Despite Beyonce's advice to protect what you love with a ring, ServiceNow recommends ACLs to secure your second love...your data. The ACLs we are referring to are ServiceNow Access Control List rules that allow and deny access to data and objects in your instance.
Administrators can modify out-of-the-box ACLs and are encouraged to create their own ACLs that are associated with new objects produced from development. It is up to the ServiceNow instance owner to implement access controls as needed. If ACLs are not created for an object, any authenticated user may be able to access the associated data.
There are quite a few base system ACLs that come preconfigured in the platform. These objects include:
- UI Pages
- Client-callable Script Includes
- Processors
- Tables
- Individual Table Fields
As you are creating objects within an instance it is always important to ensure that only intended users are able to access those objects and the data they can supply. As an administrator you have the ability to view ACL configurations in your instance. If you want to create new ACL's or modify existing ones, you need to elevate your privileges to the security_admin role.
When creating an ACL you can specify the CRUD (create, read, update, delete) operation for each ACL depending on the object type that you are locking down. Additional operations for some objects can be managed by ACL's. During table creation ACL's can be specified rather than configuring them after the table has been created. Other objects may require you to manually create an ACL afterwards. This is partially due to the common design of checking access to the underlying records via GlideRecordSecure in one of these objects. The data that these objects are accessing is almost always stored in a table, which already has an ACL on it.
As you are creating ACLs for UI Pages, Client-callable Script Includes, and Processors, the name of the object is specified in the "Name" field. Tables can be locked down entirely or more granularly by individual records, depending on the the circumstances. ACLs are evaluated in three ways:
- Based on user's roles
- Conditional requirements
- Script execution
Typically, ACLs are used to validate that the user accessing the resource has a particular role. However, a conditional requirement is also available for more flexibility. If you want to get really fancy, you can even have an ACL run a custom server-side script to determine if access should be granted. If any three of these mechanisms return "true," then access is allowed. Multiple ACLs can exist for the same object and operation, but if any one of them return "true," then access is granted.
It is always a good idea to check that ACLs are functioning as expected. UI Actions that allow an end user to create, read, update, or a delete a record are easy identifiers that ACLs are doing their job. Be sure to manually check the resources you are trying to secure by directly accessing them within the user context specified in the ACL. The last thing you want is an end user being able to access something that is unintended.
