Shared Responsibility Models for Public Clouds

Public cloud providers share some security responsibility with their customers. This means that as a security practitioner, what you should take into account in your threat model is going to be different in the cloud than on premise environments.

The concept of Shared Responsibility

If you were to operate a colocated machine in a datacenter — or a whole datacenter — you would be responsible for the security of it: from the very bottom of the physical stack (“who can touch the machines”) to the physical networking, up to the staircase of infinite software abstraction layers.

The cloud removes a lot of the hassle, since you are practically renting computing resources from someone else. This means your provider will take care of a lot of things for you and the higher you are in the As A Service stack, the less stuff you are responsible for.

In short the provider is resposible for the security of their clouds, while you will be responsible for the security in their cloud.

IaaS, PaaS and SaaS

In practice on the Infrastructure as a Service (IaaS) layer boundaries are sharp: you get a virtual machine and you are in charge of what to run on it.

As soon as we step in the Platform as a Service (SaaS) layer things gets fuzzier. Every platform service is a snowflake: to abstract away as much infrastructure as possible, things have to be opinionated and some configuration decisions are taken for you (and the provider is responsible for them) while for others you have the freedom to mess things up.

Finally in the Software as a Service (SaaS) layer the situation gets calmer again: it’s mostly about how to authenticate and authorize identities.

What you should care about

So as a security engineer what should you care about?

I don’t have a direct answer because — as everything in security — it depends.

But the rule of thumb is:

  • Start by looking at what you are using, and keep note of your platform services
  • Identity and Access Management (IAM) is always on you, on all layers
  • Keep a reference of the responsibility models handy (like this one!)

Azure Shared Responsibility Model

Azure Shared Responsibility Model

Microsoft documentation is well written and extensive, dig their docs.

References

AWS Shared Responsibility Model

AWS Shared Responsibility Model

References

GCP Shared Responsibility Model

Google do not have a go to resource for the shared responsibility model anymore, they redirect you here.

But they have detailed security models for specific services.

References

Conclusion

We tend to give the concept of shared responsibility for granted, in particular if we are used to cloud native environments.

The main issue as I see it is when you grow outside the boundaries of a cloud provider and you have to suddenly face the perils of a multi cloud or hybrid environment.

This is when it’s better to keep an eye on the nuances between provider’s models, in particular on the PaaS layer: there might be some areas that are not overlapping as you are expecting and that can become a blind spot.

Note: I intend to keep this article up to date so it can serve the purpose of having a single reference.