How the Cloud Shared Responsibility Model Divides Security Duties

The Misconfiguration That Exposed 100 Million Capital One Customers

In 2019, a former AWS employee exploited a misconfigured AWS Web Application Firewall in Capital One's cloud environment, accessing personal data of over 100 million US and Canadian customers. AWS's infrastructure was not breached. Amazon's security controls performed as designed. The vulnerability was entirely in Capital One's configuration of AWS services — a misconfigured firewall rule that allowed Server-Side Request Forgery to retrieve IAM credentials from the EC2 instance metadata service.

The Capital One breach became the most cited example of the shared responsibility model's most dangerous gap: customers who misunderstand where their security obligations begin. Gartner predicts that through 2025, 99% of cloud security failures will be the customer's fault — not the provider's. The shared responsibility model defines the boundary precisely, but misunderstanding it has cost organizations billions in breach losses.

The Shared Responsibility Framework

Every major cloud provider formalizes the division of security responsibilities between themselves and their customers. AWS articulates it as security "of" the cloud (provider responsibility) versus security "in" the cloud (customer responsibility).

The provider is responsible for the physical security of data centers, hardware lifecycle management, network infrastructure, and the hypervisor or virtualization layer. These components are invisible to customers and completely within the provider's control. No customer action can compromise the physical hardware rack in an AWS availability zone.

Customers are responsible for everything they configure and manage within the cloud environment — the operating system and patches on their VMs, firewall rules and security group configurations, identity and access management policies, data encryption choices, and application security.

Responsibility by Service Model

SaaS shifts nearly all security responsibility to the provider — but customers retain responsibility for identity and access management (controlling which users have which permissions within the SaaS application) and data governance (what data is stored in the application and who can access it). Misconfigured SaaS permissions — public-sharing settings, overly permissive API keys, or inadequate offboarding procedures — account for significant data exposure even in fully managed applications.

The Most Common Cloud Security Failures

• Publicly exposed storage buckets: S3 buckets, Azure Blob Storage, and Google Cloud Storage with public access enabled have exposed sensitive data from hundreds of organizations; AWS now blocks public access by default at the account level, but misconfigurations persist
• Excessive IAM permissions: Granting users or service accounts admin-level permissions when limited permissions would suffice violates least-privilege and expands breach blast radius — the Capital One breach exploited an overly permissive IAM role attached to an EC2 instance
• Unencrypted data at rest: Failing to enable encryption on databases, storage volumes, and backup snapshots leaves data readable if access controls fail
• Exposed management ports: Security groups with inbound SSH (port 22) or RDP (port 3389) open to 0.0.0.0/0 are continuously scanned and attacked within minutes of configuration
• Disabled logging and monitoring: Without CloudTrail, Azure Monitor, or equivalent audit logging enabled, security events are invisible and forensic investigation after incidents is impossible

Cloud Security Posture Management

Cloud Security Posture Management (CSPM) tools continuously scan cloud environments for security misconfigurations, comparing current configurations against security benchmarks like CIS AWS Foundations Benchmark, NIST 800-53, and PCI DSS. They identify exposed storage, overpermissioned roles, unencrypted resources, and disabled logging across multi-cloud environments in real time.

Zero Trust in the Cloud Context

The shared responsibility model and zero-trust security are complementary frameworks. Zero trust addresses the reality that once an attacker obtains valid cloud credentials — through phishing, credential stuffing, or metadata service exploitation — they can move freely through everything those credentials can access. Zero trust limits blast radius by enforcing least-privilege access, requiring just-in-time credential issuance for sensitive operations, and monitoring all access patterns for anomalies.

AWS IAM's permission boundaries, Azure Privileged Identity Management (PIM), and Google Cloud's Workforce Identity Federation implement zero-trust principles at the cloud identity layer — ensuring that even if one service account is compromised, the damage is bounded to what that account could specifically reach rather than the entire environment.

The shared responsibility model ultimately clarifies accountability rather than reducing the total security work required. Moving to the cloud transfers specific, well-defined security burdens to providers with dedicated security teams, billion-dollar infrastructure investments, and economies of scale that no individual organization can match. What it does not transfer is the responsibility to correctly configure, monitor, and govern cloud resources — work that remains entirely the customer's domain and where the most consequential security failures continue to occur.