Security Top Tips Part 4: Keeping to your lanes - ... - ServiceNow Community
ashok-sn
ServiceNow Employee
ServiceNow Employee

find_real_file.png

On the straight and narrow

In the last post we looked at how to make authentication to your instance more secure. That’s the first stage of access control. But there's still the question of what a user can access once they have logged in - authorization - and that's the topic of this post.

Should everyone have access to all parts of the system and data? The answer is usually no of course; in fact, sensitive data should be available only to a carefully defined subset of users. This is not only good practice but is also required by laws and regulations such as PCI-DSS, HIPAA, GDPR, CCPA, etc.

It’s also a good idea to limit users' access to just the parts of the system that they need for their roles. For example: only certain HR staff should be able to access sensitive user information; ordinary users should not be able to access system configuration... and so on. This can prevent users being overwhelmed with too many options, and help them have a good experience with the system. It also stops potential privacy violations and accidental changes to configuration or data.

In the toolbox

The Now Platform® gives you the tools for granular control right out of the box. Access to parts of the instance user interface, its functions, and data are managed with access control lists (ACLs) and role-based access controls (RBAC). ACLs are applied to objects, and they define user and groups permissions, e.g. read, write, delete, create (RWDC). Along with ACLs, you can define user roles to cater for different types of users or jobs. RBAC rules are created by first assigning user accounts and groups to roles, and then creating ACLs based on those roles. So, users are added to roles, and then permissions assigned to objects for those roles.

Access controls should of course be applied across all your systems as a matter of best practice (and not just to your ServiceNow instance).

All new instances benefit from the Security Jump Start plugin which applies a base level of permissions to important system tables, and also the High Security Plugin (HSP). This is required for the Default Deny property, which blocks RWCD capability for all tables that don’t have explicit access rules defined. You'll want to make use of all these tools to help you tighten up security!

The debrief

Once you’re up and running, it’s good practice to regularly review access levels so you can keep on top of the situation. To help you, we provide the Contextual Security Auditor plugin, an interactive tool that evaluates table access permissions and displays them in a way that's easy to understand. You can use this plugin to assess how permissions are set and whether you need to make any adjustments.

Pit crew only

On a related note, you may wonder how much access ServiceNow has to your instance. The answer is: none without your express permission. Our Data Access Controls document explores this further.

In the next post…

So far in this series we’ve seen how you can control access to your instance. In the next post, we will explore how to make sure you don’t have unnecessary user accounts, and how you can control the ways they are created.

1 Comment