The shared-responsibility model in practice
Imagine you've rented a storage unit. The facility owns the building, the perimeter fence, the cameras, and the gate. You own the padlock on your unit — and if you leave it hanging open, the facility's cameras will simply record someone walking off with your boxes. The cameras worked. The fence worked. Your padlock was the failure. That is, almost exactly, how cloud breaches happen: the provider's infrastructure is fine, and your configuration is the open padlock. This lesson turns the shared-responsibility model from Chapter 1 into a working skill — reading the line for any service, and knowing the handful of mistakes that cause the overwhelming majority of incidents.
On-ramp in one breath: the provider secures the cloud; you secure what you put in it. Cloud security is mostly the discipline of getting your settings right, because that's the side where things actually break.
Re-stating the line (and why it's your job)
From Chapter 1: the shared-responsibility model is the agreement that divides security work between the cloud provider and you, the customer.
- Security of the cloud (the provider's job): data centers, physical security, power, the host servers, the hypervisor (the software that slices one physical machine into many virtual ones), and the global network backbone. You cannot touch these and you are not responsible for them.
- Security in the cloud (your job): your data, who can access it, how you configure each service, your OS patches (on a bare VM), your application code, your network rules, and your encryption choices.
The durable test, repeated because it's that important: if you can configure it, you own it. The provider hands you a knob; how you turn it is on you.
:::note Why the line is the whole game Industry breach analyses year after year converge on the same finding: the large majority of cloud security incidents trace to customer-side misconfiguration, not to the provider's infrastructure being compromised. That single fact reframes the entire job. You are not mainly defending against a genius breaking the hypervisor; you are mainly making sure you didn't leave the padlock open. Cloud security is, first, configuration hygiene at scale. :::
The cloud threat model: what actually goes wrong
A threat model is just a structured answer to "what can go wrong, and who could make it go wrong?" You'll meet the full discipline in the Modern Security Engineer Guide; here is the cloud-operations short list — the handful of failure modes behind most real headlines:
- Exposed storage. An object-storage bucket (Ch. 2) set to public, or granted to "everyone," leaking customer data to anyone with the URL. The single most common cloud data leak.
- Leaked credentials. A long-lived access key committed to a Git repo, pasted into a log, or baked into a container image. An attacker who finds it inherits whatever that key can do.
- Over-permissive IAM. A role or user granted far more than it needs — often
*("everything") — so that one compromised identity unlocks the whole account. (The deep dive is 8.2.) - Public databases. A database (Ch. 2) reachable from the open internet, often still on a default or weak password, instead of being locked inside a private subnet.
- Unpatched/known-vulnerable workloads. A VM or container image carrying a publicly-known vulnerability (a CVE — Common Vulnerabilities and Exposures, the public catalog of known security flaws) that was never patched. (The deep dive is 8.6.)
Notice the pattern: every one of these is a setting on your side of the line. None requires the provider to fail. That's why "secure the configuration" is cloud security.
Reading the line for a real service: a traced example
Let's trace one concrete setup the way an operator would, deciding for each layer who owns it. Say you run a web app on a managed container service, with data in object storage and a managed database.
| Layer | Whose responsibility | The actual decision you must make |
|---|---|---|
| Physical hosts, hypervisor, network fabric | Provider | Nothing — you can't configure it. |
| The container runtime / managed control plane | Provider (managed) | Nothing to patch; provider keeps it current. |
| Your container image | You | Use a minimal base, no known CVEs, run as non-root (→ 8.6). |
| IAM role attached to the service | You | Grant only read on the one bucket + connect to the one DB (→ 8.2). |
| Object-storage bucket settings | You | Block all public access; encrypt at rest (→ 8.4). |
| Database network reachability | You | Private subnet only; no public IP; strong/managed credentials (→ 8.5). |
| Secrets the app needs | You | From a secret manager, never in the image or Git (→ 8.4). |
| The provider's data-center guards | Provider | Nothing. |
Walk it: of the eight layers, the provider owns three you can't touch, and you own five — and all five are pure configuration. If this app is breached, it will almost certainly be one of your five rows, set wrong. Reading the table top to bottom before you ship is the core habit; the rest of this chapter is how to get each row right and keep it right.
Why it matters
The shared-responsibility model isn't trivia — it's the map that tells you where your effort goes. Provider-side failures are rare and not your job; customer-side misconfiguration is common and entirely your job. Internalize the test (if you can configure it, you own it), memorize the five recurring failure modes (exposed storage, leaked keys, over-permissive IAM, public databases, unpatched images), and learn to read the responsibility line for any service before you deploy it. Every remaining lesson in this chapter hardens one of those rows.
Common pitfalls
- "It's in the cloud, so it's secure." The provider secures their layer; your bucket being public is your padlock, left open. This assumption is the root of most breaches.
- Assuming "managed" means "secured." A managed database still needs you to keep it off the public internet and use strong credentials. Managed removes patching, not configuration.
- Treating the line as fixed. It slides with IaaS → PaaS → SaaS (Ch. 1). More managed = provider absorbs more — but your data, access, and configuration are always yours.
- Securing only the perimeter and ignoring identity. In the cloud, a leaked key bypasses the network entirely. Identity is the real perimeter (→ 8.2).
Where this connects
- Back to Chapter 1 · Shared responsibility — this lesson is that model turned into an operational checklist.
- Forward to 8.2–8.6 — each failure mode here gets its own hardening lesson.
- Across to the Modern Security Engineer Guide — for formal threat modeling beyond this cloud-ops short list.