Salesforce Data Security
For Salesforce Admin, Security Researchers & Pen-Testers
Context
SAAS or Software as a Service, is a software delivery model where a software is made accessible via web. To an extent, it is like a web application. Also, using SAAS is like a privilege, the infrastructure and platform of the SAAS application is completely managed by the vendor.
CRM or Customer Relationship Management, helps a business organisation to maintain their relationship with its customers. Software has been built to manage CRM efficiently. Now, don’t get confused with the word customers here, for example, let’s consider an e-commerce application, the e-commerce company would use CRM to maintain relationship with their suppliers (not customers who buy), check their activity, provide analytics on how they do and enable support.
Salesforce offers SAAS applications for CRM. These SAAS application can be entirely managed and customised via an admin panel, which means you can make the SAAS app live in no time using the admin panel itself. The coding effort required is minimal and it involves one of Salesforce programming technologies. Customisation via other programming languages are also present, but the former is the most preferred.
All good ? How about the security controls? Well, a set of security controls are offered as part of the admin panel to manage user and data permissions.
Core Components
By now, you must have realised Salesforce SAAS apps is all about managing data. The backend of these apps is like any other data management software, they store data in tables, use queries to process them and expose functions to retrieve them. Tables and data are the core and the security controls have been designed for them. Lets take a look at these core components:
- Objects are like database tables, there are standard objects, that are provided by Salesforce and one can create custom objects too
- Fields are like table columns
- Records are like table rows
For example, In a customer support kind of application, all customer issues can be managed using the Salesforce standard “Case” object. This is how the mapping would look like.
Security Controls
Ok, so we know what objects, fields and records are. Let’s try do a simple visualisation based on whether these are accessible or not for a user.
- The user has access to “Case” and “Contacts” objects, but not Accounts
- The user has access to all fields in “Case” object and only “Name” field in Contacts object
- The user has access to a few records in “Case” and “Contacts” objects
- The most important point you have to understand from this visualisation, a user needs to have an object level access first before accessing a field and then a record. However, this understanding will change, but we will see it later under Permissions conflicts section.
Well, thats exactly how the permissions are set by Salesforce too, but there is a couple of detailing that Salesforce adds. Let’s now look at the first detailing, the access options.
If you are assigning permissions to an object, field or record, you are not just enabling access, you are assigning one of these access options. In our visualisation, you can now replace the ticks and cross marks with these access options.
The second detailing is the different security controls that Salesforce provides to assign these access options. Sounds too complicated ? Nah, Remember the first visualisation? it is for a single user, but in reality, if we were to be setting permissions for an entire organization, a user to user basis isn’t going to work. We might have to group them, say create profiles for common users or create Role Hierarchies, or sometimes group users within a profile to assign permissions exclusively or set permissions at an organization level. Well, that’s exactly what the security controls are for, there are around seven.
- Profile (applicable to object/field level only), a set of permissions that are assigned to a group of users performing the same function. A user is attached to a single profile.
- Permission Sets (applicable at object level only), a set of permissions that are assigned to users within a profile. A user can be attached to multiple permission sets.
- Org. Wide Sharing Defaults (applicable at record level only) is choosing the organization wide default access level for object records. By default, only the users who created the records will have access to them.
- Role Hierarchies (applicable at record level only) are creating Roles that map to an organisation’s hierarchy. This helps create vertical sharing. A simple example would be, a manager role would have access to all the records of the manager’s direct reports.
- Sharing Rules (applicable at record level only) are created to provide horizontal sharing. A simple example would be a manager sharing records with a fellow manager
- Apex Managed Sharing (applicable at record level only) is providing permissions to records via code for the ones that are not available via UI. A simple example would be if a manager wants to share an information with a different team member who is not related in anyways
- Manual Sharing (applicable at record level only) lets you share individual records with users, but this is limited to “Classic”, you can consider “Classic” to be an older version of the admin panel configuration, the upgraded one is called “Lightning”.
The applicability chart for the security controls is as follows:
Though profiles might look similar to role hierarchies, they both are placed at different levels. Profiles are only to give users the first level of access to an object, whereas role hierarchies are the one that provides access to records. Of course, they could have made it simpler, but that’s how the security controls work.
Stitching it all together
Now, let’s add the access options and security controls to our visualisation and see what it looks like
- User is now assigned to a profile, multiple permission sets, a role and also has sharing rules enabled
- Objects have access options like read, create etc. enabled and fields have read access options
- Records have a minimal org. wide sharing defaults to begin with and the permissions are expanded via roles, sharing rules, apex managed sharing etc.
- Profiles and permission sets are only for objects and fields permission, they give access only to metadata. Roles and sharing rules are for records permission, they give access to records.
Permission Conflicts
There is still one other layer we need to understand and that’s most important one. Our initial understanding was, a user needs to have an object level access first before accessing a field and then a record. This is correct, but there are scenarios where the record level permissions can be different from the object level permissions.
Let’s take a real world scenario, a supplier raises a support ticket because the supplier’s login didn’t work. In the backend, a case is raised under the “Case” object. Let’s take a look at the different permissions set for the supplier user.
- The supplier user’s object permissions lets the user perform read, create, edit and delete on the “Case” object
- Object and field permissions are inter-dependant, a user needs to have an object access to have access to its fields. This is simple.
- But when it comes to record permissions, the object permissions are both dependant and independent.
- Now since the supplier user has access to the “Case” object, the supplier user also owns the created records. In this example, the supplier user has access to the “login didn’t work” case record. The supplier user should be able to read, edit or delete this case record. This is where the object permissions are dependant on the record permissions.
- Since the supplier user has read, edit, and delete permissions on the “Case” object, should the supplier user be able to read, edit or delete other cases raised by fellow suppliers? Ideally, the supplier user shouldn't be able to perform these operations. This is where the record permissions can work independent of the object permissions. The whole purpose of record permission being a separate entity is to manage the record permissions of the user that user does not create. This is where the record level security controls come into picture.
There are different possible combinations to this. It can be confusing and this confusion can cause misconfigurations, hence it is key to understand how conflicts work.
Security Controls - Top 3 Review Pointers
Here is a set of pointers that can help you review these security controls.
- Record permissions are critical, lack of understanding and misconfigurations can lead to sensitive data leakage.
- Unauthenticated user is called a “Guest User” in Salesforce. There is a separate profile that exists for a guest user. Though Salesforce has a history of upgrades for the guest user security, it is critical that the security controls for the guest user are thoroughly reviewed. Not doing so can lead to sensitive data leaks that could be CRITICAL.
- Sometimes, by mistake you can override permissions provided in the UI by using a few functions in the code, so always remember - “Keep it simple”.
Interested to know, how Salesforce applications are pen-tested, take a look my two part blog. Part-1 and Part-2 here.
I hope you enjoyed reading the blog :) Good Day !