Salesforce Security Guide

Introduction

Setting up and maintaining org’s security is the key role of any administrator. Salesforce offers a great number of features that help you make sure that the company and user data stays safe. It also enables you to organize the data sharing model so that every user can access only the data they should. This short Salesforce Security Guide should help you understand how each of those functions work, and when you should use them. Let’s get started.

Salesforce Security Basics

This section covers the functionality that helps you protect your org from unauthorized access from outside your company. It’s crucial to understand how to use these tools to efficiently prevent any security bridges. Some of them are basic features, and others provide a more complex way of controlling access.

Security Health Check

Before we get to profiles, permissions and the rest of the settings that control user access, let’s take a look at a very useful tool that Salesforce prepared for Admins to easily identify and fix potential vulnerabilities in org security.

Security Health Check serves as a command center to check how well your Salesforce org is doing in terms of security. It gives you a quick look into how your settings compare against baseline values. The overall summary score shows you how your org measures against Salesforce Baseline Standard.

Over 90% means it’s perfect, between 80-89% - very good, and over 70% it’s good. Anything below that is a warning for you, as an administrator, to work on your org’s security.

You can use the Fix Risks button to quickly modify settings to your selected baseline’s recommended values without leaving the Security Health Check page.

Here's a Trailhead module on this security feature.

Auditing

Security Health Check is a handy tool, but it only gives you pre-defined insights. It’s not always enough to diagnose potential or real security issues. Salesforce offers tools to enable administrators to perform manual audits.

Record Modification Fields

The very basic auditing information is stored in the record modification fields. Any time a record is modified, or created, those fields will show you who was the one that made the changes.

Field History Tracking

You can enable field history tracking up to 20 fields on any custom object and some standard objects. This allows you to track who modified any of the fields, and in most cases, it will let you see the changed value (it depends on the field type). Each modification adds an entry to the History related list, which means that you can’t access field change history prior to enabling field history tracking.

You can use Data Loader or the queryAll() API to retrieve field history that’s 18-24 months old.

Field History Tracking can be useful for a variety of reasons, not just security. It can become an important feature that helps with data management.

Login History

See successful and failed login attempts to your Salesforce organization for the past six months. The Login History page shows up to 20,000 records of user logins. To view more, administrators can download a CSV or GZIP file.

You can use Login History to view other information, such as details about who is logging through My Domain, information about SSO logins, and Authentication Method Reference.

Any suspicious activity in the Login History should be a warning to you that someone unauthorized might be trying to access your org.

Setup Audit Trail

One of the most important tools in Salesforce Security - Setup Audit Trail logs any modifications made to the organization’s configuration by you or other admins. It only shows 20 most recent entries, but you can download a complete history for the past 180 days. If a delegate, like an administrator or customer support representative, makes a setup change on behalf of an end user, the Delegate User column shows the delegate’s username.

It’s good practice to regularly check Setup Audit Trail, especially when your organization has more than one administrator. Keeping track of what other users are configuring could prevent lots of issues.

Here’s a full list of changes that Setup Audit Trail tracks.

Network-Based Security

Configuring the IP settings enables you to control who and where can access your Salesforce org. There are a couple of ways you can do it.

By going to Network Access, you can set up Trusted IP Ranges. This won’t prevent users from logging into the org, but people logging from trusted networks will be allowed to access salesforce.com without having to verify their identity. This is an organization-wide setting.

If you go to specific profile’s settings you can set up Login Hours. Users assigned to that profile will be able to log in only during the selected days and hours.

In profile settings you are also able to enter the range of valid IP addresses from which users with that profile can log in. Be mindful not to confuse this setting with Trusted IP Ranges, because this setting actually restricts people from getting access to the Salesforce org.

Password Policies

While we are talking about profiles, let’s take a look at another security setting that you can configure at the profile level. Password policies control everything there is about setting passwords, as well as other things such as the maximum number of invalid login attempts or lockout time.

Password restrictions can be managed at profile level, as well as the organization level. For the latter, go to Password Policies in Setup.

Two-Factor Authentication

This is the most effective method to protect your users’ accounts. For the second factor, users are required to install a mobile authenticator app on their phones.

Two-factor authentication can be used for user interface logins, in other words, to access Salesforce from a web browser. Or to protect access to reports. The latter enforces users to verify two-factor authentication when they try to access certain reports, or when they try to export data.

Single Sign-On

SSO allows your users to access authorized network resources, including Salesforce, with just one login. This is accomplished by validating usernames and passwords against another client app or your corporate user database. You can use SSO in Salesforce with: federated authentication, delegated authentication, or with the OpenID Connect protocol.

Single Sign-On can really make your users’ life easier, improve their productivity and reduce help desk calls for password resets.

A detailed description of Authentication measures available in Salesforce can be found here.

My Domain

My Domain lets you define a Salesforce subdomain name to manage login and authentication for your org. This way, you can brand your login page, highlight your company identity with a custom URL, and even block or redirect page quits that don’t use the new domain name.

Just remember, that once chosen, the subdomain can’t be changed. Make sure to get the proper approval before setting it up.

Custom Login Flows

This is a solution for more advanced administrators who know their way around the Flow Builder. You can use Login Flows to build post-authentication processes that match your business requirements. For example, if your company requires users to read and acknowledge terms of service, or to collect some kind of information. You can even build a custom authentication process that requires users to put in the correct details before accessing the org.

Login Flows have a lot of use cases, so it depends on you how to use them. You can find an example of how to build one on our blog.

Control Access to Data

Until now in our Salesforce Security Guide, we've been focusing on how to protect company data from breaches. Now, let's take a look at how to manage internal access.

