Shared Responsibility Model: Who Secures What in the Cloud
The shared responsibility model defines the security boundary between cloud providers (security OF the cloud) and customers (security IN the cloud) — and why CSPM exists in this gap.
What is the Shared Responsibility Model?
The shared responsibility model is the framework that defines who is responsible for what in cloud security. Cloud providers (AWS, GCP, Azure) are responsible for security of the cloud — the physical infrastructure, hypervisors, networking hardware, and managed service internals. Customers are responsible for security in the cloud — their configurations, data, access management, and application code.
This division means that when a data breach occurs due to a misconfigured S3 bucket, it’s the customer’s responsibility — not AWS’s. AWS secured the infrastructure that runs S3. The customer chose to make the bucket public.
Why It Matters
The shared responsibility model creates the exact gap that CSPM tools exist to fill.
Most cloud security incidents aren’t sophisticated hacking — they’re configuration mistakes made by customers in the portion of the stack they’re responsible for. Public storage buckets. Overly permissive IAM roles. Unencrypted databases. Security groups open to the internet. Every one of these is the customer’s responsibility, and every one is preventable with proper configuration management.
The challenge is that cloud providers give you the tools to be secure, but they don’t enforce security by default. AWS gives you S3 Block Public Access, but you have to enable it. GCP gives you Organization Policy constraints, but you have to configure them. The shared responsibility model means the provider builds the lock — you have to turn it.
How It Works / Key Concepts
The Boundary
| Layer | Provider Responsibility | Customer Responsibility |
|---|---|---|
| Physical infrastructure | Data centers, power, cooling, physical security | Nothing |
| Network infrastructure | Global backbone, DDoS protection, hardware firewalls | VPC design, security groups, NACLs |
| Hypervisor/compute | EC2 hypervisor security, hardware | OS patching, security agents, instance configuration |
| Managed services | Service availability, internal security | Configuration, access control, encryption settings |
| Data | Storage durability | Classification, encryption, access policies |
| Identity | IAM service availability | User management, policies, MFA, key rotation |
How Responsibility Shifts by Service Type
The customer’s responsibility scope changes based on the service model:
IaaS (EC2, GCE, Azure VMs) — Customer manages everything from the OS up: patching, hardening, application security, data.
PaaS (RDS, Cloud SQL, App Engine) — Provider manages the OS and runtime. Customer manages configuration, access, and data.
SaaS (S3, DynamoDB, BigQuery) — Provider manages almost everything. Customer manages access policies, encryption settings, and data classification.
The higher up the stack, the less the customer manages — but configuration responsibility never disappears entirely.
Common Misconceptions
”My data is in AWS, so AWS secures it.” — AWS secures the infrastructure your data runs on. You secure access to the data itself.
”We passed the AWS Well-Architected Review.” — The review is advisory. It doesn’t continuously monitor for drift or new misconfigurations.
”Our provider is SOC 2 compliant.” — Their SOC 2 covers their controls (physical security, hiring, internal processes). Your SOC 2 audit evaluates your configurations.
”Managed services are fully managed security.” — RDS manages patching, but you still control who can connect, whether encryption is enabled, and whether backups are configured.
Why CSPM Exists in This Gap
CSPM tools continuously verify that the customer is meeting their side of the shared responsibility model. Every CSPM check maps to a customer responsibility: Is encryption enabled? Are security groups restrictive? Is logging configured? Are IAM policies least-privilege?
Without CSPM, organizations rely on manual reviews, point-in-time audits, or hoping nobody made a mistake. CSPM automates the ongoing verification.
How Kloudle Helps
Kloudle automates your side of the shared responsibility model — 1,890 checks across AWS, GCP, Azure, DigitalOcean, and Kubernetes verify that your configurations meet security best practices. Everything your cloud provider expects you to manage is continuously monitored. With sovereign deployment at $5K/year fixed pricing, you fulfill your security responsibilities without creating new ones by sharing posture data with yet another vendor.
Related Terms
- What is CSPM? — The tool category that fills the shared responsibility gap
- What is Cloud Misconfiguration? — Customer-side failures in the model
- What is Sovereign CSPM? — Meeting responsibilities without creating new vendor dependencies