The Shared Responsibility Model: Where Cloud Security Actually Breaks

The line everyone agrees on and nobody reads

Every major cloud provider publishes a shared responsibility model, and every enterprise cloud contract references one. Almost no breach post-mortem finds the provider at fault. The pattern is consistent: the platform did exactly what it promised, and the customer misconfigured something on their side of the line.

The model is simple to state. The provider secures the cloud — the physical data centers, the hypervisor, the network backbone, the managed service control planes. You secure what you put in the cloud — your data, your identities, your network rules, your operating systems, and every configuration choice you make on top of the platform. The exact boundary shifts by service tier. For raw compute (IaaS) you own the guest OS, patching, and everything above it. For managed databases and serverless (PaaS) the provider absorbs more, but you still own access control, encryption settings, and data classification. For SaaS you own the least, but you still own your accounts and how they are governed.

The trouble is that the line is invisible in day-to-day operations. A developer spins up a storage bucket in thirty seconds; nothing on the screen says "you are now solely responsible for who can read this." That gap between the contractual model and the operational reality is where cloud security actually breaks.

The four failures that cause most cloud incidents

Across cloud incident data — including the misconfiguration and credential-abuse patterns that dominate the Verizon Data Breach Investigations Report and IBM's Cost of a Data Breach research — a small set of customer-side mistakes shows up again and again. None of them are exotic. All of them are preventable.

1. Public storage buckets

Object storage is the most common accidental exposure in the cloud. A bucket gets made public for a legitimate reason — a static website, a partner file drop, a quick test — and then the exposure outlives the reason. Worse, public access is often granted indirectly through a bucket policy or an overly broad access control list rather than a single obvious toggle, so it hides from casual review.

• Enable account-level public-access blocks so a single bad object policy cannot expose data by itself.
• Default every bucket to private and require an explicit, reviewed exception to open one.
• Turn on default encryption and access logging so you can prove who read what.

2. Over-permissioned IAM

Identity is the real perimeter in the cloud, and it is routinely too generous. Roles get created with wildcard permissions because it was faster than scoping them, service accounts accumulate rights they used once and never gave back, and "temporary" admin grants become permanent. When an attacker phishes one set of credentials or finds one leaked key, the blast radius is defined by whatever that identity was allowed to touch — which is usually far more than the job required.

• Grant least privilege and review entitlements on a schedule, not just at creation.
• Eliminate standing administrative access in favor of just-in-time elevation.
• Watch for permission creep on machine identities, which now outnumber humans in most cloud estates by a wide margin.

3. Unrotated and long-lived keys

Static access keys are cloud security's version of a spare key left under the mat. They get committed to source repositories, pasted into config files, embedded in container images, and shared in chat — and because they rarely expire, a key leaked two years ago can still work today. Secret-scanning services find millions of exposed credentials in public code every year.

• Prefer short-lived, federated credentials and workload identity over static keys wherever the platform supports it.
• Rotate any key that must exist, automatically, on a fixed interval.
• Scan code, images, and infrastructure templates for embedded secrets before they ship, and vault the secrets that remain.

4. Wide-open security groups

Network rules drift toward permissive because permissive is convenient. A firewall rule opened to 0.0.0.0/0 (the entire internet) to unblock a debugging session stays open. Management ports — SSH on port 22, RDP on port 3389, database ports — end up reachable from anywhere, and automated scanners find them within minutes of exposure.

• Never expose management ports to the internet; put them behind an identity-aware proxy or a bastion.
• Default-deny inbound, and justify every open rule against a named service.
• Continuously scan your own external footprint so you see what attackers see.

Closing the gap: CSPM, CIEM, and CWPP

Human review does not scale to thousands of resources that change hourly across multiple accounts. Three categories of tooling automate the customer side of the responsibility line, and they are complementary rather than competing.

• CSPM — Cloud Security Posture Management. Continuously inspects configurations against benchmarks and your own policy: public buckets, unencrypted volumes, open security groups, disabled logging. It answers "is anything misconfigured right now?" and, better, prevents drift by flagging changes as they happen. This is the backbone of cloud security posture management and the single highest-leverage control for the failures above.
• CIEM — Cloud Infrastructure Entitlement Management. Focuses on identities and permissions. It maps who can do what, surfaces unused and excessive entitlements, and drives roles toward least privilege — the direct antidote to over-permissioned IAM and orphaned keys.
• CWPP — Cloud Workload Protection Platform. Protects the running workloads themselves: vulnerability and configuration state of virtual machines, containers, and functions, plus runtime detection of malicious behavior. It covers the OS-and-up layer that the provider explicitly leaves to you.

Used together, CSPM tells you the environment is configured safely, CIEM tells you the right people and services have the right access, and CWPP tells you the workloads themselves are hardened and behaving. That trio maps cleanly onto the customer side of the model. It is a core part of how we run cloud security for clients: posture, entitlements, and workload protection under one continuously monitored program rather than three disconnected dashboards.

The multi-cloud consistency problem

Most organizations are now multi-cloud, whether by strategy or by acquisition and shadow IT. Each provider implements the same concepts with different names, defaults, and blind spots. A security group in one cloud is a network security group or firewall rule in another; an IAM role means subtly different things in each; a control that is on by default in one platform is off in the next. Teams that manage each cloud with native, provider-specific tooling end up with inconsistent policy and gaps at the seams — exactly where attackers probe.

The fix is a single policy expressed once and enforced everywhere:

1. Define one control baseline — encryption, logging, public-access rules, identity standards — independent of any provider.
2. Enforce it with tooling that spans clouds, so "no public buckets" and "no internet-facing management ports" mean the same thing in every account.
3. Normalize findings into one prioritized view instead of three consoles with three severity scales.
4. Extend consistent access control to users and workloads with a unified layer such as secure access service edge, so identity and network policy do not fragment per cloud.

Consistency is what turns multi-cloud from a multiplied attack surface back into a manageable one.

Own your side of the line

The shared responsibility model is not a trap; it is a clear contract. The provider holds up its end almost without exception. Breaches happen on the customer side, in the configurations and identities you control — and those are precisely the things automated posture, entitlement, and workload tooling are built to keep in check.

If you are not certain what is public, who is over-permissioned, or which keys have not rotated this year, that uncertainty is the finding. intSignal runs continuous cloud security posture, entitlement, and workload monitoring across single and multi-cloud environments so the customer side of the line stops being the weak one. Talk to our cloud team for a posture assessment that shows you exactly where your side breaks — before someone else finds it.