An AWS environment review reveals an S3 bucket with customer data that had been publicly accessible for eight months. When asked how this happened, the response: "We assumed AWS handled security."
This is the shared responsibility model misunderstanding in action—and it's behind most cloud security incidents.
What the Model Actually Says
Every major cloud provider publishes a shared responsibility model. The summary:
Cloud provider secures: The physical data centers, the underlying hardware, the hypervisors, the managed service infrastructure—everything "below the line" that you never touch.
You secure: Everything you deploy on top. Your configurations, your data, your access controls, your applications, your operating systems (for IaaS), your identity management.
Here's the brutal truth: the cloud provider has extremely strong security for their portion. Your portion is where breaches happen.
| Provider Handles | You Handle |
|---|---|
| Physical security | IAM configuration |
| Hardware | Data encryption |
| Hypervisor | Network security groups |
| Managed service availability | Application security |
| Global infrastructure | Access controls |
| Platform patching (for managed services) | OS patching (for VMs) |
Where Teams Get It Wrong
"We're in the cloud, so we're secure"
Being in AWS, Azure, or GCP gives you access to world-class infrastructure security. It doesn't magically secure your workloads. An S3 bucket is secure by default, but if you override those defaults (as many teams do), you own the consequences.
"We use managed services, so patching is handled"
For fully managed services like Lambda or RDS, the provider handles the underlying infrastructure. But you're still responsible for what runs on them—your code, your database permissions, your API exposure.
For IaaS (EC2, VMs), you're responsible for everything from the operating system up. If you're running unpatched Windows servers in EC2, that's on you.
"We're SOC 2 certified because our cloud provider is"
Cloud providers have impressive compliance certifications. Those certifications cover their infrastructure, not yours. Your SOC 2 audit will assess your configurations, your controls, your evidence—regardless of what the provider certified.
"Default configurations are secure enough"
Defaults prioritize functionality over security. They're designed to let you get started quickly, not to be production-ready. Security groups that are too permissive, logging that's not enabled, encryption that's not enforced—these are your responsibility to configure.
"Serverless means security-free"
Serverless removes infrastructure management but not security responsibility. You still own:
- IAM permissions for your functions
- Input validation in your code
- Secrets management
- API security
- Event source authentication
A Real Incident
A healthcare company deployed their patient portal on AWS. They stored sensitive data in S3 and assumed AWS encryption was automatic. It wasn't—they hadn't enabled server-side encryption. They also hadn't restricted bucket access properly.
A security researcher found the bucket and reported it. The company got lucky—it could have been an attacker.
Remediation required:
- Enabling encryption with customer-managed keys
- Implementing proper bucket policies
- Adding access logging
- Configuring GuardDuty for threat detection
- Training the development team on cloud security
The AWS infrastructure was perfectly secure. The customer configuration was not.
What This Means Practically
Know Your Service Model
Your responsibilities differ based on what you're using:
IaaS (EC2, VMs): You own everything from the OS up—patching, configuration, applications, data, identity.
PaaS (App Service, Elastic Beanstalk): Provider handles the runtime; you own the application code, data, and access controls.
SaaS (Office 365, Salesforce): Provider handles the application; you own user access, data security, and policy configuration.
Serverless (Lambda, Functions): Provider handles execution; you own code security, IAM, and API protection.
Configure Actively
Don't accept defaults. For every cloud resource:
- Enable encryption (at rest and in transit)
- Restrict access to least privilege
- Enable logging
- Review security group rules
- Tag resources for governance
Monitor Continuously
Use cloud-native security tools:
- AWS: Config, GuardDuty, Security Hub, CloudTrail
- Azure: Defender for Cloud, Sentinel, Policy
- GCP: Security Command Center, Policy Intelligence
These tools are cheap relative to the visibility they provide.
Document the Split
For compliance purposes, document explicitly:
- What the provider handles (reference their documentation)
- What you handle (your policies and controls)
- How you verify your responsibilities are met
Auditors will ask.
The Mental Model
Think of cloud computing like renting office space in a building:
The building owner secures the structure—locks on the main doors, security cameras in the lobby, fire suppression systems. They guarantee the building won't fall down.
You secure your office—who has keys, what's in your file cabinets, whether you shred sensitive documents. If someone walks into your unlocked office and takes customer files, that's not the building owner's fault.
Cloud providers secure the building. You secure your office.
Need help understanding your cloud security responsibilities or assessing your configurations? Our cloud security services include shared responsibility model reviews and configuration assessments. Let's talk.
