6 Salesforce Security Best Practices

6 Salesforce Security Best Practices

This post is for Salesforce Admins who want to learn more about advanced security best practices. If you haven’t already, we recommend you read Salesforce Security: Admin Checklist before you read this post. In it, we cover basic Salesforce security best practices your organization should be following. 

Salesforce Security Myths 

Before we dive into best practices, let’s take a look at two common Salesforce security myths. 

Unauthorized User Access is a Common Threat 

We surveyed IT leaders at companies with over a billion dollars in revenue, and unauthorized user access was their number one concern. Organizations are often worried about unauthorized user access because the impact of a breach can be significant. IBM recently published that the average cost of a data breach is $3.86 million.

However, unauthorized user access in Salesforce is not very common for two reasons:

  1. Salesforce is a very secure platform.
  2. There are basic steps Admins can take to prevent nefarious users from gaining access to Salesforce (learn how here).

Employees Are Not A Threat 

What is far more common than unauthorized users gaining access to Salesforce, is employee error or a former employee who was not deactivated properly logging in (check out: How to Safely Deactivate a User in Salesforce). As an Admin, it is essential to understand what your team has access to and how they impact the security of the Org.  

1) Data Sharing

Sharing rules aren’t always associated with Salesforce security. However, who has access to what data in Salesforce is very relevant to the data security of each instance. This next section discusses, data sharing, implicit sharing and external sharing in Salesforce. 

When it comes to data sharing, what isn’t top of mind for most Admins is the complexity of hierarchical sharing; including how a user can gain access to a record or set of records because of where they sit in a hierarchy. Public Groups can sometimes be a more straightforward way to manage what gets shared (vs. hierarchical sharing). 

Here’s a great resource on how to leverage Public Groups in Salesforce. 

Another thing to be mindful of is owner sharing. Often, it can be difficult to identify records that have been shared manually in the backend of Salesforce. An Admin can leverage the Developer Console to find manually shared records, however, when the owner of these records changes, the trail will be wiped. This leads to a lack of visibility into what has been shared manually. As a best practice, minimize owner sharing in Salesforce. 

2) Implicit Sharing

Admins often forget that Salesforce has an implicit sharing model for Accounts. Implicit sharing means, it’s built into Salesforce’s data sharing model; therefore an Admin cannot modify it. It’s also important to remember that changing a user’s role or where the role is in the hierarchy can change the access to the child records a user has. 

Example 

In the context of Opportunities, Cases, and Contacts and their Account, if a user has access to a child record (like a contact), that means they also have (at least) read-only access to the parent account. The reverse is also true, if a user has access to an account, that means they have some access to the child record (the level of access depends on role, permission sets etc).

Configure Child Objects Controlled by the Parent Object 

Want to have more granular control over who has implicit access to Account records? Configure child objects to be controlled by the parent object. 

To do this, check the Organization-Wide Sharing Defaults for Opportunities, Cases, and Contacts from the Sharing Settings.

In Lightning Experience

Click on the gear icon | Setup | Security | Sharing Settings

Set Contact sharing to ‘Controlled by Parent,’ so that sharing access to Contacts is controlled by access to the related Account record.

3) External Sharing

Most Admins are familiar with Internal Sharing Org Wide Defaults (OWD). However, Salesforce also allows for separate External Sharing Org Wide Defaults (OWD). This is most commonly leveraged in Communities. 

To do this, a feature must be activated in Salesforce, as seen below:Sharing settings External OWD SFDCOnce this feature is enabled, an Admin(s) has the ability to enable a second set of OWDs for external users. It’s important to note, a user’s external OWD cannot have greater access than their internal OWD. Also, there is no concept of roles or a hierarchy for most Communities (the Partner community is an exception to this). Instead, Communities leverage Share Groups to control data sharing.

If you work heavily with Communities, here are some resources about external sharing: 

Lastly, here is a great Trailhead that covers manual sharing, sharing rules, role hierarchy, and organization wide defaults: Control Access to Records.

4) Session Settings: Identity Verification

