SaaS Security Series: Understanding Salesforce Administrative Permissions

Today, more than ever, SaaS applications drive the modern enterprise. They are relied upon for managing customer data, allowing internal collaboration, and keeping organizations connected across the world. As the amount of sensitive and business-critical information stored in or flowing through SaaS applications has grown, it has become increasingly important for security teams to recognize that managing the security posture of these applications requires new approaches and new technologies.

Just as the adoption of IaaS clouds necessitated the development and deployment of Cloud Security Posture Management (CSPM) solutions uniquely suited to continuously monitoring the security posture of infrastructure clouds, widespread adoption of SaaS applications necessitates the use of purpose-built security technology solving the unique security challenges SaaS introduces to the enterprise stack. SaaS Security Posture Management (SSPM) platforms must be capable of deeply understanding the security posture, data access entitlements, system configurations, and monitoring capabilities of varied SaaS clouds. SSPM platforms must be able to normalize those capabilities across the most common and most powerful SaaS clouds in use by enterprises today to provide effective, actionable, and continuous security assurance.

In the first part of an ongoing series of publications, we’ll take a deep dive into key components of major SaaS applications that play a large role in the security of those systems. In this article, we’ll explore the Salesforce permissions architecture, which acts as an additional mutation layer on top of the comprehensive Role-Based Access Control (RBAC) system that powers access to data and functionality in the Salesforce platform.

Key Takeaways

• Salesforce now provides more granular permissioning, which helps customers achieve a better separation of duties so that their configurations can adhere to the principle of least privilege.

• As enterprises manage their Salesforce permissions, it’s important to restrict administrative permissions — such as View All Data, Modify All Data, Manage Users, Modify Metadata, and Apex — so that only administrative users and integrations that interact with Salesforce metadata and configuration have those permissions.

• While permissions are a critical component of Salesforce access control configuration, enterprises must also consider other access control concepts — including sharing models, roles, groups, and permission sets — to get a complete view of the security posture of the enterprise’s Salesforce systems. Without a holistic approach to access control, enterprises cannot see how the interactions between components, permissions, and other settings play into their overall Salesforce system security.

Salesforce Permissions Architecture 101

The Salesforce platform is one of the most powerful and flexible SaaS platforms available today, as it can be configured to host and automate almost any business process. With that level of flexibility, however, necessarily comes a level of complexity that includes a robust and multifaceted access control system. While Salesforce has many elements of access control — including permissions, groups, roles, profiles, permission sets, and record level sharing — this article focuses on permissions. Specifically, we cover Salesforce’s granular designation of administrative functions and how customers should view a handful of the most powerful administrative permissions.

At the time of this writing, there are over 360 system permissions across the different versions and editions of Salesforce. In recent years, Salesforce has made a major push to provide more granular permissioning, breaking down the most powerful permissions into several less powerful component permissions, allowing customers to achieve better separation of duties and better adhere to the principle of least privilege in their configurations. Salesforce also uses permission dependencies, where assigning one permission automatically assigns dependent permissions. With this feature, a given permission grants superset access to dependent permissions or effectively provides similar administrative capabilities through alternative mechanisms. This explicit and mandatory assignment of dependent permissions, combined with the documentation describing the effect of the access, serves as a safeguard against accidental assignment.

Below we’ll cover some of the most common administrative permissions that should generally only be available to administrative users and integrations that interact with Salesforce metadata and configuration:

These are living systems which hold increasingly critical data in ever-growing amounts, representing a frequently overlooked risk to a company’s security posture.

View All Data

Description

Salesforce object access can be restricted at both the object and record levels. Object access control is typically called CRUD, for Create-Read-Update-Delete. In Salesforce, the concept of “sharing” means granting record-level access control over reading and changing records. For example, your field sales team should likely be able to edit the records of customer contacts, accounts, and opportunities they own but not those of other field sales teams.

The View All Data (VAD) permission acts as a bypass to the object- and record-level read settings. That is, the assignment of View All Data allows the target user to see all records in all data objects. As this is typically not desired and would normally violate the principle of least privilege access, use cases should be carefully reviewed before granting this access as the use cases can often be satisfied using sharing rules and/or the more granular object-level View All Data setting.

Dependencies

View All Data has quite a few dependent permissions and settings, clearly showing the sweeping level of data access users with this permission possess.

