DEV Community

StarkMan
StarkMan

Posted on

Object Storage Access Reviews: Turning a Bucket List into Evidence

#cloudsecurity #objectstorage #accessreview

Object Storage Access Reviews: Turning a Bucket List into Evidence

Access reviews in object storage tend to produce a spreadsheet of bucket names and owner names, which satisfies the process and settles nothing. The file that answers the useful questions is not who owns a bucket. It is which principals can read it without authentication, which can write to it from outside the account, and which policies grant access to a wildcard that was meant to be temporary.

Start with the policy, not the name

The access decision for an object is made by a combination of identity policies, bucket policies, access control lists and any organisation-level guardrail. Reading only one of those layers produces a review that concludes a bucket is private when a resource policy grants public read.

Bucket policies are the layer most often missed, because they attach to the resource and are invisible in the identity view of the environment. A practical enumeration collects the bucket policy, the public access block configuration and the access control list for every bucket in the account, and stores the result next to the identity policies that reference the same resources.

aws s3api get-public-access-block --bucket example-bucket
aws s3api get-bucket-policy --bucket example-bucket
Enter fullscreen mode Exit fullscreen mode

What makes a finding real

A public access block that sets all four flags to false is not a finding by itself. It is a condition that permits a policy to expose the bucket. The finding is the combination: a block setting that allows public policy, and a policy statement whose principal is wildcard and whose action includes object reads.

This distinction matters when the review is used to justify an expensive remediation. A bucket with public access blocked and no public policy is inventory, not risk. A bucket with a wildcard principal and no condition is exposure, and it deserves the change ticket.

Access Analyzer addresses the same question from the outside by identifying resources shared with external entities. Its findings are a useful cross-check on a manual review, particularly for resources created by automation that no team claims.

Review the write paths

Read exposure dominates the discussion because it is what an attacker gets first, but write access is the more damaging grant in several ways. A principal that can write to a bucket can replace the content a website serves, and a principal that can write to a bucket used for logs can destroy evidence.

Include the write actions in the review even when the bucket is not readable by the same principal. Check for s3:PutObject granted to principals outside the account, for lifecycle rules that move objects to a less protected storage class, and for replication rules that copy data to a second account.

Make the result reproducible

The review is only repeatable if it is a script rather than a quarterly exercise. Produce output with the account identifier, bucket name, public access block state, policy statement summary, and the date. Store it under version control so the next review can be compared against the previous one, and so a change in state produces a diff rather than a rediscovery.

Two habits keep the output honest. Record the API call and its parameters next to each line, so a reviewer can reproduce the result. Record what was not checked, such as buckets in accounts outside the review scope or resources in other regions.

References

Top comments (1)