Topic 67

The Shared Responsibility Model

Shared Model

The cloud does not make security someone else's problem — it splits it, and misunderstanding the split is the root of a huge share of cloud breaches. The provider secures the infrastructure (the cloud itself); the customer secures what they put in it (data, configuration, identity, access) — and the customer's half is where nearly every reported cloud breach happens.

This topic frames the whole chapter by drawing the responsibility line clearly, so that "the cloud is secure" and "your cloud deployment is secure" are recognized as entirely different claims.

The Line, Drawn

The provider handles physical security, the hypervisor, and the managed-service internals; the customer handles their data, identity and access (Chapter 3), network configuration (Chapter 4), OS patching for IaaS, and application security (Chapter 6). The shorthand is "security of the cloud" (provider) versus "security in the cloud" (customer) — and confusing the two is how owned controls fall through the gap.

How the Line Shifts by Service Model

IaaS leaves the customer the operating system and everything above it; PaaS and managed services take more off their plate; serverless and SaaS take more still. But the customer always owns data, identity, and access configuration, no matter the model — so a serverless app with a public data store and an over-privileged role is just as breached as a misconfigured virtual machine.

Where Breaches Actually Happen

Overwhelmingly, the customer side: misconfigured storage, over-privileged identities, exposed credentials, and open security groups. The provider's infrastructure rarely fails, so defensive attention belongs on configuration and identity, not on the parts the provider already secures well. Spending effort auditing the provider's rock-solid hypervisor while your bucket is public is defending the wrong half.

The Misconfiguration Problem

The cloud makes it trivial to deploy and equally trivial to expose — a public bucket is one setting. The speed and scale that make cloud useful also make one wrong default a data breach, which is why cloud security posture management (the following topics) exists. Meridian's responsibility map lists concretely what the provider secures versus what Priya must, so the rest of the chapter targets the customer-owned controls that actually get breached.

Security of the Cloud vs Security in the Cloud

Of the cloud (provider) — datacenters, hardware, hypervisor, managed-service internals; hardened, and rarely the breach point.

In the cloud (customer) — data, identity and access, network and resource configuration, and application security; where essentially all cloud breaches occur. The provider's strong security can lull customers into neglecting the half that is actually theirs.

Common Mistakes

Assuming "the cloud is secure" means your deployment is secure, and neglecting the customer-owned configuration and identity.
Not knowing where the responsibility line sits for each service model, leaving gaps like an unpatched OS on IaaS or unencrypted data on PaaS.
Focusing security effort on the provider's rock-solid infrastructure while the customer-side misconfigurations go unaddressed.
Treating cloud like the old datacenter perimeter instead of an identity- and configuration-driven model.
Forgetting that data, identity, and access are always the customer's, regardless of service model.

Best Practices

Map the shared-responsibility line explicitly per service you use, so no owned control falls through a gap.
Concentrate defensive effort on the customer side — data, identity, configuration — where breaches actually occur.
Never assume provider security covers your configuration; the public bucket and over-privileged role are yours to prevent.
Treat cloud security as identity- and configuration-centric (Chapter 3), not perimeter-centric.
Know that data, identity, and access remain yours across IaaS, PaaS, and SaaS alike.

Comparable toolsModels AWS/Azure/GCP shared-responsibility modelsFraming security of vs in the cloudTooling CSPM (next topics) — ties to Ch 3, Ch 4

Knowledge Check

Under the shared responsibility model, where do nearly all cloud breaches occur?

On the customer side — misconfiguration and identity
On the provider's own hypervisor and physical datacenters
In the network cables running between the datacenters
Split roughly equally between the provider and customer

What does the customer always own, regardless of IaaS, PaaS, or SaaS?

Their data, identity, and access configuration
The hypervisor and physical hardware
Nothing — SaaS removes all customer responsibility
Only the operating system patches

Why does the cloud's ease of deployment increase breach risk?

Exposing resources is just as trivial — a wrong default breaches
It forces all of your data to be stored unencrypted
It removes any remaining ability to configure access controls yourself
It automatically makes every new resource public

You got correct