.avif)
Welcome back to part two of our series on increasing your security posture and minimizing your risk of exposure to data loss and corruption.
This series uses our DR3(™) framework to approach the challenges every Salesforce admin faces. In this blog, we'll cover part two- 'Protect.' If you missed part one, Identify, take a look and then come back!
Part 2: Protect
In step one, Identify, we looked into our Salesforce setup and highlighted some potential issues. In step two, we become proactive and take the first steps to making our data more secure.
We are going to start by removing everyone from the System Admin profile. No, you don't need anyone to have administrative access on a day-to-day basis, and there are ways to manage this.
Then, we will tighten up our Integration user profiles and remove some of the permissions we identified in part one.
We'll also touch on the importance of backing up your data and what to look for in a complete backup solution.
Profiles and Permissions
System Admin
At Own, we know from experience that the majority of data loss or corruption is human error. I would argue that 100% of data loss is, in some way, human error since the other prominent causes (errant code, integration/migration error) are also caused by humans. But let's take this one step at a time.
In part one, we identified how many users have System Admin access. We're now going to make a copy of this profile. You can do this from Setup -> Profiles and click the 'clone' link next to this powerful profile.
There are a few permissions that are too powerful. We should remove these from day-to-day use where possible. These permissions include the following.
- Modify All: Users with this can view and edit all data within the application
- Manage Users: Users with this can change access levels to any user… including themselves
- Customize Application: Makes it possible to make changes to your production instance, which could lead to issues of an unexpected nature
Ultimately, you must decide which permissions you are comfortable with being proliferated around your business. The above, in my view, poses the highest risk.
Access of Least Privilege
The access of least privilege principle means giving any user's account or processes only those privileges that are vital to performing its intended functions. Here are a couple of examples to illustrate this point and highlight some common gaps.
Sales Reps
Does every sales rep require the ability to edit Account profile information? What if changing these fields has implications for territories or regions? Consider what fields are essential for day-to-day edits and which ones should be controlled by a Revenue Ops team (or similar).
Integration Users
It's very easy to grant 'system admin' to an integration. That will ensure no issues when it comes to a connected system updating Salesforce. But it's hugely over-provisioned! Start with zero access and move UP, rather than with all access and moving down. Most integrations will require just a handful of objects and specific fields. Lock down these users appropriately to remove a significant risk vector.
Admin Users
We have covered this above as a start. But it would help if you also considered what access is required in terms of 'admin-as-usual' (day-to-day activities to keep your business running) and what should be regarded as a 'project' or 'deployment' activity.
Here are two examples of this:
Manage Public Lightning Email Templates permission could be considered day-to-day. There is limited risk in changing an email template. You should still follow a release process and have governance in place - as an incorrectly formatted email could lead to embarrassment. But it won't cause data loss.
Manage Flows should be considered a controlled activity. Flows are very powerful and likely widely used in your organization. They allow you to update records and change field values and are, therefore, much more risky to the quality of your data than some other permissions.
Unfortunately, the granularity of Salesforce permissions can lead to excess rights and privileges. It becomes too hard to control and needs monitoring. Multiple tools are available to help you with this, but the 'Who Sees What' lens in Own Secure will clearly show this.
Remove Powerful Permissions for Data Egress
We looked at this in part one. We're now looking to control and restrict who can carry out data export operations. Here are some of the permissions that allow data to be exported from your Salesforce org:
- Export Reports
- Email Reports
- Data Export
- View All (on any object)
You should work with your business owners and IT / InfoSec to determine what level of risk you accept. You should also consider this is not an all-or-nothing situation. It might make sense that some users can have these permissions, but the majority don't.
This does not represent a complete list but is designed to give you some considerations for tightening your security settings to protect your most valuable asset: your data.
Implement a Backup
At Own, we believe data loss or corruption is a case of 'when' and not 'if.' We advocate for everyone to have a backup solution in place. This is the ultimate safety net, and while we can take proactive measures to increase security posture, your data is still working for you. And while doing so, it is at risk.
Own Recover allows you to restore when you experience an issue. When considering a backup, there are several factors you should consider:
- Does the backup frequency align with your recovery objectives?
- Does the backup represent data independence?
- Can you back up metadata as well as data?
- What restore capabilities are possible?
- Is it actually a backup?
Simply exporting data is not good enough. If you cannot use your export to recover, then it's not a backup. You need to consider the recovery scenarios and how your backup tool makes these possible.
That’s all for part two of this short series. Join me next time as we continue our journey to be better positioned to minimize data loss and handle it when it happens.
