What Is The Salesforce Data Security Model

According to Cybersecurity Ventures:

Let us find out more about data security and the comprehensive model Salesforce has in place.

The Architecture Of The Salesforce Data And Security Model

Salesforce stores data in three forms – objects, fields, and records. Objects are referred to as tables in databases. Similarly, the fields and records are equivalent to the columns and rows of a table.

To enforce data layers of security at a personal and organizational level, Salesforce uses three levels of security:

1. Object-level security.
2. Field-level security.
3. Record-level security.

Salesforce uses these three core security functions and levels to grant or revoke the level of access to objects, fields, and records.

It gives you an entire range of options to scale up your data's access and security features. Hence, making it one of the most powerful and secure CRM platforms.

Object-Level Security

The first security level that Salesforce uses is object-level security. Before allowing or revoking any access, Salesforce first checks if the user has relevant permissions on the object, app, tab, etc.

Access Through Profiles

Salesforce profiles are one of the most basic enforcers of object-level and field-level security. Every user in a Salesforce organization needs to have a single profile.

In some cases, you can create a new profile for a specific user or a set of users.

One thing to note here is that Salesforce is often shared, meaning multiple organizations may use a profile simultaneously. In such cases, the best option is to give profiles a minimum access level and enhance them with organization-level permission sets.

Permission Sets And Permission Set Groups

Once a user is assigned a suitable custom profile with preferably ‘a skeleton’ of minimum permissions, they are assigned organization-specific permission sets.

Permission sets are used to deliberately assign additional user permissions on top of profiles. Preferably, an organization should use permission sets to give object permissions and field-level access.

These sets make the permissions more flexible and easily upgradeable. On top of this, they keep the changes organization-specific, which won’t affect any other user or organization.

Moreover, organizations can have multiple roles and numerous permission sets. To tackle the management of such cases, permission set groups come in handy. Multiple permission sets that are combined are called permission set groups.

Field-Level Security

The next level is field-level security. It takes care of permission over fields and can be enforced through profiles and permission sets. This level is preferred over removing or adding fields from the overall Salesforce page layout.

However, having access to a type of object-level data doesn’t guarantee access to fields and records.

Access to individual users needs to come into play when it comes to fields and being able to view, create, or edit them.

As stated above, multiple organizations or projects can use a profile simultaneously. Therefore, it is recommended that you activate field-level Salesforce security with permission sets.

Moreover, permission sets in Salesforce give you options to hide a field completely, make it read-only, or grant read-and-write access. It is necessary in many ways, such as in an example where an object is used by more than one organization and has different project-specific custom fields.

Steps To Configure Object-Level And Field-Level Security

You can configure object-level and field-level security controls from profiles and permission sets.

These are the general configuration steps:

1. Log into Salesforce and go to “Setup.”
2. Search for “Profile” or “Permission Set” (depending on what you want to grant access for).
3. Lookup for the preferred profile or permission set and click on it.
4. Now, click on “Object Settings.”
5. Search for the “Opportunities” object and click on it.
6. Finally, you can mark the checkboxes as accurate for whatever permissions you want to be enabled.

Record-Level Security

When you have secure access to an object, you can access its fields and enforce user record sharing. These two access levels allow you to view or edit your records. But what about other object records?

What if you need read-only or read-and-write permission for all other records on the object?

During this process, the record-level sharing and security of the Salesforce data security model come into the picture. You can also refer to record-level security as the Salesforce layered sharing tools model.

Salesforce lays down five ways to control record-level access. These are:

• Organization-wide defaults.
• Role hierarchies.
• Sharing rules.
• Manual sharing.
• Apex sharing.

Organization-Wide Sharing Defaults

Organization-wide defaults of a Salesforce object decide the visibility and editability of its records concerning the access of users who don’t own them. But, before getting into the access options of non-owners, let us first understand the owner’s access.

Every Salesforce object has standard individual fields – the “owner ID,” which points to owners of records. The owner of a record automatically gets CRUD (create, read, update, and delete) access to those record types.

When it comes to organization-wide defaults (OWDs), you can set up OWDs for an object in the following ways:

• Private: If you set up the OWD of an object as private, a user won’t be able to see any records other than the one they own.
• Public read-only: This OWD setting will allow all authorized users to view the records – provided they have access to the object. However, this setting only makes the records visible, and a user can’t edit or delete record access unless they own it.
• Public read-and-write: This setting allows anyone to view or edit an object's records.

Role Hierarchies

Every organization has a role hierarchy-sharing model that depicts all the job roles within the system. Salesforce, too, attaches all the roles within a hierarchy system, which also represents data access.

For example, if ‘role A’ is above ‘roles B,’ ‘C,’ and ‘D,’ it will automatically access all the data that the lower roles possess. Role hierarchies are also referred to as vertical sharing.

Sharing Rules

One drawback of vertical or hierarchy-based sharing is that they depict no meaning for a lateral share. For example, how will you share records owned by a user with other sets of additional users outside of the hierarchy?

It’s in these instances where sharing settings and rules come into action. Sharing rules allow you to share access to records with other users laterally. You get two options for record-level access in sharing rules:

• Read-only.
• Read-and-write.

Salesforce allows you to create sharing rules based on criteria, ownership, or as a guest user. These are the most diligent ways to handle user access to records. Let’s look at each of them individually:

Ownership-Based Sharing Rules

This type of sharing rule lets you share records based on their owners. The ownership can be categorized based on role, public group, or role-and-subordinate.

You can also share records based on public groups, different roles, subordinates, and more.

Criteria-Based Sharing Rules

The criteria-based sharing rules allow you to share records based on criteria. This criterion refers to a specific value of a field in a record.

Guest User Sharing Rules

This one differs from the other sharing rule types. Guest user sharing rules only allow read-only access to records to guest users. Such users aren’t authenticated and don’t need login access to the organization.

Manual Sharing

One drawback of vertical or hierarchy-based sharing is that they depict no meaning for a lateral share. Technically, it is a way to grant one-off access. But who has the right to share a record manually? The record owner, roles above the hierarchy, and system administrators can manually share a record.

You can manually share a record by clicking the “Sharing” button on the record-detail page. While sharing the record manually, you can choose the access level, such as read-only or read-write.

Apex Managed Sharing

As a system admin or Salesforce developer, you can write an Apex class code to fulfill such out-of-the-box needs. A Salesforce developer can easily write an Apex trigger that shares a record with other users. However, you likely won’t need Apex-based sharing very often.

A Final Checklist To Make Sure Your Data Is Safe

Run A Salesforce Health Check

Run the Salesforce Security Health Check. It'll give you a baseline of where you're at compared to best practices. You will then be able to make any suggested changes, inform your team about the changes, and how they can uphold the standards to avoid any security concerns in the future.

Once potential security issues have been identified, they're classified into three categories: high-risk, medium-risk, and low-risk.

Enable Two-Factor Authentication

Enable two-factor authentication for your Salesforce account. It’s an easy way to add another layer of security to your account.

You should turn on two-factor authentication if you haven't yet done so. Two-factor authentication requires your user to enter a code sent via text message or phone call after they log into their account. It's an extra layer of security that helps prevent unauthorized access to your account.

You can use apps like Salesforce Authenticator or receive a text from Salesforce to verify that it's really you who wants to log into your Salesforce instance.

You can roll this out in two ways:

• You can require people to use two-factor authentication whenever they log into their accounts. In this case, most members would need to go through this step before gaining access. Keep this in mind when considering the urgency of a task, time sensitivity, a user’s role, etc.
• You can trigger the login only when a user meets certain conditions, such as trying to view a report or accessing an app. You can set these conditions to fit into your workstream and roles.

Admins can also restrict which IP addresses can connect to their instances by setting IP restrictions. These restrictions ensure that only authorized IPs can connect to an account.

Create A Custom Login Flow

Due to the unpredictability of the world, your users might need to access your instance at different locations and different hours than usual.

Fortunately, Salesforce has a security setting that allows legitimate users to access their accounts even when they're not logged into the system typically.

A Custom Login Flow will enable you to add extra authentication steps for users who attempt to access your site using an unusual method. For instance, if someone tries to access your site from a restricted IP address or outside business hours, you can create a custom login Workflow that requires them to answer a secret question before they're allowed to proceed.

A Workflow might also include notifying an administrator if someone tries to log in using invalid credentials. These Workflows help keep your instance secure without stopping legitimate users from performing their jobs.

You Are Now On The Safer Side

The three levels of Salesforce’s data security model make it one of the market's most flexible and easy-to-go CRM model. The functionality to individually control access over custom objects, fields, and records make it easy to use for any business need.

These practices help put all the changes and application-level security within a project or organization. Since record-level session security can be split into five different methods, you should confine it mainly within the OWDs and sharing rules.

Now that you’re better equipped to keep your Salesforce data secure from actual security issues, you won’t be fooled, trapped, or taken advantage of like Little Red Riding Hood.