The main purpose of data security is to protect organizational data, which contains trade information and customer data. Data can be accessed by cybercriminals for malicious reasons, compromising customer privacy.
According to Cybersecurity Ventures:
Let us find out more about data security and the comprehensive model Salesforce has in place.
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:
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.
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.
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.
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.
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.
You can configure object-level and field-level security controls from profiles and permission sets.
These are the general configuration steps:
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 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:
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.
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:
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:
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.
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.
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.
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.
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.
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 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:
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.
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.
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.
Sign up for our newsletter & receive fresh content about all things Salesforce.