Salesforce provides a flexible data sharing design that allows you to control exactly what each user can create, view, delete or edit. You can use Profiles, Permission Sets, and the combination of both, to effectively restrict access to objects, records and other features.

Profiles and Permission Sets

Profiles are assigned based on a user’s job function. They define almost everything the user can view or do in the org. Salesforce offers a number of predefined standard profiles that you can use, but you are free to create your own. You can modify standard profiles to some extent, but it’s recommended that you clone a standard profile to create a new one, and then adjust it. You can assign a profile to multiple users.

Profiles work great for restricting and granting access to many people without the need of configuring access for each individual person on your team. But sometimes, people get assigned specific roles and need more access. That’s where the permission sets come in. By assigning them to users, you can grant them additional privileges. It’s easier to manage users’ permission this way, because you can just assign multiple permission sets to users that need them instead of creating a new profile each time.

Remember that permission sets can only extend permissions, they can’t restrict access that’s already configured on the profile level.

Also, there are certain settings that you can only configure on Profile level, such as page layout assignments, desktop client access, login hours and login IP ranges.

Now that we know what Profiles and Permission Sets are, let’s take a look at the types of security settings that you can configure in Salesforce.

Object and Field-Level Security

Profiles and Permission Sets control object- and field-level security. If you want to prevent users from reading, creating, editing or deleting (CRED) a particular type of object, such as contact or opportunity, you can do it by changing the object-level security. When you want to restrict access to specific fields, you can use the field-level security settings to make them visible, read-only or not available.

Be careful when assigning View All and Modify All settings. When selected, users get access to all records associated with a given object, ignoring all sharing rules and settings.

You can also assign record types to users in their profiles and permission sets. Although, you can assign only custom record types in permission sets. The --Master-- record type can be assigned only in a profile. The default record type specified in a user’s profile (which can’t be specified in a permission set) is also a default record type when converting a lead.

App Settings

Apps are sets of tabs customized to suit users’ specific business requirements. For example, you can build an app for a specific marketing team that works mainly with Leads and Campaigns. You can use both profiles and permissions sets to control which apps users can access.

System Settings

Aside from object and field security, there are multiple permissions that allow users to use different system functions. They apply to the whole organization, not just to a single app. You can assign system permissions to enable features, such as: creating and managing reports, running flows, or viewing setup and administrative settings pages.

System Settings are divided into Administrative Permission and General User Permissions.

Custom Permissions

Sometimes you need to grant users access to a custom process or element that you built. For this, you can use custom permissions. Just like with standard permissions, you can assign them to profiles or permission sets. They can be used in a number of different ways. For example when you add a custom element - a component or a flow - to a lightning page, you can define the visibility based on custom permissions. Developers can use them to define access in Apex.

Control Access to Records

While Profiles and Permission Sets control access to specific types of data (objects and such), the access to records is determined by the sharing settings.

Organization-Wide Sharing Defaults

Organization-Wide Sharing Defaults define the default access level for an object’s record. For most objects, they can be set to Private, Public Read Only, or Public Read/Write. There are some exceptions, such leads and cases that have an additional sharing setting “Public Read/Write/Transfer”.

Role Hierarchy

When the organization-wide sharing default is set to Private for an object, the role hierarchy is the key factor that determines which records of that object users can see. This applies to all standard objects. For custom objects, you can uncheck the “Grant Access Using Hierarchies” option to disable the role hierarchy control over access to records.

Remember that role hierarchy shouldn’t necessarily reflect the hierarchy in your company. It’s used solely for sharing records and should be treated as such.

Sharing Rules

You can use sharing rules to extend access to users in public groups, roles, or territories. You can define up to 300 total sharing rules for each object, including up to 50 criteria-based or guest user sharing rules, if available for the object.

Sharing Rule Types:

• Owner-Based - They open access to records owned by users of certain roles, roles and subordinates, or public groups.
• Criteria-Based - Based on record values. Like in workflows, you can add field criteria and filter logic. You can create criteria-based sharing rules for accounts, assets, campaigns, cases, contacts, leads, opportunities, work orders, and custom objects.
• Guest User Sharing Rules - A special type of criteria-based sharing rules that determines access to unauthenticated guest users.

Remember that a sharing rule can never be stricter than your org-wide default settings. It only allows for greater access.

Manual Sharing

A feature that until Spring 21’ Release has only been available for Salesforce Classic, finally came to Lightning. You can use manual sharing to give other users access to specific records. Granting access to a record includes all its related records. For example, if you manually share an account with a colleague, they gain access to opportunities and cases that are associated with that account.

The people who can manually share a record are:
The record owner,
A user above in the role hierarchy,
A user granted full access to the record,
An administrator.

Records can be shared with managers groups, manager subordinates groups, public groups, personal groups, individual users, roles, roles and subordinates, roles and internal subordinates, roles and internal and portal subordinates, territories, territories and subordinates.

Salesforce Encryption

And last but not least, Shield Platform Encryption. It’s a critical platform functionality that enables you to encrypt a variety of standards fields, custom fields, files and attachments, search indexes, and more.

How does it work? Shield Platform Encryption relies on a unique tenant secret that you control and a master secret that’s maintained by Saeslfroce. These secrets are combined to create a unique encryption key.

To read more about Shield Platform Encryption, visit this page.

Conclusion

There’s a lot to know about Salesforce security. If you are looking for more resources, make sure to check the official documentation that talks about each feature introduced in this Salesforce Security Guide in detail. You can also visit Trailhead. There are modules focused on this topic, and even a superbadge that tests your skills on setting up and maintaining security in a Salesforce org.