Disclaimer – This article is part of a series exploring the new features and capabilities introduced in the Zurich release. Since we’re still in the Early Availability (EA) phase, things may change before General Availability (GA). After GA, these articles will be reviewed and updated as needed. Also, this message will be removed.
Knowing exactly which integration user can use which API and access which data is… not trivial. It takes strong governance and a bit of discipline. Data security has always mattered, but in the age of AI where we build platforms that have access to any data of your organization a single misconfiguration can turn into significant damage.
You can protect data and APIs on several layers. At the most basic level, record ACLs define which CRUD operations a user can execute. But keep in mind, especially when building your own Scripted REST APIs if they are not build the right way your ACLs are not evaluated. If your SRAPIs use GlideRecord your ACLs will not be applied. There are use cases where this is done intentionally but if you actually rely on these ACLs you need to use GlideRecordSecure.
There are also mechanisms to restrict access to the API itself. For example, you can use REST_Endpoint ACLs to control which user can access your REST API or only specific resources of it.
Security isn’t only about what data an integration user can reach. It’s also about how they authenticate. Will you allow Basic Auth? Do you want to enforce OAuth? Should certain APIs only be callable from specific IP ranges? This is where API access policies come into play. With the help of these polices you can enforce certain authentication methods or restrict the use to certain IP Addresses.
Even with all of that, you can still end up in a situation where an integration user has certain roles which grant access to APIs you are not aware of. You may argue that you need to know your platform and you need to set up proper governance to avoid this. Sure, you certainly need to do this but let’s be realistic. These kinds of situations happen. The good news: with the Zurich release, Machine Identity Access Controls help reduce these situations.
Typically, you create an integration user for one purpose. The user should be able to call one API, even if their roles would let them call others. That’s exactly what Machine Identity Access Controls enable.
What are Machine Identity Access Controls?
In short, they let you whitelist APIs for integration users. When you link a user to a Machine Identity Access Control, that user can access only the APIs, resources, and tables specified there. Every other API access is blocked for that user. Note that this applies to users with Web service access only enabled.
Create one under All > System Security > Machine Identity Access Controls
As you can see on the screenshot above, this binds SOAP/REST API Access Policies and table access to a list of users. You need to specify at least one REST/SOAP API Access Policy.
Let’s look at an example.
Imagine a REST API Access Policy that enforces OAuth for the CMDB Meta API.
Add that policy to a new Machine Identity Access Control and link it to a user called integration user. This user has Web service access only set to true.
When the integration user calls the CMDB Meta API, the API returns the meta data of the given class, like we would expect.
Calling any other API, like the Table API in this example, an error message will be returned. That’s the whitelist doing its job.
Now switch the REST API Access Policy in the Machine Identity Access Control to one that enforces OAuth for the Table API and try again.
You can reach the Table API, but you still can’t access the incident table, because it isn’t listed in the Machine Identity Access Control.
Let’s change that and add the incident table.
After adding incident to the tables list the integration user can use the Table API to query incidents.
With Zurich, we can finally enforce granular controls on integration users. Once a Machine Identity Access Control is configured for a user, the user can only access the whitelisted APIs. Even if the user has the admin role.
