There is a persistent gap between how secure cloud platforms are and how secure cloud deployments turn out to be. The hyperscalers operate physical and hypervisor security at a standard almost no organisation could replicate. Yet cloud data breaches are unremarkable events, and the overwhelming majority trace back to configuration, identity and exposure decisions made by the customer.
Understanding why requires taking the shared responsibility model seriously rather than treating it as a diagram in an onboarding deck.
The line, and how it moves
The provider secures the infrastructure of the cloud. The customer secures what they put in it. The complication is that the boundary shifts depending on the service model, and teams frequently apply assumptions from one to another.
- Infrastructure as a service. The provider handles physical security, hardware and the hypervisor. Everything above — guest operating system, patching, runtime, application, network configuration, identity and data — is yours.
- Platform as a service. The provider additionally manages the operating system and runtime. You retain the application, its configuration, access control and data.
- Software as a service. The provider runs nearly everything. You still own identity, access, data classification and sharing settings — which is precisely where SaaS incidents concentrate.
Two things are yours in every model without exception: identity and access management, and data. Not coincidentally, that is where breaches happen.
Why configuration replaced exploitation
Traditional infrastructure had a natural safety property: a mistake was usually contained by a network perimeter. A misconfigured internal server was still behind a firewall.
Cloud removes that cushion. A storage bucket’s access policy is the perimeter. A single boolean, changed by anyone with permission, can move a dataset from private to globally readable with no exploit, no malware and no alert — because from the platform’s perspective nothing went wrong. The API call was authorised and succeeded.
The velocity compounds it. Infrastructure that once took a procurement cycle now takes an API call, and the number of people able to make that call is far larger than the number who could once rack a server.
Identity is the real perimeter
In cloud environments almost every action is an authenticated API call, which makes the identity layer the primary control plane and the primary target. Several failure patterns recur:
- Over-permissive roles. Wildcard permissions granted during troubleshooting and never revoked. The gap between permissions granted and permissions used is usually enormous, and every unused permission is available to whoever compromises the identity.
- Long-lived static keys. Access keys embedded in code, container images and CI variables. They do not expire, they are copied freely, and they are what credential-scanning bots hunt for in public repositories continuously.
- Privilege escalation paths. Permissions that appear modest but allow escalation — the ability to modify a role policy, attach a policy to oneself, or pass a privileged role to a compute service. These rarely appear in a permissions review because each looks innocuous alone.
- Machine identity sprawl. Service accounts and workload identities now vastly outnumber humans, rotate less, are monitored less, and are frequently over-privileged because scoping them precisely is tedious.
The structural fix is to eliminate static credentials wherever the platform allows. Workload identity federation lets a compute resource or CI pipeline obtain short-lived credentials from its own verified identity, removing the secret that would otherwise be stolen.
The metadata service and SSRF
One cloud-specific attack path deserves singling out. Instances retrieve their credentials from a link-local metadata endpoint reachable only from the instance itself. That is convenient, and it means any server-side request forgery vulnerability in an application running on that instance can be turned into credential theft: the attacker induces the application to request the metadata endpoint and return the response.
This converts a bug class usually rated medium severity into full compromise of whatever the instance role can do. Mitigations exist and should be treated as mandatory: require session-oriented metadata requests that a naive SSRF cannot perform, limit the response hop count so proxied requests fail, and scope instance roles tightly so that a stolen credential is worth as little as possible.
Logging is opt-in, and defaults are short
Cloud platforms can produce excellent telemetry, but much of it is disabled or minimally retained by default. Management-plane audit logs typically record API calls including caller identity and source address; data-plane logging, which records access to individual objects, is frequently off because it costs more.
The consequence surfaces during an incident. Determining whether an exposed bucket was actually accessed, and by whom, requires data-plane logs that were never enabled. The investigation ends at “we cannot rule it out”, which is also what has to be written in the regulatory notification.
Enable management-plane logging across every account and region, ship it somewhere the compromised account cannot delete it, and enable data-plane logging on anything holding sensitive data before you need it.
Cloud audit logs are timestamped in UTC and network exposure questions come down to CIDR ranges.
Multi-account structure as a control
The most effective architectural decision available is separating workloads into distinct accounts or subscriptions — production from development, sensitive from general. Account boundaries are the strongest isolation the platform offers, considerably stronger than tags or naming conventions inside one account.
It limits blast radius: a compromised development credential cannot reach production because the permission does not exist across the boundary. It makes least privilege tractable, because scoping to an account is simpler than scoping to resource patterns. And organisation-level guardrails can enforce invariants centrally — preventing the disabling of audit logging, or the creation of public storage — in a way individual teams cannot override.
Practical priorities
For teams wanting an ordered list rather than a framework:
- Enable and centralise audit logging in every account and region, delivered to an account with restricted access.
- Eliminate long-lived keys. Move to federated workload identity and short-lived credentials.
- Enforce phishing-resistant MFA on all human access to the control plane, especially root and break-glass accounts.
- Find public exposure systematically — storage, databases, management interfaces — and confirm each instance is intentional.
- Right-size permissions using access-analysis data showing which granted permissions are actually used.
- Encrypt with customer-managed keys for sensitive data, so key policy provides a second authorisation layer.
- Apply organisation-level guardrails that individual accounts cannot bypass.
- Monitor for drift, because the risk is not the initial deployment but the change made six months later.
The mental adjustment
The hardest part of cloud security is not any individual control. It is recognising that the failure mode has changed. On-premises security was largely about keeping attackers out of a network. Cloud security is largely about ensuring that authorised API calls are only made by the right identities for the right reasons — because the attacker’s goal is no longer to breach a perimeter but to obtain a credential and then behave, from the platform’s perspective, entirely legitimately.
That is why identity hygiene and configuration discipline outrank almost everything else, and why the provider’s excellent infrastructure security cannot save a deployment that grants too much to too many.
The misconfigurations that actually cause incidents
Generic advice about least privilege is easy to agree with and hard to act on. These are the specific patterns that recur in real cloud breach reports.
- Storage exposed to the public internet. Still the most common single cause of cloud data exposure. Modern platforms provide account-level settings that block public access regardless of individual object policies — enable them centrally rather than relying on per-bucket correctness.
- Databases and caches reachable from anywhere. Managed database services with a public endpoint and a permissive security group, frequently created during development and never restricted. Search engines index these continuously.
- Management interfaces open to the internet. SSH and RDP exposed to 0.0.0.0/0. Session-based access services remove the need for this entirely, and remove the credential from the equation.
- Overly broad trust policies. Roles that any account can assume, or that trust an entire external service without a condition scoping it to your resources. The condition is what prevents a confused-deputy problem, and it is routinely omitted.
- Serverless functions with excessive roles. Functions frequently inherit a role broad enough for the whole application rather than the specific action they perform, so a code-injection flaw in one function grants everything.
- Snapshots and images shared publicly. Disk snapshots made public, containing entire filesystems including credentials.
What unites them is that each is a single setting, each is authorised, and none generates an alert unless you configured one.
Detection in the control plane
Cloud detection works on API calls rather than processes, and a compact set of events carries most of the value:
- Audit logging disabled or a trail deleted. The cloud equivalent of clearing event logs, and rarely legitimate.
- Identity changes: policy attachments, new access keys created, role trust modified, a new identity provider federated. These are how access is made durable.
- Public exposure introduced: a bucket policy opened, a security group changed to allow the world, a snapshot shared.
- Credential use anomalies: instance role credentials used from outside the platform’s address ranges — a strong indicator of stolen metadata credentials — or an identity calling services it never has before.
- Encryption key policy changes, and bulk decrypt calls that do not match normal workload patterns.
- Reconnaissance patterns: a burst of list and describe calls across many services, which is what an adversary does immediately after obtaining credentials.
The last one is particularly useful because it is early. Enumeration precedes action, and an identity suddenly describing every resource in the account is behaving unlike any legitimate workload.
Guardrails beat audits
Periodic configuration review finds problems weeks after they appear. Preventive controls stop them existing. Where the platform supports organisation-level policy that member accounts cannot override, the highest-value invariants to enforce are: audit logging cannot be disabled, storage cannot be made public, regions outside your footprint cannot be used, and root account use is blocked outside break-glass.
Pair that with policy-as-code in the deployment pipeline, so a template creating a public database fails review before it reaches an account at all. The combination — prevention at deployment, invariants at the organisation level, detection for what slips through — is what makes cloud configuration tractable at scale, because it removes reliance on every engineer getting every setting right every time.