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 learn 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.
Salesforce uses object-level security as its first security level. Before allowing or revoking 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.
Sometimes, you can create a new profile for a specific user or a set of users.
One thing to note 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 deliberately assign additional user permissions on top of profiles. An organization should preferably 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 manage 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.
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, Salesforce permission sets allow you to hide a field completely, make it read-only, or grant read-and-write access. This is necessary in many ways, such as when an object is used by multiple organizations 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:
The organization-wide defaults of a Salesforce object decide the visibility and editability of its records regarding the access of users who don’t own them. But before discussing the access options of non-owners, let's 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 it does not convey any meaning for lateral sharing. 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, roles, subordinates, etc.
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 sharing rule type differs from the others. Guest user sharing rules only allow read-only access to records for 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 your current situation compared to best practices. You can then make any suggested changes, inform your team about the changes, and discuss 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 you want to log into your 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 allowing legitimate users to access their accounts even when they're not logged into the system.
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 secure your Salesforce data from actual security issues, you won’t be fooled, trapped, or taken advantage of like Little Red Riding Hood.