The shared-responsibility model
The cloud provider secures the platform; you secure how you use it — and the line moves with IaaS, PaaS, and SaaS. The dominant failure isn't a 0-day, it's a misconfiguration on your side of the line. Identity is the new perimeter; blast radius is the metric.
A team ships an analytics feature. The data lands in an S3 bucket, the app reads it, everyone moves on. Eight months later a security researcher emails: the bucket is world-readable and has been indexed by a public scanner. Inside are six million customer records. Nobody disabled encryption, nobody got phished, no CVE was exploited — someone left a bucket policy at "Principal": "*" because they assumed the cloud “secures storage.” The provider did secure the disks, the datacenter, and the hypervisor. The bucket policy was never theirs to write. That gap — between what the provider runs and what you configure — is where most cloud breaches actually live.
By the end of this lesson you’ll know exactly where the customer-vs-provider security line sits across IaaS, PaaS, and SaaS, and why a misconfiguration on your side of that line — not a 0-day — is the failure mode you’ll spend your career defending against.
The line, and why it moves
Every major cloud frames security the same way: security of the cloud is the provider’s job; security in the cloud is yours. AWS calls it the Shared Responsibility Model, and Azure and Google publish near-identical versions. The provider owns the physical datacenter, the hardware, the hypervisor, and the managed-service software it runs for you. You own your data, your identities and access policies, your network rules, and — depending on the service — the operating system and application code on top.
The trap is treating that boundary as fixed. It is not: the more managed the service, the more of the stack the provider absorbs, and the less is left to you. That is the entire point of the IaaS → PaaS → SaaS spectrum.
- IaaS (a raw EC2 instance, a bare VM): you get compute, storage, and network primitives. The provider secures the hypervisor and below; everything from the guest OS up is yours — patching, runtime, the app, the data, and the IAM and network config around it.
- PaaS (a managed app platform, a serverless function, a managed database): the provider also runs and patches the OS and runtime. You stop worrying about kernel CVEs, but you still own your code, your data, and — critically — the access and network configuration.
- SaaS (a finished product like a hosted CRM): the provider runs almost the whole stack. Your responsibility shrinks to your data and your identity/access configuration — who can log in, with what permissions, and how.
Notice the one column that never crosses to the provider, at any tier: data and identity are always yours. That is the single most important reading of the whole model.
| Layer | IaaS (raw VM) | PaaS (managed runtime) | SaaS (finished product) |
|---|---|---|---|
| Data (yours) | Customer | Customer | Customer |
| IAM / access policy | Customer | Customer | Customer |
| Network config | Customer | Customer | Provider* |
| Application | Customer | Customer | Provider |
| Runtime | Customer | Provider | Provider |
| Operating system | Customer | Provider | Provider |
| Compute / virtualization | Provider | Provider | Provider |
*In SaaS the provider runs the network, but you still configure tenant-level access and any IP/allowlist settings exposed to you. Data and IAM never cross to the provider at any tier.
Identity is the new perimeter
In a datacenter, the perimeter was a place: a firewall, a VLAN, a locked rack. Inside was trusted, outside was hostile, and “security” largely meant guarding the edge. The cloud erases that geography. Your services, data stores, and management plane are reachable over the internet through APIs, and the only thing standing between a request and your resources is who the request proves it is, and what that identity is permitted to do.
So the perimeter moved. It is no longer a network boundary you can point at — it is the set of identities (users, roles, service accounts, access keys) and the policies attached to them. A leaked access key, an over-permissive IAM role, a service account with *:*, or an unauthenticated endpoint is the breach path. There is no inner network to fall back on. This is why “identity is the new perimeter” is not a slogan — it is a literal description of where the wall is now, and it is why the next unit in this track is about IAM.
The practical consequence is least privilege as a default reflex: every identity gets only the permissions it actually needs, scoped to the specific resources and actions it uses, and nothing more. A wildcard policy is not a convenience — it is a pre-staged breach.
Misconfiguration, not 0-days, is the dominant failure
Here is the senior-level reframe of cloud security. The headlines say “breach,” and you picture a brilliant exploit. The reality is almost always duller and entirely your side of the line: a storage bucket left public, an IAM policy with a wildcard, a database with no auth bound to a public IP, a security group open to 0.0.0.0/0, a secret committed to a repo, default credentials never rotated. Industry post-mortems and cloud-provider guidance converge on the same finding year after year — the overwhelming majority of cloud data exposures trace to customer misconfiguration, not to a vulnerability in the provider’s platform. Gartner’s widely cited framing is that through 2025, the vast majority of cloud security failures will be the customer’s fault. The provider’s side of the line is, frankly, hardened far better than most teams can harden their own datacenter.
That changes where you spend effort. You are not primarily hunting for novel exploits; you are making sure the boring controls are correct and stay correct: every bucket private by default, every IAM policy scoped, every network rule justified, every secret in a secret manager. This is why the rest of this track is about posture — continuously checking that your side of the line is configured the way you think it is — far more than it is about exotic attacks.
▸Why this works
Why is the customer’s side so much weaker than the provider’s, given the same engineers? Because the provider configures one hardened platform millions of times with deep automation and a dedicated security org, while every customer reinvents their config under deadline pressure, with broad defaults that favor “it works” over “it’s locked down.” A new bucket is easy to make public; a new role is easy to grant *. The model doesn’t make you less safe — it hands you a powerful, sharp tool and trusts you to hold it correctly. Most breaches are someone cutting themselves.
Blast radius: the metric that ties it together
Least privilege isn’t an end in itself — it’s how you control blast radius: the scope of damage when (not if) one identity, key, or component is compromised. Assume any single credential will eventually leak. The question that matters is: when it does, how much can the attacker reach?
- A leaked key scoped to read one bucket exposes one bucket.
- A leaked key with
AdministratorAccessexposes the entire account.
Same leak, wildly different outcomes — and the difference is entirely the permissions you granted in advance. This is the through-line for the whole track: IAM scoping, container isolation, infrastructure-as-code reviewed before it ships, and posture scanning all exist to keep blast radius small. You design as if compromise is inevitable, because at scale it is, and you make sure the cost of any single compromise stays contained.
- 01Explain the shared-responsibility model and how the customer-vs-provider line moves across IaaS, PaaS, and SaaS.
- 02Why is 'identity is the new perimeter,' and why is misconfiguration — not a 0-day — the dominant cloud failure mode?
The shared-responsibility model splits cloud security into security of the cloud (the provider’s job: datacenter, hardware, hypervisor, and the managed OS/runtime in higher tiers) and security in the cloud (yours). The line is not fixed — it slides down the stack toward the provider as you move from IaaS to PaaS to SaaS — but two layers never cross: your data and your IAM/access configuration are always yours. Because resources are reachable over APIs with no inner trusted network, identity becomes the new perimeter: a leaked key or over-permissive role is the breach path, so least privilege is the default reflex. And the dominant cloud failure is not a 0-day in the provider’s platform — that side is hardened better than you could manage — but a misconfiguration on your side: a public bucket, a wildcard policy, an open security group. The metric that ties it together is blast radius: you scope every identity and resource as if compromise is inevitable, so that when one credential leaks, it reaches as little as possible. That through-line — least privilege to contain blast radius — is what the IAM, container, infrastructure-as-code, and posture units of this track all build on.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.
Apply this
Put this lesson to work on a real build.