Five-Step Review to Find Exposed Object Storage Early
You find exposed object storage before attackers do by pairing account-wide prevention controls with a scheduled review of native access findings, not by scanning buckets ad hoc once a quarter. On AWS, that means account-level Block Public Access plus IAM Access Analyzer for S3; on Google Cloud, public access prevention enforced as an organization policy; on Azure, disallowing anonymous access at the storage account and watching anonymous request metrics. AWS recommends turning on all four settings so every current and future bucket is protected, and the same logic applies on the other platforms: make public access structurally impossible, then treat every exception as a deliberate, reviewed decision.
The review method below turns that principle into a repeatable cycle that a small platform or security team can run monthly. Every control cited is vendor-native; none of it requires buying a CSPM license first.
Why exposure keeps returning
Storage rarely becomes public through a single careless click. The recurring patterns are drift, exception creep, and account sprawl: a bucket policy edited directly in the console during an incident, a project created outside the landing zone, a pipeline that predates your current baseline. Because each cloud grants public access through several mechanisms — ACLs, bucket policies, access point policies, container-level public access — a review that checks only one of them will miss exposure created through another. The fix is to review the signals that evaluate all mechanisms at once, and to review them on a schedule rather than when someone remembers. A Terraform plan review routine catches many of these changes before apply, but it cannot see console edits or legacy resources, which is why runtime review still matters.
The five-step review method
- Inventory every storage resource. Export buckets and containers per account, per region, including those owned by forgotten test accounts. An exposure you have not inventoried is an exposure you cannot review.
- Verify the guardrail, not the bucket. Check that account- or organization-level prevention is on everywhere before auditing individual buckets; the guardrail makes most per-bucket questions moot. IAM Access Analyzer for S3 updates its findings within 30 minutes when a bucket policy or bucket ACL is added or modified (AWS documentation), so findings reflect near-current state, though the console summary refreshes only once every 24 hours.
- Review findings, then close them or record intent. Every public or shared resource needs one of two terminal states: fixed, or archived as an acknowledged exception with an owner and a reason.
- Test the exception path. For resources that must stay public, verify the blast radius: which prefixes are public, whether listing is possible, whether write is possible. Archive the finding only after this check.
- Fix the cadence and the diff. Re-run monthly and diff findings against last cycle; a new public resource that nobody requested is the highest-priority signal you will see all month.
Guardrails per platform
Each platform implements the same idea with different names. On Google Cloud, public access prevention makes grants to anonymous principals unusable: requests authorized with allUsers or allAuthenticatedUsers fail with HTTP 401 or 403 status codes, and existing grants remain in place but overridden while prevention is enforced. Enforcement can take up to 10 minutes to apply, so do not treat a just-enabled policy as already protective in the middle of an incident.
On Azure, anonymous read access is controlled at two layers, and the account-level setting overrides any container configured for public access — so the review should verify the account setting first and container settings second, then back both with a deny policy.
| Platform | Prevention control | What it blocks | Review signal |
|---|---|---|---|
| AWS S3 | Block Public Access at account or organization level | Public ACLs and public bucket, access point policies | IAM Access Analyzer for S3 findings |
| Google Cloud Storage | Public access prevention (org policy) | Grants to allUsers and allAuthenticatedUsers | Cloud Asset Inventory policy query |
| Azure Blob Storage | Disallow anonymous access at account level | All container-level public access | Metrics filtered to Anonymous plus StorageBlobLogs |
Limits and edge cases
Three limits decide whether this method is honest or theater. First, static website hosting and public download buckets are legitimate exceptions; the goal is a recorded exception list, not zero public buckets. Second, caches outlive the fix: Google notes that objects can remain in internet caches according to their Cache-Control setting, so a closed bucket can still serve cached copies for the cache lifetime. Third, coverage gaps exist — IAM Access Analyzer for S3 requires an account-level analyzer in each region and does not analyze cross-account access point policies, so complementary policy checks still earn their place, the same way secrets controls in Kubernetes layer encryption, RBAC and external vaults instead of relying on one gate.
Run the checklist against your newest account first; sprawl is where exposure hides. This review method is original to this site and was verified against vendor documentation on October 16, 2026.