Shared Responsibility Model
One of the most important ideas in cloud security is the shared responsibility model. It answers a critical question: when something goes wrong, who is responsible for fixing it — you or the cloud provider? The answer depends on which layer of the cloud stack the problem occurred in.
The Apartment Building Analogy
Imagine you rent an apartment. The building owner is responsible for the roof, walls, plumbing, and common areas. You are responsible for locking your door, keeping your furniture safe, and not leaving windows open during a storm. If the roof leaks, that is the owner's problem. If you leave your front door unlocked and someone walks in, that is your problem. Cloud security works exactly the same way.
What the Cloud Provider Always Secures
Every major cloud provider — AWS, Azure, Google Cloud — takes responsibility for the physical and foundational layers of the cloud. These include the physical data centers, the hardware servers, the global network cables and switches, and the virtualization layer that separates one customer's workloads from another's. You never touch these, and you never need to worry about them.
What You Always Secure
Regardless of whether you use IaaS, PaaS, or SaaS, you always own the security of your data and your user accounts. A cloud provider will never tell you what password policy to enforce on your team. They will never delete your exposed database for you. Your data, your users, and your access controls are always your responsibility.
The Sliding Responsibility Boundary
IaaS PaaS SaaS
Data YOU YOU YOU
User Access YOU YOU YOU
Application YOU YOU PROVIDER
Runtime YOU PROVIDER PROVIDER
OS YOU PROVIDER PROVIDER
Virtualization PROVIDER PROVIDER PROVIDER
Hardware PROVIDER PROVIDER PROVIDER
Data Center PROVIDER PROVIDER PROVIDER
As you move from IaaS to SaaS, the provider takes on more layers. Your security workload shrinks — but your responsibility for data and users never disappears.
Where Most Security Failures Happen
Most cloud security breaches do not happen because a cloud provider failed. They happen because a customer misconfigured something on their side of the responsibility line. Gartner, a leading technology research firm, has noted that a large portion of cloud security failures result from customer misconfigurations — not provider failures. Common examples include leaving a storage bucket publicly readable, giving an employee admin access they do not need, or failing to enable encryption on a database.
A Real-World Scenario
A company stores customer records in an AWS S3 storage bucket. AWS secures the physical servers where that bucket lives. But the company accidentally sets the bucket permissions to "public." Anyone on the internet can now read those records. AWS did nothing wrong. The company failed its own side of the shared responsibility model.
How to Apply This Model Practically
- Map every resource you run in the cloud to its service model (IaaS, PaaS, or SaaS).
- For each resource, identify which layers you own — then build security controls for those layers.
- Review your cloud provider's published shared responsibility documentation — AWS, Azure, and Google Cloud all publish it publicly.
- Treat "the provider handles it" as a starting point, not an excuse to skip security reviews.
Key Terms to Know
- Misconfiguration: A security error caused by incorrect settings rather than a software vulnerability.
- Security Posture: The overall strength of your security controls at any given time.
- Cloud Native Controls: Security features built directly into a cloud platform (e.g., AWS IAM, Azure Security Center).
What You Learned
The shared responsibility model divides cloud security duties between you and your provider based on the service model you use. The provider always protects the physical infrastructure. You always protect your data and user accounts. The boundary between your responsibilities shifts depending on whether you use IaaS, PaaS, or SaaS. Most cloud breaches happen when customers misunderstand or ignore their side of this boundary.
