This post discusses an important aspect of Salesforce security; Ghost Admins. In this blog, we cover:
- What is a Ghost Admin?
- Why do they compromise the security of your Org?
- How Admins can use permission sets to prevent Ghost Admins
Having too many Users with the standard Salesforce Admin Profile can be problematic. As a best practice, one to two percent of Salesforce users should be System Administrators within your Org. Salesforce Admins have “God-like” powers. The more Admins you have, the more liability you introduce into your Org.
Most seasoned Admins know this and keep their Admin Profile User numbers low. However, what isn’t top of mind for all Admins is how many Ghost Admin users exist within their org.
What is a Salesforce Ghost Admin?
A Ghost Admin is a user, who through their Profile and Permission sets, has much of the same access and ability to impact a Salesforce Org as a full Admin Profile User. These users don’t have a variation of the Standard Admin Profile, but through another Profile and/or Permission Sets they have:
- The ability to create or update Users, Permission Sets, Roles or Profiles
- The ability to Modify All records
- The ability to Export All data from Salesforce
How do we end up with Ghost Admins?
Ghost Admins tend to appear organically over time. Most often they occur because a series of Permission Sets get added to a User as their role and the Org evolves. This is particularly common with executive profiles; who are typically under tight timelines and have the authority to request further permissions.
For example, a new package may require a Sales leader is given access to an object. To address this, an Admin gives the user broad Modify All access as a quick fix, and it is never revoked. It is common for users to be given Modify All access as a quick fix for requests that should be solved with Account or Opportunity teams, Hierarchies and a sharing rule.
Why Ghost Admins Compromise Salesforce Security
Ghost Admins are problematic because often, these users are not trained and don’t understand why their changes may impact Salesforce. At best, this means changes will be made without considering the long-term cost of maintaining those changes. At worst, this results in items breaking, disruptions to productivity, or introducing security vulnerabilities. Also, often, Ghost Admins aren’t aware of how much power they have in Salesforce as their access in the instance has grown over time.
How to Find Ghost Admins in your Org
Step 1:
Open Workbench and type in the following query under SOQL query to get a list of all users with the permissions mentioned at the beginning of this post:
Note: You will have to turn on “Allows SOQL Parent Relationship Queries” in order to perform this query.
Select Assignee.Name,PermissionSet.PermissionsModifyAllData,PermissionSet.PermissionsDataExport,
PermissionSet.PermissionsManageUsers from PermissionSetAssignment where
(PermissionSet.PermissionsModifyAllData = true OR PermissionSet.PermissionsDataExport = true OR PermissionSet.PermissionsManageUsers = true) and assignee.isactive=true
Step 2:
Perform this query by clicking the bulk CSV button in order to get the results in a file format that you can review and present.
Step 3:
Once the CSV has been downloaded, you may want to add columns like “Salesforce Certified”, “Security Cleared”, etc. to rationalize which users should have which levels of access.
Step 4:
After the CSV has been updated to show whose access needs to be adjusted, book a meeting with your leadership team. In this meeting, demonstrate why certain team members need their level of access in Salesforce reduced.
Come to this meeting prepared, with documentation, because in some cases you may propose reducing the level of access the C-Suite has. The reason being, high profile team members are the least likely to take the time to QA or understand changes they make in Salesforce. They are also prone to make mistakes because of how much they have on their plates (and they are sought after targets for external attacks).
Creating Admins with Permission Sets
After an agreement with the leadership team has been reached, moving forward, best practice is to create System Admins with Permission sets instead of Profiles.
Using Profiles for Admin Permissions is a blunt instrument, and as we’ve discussed in this post, it leads to providing types of access that isn’t required. Instead, Admins can create three Permission Set(s) as a more nuanced and more secure solution. Each of these Permission Sets can be applied individually, or a Systems Admin user may need all three. These permission sets are User Admin, Record Admin and Metadata Admin.
User Admin
This user has the ability to assign and deactivate profiles. For example, HR associates need to be able to create new users when people are hired and deactivate users when people are terminated. However, they do not need the ability to change metadata.
Record Admin
A Record Admin needs to be able to do things to records in Salesforce but shouldn’t be allowed to change anything in the setup area that could negatively impact the org. As an example, a junior marketer may want to upload a lead list from a tradeshow for a Salesforce Campaign.
Metadata Admin
A Metadata Admin is able to make changes in the Setup area of Salesforce and impact Salesforce metadata. We recommend only one to two percent of your overall license base should have this level of access (ideally only dedicated Admins).
Wrap Up
I hope you found this post helpful and are walking away with actionable insights on how to manage a more secure instance of Salesforce. Have questions about Salesforce security? Sign up for our newsletter! We send out a monthly recap of our latest Salesforce content, including articles on security best practices, actionable insight on Salesforce optimization for enterprises, and more.
