“Shared responsibility” is the cloud provider’s contract. They secure the infrastructure; you secure what you deploy on it. Simple in principle. Disastrous in practice because the boundary between “their responsibility” and “yours” is often unclear to the customers — and because almost every major cloud breach happens on the customer side of the line, not the provider side.
Why this happens
Cloud providers advertise “secure by default” as a selling point. This is marketing for infrastructure security (AWS’s datacenters, Microsoft’s hypervisor, Google’s network). It is NOT marketing for your configuration of their services. The provider’s side of the shared responsibility model is genuinely well-protected; AWS hasn’t had a hypervisor compromise in two decades.
Customers misinterpret this. They deploy S3 buckets with public ACLs and think “AWS security is good.” They create IAM users with wildcard permissions and think “AWS IAM is secure.” The provider provided safe primitives; the customer assembled them unsafely.
The boundaries by service type
- IaaS (EC2, VMs): Provider secures hypervisor + hardware. You secure OS, patches, applications, network rules, IAM.
- PaaS (RDS, Cloud SQL, App Service): Provider secures OS + runtime. You secure data, network config, IAM, app code.
- SaaS (O365, Salesforce): Provider secures most. You secure identity, access configuration, sharing settings, your users’ data classification.
The customer’s responsibility shrinks as you move up the stack — but configuration mistakes happen at every layer.
Real incidents on customer side
- Capital One 2019: SSRF + over-privileged IAM role on EC2 → S3 bucket access. Customer configuration, not AWS platform.
- Twilio 2022: Phishing → AWS admin compromise → customer data access. Customer IAM + MFA not configured to modern standards.
- Snowflake 2024 (multiple orgs): Customer accounts without MFA compromised via credential stuffing. Snowflake’s platform wasn’t breached; customer configurations were.
- Numerous S3 data leaks (Verizon, Accenture, Booz Allen Hamilton, FedEx, various US government agencies): public S3 buckets with sensitive data. Provider-offered the “public access” option; customer selected it incorrectly.
What shifts attackers’ attention to cloud
Modern workloads are cloud-native. Modern identities are cloud-native (Entra ID, Okta). Modern data is in cloud storage (S3, GCS, Azure Blob, Snowflake, BigQuery). The attack surface followed.
Attackers don’t need physical access, on-prem footholds, or network position to compromise cloud workloads. A stolen API token, a phished cloud admin, an exposed IAM credential — any of these can give direct cloud access bypassing traditional perimeter defenses.
The “customer blind spots” pattern
- Cloud audit logs not forwarded to SIEM (default retention short)
- IAM permissions reviewed rarely (permissions sprawl for years)
- Defaults remain (AWS S3 encryption, Azure Security Defaults) — often OK, but not audited
- Developer AWS/Azure accounts without governance (shadow cloud)
- Cross-account roles with over-broad trust
- Service principals with wildcard Graph permissions
- No inventory of cloud assets (you can’t protect what you can’t count)
Where the customer actually has to act
- Identity: MFA, PIM, privilege review, service principal lifecycle
- Network: VPC/VNet design, security groups, private endpoints, egress controls
- Data: encryption at rest + in transit, customer-managed keys where warranted, public access controls
- Logging: enabling audit logs, forwarding to SIEM, retention
- IAM: least-privilege, SCPs/Org Policies, role vs user, short-lived credentials
- Posture management: CSPM tools (Wiz, Prisma, Orca, Defender for Cloud) to continuously scan configurations
- Workload protection: CWPP (runtime protection for containers, serverless)
- Secrets: secret manager + rotation + access audit
- Compliance: controls documentation, evidence collection, regular audits
Tools
- Wiz, Orca, Prisma Cloud, Lacework: commercial CSPM + CWPP. Continuous configuration scanning, risk scoring, attack path visualization.
- Microsoft Defender for Cloud, AWS Security Hub, GCP Security Command Center: native. Free baseline; paid advanced features.
- Prowler, ScoutSuite, CloudSploit: open-source auditors. Run against your AWS/Azure/GCP.
- OPA / Conftest / Checkov: policy-as-code for IaC and runtime.
Mindset takeaway
Cloud providers protect their side of the shared responsibility boundary well. Customers routinely fail on their side. Every cloud breach you hear about is almost certainly customer-side. Your job: know where the boundary is for each service you use, and rigorously secure what’s on your side.
The rest of this track dives into specific cloud attack classes: IAM depth, metadata endpoints, cross-account attacks, Kubernetes, serverless, supply chain, data stores, detection gaps, multi-cloud complexity. Each starts with “why does this happen?” before showing techniques.