Production Considerations

In environments containing sensitive data, View All Data is appropriate for management and IT data administrators. Integrations should not generally need global View All Data, and object-level View All is preferred for those use cases.

Integration (Fullcopy) Considerations As fullcopy integration environments often contain recent copies of all production data, all data confidentiality requirements should be applied to these environments, and assignment of View All Data should generally follow the rules of production environments.

Modify All Data

Description

Modify All Data is one of the oldest and most powerful permissions in Salesforce. As its name suggests, it generally provides full access to edit all data in the system. In addition, many administrative actions and capabilities still require the Modify All Data permission in order to be performed as a generic check by the Salesforce platform that the user is a highly privileged administrator.

Dependencies

Modify All Data has a large number of dependencies, including permissions such as View All Data, which themselves have many dependencies.

Production Considerations

Modify All Data is appropriate for IT data administrators. Outside of ETL solutions and similar use cases, integrations should not generally need Modify All Data unless they are performing a specific action explicitly requiring the Modify All Data permission. Vendors of such solutions should be able to identify specific, documented scenarios where Modify All Data is required.

Public companies should pay particular attention to this permission due to Sarbanes Oxley (aka SOX or SARBOX) compliance if data derived from Salesforce is part of their financial reporting.

Integration (Full Copy) Considerations

As data changes in integration environments are not typically promoted to production, Modify All Data provisioning in integration should generally follow the same guidelines used for View All Data, as keeping the dependent View All Data confidential is the prevailing security concern.

Manage Users

Description

Manage Users is another old and powerful permission in Salesforce. If Modify All Data makes a user a full data administrator, Manage Users makes them a full user administrator capable of adding, removing, or changing any user’s configuration. Recognizing that it may be too powerful a permission, recent releases have separated Manage Users into several more narrowly defined permissions that can be assigned independently. Additionally, and somewhat unfortunately, many system actions still require the full Manage Users permission (e.g., reading login history for all users).

Dependencies

Manage Users has a large number of dependencies, including all of the more recent and narrower user management permissions.

Production Considerations

Few users should have the full Manage Users permission in production environments. Customers should instead provision access to the other recent and more granular user management permissions.

The main driver for provisioning Manage Users will be the many metadata and configuration interactions that continue to be directly tied to the Manage Users permissions. In these scenarios, customers should have monitoring in place to identify if these integrations or users actually exercise the full capability of Manage Users to create backdoor accounts or take over existing users.

Integration Considerations

Manage Users is more common in integration environments that may be test beds for additional integrations needing purpose-specific users to be created. Additionally, Manage Users is often used during User Acceptance Testing (UAT) as test accounts are often created and reconfigured in the scenarios required by UAT.

Modify Metadata

Description

In the Summer ‘17 release, Salesforce launched the Metadata API to expose all configuration and metadata within an organization programmatically. Unfortunately, when originally launched the Metadata API required the Modify All Data permission. Salesforce changed that in 2018 when it added a beta permission originally named “Modify Metadata (beta).” The permission has since been given the more verbose name “Modify Metadata Through Metadata API Functions,” along with a very specific warning around the nature of the permission:

“Create, read, edit, and delete org metadata. Users must have appropriate access rights to the metadata they’re trying to modify. Be careful if delegating this permission. Some metadata executes in system context, when object permissions, field-level security, and sharing rules that apply to the user are ignored. For example, Apex executes in system context.”

Either Modify All Data or Modify Metadata is required to access the Metadata API. Usage of the Modify Metadata permission is considered best practice, as the role of data administrator (implied by Modify All Data) and metadata administrator are typically separate.

The Metadata API is commonly used by Salesforce DX, as well as commercial products that perform configuration management or SaaS Security Posture Management (SSPM). The API gives access to the full range of configuration in Salesforce, to include schema, profiles, and permission sets.

Dependencies

Modify Metadata has a single dependency on View Setup and Configuration, a low-level permission commonly given to internal users.

Production Considerations

In production, Modify Metadata should be available only to users in a release management or deployment role and those integrations with a configuration management or SSPM function.

Integration Considerations

Similar to production, Modify Metadata should be available only to users in a release management or deployment role and those integrations with a configuration management or SSPM function. In config sandboxes and other low-tier sandboxes, many users will have this permission to use deployment utilities, such as SFDX.

