Expert Insights: Salesforce SaaS Data Security Fundamentals

Salesforce provides a rich and deep set of tools to allow data and metadata to be exposed selectively to your users.  However, it’s complicated to know how data can be exposed and to ensure you don’t have any data leaks.  Over time, things outside of your control – such as new features – may expose your data in ways you didn’t expect.  Here are some basic guidelines and tips on how you can get a handle on your SaaS data security.

• Write down your incident response plan before there’s a crisis.
• Know your users and plan for what they can do
• Keep your documentation up to date
• Use the Principle of Least Privilege, especially with risky permissions and apex controllers
• Avoid exceptions, make them temporary, and document extensively.
• Beware of AppExchange packages, OAuth connections, and service users
• Know the Salesforce Security Model
• Use the health check and go beyond it
• Apply Security all the way down, UI, API, CRUD, FLS, Apex
• Keep a clean sandbox
• Read the release notes

Write down your incident response plan before there’s a crisis

If a security incident happens, you want to have a playbook readily at hand, and have each person who needs to be involved aware of what’s at stake. Salesforce has a trailhead for preparing for an incident response, and it’s a good starting point. Each organization is different and different categories of data need to be handled differently, especially when covered by government regulations or required for compliance. Don’t just do it to get a checkbox or talk about it: actually do exercises and understand how you can reduce your reputational risk.

Know your users and plan for what they can do

Security should be planned like a product.  Enumerate the tasks your users are going to do, regardless of job title, and write those tasks and their requirements down. Have specific personas that you are using and try to make sure you plan how those personas map to your existing applications. Salesforce permission sets should reflect those personas and tasks.  Avoid aggregating permission sets to keep things clear.

Keep your documentation up to date

Make sure you document your schema and flows.  Make sure you set the data sensitivity, owner, and usage on fields.  Make sure the documentation is readable: imagine the person who will be making a change in the future will be doing so without being able to talk to you.  Be concise and consistent.  Avoid talking about individuals but talk about the teams involved and problems being solved, especially the personas and tasks you’ve written down.

Consider having a template for the descriptions of metadata you’ll use, especially permission sets, to keep track of what the intended usage is, why something was created and how it has changed.  In my org I start with the purpose, then include the risk when granting and a link to any external documentation.  For example a Permission set called SalesManagerContractMgr would have a description of: Allows an enterprise sales manager to update contract details. Medium Risk. See https://myco.slack.com/docs/TXXX/FXXX.

Keep a changelog documented in Salesforce or Slack where possible, but if it’s too long, have a link to an internal documentation site.  Out of date documentation is often worse than none at all, so have it as part of the review process for changes to production.  If you’re using github and sfdx, require descriptive git comments to help find changes quickly.  By having this documentation, in case of a security issue, you’ll be able to better isolate when and how something happened and easily know the scope of a problem.  Knowing when a problem started is extremely important; make sure you have versioning with timestamps in your documentation.

Use the Principle of Least Privilege, especially with risky permissions and apex controllers

Once upon a time, all Salesforce had was profiles, and those profiles weren’t very granular.  But those days are in the past and profiles should only be used for controlling login.  Grant *all* data and metadata access through permission sets and don’t deviate.  For practical reasons, you may still need a system administrator account so you don’t get locked out, but keep that user frozen and monitor access to that account. 

While Salesforce licenses aren’t free, sharing logins is an extremely bad security practice and usually non-compliant.  Restrict customize application, use delegated admin, and avoid granting modify all data to users that normally log in.  These uber-perms are very dangerous.  Enforce high assurance sessions and use salesforce authenticator where possible.  

For Apex code, an unfortunate decision was made very early on to have security be permissive instead of secure by default.  Thankfully, this is a straightforward fix in a boilerplate manner by putting with sharing on all classes and WITH SECURITY_ENFORCED on all SOQL.  Consider using PMD on all the apex code you write to require sharing enforcement and avoid CRUD violations.  

Avoid exceptions, make them temporary, and document extensively

Permission Set assignment can be granted on a temporary basis with a hard expiration date; require that.  All elevated permissions should be granted for only the length required for the work, no more.  

For long running exceptions, put the expiration date in your work calendar with a reminder to review them on a monthly basis, just like you should be doing with certificate expiration, and update the documentation of the permission set.  

