Salesforce and the shared responsibility model

Shared responsibility from the beginning

Did you know that Salesforce has a shared responsibility model, like other cloud service providers such as AWS and Azure? It’s true – you are responsible for many aspects of data protection from the moment you take ownership of your Salesforce organization, beginning the second you first log in to your brand-new Salesforce organization and start creating your very first users! (For example, do the users have strong passwords and multi-factor authentication configured?) Now, think of every change that has been made to your Salesforce organization (for example, anything that could appear in the Setup Audit Trail). Were all those changes made with the shared responsibility model in mind?

How does the shared responsibility model apply to Salesforce?

As solutions have moved steadily from being hosted on-premises to infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) – ever more of the shared responsibility shifts from the customer to the cloud service provider (CSP). Salesforce offers both PaaS and SaaS solutions, which both require customer involvement – meaning some responsibility always remains with the customer. Areas such as system integration, identity access management, authorization model, monitoring, auditing, and secure development are either the customer’s sole responsibility or a shared responsibility between Salesforce and the customer. This means that configuration, low-code, and especially pro-code customization are all subject to the shared responsibility model.

DevSecOps to the rescue

Security is not a milestone; it does not occur at a single point in time. Instead, security is achieved through a comprehensive set of processes, continually and consistently applied. Just like the best time to perform unit tests and solution quality checks is every time you check into the version control system or deploy, the same is true for security checks that help uphold your part of the shared responsibility model. If you are familiar with DevOps – the methodology that integrates and automates the work of solution development and operations – then you are ready to consider DevSecOps, which also addresses your obligations under the shared responsibility model. With DevSecOps, automated security audits and mitigation are incorporated into your development and operations processes. In our experience, automating security into your DevSecOps process is one of the only ways to fulfill your obligations continually and consistently within the Salesforce shared responsibility model. The great news is that in addition to improving security, a good DevSecOps process tends to dramatically increase an organization’s solution velocity!

Learning more & next steps

Are you, like many other Salesforce customers, only now becoming aware of your obligations under the shared responsibility model? If so, you probably have questions. Turnberry Solutions is here to help. We have extensive experience implementing DevSecOps and providing Salesforce solutions to help customers fulfill their obligations within the shared responsibility model. In addition to the materials shared in the list below, please contact us to learn more.

---

Resources

• Salesforce: Standard Questionnaires, FAQs, and Whitepapers
  Look for the document named Security Perspective on the Shared Responsibility Model
• Salesforce Security Guide
• Migrating to the Cloud: What Shared Responsibility Means For Your Organization
• Salesforce B2C Commerce Shared Responsibility Model
• AWS Cloud Security: Shared Responsibility Model
• Azure: Shared Responsibility in the Cloud