Another way Admins can increase the security of their Salesforce instance is by leveraging session settings. Admins can protect the most sensitive parts of Salesforce by enabling “Raise session to high assurance” on certain items. As seen in the screenshot below, this feature can be enabled on a number of things including, Reports and Dashboards, Manage Connected Apps, and more. 

Session settings high assurance

What Does High Assurance Mean?

High Assurance can vary by your org, but in most Salesforce orgs, a high assurance login will require the user to complete multi-factor authentication (MFA). 

Example: Reports and Dashboards 

A best practice is to “raise session to high assurance” when users are exporting or printing from reports and dashboards. Which means, when a user goes to print or download a report, they’ll be asked to authenticate. While this doesn’t block them, it does add a level of security theatre that will deter some employees from completing the action. 

5) Session Settings: Session Timeout

In Salesforce, an Admin can configure Session Settings so that if a user is in Salesforce and isn’t active for a certain period of time, they’ll be forced to log out. Configuring Session Settings so that a session times out after two hours is ideal. Two hours is somewhat arbitrary, but it doesn’t add too much friction to team member’s day to day. People tend to start getting aggravated if the session timeout is only 30 minutes.

How to Configure Session Timeout 

  1. Go to Setup and search for Session Settings
  2. Set Session Timeout for 2 hours 
  3. Do not disable the session warning popup (do not select)
  4. Select: Force logout on session timeout
  5. Select: Lock sessions to the domain in which they were first used

Sessions settings

Step three is important because when a user is not warned they are going to be kicked out of Salesforce, they’ll lose work if they’re in the middle of something. Angry team members will only make it harder to put other security measures in place down the road.

6) Creating Admins with Permission Sets

The last item we’ll explore today is; why creating Admins with Permission Sets instead of Profile is more secure. 

Using Profiles for Admin Permissions is a blunt instrument, and it leads to providing types of access that isn’t required. Instead, Admins can create three Permission Set(s) as a more nuanced solution. Each of these Permission Sets can be applied individually, or a Systems Admin user may need all three. These permission sets are User Admin, Record Admin and Metadata Admin.

User Admin 

This user has the ability to assign and deactivate profiles. For example, HR associates need to be able to create new users when people are hired and deactivate users when people are terminated. However, they do not need the ability to change metadata.

Record Admin 

A Record Admin needs to be able to do things to records in Salesforce but shouldn’t be allowed to change anything in the setup area that could negatively impact the org. As an example, often, junior marketers have to upload a lead list from a tradeshow for a Salesforce Campaign. 

Metadata Admin 

This user is able to make changes in the Setup area of Salesforce and influence Salesforce metadata. Only 1% – 2% of your overall license base should have this level of access (ideally only dedicated Admins). 

Wrap Up 

Have more questions about security or other Advanced Admin topics? Sign up for our newsletter! We send out a monthly recap of our latest Salesforce content, including articles on security best practices, actionable insight on Salesforce optimization for enterprises, and more.

You may be interested in

How to Create Dynamic CPQ Quote Templates in Salesforce

After finalizing a quote, the goal is typically to create an accurate and professional quote document to customers. But without the right processes in place, quoting can be challenging, time-consuming, and prone to errors. Thankfully, Salesforce CPQ (Configure, Price, Quote) helps with the configuration and management of quote documents, streamlining the process and making quotes […]

Read More

Integrating Financial Services Cloud and Data Cloud

The Customer Data Problem The vast majority of Financial Services organizations today share a common problem: customer data is siloed across departments and systems. Imagine an investment firm that offers a portfolio of financial products like mutual funds, stocks and retirement planning services. Information about these various products typically reside in separate (and typically proprietary) […]

Read More

Guide

How to Eliminate Salesforce Maintenance Headaches

In this guide we discuss how taking a proactive approach to Salesforce management can eliminate […]

Download Now

Template

Salesforce Technical Debt Reduction Policy Template

In today’s data-rich world, managing technical debt in Salesforce is a challenge almost all enterprises […]

Download Now

Sign up for the latest tips & news from CloudKettle

Thank you for subscribing.