Beware of AppExchange packages, OAuth connections, and service users

Salesforce is an open system, and if you’re paying for enterprise edition or higher, there are multiple layers of APIs to access all sorts of data.  OAuth is often confusing for very technical users, and there’s a distinct possibility of data leakage into vendors you don’t know about.  Thankfully, since Summer ‘23, username-password flows are disabled by default; consider disabling them in your org if it was created before then. In the meantime, monitor your Connected App Oauth Usage.

Having specific Service users to connect to external systems is usually fine, but use Mutual Authentication if at all possible, as MFA can’t be enabled.  Make sure those users are marked API-only and restrict their access as much as possible.  Do not reuse the service logins across multiple services; use the relatively new Salesforce Integration user if you were using a full license in the past to save your expensive licenses for employees.

Know the Salesforce Security Model

Salesforce allows data security to be specified at four levels, and it’s often confusing to know what is going on at any particular time.  Your enterprise’s sharing architecture is highly dependent on your needs, but here are some rules of thumb of how to manage data sharing

• Read the Secure section of Salesforce Well-Architected and see if you’re following their patterns, and avoiding the anti-patterns.
• Always use private external sharing, and avoid Public Read-Write for most objects for internal users.  
• Try to use criteria based sharing instead of papering over with manual shares.  
  

Use the health check and go beyond it

The standard Salesforce health check is a good way to make sure your settings are set correctly. Make sure you take a look every release to make sure you haven’t fallen behind on new security parameters Salesforce introduces. Make sure you pick the right baseline for your industry and compliance requirements. 

However, it’s usually not enough to prevent a misconfiguration from leaking data.  The health check doesn’t alert nor does it prevent reverting settings. Having an SSPM, like SpinSPM, monitor your Salesforce configuration is a must.  They usually go beyond the simple Security Health Check to monitor the sharing rules where you may be inadvertently leaking data without your knowledge. 

Apply Security all the way down, UI, API, CRUD, FLS, Apex

Misconfiguration of Salesforce leading to data leakage is a primary concern.  When I was at Salesforce, there was a pernicious source: hiding data at the wrong level.  Here are some examples I encountered:

• Hiding a field from the layout, but not from Field-Level Security for a set of users and assuming it applies to the API.  This is dangerous if you’re upgrading from Professional Edition, where field security is controlled by Layout, to a higher edition where it’s in FLS.
• Creating a visualforce or lightning component that doesn’t respect sharing and FLS, and then having that component exposed on a different page exposing information that shouldn’t be there.
• Granting access to an Apex class that had a REST endpoint for a component that leaked data when run through a DAST Vulnerability Scanner.
• When creating a field or object, adding it accidentally to the guest user for an external site.

Hide data all the way down: UI, API, CRUD, FLS, and Apex.  Do defense in depth of secure data.  Don’t just click through the “add field to layout” screen but be mindful of which personas will need it.  Consider using classic encryption for sensitive data to have masking built in.  

Keep a clean sandbox

Sandboxes should not have customer data, but often do.  The sandbox copy process migrates lots of secrets, user info, encrypted data, and has different authentication. There’s also a tendency to allow freer access to data in sandbox for development and granting more admin access.  Avoid this temptation on a full copy sandbox.

• Use Data Mask.  This isn’t as easy as it should be, but if you’re doing a full copy sandbox, it is a great tool to prevent data leakage.
• If you reestablish SSO in your sandboxes after copying, inactivate or freeze users that shouldn’t have access. 
• Consider using a Salesforce backup solution to restore seed data in the sandbox so you don’t have to do a full copy sandbox.
  
  

Read the release notes

A lot of the advice here might be out of data or things may improve.  For example, flows had their security upgraded when started from Apex in Spring ‘24.  Often betas are announced that can let you improve security and reduce code or process, like FLS on permission sets or delegated admin changes.  The release notes are long and Salesforce’s portfolio is vast, so consider looking at summaries like at salesforceben.com to get started, or searching for the word security in the release notes themselves.

These are just highlights of fundamentals to consider when securing your Salesforce data. Salesforce invests heavily in both securing its systems from attack and providing tools to let you build your own powerful business applications.  

Click here to learn how SpinOne provides an extra layer of security for your Salesforce data.