The shared-responsibility model
In your own house, you're responsible for everything: the locks, the wiring, the roof. In a rented apartment, the line splits — the landlord maintains the building structure and the front-door entry system; you're responsible for locking your own unit and not leaving the windows open. The cloud works exactly like the apartment, and the agreement that draws the line is called the shared-responsibility model. Understanding precisely where the line falls is the single most important thing to get right in cloud, because most cloud breaches happen on the customer's side of it — not because the provider failed.
Security of the cloud vs security in the cloud
The model splits all responsibility into two halves with a memorable phrasing:
- The provider is responsible for security of the cloud. That means the physical things and the global machinery you can't touch: the data centers, the buildings' physical security, the power and cooling, the host servers, the virtualization layer (hypervisor), and the network backbone that connects regions. You never patch their hypervisor or guard their building door — that's theirs.
- You, the customer, are responsible for security in the cloud. That means everything you put into and configure on top of the rented resources: your data, who you grant access to, how you configure each service, your operating-system patches (on IaaS), your application code, your network rules, and your encryption choices.
A one-line test: if you can configure it, you own it. The provider hands you a knob; how you turn it is on you.
:::note The most expensive misunderstanding in cloud The classic failure is assuming "it's in the cloud, so the cloud provider secures it." It does not. A storage bucket left open to the public internet, an over-permissive access policy, a database with a default password — these are your configuration, on your side of the line, and they cause the large majority of real-world cloud data leaks. The provider's infrastructure was working perfectly the whole time. :::
The line moves with the service model
Here's the part people miss: the boundary is not fixed. It slides depending on whether you're using IaaS, PaaS, or SaaS — exactly the ladder from the previous lesson. The more the provider manages, the more of the security burden shifts to them, and the less is left to you.
Walk the ladder:
- On IaaS (a bare VM), the provider secures the physical host and below; you own the operating system upward — meaning you patch the OS, secure the runtime, the app, the data, and the access rules. The most on your plate.
- On PaaS, the provider also takes the OS, the runtime, and patching. You're left with your application code, your data, and access configuration.
- On SaaS, the provider runs the whole application too. But notice what never leaves your side, at every level: your data, who has access to it, and your configuration of the service. Those three are always yours.
:::tip The three things that are always yours No matter how managed the service is — IaaS, PaaS, or even SaaS — you are always responsible for: (1) your data, (2) identity and access (who can do what), and (3) service configuration (the settings you choose). These are the durable core of the customer's half, and they're where almost all incidents originate. :::
A concrete walk-through
Say you store customer records in a managed object-storage service (a PaaS-ish storage primitive). Map the responsibilities:
- Provider's job: keep the storage service running, secure the data centers and disks, encrypt data on the physical drives, replicate it so a disk failure doesn't lose it.
- Your job: decide the bucket is not public, attach an access policy that grants only your application read access, enable encryption-at-rest with a key policy you control, and avoid putting secrets in object names. Every one of those is a setting you turn.
If that bucket leaks, it will be because a setting on your side was wrong — public access left on, an access policy too broad — not because the provider's disks failed. That's the model working as designed, and it's why reading the line correctly is a security skill, not a trivia fact.
Why it matters
The shared-responsibility model splits cloud security into security of the cloud (the provider's hardware, network, and virtualization) and security in the cloud (your data, access, configuration, and — depending on the service model — your OS, runtime, and app). The line slides as you move from IaaS toward SaaS: the more managed the service, the more the provider absorbs, but your data, your access control, and your configuration are yours at every level. Internalize the test — if you can configure it, you own it — and you'll correctly predict where responsibility falls for any service you ever meet.
We've now established what the cloud is and who owns what. The next foundational question is where — because "the cloud" is not one place. It's a worldwide grid of regions and availability zones, and where you put things determines their latency, their resilience, and sometimes their legality.
Where this leads: the customer's side of this line — identity, configuration, data — is exactly what Cloud Security (Chapter 8) drills into.