Most cloud data exposure incidents are not clever attacks. Someone made a bucket public to share a file with a contractor, or a broad policy written for a quick test was never narrowed, and the data sat there for months. Object storage is easy to create and easy to open up, which is exactly why it needs a deliberate review.

This guide walks through the misconfigurations I see most often and a sensible order for fixing them. Exact setting names differ between providers, so treat the concepts as the stable part and check your vendor’s current documentation for the specifics.

Start by Finding Out What You Have

You cannot secure what you have not listed. Pull an inventory of every bucket or container across every account and project, including the ones created by people who have since left. For each one, record the owner, what data it holds, and whether anything outside your organization can read it.

A common trap is to review only the accounts the data team knows about. Experiments, proof-of-concept environments and old project accounts are where forgotten buckets live. Include them.

The Misconfigurations That Matter Most

Public read access that nobody remembers granting. Public access is occasionally legitimate, such as hosting static website assets. For analytics data it almost never is. Most providers now offer an account-level or organization-level setting that blocks public access regardless of individual bucket settings. Turn that on first, then make explicit exceptions only where you can name the business reason.

Wildcard principals in policies. A policy that grants access to “everyone” or to every authenticated user of the whole cloud platform, not just your organization, is far broader than it reads. Search for these specifically.

Over-broad roles for pipelines. An ingestion job that only writes to one prefix often runs with permission to read, write and delete everything in the account. When that job’s credentials leak or the code misbehaves, the blast radius is the whole estate.

Long-lived access keys. Static keys copied into scripts, notebooks and CI variables get shared, committed and forgotten. Prefer short-lived credentials issued through roles or workload identity wherever your tooling supports it.

Missing encryption settings. Most providers encrypt stored objects by default today, but verify that for your account and decide whether you need customer-managed keys for sensitive data. Also confirm encryption in transit is required, so clients cannot fall back to plain connections.

No logging. If access logs are off, you cannot answer “who read this file last week” after an incident. Enable object-level access logging for buckets holding sensitive data, and send the logs to a separate location that the data team cannot modify.

A Fix-It Order That Avoids Breaking Things

Lockdown projects fail when someone flips a global switch on Friday afternoon and a dashboard stops loading. A safer sequence:

1. Turn on logging and let it collect for a week or two. This tells you who actually uses each bucket.
2. Block public access at the account level, with a short, documented exception list.
3. Replace wildcard and broad policies with named roles, using the access logs to see what each consumer really needs.
4. Move pipelines and applications off static keys.
5. Add alerts for policy changes and for any bucket becoming public.

Step 1 is the one people skip, and it is what makes the rest low-risk.

A Quick Review Table

Check	What good looks like	Red flag
Public access	Blocked at account level, exceptions documented	Individual buckets open with no owner
Policies	Named roles, scoped to prefixes	Wildcard principals, full-access roles
Credentials	Short-lived, role-based	Static keys in scripts or notebooks
Encryption	Verified at rest and in transit	Assumed but never checked
Logging	Enabled, stored separately	Off, or writable by bucket users
Ownership	Every bucket has a named owner and tag	Unlabelled buckets nobody claims

A Realistic Example

Imagine a small analytics team that inherits an account with about forty buckets. An inventory shows six with no owner tag. Two of them are readable by any authenticated user on the platform, left over from a vendor data exchange that ended long ago. The team enables logging first and finds that neither bucket has been read in months. They snapshot the contents to a restricted location, delete the originals after a short holding period, and enable account-level public access blocking. Total disruption: none, because the logs had already shown nobody depended on those buckets.

Keep It From Drifting Back

Fixing the current state is half the job. Define buckets through infrastructure-as-code so a reviewer sees any policy change in a pull request, and run a scheduled scan that flags public or wildcard-accessible storage. Treat a new public bucket the way you would treat a failing test: it blocks until someone explains it.

Frequently Asked Questions

Is a bucket safe if the object names are hard to guess? No. Obscure names are not access control. Names leak through logs, URLs, error messages and shared links. Rely on policies and authentication.

Should we encrypt everything with customer-managed keys? Not automatically. Provider-managed encryption is adequate for many datasets. Customer-managed keys add control and some operational burden, so apply them to data where your classification or regulations call for it, and consult your compliance advisers about requirements in your jurisdiction.

How do we share data with an external partner safely? Prefer a time-limited, narrowly scoped grant to a specific prefix or a managed sharing feature over making anything public. Set an expiry date and review it when it lapses.

Who should own bucket security, the data team or the platform team? Platform or security teams usually own the guardrails, such as account-level blocks and logging. The data team owns what is inside each bucket and who needs access. Both need to be named.

What is the first alert worth setting up? A notification when any bucket policy changes or when a bucket becomes publicly accessible. It is cheap, catches the most damaging mistakes, and rarely produces noise.

Next Step

Export a list of every bucket you own today and add two columns: owner and “public or wildcard access, yes or no.” Anything without an owner or with a yes goes to the top of your cleanup list this week.