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.
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 364 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:
