As GDPR came into view, I took a closer look at the security settings in our Salesforce org. Probably nothing novel about that statement, but I'll share a few of the changes that resulted.
First, I ran the Health Check. It's under Setup | Security. It provides an immediate view of some big-picture security issues. I'll confess that I knowingly have not taken all the recommended actions. In some cases, that's for my own convenience (I do want to be able to log in as any of my users, and I don't want to log in under my own credentials after I log out under a user's id). But some of the isues identified are no-brainers and do leave you in a better security posture.
But that's primarily about ensuring that the a user should indeed be logged in to your org. What about the permissions that those legit users have?
I've taken a number of steps to further limit access to company data.
First, I inherited an org with roughly a hundred users and nearly a dozen (!) system admins. I'm down to two. Some of these users just became standard users. But I also created two custom profiles.
One is 'Admin user without Setup and User Management.' This profile lets assigned users modify all data, and gets the same page layouts as the system admin. But, as the profile name suggests, this user can't access the setup menus, and cannot add/delete/edit users. Most of the users who had been system admins but don't manage the org got reassigned here. (Typical users are in Legal or the C-Suite.)
The second custom profile is 'SysAdmin for Integrations.' How many apps do you have that, as part of the setup, require a dedicated license configured for admin rights? I say NO! Again for this profile, I have disabled Setup and User Management. But I also set up specific IP ranges, allow only API access, and block report exports. On the flip side, I don't expire passwords for users in this profile to avoid the surprise of failed logins every three months and the need for the owner of the other system to recognize the error and figure out how to correct it 😏.
Next, I find a lot of the standard profiles to be too loose. Two areas I've locked down are leads and report exports. Most of my users don't have any need to access leads. Sure, Sales and Marketing live there. But my service team? Finance? Not at all. Most of my profiles no longer have access to the Lead object. And I don't allow most of my users to export reports. Most of my users' profiles no longer have that permission, though I can provide it to individual users via a permission set. I'm also pretty quick to block that when I know someone is leaving the company... I'll do what I can to keep anyone from leaving with our company data. In at least one case, a user needed a single report's data on a regular basis. He's now getting a report that I scheduled (with cc to that user), and he otherwise can't export reports.
One area I tried to lock down further: Accounts and Contacts. Similar to leads, this is where a lot of PII lives. And most of the accounts and contacts are only relevant to Sales and Marketing. Legal, Finance, Service... unless there's an active opportunity, or it's a current/recent customer, there's no need to access those records (that's about 95% of them!). My intent was to mark an account to 'allow access' based on either the account type (Customer vs Prospect) or the presence of an open opportunity. Then the default access would be private, with sharing based on the 'allow access' checkbox. And I set up a Flow to this end. But it doesn't operate as expected when a lead gets converted, creating a new account and opportunity. So for now, Accounts and Contacts are still public. I'm sure I'll come back to this issue, maybe just setting a batch process to run daily. I want to limit PII access as much as reasonable!
Finally, I eliminated many of the IP Ranges (Security | Network Access) from which our org allowed users access without activating their devices. I started with the IT department to understand the IP ranges in our offices, and checked the login history to validate any other IP addresses from which we saw regular activity (some were those apps referenced above, some were reps on site in secure locations). Any other IP ranges were deleted from the approved list. For those that remain, each now has a description as to what it is and why it's there. So if we change ISPs, for instance, I can easily identify which entry to delete.
What have you done to limit access to your org? To the data within your org? How might I better detect the accounts with open opportunities?
First, I ran the Health Check. It's under Setup | Security. It provides an immediate view of some big-picture security issues. I'll confess that I knowingly have not taken all the recommended actions. In some cases, that's for my own convenience (I do want to be able to log in as any of my users, and I don't want to log in under my own credentials after I log out under a user's id). But some of the isues identified are no-brainers and do leave you in a better security posture.
But that's primarily about ensuring that the a user should indeed be logged in to your org. What about the permissions that those legit users have?
I've taken a number of steps to further limit access to company data.
First, I inherited an org with roughly a hundred users and nearly a dozen (!) system admins. I'm down to two. Some of these users just became standard users. But I also created two custom profiles.
One is 'Admin user without Setup and User Management.' This profile lets assigned users modify all data, and gets the same page layouts as the system admin. But, as the profile name suggests, this user can't access the setup menus, and cannot add/delete/edit users. Most of the users who had been system admins but don't manage the org got reassigned here. (Typical users are in Legal or the C-Suite.)
The second custom profile is 'SysAdmin for Integrations.' How many apps do you have that, as part of the setup, require a dedicated license configured for admin rights? I say NO! Again for this profile, I have disabled Setup and User Management. But I also set up specific IP ranges, allow only API access, and block report exports. On the flip side, I don't expire passwords for users in this profile to avoid the surprise of failed logins every three months and the need for the owner of the other system to recognize the error and figure out how to correct it 😏.
Next, I find a lot of the standard profiles to be too loose. Two areas I've locked down are leads and report exports. Most of my users don't have any need to access leads. Sure, Sales and Marketing live there. But my service team? Finance? Not at all. Most of my profiles no longer have access to the Lead object. And I don't allow most of my users to export reports. Most of my users' profiles no longer have that permission, though I can provide it to individual users via a permission set. I'm also pretty quick to block that when I know someone is leaving the company... I'll do what I can to keep anyone from leaving with our company data. In at least one case, a user needed a single report's data on a regular basis. He's now getting a report that I scheduled (with cc to that user), and he otherwise can't export reports.
One area I tried to lock down further: Accounts and Contacts. Similar to leads, this is where a lot of PII lives. And most of the accounts and contacts are only relevant to Sales and Marketing. Legal, Finance, Service... unless there's an active opportunity, or it's a current/recent customer, there's no need to access those records (that's about 95% of them!). My intent was to mark an account to 'allow access' based on either the account type (Customer vs Prospect) or the presence of an open opportunity. Then the default access would be private, with sharing based on the 'allow access' checkbox. And I set up a Flow to this end. But it doesn't operate as expected when a lead gets converted, creating a new account and opportunity. So for now, Accounts and Contacts are still public. I'm sure I'll come back to this issue, maybe just setting a batch process to run daily. I want to limit PII access as much as reasonable!
Finally, I eliminated many of the IP Ranges (Security | Network Access) from which our org allowed users access without activating their devices. I started with the IT department to understand the IP ranges in our offices, and checked the login history to validate any other IP addresses from which we saw regular activity (some were those apps referenced above, some were reps on site in secure locations). Any other IP ranges were deleted from the approved list. For those that remain, each now has a description as to what it is and why it's there. So if we change ISPs, for instance, I can easily identify which entry to delete.
What have you done to limit access to your org? To the data within your org? How might I better detect the accounts with open opportunities?
Comments
Post a Comment