Shared Responsibility: What Cloud Security Actually Covers

"We're on the cloud, so security is handled" is one of the more expensive misunderstandings in modern IT. Every major cloud provider operates on a shared responsibility model — and the provider's half is narrower than most customers assume.

Where the line actually sits

Cloud providers are generally responsible for security of the cloud: physical data center security, the hypervisor, the underlying network infrastructure. Customers are responsible for security in the cloud: how data is configured, who has access, which services are exposed publicly, and whether identity and access controls are set up correctly. The provider secures the building; you're still responsible for locking your own door.

Why this keeps causing breaches

The overwhelming majority of publicly disclosed cloud security incidents trace back to customer-side misconfiguration, not a flaw in the provider's infrastructure:

• Storage buckets left publicly accessible — a default or forgotten setting exposing files to anyone with the URL.
• Overly broad identity permissions — a service account or user with far more access than its actual job requires, so a single compromised credential exposes everything.
• Unmonitored administrative activity — cloud environments log extensively by default, but logs no one reviews don't prevent anything.
• Unpatched customer-managed components — the provider secures the platform; software you deploy on top of it is still your responsibility to patch.

Practical starting points

1. Know exactly what's public-facing in your environment — not what you think is public, what actually is.
2. Apply least-privilege access: permissions should map to what a role actually needs, not the broadest option that "just works."
3. Enable and actually review logging and alerting for administrative changes, not just application errors.
4. Treat cloud configuration as code that gets reviewed, not a one-time setup you never revisit.

The audit question worth asking

For a business evaluating its own cloud posture, the useful question isn't "is our provider secure" — it almost certainly is, at the infrastructure layer. The useful question is "if someone got a single set of valid credentials, what could they actually reach?" That answer is usually more revealing than any compliance checklist.