5 Storage Exposure Drift Signals to Review Monthly
Most exposed buckets do not start exposed. They drift there one change at a time: a policy edited during a migration, an access point created for a demo, a container flipped to public read for a one-off file share. A review anchored on storage exposure drift — the difference between each account’s current public-access guardrails and the baseline you approved — catches those changes while they are still fresh enough to tie back to a ticket and an owner. On AWS, S3 Block Public Access settings override bucket policies and object permissions, keeping data private no matter how a bucket was created, per the Block Public Access documentation. The same guardrail pattern exists in Google Cloud and Azure, and it turns a monthly review from an inventory crawl into a targeted diff that costs one export per account and about an hour per cycle.
Anchor the review on guardrails
Scanning buckets one by one treats every object store as a separate question, and the answer is stale the moment someone creates a new bucket. Guardrails invert the problem. Each cloud exposes a small number of account- or organization-level switches that make public access structurally impossible, and reviewing those switches covers every current and future resource beneath them. Your review baseline is therefore the guardrail state per account, snapshotted and versioned, not a bucket inventory that ages out within a sprint.
On Google Cloud, public access prevention means no one can make bucket data public through IAM policies or ACLs while the setting is enforced — existing allUsers grants stay in the policy document but stop authorizing requests, a behavior documented on the public access prevention page. On Azure, the equivalent switch is the storage account’s AllowBlobPublicAccess property: disallowing anonymous access at the account level overrides the access settings for all containers in that account, so even a container deliberately set to public read stops serving anonymous requests. Both vendors let you enforce these settings from the organization or management level down, which is where the review baseline should come from.
Five drift signals to watch
With the baseline defined, the review reduces to checking what moved. Five signals cover the changes that turn a clean baseline into an exposure:
| Drift signal | Where to check | Why it matters |
|---|---|---|
| Guardrail disabled at a higher level | AWS account or organization Public Access Block; GCP storage.publicAccessPrevention constraint; Azure AllowBlobPublicAccess | One switch can re-open every bucket or container beneath it in a single change |
| Bucket- or container-level exceptions | Bucket-level BPA overrides; Azure container access level; GCP bucket setting left as inherited | An exception negotiated for one workload becomes the forgotten default for the next |
| New storage in unreviewed accounts | Organization-wide asset inventory exports | Buckets created outside your scan scope never trigger a finding |
| Acknowledged or archived findings | Analyzer archive lists and exception registers | An approved public bucket is fine; an expired approval is an exposure |
| New policy surfaces on existing data | Access point policies; managed folder IAM | Same objects, new authorization path that a bucket-only review never inspects |
Each row is a question the diff answers in minutes; answering them bucket-by-bucket is what turns a review into a project.
Run the monthly review
The review itself is a short, repeatable procedure. The point is attribution: every change in guardrail state must map to an approved change, or it becomes a finding the same day.
- Export the guardrail state for every account: AWS account- and bucket-level Public Access Block settings, the GCP organization policy constraint per project, and Azure
AllowBlobPublicAccessper storage account. - Diff the export against last month’s snapshot. Every difference gets mapped to a change ticket and an owner; unmatched changes move to step 3 immediately.
- Pull the audit trail for each unmatched change — who called
PutBucketPublicAccessBlock, changed the organization policy constraint, or updated storage account properties, and from where. - Validate every standing exception. For each intentionally public bucket or container, confirm the acknowledgement record names a current owner and a business reason, not a departed engineer’s demo.
- Sweep with analyzer output to catch what the diff missed: IAM Access Analyzer for S3 reports buckets that grant access to anyone on the internet or to AWS accounts outside your organization, per AWS guidance on reviewing public buckets. Cloud Asset Inventory policy queries and a container-by-container Azure listing serve the same role on the other platforms.
- Store the new snapshot, the diff, and the findings log together, so next month’s review starts from evidence instead of memory.
Fix findings without breaking apps
Remediation order matters as much as detection. Before re-enabling a guardrail, check whether anything reads that data anonymously — static websites, unsigned download links embedded in emails, partner integrations that never authenticated. Guardrail enforcement blocks the request, not the configuration, so a hard block on a live dependency is an outage you chose. Where the dependency is real, move it to a signed-URL pattern or a CDN-fronted private backend before tightening the switch; where it is not, block at the highest level the change was approved for. If the exposure involved credentials rather than objects — a leaked key or a state file with embedded secrets — switch to an incident process instead of a review item, and work a containment sequence like the five-step runbook for a leaked Terraform state file. For data that was public long enough to be copied, auditing public cloud snapshots is the companion check, since snapshots often outlive the bucket that embarrassed you.
Close the loop by scheduling the next snapshot before closing the current review. A drift review that runs only when someone remembers it measures memory, not exposure.