Every cloud relationship is a rental. You are renting compute, storage, network, and sometimes the application itself. The thing you are not renting is responsibility for the data inside — that always stays with you. Everything between the bare metal and your data gets divided according to which service model you chose.
The model has a name — the shared responsibility model — but it is really just the cloud version of a question every IT contract has had to answer: if this breaks, whose job was it to prevent that? The reason cloud breaches read like they do — an exposed bucket here, a leaked API key there — is that the answer to that question is not always what the customer thought it was.
The interactive line
Click a service model. The stack below redraws to show which layers the provider owns, which you own, and which are shared. Click any layer to read what that ownership actually means in practice, including a representative incident where someone got the line wrong.
Comparison at a glance
The same nine layers viewed across all five models. The columns get bluer as you move right — more of the stack becomes the provider's job. But the bottom row, your data, never changes color. That is the rule the whole model rests on.
| Layer | On-Prem | IaaS | PaaS | FaaS | SaaS |
|---|
Misread contracts — the breach pattern
Cloud breaches that hit the news rarely involve an exotic exploit. They almost always involve a layer the customer assumed the provider was protecting. Each of these is the same story told four different ways:
Capital One
A misconfigured WAF on an EC2 instance let an attacker reach the instance metadata service and steal credentials for a role with read access to ~100 million customer records in S3.
Verizon / Nice Systems
A third-party vendor stored ~14 million customer call records in an S3 bucket that was set to publicly readable. Nothing was exploited — a researcher just listed the bucket.
Microsoft Storm-0558
A stolen Microsoft consumer signing key was used to forge tokens for Exchange Online and Outlook.com accounts. Federal agency mailboxes were accessed.
ChaosDB (Cosmos DB)
A vulnerability in the Jupyter Notebook feature of Azure Cosmos DB allowed cross-tenant access to other customers' databases via the primary keys.
Reading the contract
Every major provider publishes a shared responsibility matrix. They look slightly different and use slightly different vocabulary, but they answer the same nine questions. When you adopt a cloud service, the first thing to do — before the first VM, before the first deployment — is read that matrix for the specific service you are about to use.
There is one more rule worth memorizing: data classification, access control, and identity are always yours. They are yours under On-Prem, IaaS, PaaS, FaaS, and SaaS. They were yours before cloud existed. The line slides through every other layer, but never through those three.
The shared responsibility model is not a technical control — it is a contract. It does not prevent any breach; it only tells you whose mistake the breach was.
Most cloud breaches happen on the customer side of the line, not because the customer side is intrinsically weaker, but because customers underestimate how much of the line is theirs. Reading the matrix for every service before deploying it is the single highest-leverage habit you can build for cloud security.
One rule above all the others: identity, access, and your data are always yours. Everything else negotiates.
References
Formatted in APA 7. Pattern: Author(s). (Year). Title (Identifier). Publisher. URL. Alphabetized by first author's last name.
- Amazon Web Services. (n.d.). Shared responsibility model. https://aws.amazon.com/compliance/shared-responsibility-model/
- Cloud Security Alliance. (n.d.). Cloud Controls Matrix (CCM). https://cloudsecurityalliance.org/research/cloud-controls-matrix/
- Google Cloud. (n.d.). Shared responsibility and shared fate on Google Cloud. Google Cloud Architecture Framework. https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate
- Mell, P., & Grance, T. (2011). The NIST definition of cloud computing (NIST Special Publication No. 800-145). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-145
- Microsoft. (n.d.). Shared responsibility in the cloud. Microsoft Learn. https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
- Microsoft Security Response Center. (2021, August 27). Coordinated disclosure of vulnerability in Azure Container Instances Service. https://msrc.microsoft.com/blog/2021/08/coordinated-disclosure-of-vulnerability-in-azure-container-instances-service/
- Microsoft Security Response Center. (2023, September 6). Results of major technical investigations for Storm-0558 key acquisition. https://msrc.microsoft.com/blog/2023/09/results-of-major-technical-investigations-for-storm-0558-key-acquisition/
- Oracle. (n.d.). Security overview: OCI shared security model. Oracle Cloud Infrastructure Documentation. https://docs.oracle.com/en-us/iaas/Content/Security/Concepts/security_overview.htm
- U.S. Department of Justice. (2019, July 29). Seattle tech worker arrested for data theft involving large financial services company [Press release]. United States Attorney's Office, Western District of Washington. https://www.justice.gov/usao-wdwa/pr/seattle-tech-worker-arrested-data-theft-involving-large-financial-services-company