Cloud Models and Shared Responsibility
The breach that starts with "we thought AWS handled that."
What you will learn
- -Tell IaaS, PaaS, and SaaS apart by what you have to patch
- -Draw the line between provider duty and customer duty for a given service
- -Predict where the exploitable gap sits before you touch a cloud target
Half the cloud breaches you read about trace back to one sentence in a meeting: "we thought the provider handled that." They did not. The provider secured the data center, the hypervisor, and the physical disks. The customer left an public and a database open to the internet. Both were doing their jobs. Nobody was doing the customer's job.
That gap has a name. The is the contract, usually a diagram, that says who patches what. AWS, Azure, and Google all publish one. They differ in the details, but the shape is the same: the provider secures the cloud, you secure what you put in it.
Where the line falls depends entirely on the service model. That is the thing most people skip, and it is the thing that decides where you attack or defend.
The three models, by who patches the OS
Forget the marketing definitions. The useful question is: when a kernel CVE drops, who reboots the box?
With (EC2, Azure VMs, GCE) it is you. You rent a virtual machine and the provider hands you a running OS. Everything above the hypervisor is yours: the OS patches, the rules, the keys, the app, the data. The provider guarantees the metal and the fabric underneath. This is the most and the most rope to hang yourself with.
With (App Engine, Elastic Beanstalk, Azure App Service, ) the provider patches the OS and the runtime. You bring code and configuration. You still own your app's logic, its dependencies, its , and its permissions. A vulnerable npm package in your Lambda is your problem, not Amazon's.
With (Microsoft 365, Salesforce, Google Workspace) you own almost nothing technical. You own the data you put in and, critically, the access configuration. The Capital One and countless M365 were not the vendor's code breaking. They were customer-side settings: over-broad sharing, weak conditional access, an account with no .
No matter the model, you always own your data, your identities, and your access management. The provider will never fix a permission you set wrong. Read that twice, because it is the source of most real-world cloud compromise.
Why an attacker cares about the model
The model tells you where the soft spots are before you send a single . Against an IaaS target, unpatched OS services and exposed management are live because the customer owns patching. Against SaaS, there is no OS to , so the game is : phished sessions, theft, misconfigured sharing.
Map it fast. See a raw VM with SSH on the internet? That is IaaS, and the customer's patch discipline is fair game. See a managed with no to reach? That is PaaS or SaaS, and you pivot to IAM and app logic.
Enumerating a cloud tenant, even just reading its public config, is testing you must be contracted to do. Cloud accounts belong to a company and often carry data from thousands of users. Practice on your own free-tier account or a lab like flAWS.cloud or CloudGoat. Do not point these ideas at a tenant you were not hired to assess.
The trap for defenders is assuming a managed service is a secure service. Moving a database to RDS patches the engine for you. It does nothing about the you left wide open, the master in a Git repo, or the snapshot you shared publicly. Managed means the provider handles their layer. Yours is still yours.
Your company runs its app on AWS Lambda (PaaS). A critical CVE is announced in the Node.js runtime. Who is responsible for patching it?
Pick one service you use (say, an S3 bucket, an EC2 instance, and a Salesforce org). For each, write two lists: what the provider secures and what you secure. If you cannot fill in the customer column, you have found your blind spot.