The Shared Responsibility Model

The Shared Responsibility Model is the single most important thing to understand about working in the cloud because this model defines how operational and security work gets done.



If you don’t understand the model, you’re not going to get the most out of your move to the cloud as you could be opening up your workload to additional risks and duplicating work your CSP is already doing.

The Premise

At its core, the model is a map. It lays out who is responsible for doing work in various areas. And as the name implies, that work isn’t always done by the same teams.

The division of labour between your organization and the cloud service provider has long been a point of contention. In the security world, it’s usually a question of trust.

“We can’t blindly trust another organization to do the work!” No one is asking you to. This model isn’t cloud specific. It’s how organizations work on-premises as well. The difference there is that teams all fall under the same leader (usually the CIO) instead of different companies. But the process is the same. Some teams are responsible for this area while other teams take care of that one.

Together, they share responsibilities of making sure all of the work gets done–verifying each other’s work as needed.

AWS, Azure, and Google Cloud

As you might have guessed, each of the “big three” has a slightly different take on the model.

AWS presents it as a question of responsibility “in” and “of” the cloud. They use this (figure 1.) visual to help show the division of labour.


AWS Shared Security Model

Azure looks at the model across types of cloud services. Using the traditional SaaS, PasS, and IaaS, they directly acknowledge the grey areas where responsibility varies.

You can see that in their visual (figure 2.).

While Google takes a very technical approach to the model, they don’t use visuals. Instead, they deliver an eighty-seven page document that specifies each responsibility for their service offering.

When you dig into each of these presentations, you’ll find that the model itself is actually the same. In fact, the division of labour for comparable services is also, almost exactly the same.

The Simplest Version

I prefer to look at the model in its simplest terms. The cloud service providers are constantly introducing new services and features that require evaluation. Keeping the model at first principles makes it easier to evaluate new offerings.

In order to deliver reliable solutions, daily work is needed in six different areas: physical, infrastructure, virtualization, operating system, application, and data.

Depending on the type of service in question, you—the builder—will be responsible for up to half of those areas. You are always responsible for your data and the configuration of the service. Because the configuration of the service isn’t a core area but a result of how the technology is delivered.

You are never responsible for the physical, infrastructure, or virtualization areas.

Now, that’s not to say that you can’t influence these areas. With each of the big three CSPs you can choose which physical region the services you are using are located in.

You can also enable various configurations that change how the network infrastructure is used. But, despite these configurations, you’re still not responsible for the daily work. You’re just leveraging a feature to guide that work.

Here’s a visualization of the simplified model (figure 3.).

Viewing the model this way clarifies your responsibilities.

Applying The Model

The goal of this model is to help you focus your efforts and maximize the value you’re getting from your cloud service provider.

Understanding this model is critical to the set up of your practice. You need to understand what work needs to be done by your teams and what work you only need to verify (where appropriate).

For any new service, you need to ask if you are responsible for the operating system and application.

You already know that you are responsible for your data and the overall configuration. You also know that you are not responsible for the physical, infrastructure, and virtualization.

This is the power of the shared responsibility model. Whether you view it like AWS, Azure, or Google Cloud, the goal is the same, maximize the value you are getting from the cloud.

Copyright 2022 Lacework Inc. All rights reserved.