This post is for Advanced Admins who oversee a Salesforce instance and 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:
- Salesforce is a very secure platform.
- 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.
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).
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.
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.
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.
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:Once 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.
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.
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 two-factor authentication.
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.
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
- Go to Setup and search for Session Settings
- Set Session Timeout for 2 hours
- Do not disable the session warning popup (do not select)
- Select: Force logout on session timeout
- Select: Lock sessions to the domain in which they were first used
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.
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.
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.
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.
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).
Have more questions about security or other Advanced Admin topics? Get in touch today. We love chatting with other Salesforce Admins and Developers about their challenges.