S3 buckets where Block Public Access is not fully switched on
What does ZopNight detect here?
S3 Block Public Access is 4 switches per bucket, and the guardrail only holds when all 4 are on. ZopNight flags buckets where any switch is off or no configuration exists at all. That is an open guardrail gap, deliberately not a claim that the bucket is publicly reachable today.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-086 |
| Category | compliance |
| Severity | critical |
| Metric | none — pure configuration read |
| Source | s3_public_access.go |
Where it applies
One guardrail, four switches
Block Public Access is not a single toggle. It is four settings (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy and RestrictPublicBuckets), each closing a different route to exposure: two govern ACLs, two govern bucket policies. Leave any one off and a route stays open; a future quick-fix ACL or a pasted policy can then make the bucket public with no further warning. The guardrail’s value is that it makes public access impossible to configure by accident, and that only holds at four of four.
Read the finding precisely
This is a guardrail-hygiene finding, and it says so. Discovery derives one boolean from the bucket’s Block Public Access configuration: true when the four switches are not all on, and also true when no configuration exists at all. What discovery does not do is inspect the bucket’s ACL grants or its policy’s principals. That content is never read for this rule. A flagged bucket is therefore not necessarily reachable by the public today; it is a bucket where nothing prevents that from being configured. Treat it as the seatbelt being unbuckled, not as the crash having happened. The check mirrors the AWS Security Hub S3.1 control.
Verify a bucket
aws s3api get-public-access-block --bucket my-bucketFour true values is a pass. Any false, or a
NoSuchPublicAccessBlockConfiguration error, reproduces this finding.
Closing the gap
Enable all four settings, from the console’s Permissions tab or with
put-public-access-block from the CLI. If the bucket genuinely serves a public
website, do not weaken the guardrail. Front it with CloudFront and an Origin Access
Control so the bucket stays private while the content stays public. Then review the
ACL and policy for existing public grants: the guardrail blocks future ones but does
not audit history for you.
The signal’s deliberate edge
Because ACLs and policy principals go unread, the rule cannot rank flagged buckets by actual exposure, and it will flag intentionally public buckets too, and those need the CloudFront pattern or a documented exception, not silence. When the Block Public Access state could not be captured at discovery, the rule abstains rather than assuming the worst.