Salesforce’s new Integration User Licence and why it’s good for security
TL;DR; Salesforce’s new licence is designed just for API users and at the low cost (5 free and only US$120/year for another licence) it will allow customers to stop sharing a user licence with APIs thereby making things more secure.
At Trailblazer DX 23, Salesforce announced that all customers with Enterprise Edition and higher will get 5 free Integration User licences in their org from mid March. The price for extra licences, if you need more than 5, is good value at US$120/year each (at present).
Why is this good for security? It will allow Salesforce customers who do integration to stop piggybacking on a human user. This was done by many customers as the cost for an integration user in the past was the same as a human user. The new licence is so much cheaper that you should be able to afford an Integration User licence for each of your external integrations.
In most of Security Assessments I do for Salesforce customers, the number one issue I find is that they are using human System Administrator accounts as API users as well.
My article https://medium.com/@doug-merrett/why-you-should-not-use-the-system-administrator-profile-for-integration-users-in-salesforce-96800b260135 explains the reasons for not doing this — the main one is that the system at the other end of the integration most likely has your credentials and you have probably set the password to never expire. Since it is a System Administrator, if someone gets these credentials, they can run roughshod all over your system — delete objects, modify data, deploy new applications, create users, … the list goes on.
So, having 5 free licences for API users, you can now create a user for each external system that needs access, and most importantly, set the appropriate permissions for the objects and fields needed for that external system.
For example, if you have an external system for accounting, it will need to let Salesforce know that an invoice has been paid — the API user for this integration would just need read and edit access to the Invoice object and for the field level security, it would need read access to the Invoice Id (or Invoice Number if it is an External Reference), as well as, read and edit access for the Paid checkbox (or Date Paid field depending on how you do this). Just that one object and two fields — that’s it. This means that if the credentials are stolen they cannot do any damage that you cannot fix, as you should be using Field History Tracking on this important field and you could see when and who updated the values to reverse these if needed.
Thanks for reading. Please provide any comments or feedback and ask any questions in the comments below. My company website is https://www.platinum7.com.au.
