One of the most common and dangerous misconceptions among students moving into cloud computing is the belief that once an application is hosted on AWS, Azure, or Google Cloud, security becomes the provider's problem. In reality, cloud security works on a Shared Responsibility Model - and misunderstanding exactly where that line sits has caused some of the most damaging breaches of the past decade.
What the Shared Responsibility Model Actually Says
Every major cloud provider splits security obligations into two categories:
Security "IN" the Cloud (the customer's job): data classification, identity and access management, application-level security, network configuration (firewalls/security groups), and encryption of the customer's own data.
How the Split Changes by Service Model
| Service Model | Example | Customer Responsibility |
|---|---|---|
| IaaS (Infrastructure as a Service) | AWS EC2, Azure VMs | OS patching, network config, app security, data - nearly everything above the hardware |
| PaaS (Platform as a Service) | AWS Elastic Beanstalk, Azure App Service | Application code, data, access control - the provider manages the OS/runtime |
| SaaS (Software as a Service) | Google Workspace, Microsoft 365 | Mostly just your own data, users, and access settings |
The lower the service model (IaaS), the more security responsibility sits with the customer. This single fact is exactly what catches so many companies off guard.
Real-World Case Study: The 2019 Capital One Breach
This is a textbook shared-responsibility failure. AWS was responsible for, and correctly maintained, the security of the underlying cloud infrastructure itself - the physical data centers, the hardware, the core network. Capital One was responsible for how its own WAF was configured, how its IAM roles and permissions were scoped, and how its S3 buckets were secured - and a misconfiguration on Capital One's side of that line is what an attacker exploited. No AWS infrastructure vulnerability was involved.
Practical Lessons for Anyone Building on the Cloud
- Never assume the provider secures your configuration. IAM roles, storage bucket permissions, security groups, and WAF rules are always the customer's responsibility to configure correctly.
- Apply least privilege to every role and credential. A compromised component should never have broad standing access to unrelated resources.
- Regularly audit storage bucket and database permissions. Publicly-exposed or overly-permissive storage buckets remain one of the most common real-world cloud misconfigurations found in security assessments today.
- Restrict access to cloud metadata services where possible, since they can be a powerful pivot point for attackers, exactly as seen in the Capital One case.
A Simple Way to Remember the Split
A commonly used analogy: think of a cloud provider like a landlord of a secure apartment building. The landlord is responsible for the building's structure, the front gate, and the security cameras in common areas (security of the cloud). But whether you lock your own apartment door, who you give a key to, and what you leave visible through your window is entirely on you (security in the cloud). A break-in through your own unlocked door isn't a building security failure - and a breach through a customer misconfiguration isn't a cloud provider failure either.
Key Takeaways
- Cloud security is shared: the provider secures the underlying infrastructure, the customer secures their own configuration, access, and data.
- The lower the service model (IaaS vs PaaS vs SaaS), the more security responsibility falls on the customer.
- The 2019 Capital One breach - caused by a misconfigured WAF and overly-permissive IAM role, not an AWS infrastructure flaw - is one of the clearest real-world examples of this line in practice.
- Regular configuration audits, least-privilege access, and careful IAM design are non-negotiable skills for anyone working with cloud infrastructure.
