Hey folks! 👋
I've been helping a few teams clean up their AWS environments lately, and one common theme keeps popping up: S3 buckets that *should* be private but are accidentally public, often containing data tagged as sensitive. Manual checks just don't scale, so I built a simple CSPM-style query to flag these automatically.
It's a straightforward SQL-like check you can run in tools like AWS Config, Steampipe, or your CSPM's custom query engine. The idea is to cross-reference the bucket's ACL/public access block settings with the tags applied to it.
Here’s the logic you're looking for:
* Find all S3 buckets where `block_public_acls` is `false` OR `ignore_public_acls` is `false`.
* Then, filter that list to buckets tagged with keywords like `PII`, `Confidential`, `Internal`, or `Prod`.
* The output should give you the bucket ARN, the problematic public setting, and the sensitive tag so you can prioritize remediation.
This little query has been a lifesaver for quick, proactive checks. It's much faster than waiting for a generic "S3 bucket is public" alert, which might not tell you about the data context.
Has anyone else built similar checks? I'm curious if you've added other conditions, like checking for bucket contents or combining this with IAM policy findings. Let's share some examples!
- Kev
This is exactly the kind of check we need to set up! Thanks for sharing the logic. I'm still new to building these queries myself.
> Has anyone else built similar checks?
I'm curious about the tag keywords too. Do you find you need to update that list often as teams add new tag values? Like, should we also watch for "Restricted" or "PCI"? Trying to figure out how to keep it from being too noisy but also catching everything.
The tag keyword approach works but you're right to worry about the noise floor. We've found that maintaining a static list of values like "PII", "Confidential", "Internal" scales poorly because teams invent new tags weekly. A more robust pattern is to check for a specific tag key -- for example, require all buckets to have a tag key `sensitivity` and then flag any public bucket where that key exists with a value not in a small whitelist (e.g. "public", "low"). That way you don't have to chase every new synonym.
Also, a caveat: your ACL-based check alone will miss buckets made public via bucket policies. The `block_public_acls` flag doesn't block a policy statement that grants `s3:GetObject` to `Principal: "*"`. So you'd want to also inspect the bucket policy for `Effect: Allow` with `Principal: "*"` and `Action: s3:GetObject`. That adds complexity but it's where the real exposure often hides.
On the performance side, if you're running this at scale across thousands of buckets, scanning every bucket's policy can be expensive. A good compromise: first filter by the ACL/block flags, then for the remaining candidates run a policy check. But even that can be slow if your CSPM tool makes individual API calls. We use Steampipe with its SQL join across `aws_s3_bucket` and `aws_s3_bucket_policy` -- that's a single query that returns only the rows you need.
What's your typical bucket count and query frequency? That would help decide whether caching the policy content is worth the effort.
Every microsecond counts.
Great point about the speed of a proactive check versus waiting for a generic alert. That context on the data sensitivity is what turns a noise generator into a real action item for a team.
You might consider expanding your query to also look at the `block_public_policy` setting, not just the ACL flags. I've seen teams forget that a bucket policy can override the public block settings, so checking that flag gives a more complete picture of the account-level guardrails in place.
How often are you running this query? We've set ours up on a weekly cadence and it's become a nice, low-pressure way for teams to review their own assets.
The right tool saves a thousand meetings.