The Shared Responsibility Model
A common and dangerous assumption: because my app runs on a cloud provider's infrastructure, the cloud keeps it secure. This assumption is wrong — and it is behind a large share of real breaches. The provider does secure things, but only specific things. The rest is your job.
This arrangement has a name: the shared responsibility model. Security is split between the provider and the customer, and the boundary is clearly defined. Neither side is fully in charge; both sides must do their part or a gap appears.
Think of renting an apartment. The landlord is responsible for the building's structure: the locks on the front door, the fire exits, the plumbing inside the walls. That is their job. But you are responsible for locking your own apartment door, choosing a safe password for your Wi-Fi, and not handing out keys to strangers. The landlord cannot do those things for you — and if you leave your door open, no amount of front-door security will help.
The Provider's Half: Security "of" the Cloud
The cloud provider is responsible for the foundation everything else sits on. That means the physical buildings and data centers — the guards, the badge readers, the fire suppression. It means the hardware: the actual servers, the disks, the network switches. And it means the software layer that lets many customers share the same machines safely, called the virtualization layer. Providers spend heavily on this half; breaches at this layer are rare, and when they do occur, they are the provider's problem to fix.
Your Half: Security "in" the Cloud
Everything you build or configure on top of that foundation is your responsibility. That includes your cloud account credentials — the passwords and login methods that protect your account. It includes access control: deciding who on your team can do what, and setting those rules correctly. It includes configuration: how your storage buckets, databases, and network rules are set up. And it includes your data: what you store, how you handle it, and who can reach it. Most real-world breaches happen here, not in the provider's half.
The Line Moves With the Service
The split is not always in the same place. With a raw virtual machine (IaaS), you manage the operating system and everything on it — the provider only covers the hardware underneath. With a managed database (PaaS), the provider also patches the database software for you, so your slice shrinks. With a finished app you just log into (SaaS), the provider covers almost every technical layer; your job shrinks to managing your account and what you do with the data inside the app. More managed service means the provider handles more — but your security job is never zero.
Where It Goes Wrong
The most common failure is a simple misunderstanding: the customer assumes the provider covers something that actually falls on the customer's side. A storage bucket left publicly readable, a weak password on the admin account, a server configured to allow connections from anywhere — these are customer mistakes, not provider failures. The line is well documented; crossing it unintentionally is how most incidents begin.
- "The cloud is secure, so my stuff is secure." The provider secures the infrastructure. You still have to secure everything you put on top of it — your accounts, access rules, and data are your job.
- "If there's a breach, it must be the provider's fault." The vast majority of cloud incidents are customer misconfigurations on the customer's side of the line, not provider failures.
- "A fully managed service means no security work for me." It means less security work — the provider covers more layers. But your account security, access control, and data handling remain yours. The job shrinks; it never disappears.
- "The split is a technicality that doesn't affect me." This model explains why every other security topic in this chapter is partly your job. It is the foundation everything else rests on.
- This single model explains why every other security topic in this course — access control, encryption, compliance — is at least partly the customer's job, not something the provider handles automatically.
- Knowing which half is yours is the starting point for any honest conversation about cloud security in your organization, whether you are an engineer, a manager, or an auditor.
- Most cloud security advice and most breach post-mortems come back to this model. Fluency here makes all of it readable.
Knowledge Check
In the shared-responsibility model, which side covers the physical data-center buildings and hardware?
- The cloud provider covers physical buildings, hardware, and core network
- The customer — whoever rents the machines covers all physical security
- A third-party auditor who certifies the data center annually
- Neither side — data centers are not considered part of the security model
What does "security in the cloud" refer to in the shared-responsibility model?
- Security the provider enforces at its physical data centers and hardware level
- Your responsibilities: accounts, access controls, configuration, and data
- Encryption the provider automatically applies to data as it travels over the network
- Automated scans the provider runs on your storage buckets on your behalf
When you switch from a raw virtual machine to a fully managed database, how does the shared-responsibility line change?
- The provider covers more layers, so your part shrinks
- The split stays fixed no matter what type of service you use
- You must manage more security because the provider is less involved
- Your responsibility disappears entirely because the provider manages every layer
You got correct