Securing the cloud: a 2024 framing of shared responsibility
The shared-responsibility model isn't ambiguous - it's just frequently unread. A practical map of what AWS, Azure, and GCP own versus what you own, and the three architectural patterns that move the needle for mid-market customers.
The shared-responsibility split, in plain terms
Cloud providers secure the infrastructure they run. You secure everything you put on top of it - identity, data, configuration, workloads. AWS, Azure, and Google Cloud all publish near-identical matrices to make this explicit; the matrices have not changed materially in five years.
Most of the breaches we triage are not "cloud provider failures." They are misconfigured customer-owned controls running on a perfectly secure platform.
Who is responsible for what
The same matrix, in plain language, across all three major providers:
| Layer | Cloud provider | You |
|---|---|---|
| Physical / hardware / hypervisor | Owned | N/A |
| Provider-side network controls | Owned | Configured |
| Operating system (IaaS) | No | Owned |
| Identity & access management | Service | Owned |
| Data classification & encryption | No | Owned |
| Workload & app security | No | Owned |
| Logging, detection & response | Service | Owned |
The model isn't ambiguous - it's just frequently unread. AWS, Azure, and GCP all publish a clear matrix. Breaches in the customer-owned rows aren't "cloud failures" - they're configuration choices that the provider's matrix already warned against.
Three architectural patterns that earn their keep
The three patterns below align with NIST SP 800-207 (Zero Trust Architecture) and the CISA Cloud Security Technical Reference Architecture. They're not novel; they're the consensus of the past five years of cloud security research.
Identity as the perimeter, not the network
The network boundary is dead. Authentication and authorization are the real perimeter. Invest in your identity provider, not your VPN. Every request - human or service - authenticates and is authorised against policy. This is NIST SP 800-207's central tenet.
Infrastructure-as-code with policy-as-code
If your infrastructure isn't defined in code, you can't audit drift. If your policies aren't defined in code, you can't enforce them consistently. Pair Terraform/OpenTofu/Pulumi with Open Policy Agent (Rego) or HashiCorp Sentinel and run the policy check in CI before merge.
Default-deny networking
Within your cloud account, start with no traffic allowed and add explicit rules. The opposite - default-allow with exception rules - accumulates exceptions over years until everything is allowed. CISA's reference architecture recommends this as a baseline.
Maturity by control area (engagement data)
Startups vs enterprises vs mid-market
The same controls scale poorly in two directions: startups skip them; enterprises drown in them. The mid-market sweet spot - which is where we see the most predictable outcomes - is to apply these patterns rigorously but only to your top three risks, not to everything.
| Dimension | Startup | Mid-market | Enterprise |
|---|---|---|---|
| Identity strategy | Ad-hoc | Centralised IdP (Okta/Entra) | Federated IdP + SCIM |
| Network defaults | Default-allow | Selective deny | Default-deny + microseg |
| Policy-as-code | None | OPA in CI | Multi-tenant policy |
| Logging retention | 7-30 days | 90 days | 1+ year, SOC-piped |
| Incident response | Reactive | Documented IR plan | SOC integrated, table-tops |
Most of the breaches we triage are not "cloud provider failures." They are misconfigured customer-owned controls running on a perfectly secure platform. The vendor did their part - and published the matrix that says so. The customer did theirs, just not all of it.
- Staatse cloud incident retrospective, 2024
Key takeaways
- The cloud provider isn't going to breach you - the misconfiguration in your half of the matrix will. Every breach this year proves the point.
- Identity is the perimeter now (NIST SP 800-207). If your IdP isn't your strongest control, your architecture is upside-down.
- IaC + policy-as-code together is what makes the rest auditable. Without them, drift wins within 90 days.
- Pick three risks and apply rigour there. Trying to harden every layer to enterprise depth is how mid-market teams drown.
Closing
If you'd like a structured opinion on which three to start with for your environment, our cloud pen-test includes that scoping conversation. Two-week fixed scope, fixed quote. Get in touch.
References & further reading
- AWSShared Responsibility Model
- Microsoft AzureShared responsibility in the cloud
- Google CloudShared responsibilities and shared fate on Google Cloud
- NISTSP 800-207: Zero Trust Architecture
- Open Policy AgentOPA documentation and Rego policy language
- HashiCorpSentinel - policy as code framework
- IBM SecurityCost of a Data Breach Report 2024 - cloud breach analysis
- CISACloud security technical reference architecture