Author Apex

Description

Apex is Salesforce’s version of “cloud code,” which is created by customers and uploaded for execution on Salesforce servers in a restricted runtime environment. Apex is part of the Lightning Platform (previously Force.com), which also includes the server-side templating language VisualForce, client-side Lightning components, and other development technologies. Customers can use Apex to extend the native capabilities of Salesforce to implement special business logic or even create complete applications that may not even be related to traditional CRM use cases.

An important consideration of Apex is that the author can choose to write Apex that enforces the access restrictions of the calling user or, like most other software, runs in a system context. In the latter scenario, the code has largely complete access to data and other resources in Salesforce. Developers creating Apex running in a system context often have use cases involving aggregating data across Salesforce to create statistics or otherwise performing actions that the user should not be allowed to perform on the raw data. For example, an Apex class could search across all customer records to identify a potential duplicate even if the calling user does not have direct access to all customer records.

The Author Apex permission allows the user to upload Lightning/Force.com components to Salesforce. As the user gets to choose whether an Apex class ignores or enforces the calling user’s restrictions, they could trivially write, upload, and execute a class to retrieve all data in the environment. As such, Author Apex is purely an administrative permission.

In other words, any potentially malicious changes that a developer could make by using Author Apex as an underhanded mechanism to change configuration, such as profile or permission set assignments, can be done trivially and directly using Metadata API utilities, such as the open sourced SFDX. This eliminates any concern around abusing privilege escalation in Salesforce using Author Apex, as the user already has full and direct access to change any system configuration via the Metadata API.

Production Considerations

Author Apex should only be assigned in production to users with a release management role. As Apex and other Force.com components are typically a large focus of UAT testing and there is justified concern about Apex being created directly in production, we seldom see Author Apex assigned broadly in production environments.

Integration Considerations

In integration environments, Author Apex is generally provisioned to release management roles, as well as to developer roles if integration becomes the necessary environment to debug Apex classes.

Summary

This article covers just a handful of the hundreds of permissions in Salesforce. The permissions detailed here are administrative in nature and should not generally be assigned to non-administrative users or integrations where their vendors are unable to justify the requested access. Security teams and auditors should also consider the scope of platform features when identifying potential risks. For example, Salesforce’s permission dependency concept effectively nullifies the subversive potential of the Author Apex permission by making the full scope of the access explicit. In that example, a team or vendor not familiar with Salesforce or the Metadata API feature may mistake that permission as creating a potential vulnerability, causing unnecessary concern and work for their company or customers.

Also remember that permissions are just one part of the overall access control configuration of the Salesforce platform. Looking only at permissions and not the other access control concepts — such as sharing models, sharing rules, roles, groups, profiles, permission sets, and so on — is likely to lead to an inaccurate view of the overall security posture of your Salesforce systems. As there tends to be significant interaction between these components, permissions, and other settings, security managers should consider all access control concepts holistically to gain an accurate view into their system security.

Security teams today have, realistically, two paths they can take to effectively manage and secure SaaS products. The first is to dedicate internal resources to the time consuming process of developing and maintaining deep expertise in each SaaS product for which they are responsible. The challenge for many security teams who choose this option is that a small subgroup is often responsible for all SaaS applications a company uses. This centralization of responsibility and expertise differs from their IT counterparts, where entire teams may specialize in just one or two applications. The time and resource investment in this scenario is continual, as security engineers must stay up to date with changes, upgrades, and new behaviors of the SaaS platforms they are monitoring.

The second option is to leverage an SSPM product which has built that expertise into the platform. This consolidation of SaaS platform expertise on the SSPM provider effectively amortizes the research and maintenance costs just as SaaS platforms amortize security and operational costs away from the end-user.

Complete SSPM solutions are capable of then exposing that information to customers in the form of security configuration recommendations, data access entitlement monitoring, and the ability to perform detections based on data and business-logic violations. These capabilities and the depth of understanding between SSPM platforms and the SaaS applications they monitor are the key differentiators between SSPM and CSPM or generic Cloud Access Security Broker (CASB) platforms.

Whether a security team elects to invest resources internally or make use of an external SSPM platform, it is critical that the security posture and access configuration of SaaS applications be continuously monitored.

Related Resources