Why cloud storage keeps getting exposed

Is misconfigured storage still the most common cloud incident?

Publicly reachable data remains one of the most frequently reported causes of cloud data loss, and the reason it persists is that the failure has moved rather than gone away. New buckets on the major providers now block anonymous access by default, and grants based on legacy access control lists are disabled by default on AWS, so the single-click mistake that produced the headlines of a few years ago is largely designed out.

What produces exposure now is a policy someone wrote deliberately. A wildcard principal added so a partner's script could fetch a file. A grant to all authenticated users, which on some services means any account on that provider rather than anyone in your organisation. A policy that was correct for one prefix and then applied to the whole store. None of these look like a mistake in a change review, because each was requested by someone with a real problem.

The consequence is that the useful question is not whether a store is marked public. It is what an unauthenticated request and an unrelated cloud account can each actually read, which is a computed answer, not a setting you can look at.

What gets exposed that is not a bucket?

Snapshots, images and derived copies, which are the exposures teams find last because nobody thinks of them as storage. A disk snapshot shared with everyone contains the filesystem it came from, including credentials on disk. A shared machine image contains whatever was baked into it. A database snapshot restored by a stranger yields the entire database without touching your running instance or generating a single log line in your application.

Why does a policy review miss an open store?

Because access is the result of several documents evaluated together, and no single one of them tells you the answer. Effective access on the major providers combines the resource policy, the caller's own identity policy, account-level public access blocks, organisation-level denials, and in some services a network rule or endpoint policy as well. A reviewer reading the bucket policy alone is reading one term of an expression.

The evaluation order also defeats intuition. An explicit denial anywhere usually wins, which is what makes organisation-level denials so useful, but the absence of a denial plus a broad allow in either document can be enough. Conditions add another layer, and a condition that looks restrictive, such as one keyed on a source network or a source account, may be trivially satisfied or may not apply to the request pattern you were worried about.

This is why the practical control is an external access evaluator rather than human review. All three major providers now offer a service that computes which resources are reachable from outside your organisation, and reads that as a finding rather than as a configuration value. It is the one piece of cloud tooling that consistently earns its place on day one.

How would you know if data had been read?

Frequently you would not, because data plane logging is separate from control plane logging and is generally off by default. Your audit trail records that a policy was changed. It does not record that ten thousand objects were then downloaded, unless you enabled object-level logging on that store, which costs money and produces volume, so it is commonly left off precisely on the stores holding the most data.

That gap shapes real incidents. Organisations often learn about exposure from a researcher, a customer, or a public listing rather than from their own monitoring, and then cannot answer the question that actually matters to a regulator or a customer: was anything accessed, by whom, and when. Without data plane logs the honest answer is that you cannot tell, and the response has to assume the worst.

So decide deliberately where read logging is on. Do not try to enable it everywhere. Classify the small number of stores holding personal data, credentials, backups or intellectual property, turn object-level logging on for those, send it somewhere the account itself cannot delete, and accept sampling or nothing for the rest. That choice is cheap to make now and impossible to make retrospectively.

What actually prevents this rather than detecting it?

Denials that sit above the account, combined with default-private modules in your infrastructure code. An organisation-level policy that refuses to allow public access blocks to be disabled, refuses public snapshot sharing, and refuses removal of the logging configuration will stop the entire class of accidents, and it does so without slowing anybody down, because no legitimate delivery task requires those actions.

For anything genuinely meant to be public, move it. A separate account whose only purpose is public content is a structural control: the blast radius of a mistake in that account is a set of files you intended to publish, and it lets you keep the strict denials everywhere else without exceptions. Exceptions are what erode this control, and separating the public case removes the demand for them.

Then make the safe path the default path. If the storage module in your infrastructure code emits encryption, versioning, public access blocking and a logging destination without being asked, the common case is right without any reviewer thinking about it. Teams do not misconfigure storage because they want to; they misconfigure it because the raw resource has more knobs than the task appeared to need.

What can you test this week?

Run the provider's external access analysis across every account and read the findings as an inventory rather than a report. Then query for shared resources by type: snapshots, machine images, database snapshots, container registries, and anything with a resource policy containing a wildcard principal. That combination takes an afternoon and typically finds two or three things nobody knew were reachable.

Next, test from outside. Take the hostnames your content delivery network serves and request the origin directly, bypassing the edge. A surprising proportion of estates have a locked-down edge in front of an origin that answers anyone who asks, which means every control implemented at the edge, including authentication and rate limiting, is optional for anybody who finds the origin address.

Finish with a question rather than a scan: for each of your three most sensitive data stores, could you produce a list of every read in the last thirty days. If the answer is no, that is the highest-value change on this page, and it is a configuration switch rather than a project.