CIS AWS Foundations v1.2 2.3: Ensure the S3 bucket used to store CloudTrail logs is not publicly accessible

To meet CIS AWS Foundations v1.2 2.3: ensure the S3 bucket used to store CloudTrail logs is not publicly accessible requirement, you must configure the CloudTrail log S3 bucket so it cannot be accessed by the public (anonymous or broad internet access) through bucket policies, ACLs, or misconfigured public access settings. Operationally, lock down S3 Public Access settings, restrict the bucket policy to CloudTrail and approved principals, and retain evidence that the bucket is private and continuously monitored.

Key takeaways:

• CloudTrail logs are security evidence; storing them in a public S3 bucket breaks auditability and incident response.
• “Not publicly accessible” requires controls at multiple layers: S3 Block Public Access, bucket policy, and ACL posture.
• Treat this as a continuous control: implement preventive guardrails plus detection (AWS Security Hub mapping) and evidence capture.

This requirement exists for a simple reason: CloudTrail logs often become your system of record during investigations, audits, and disputes. If the S3 bucket that stores CloudTrail logs is publicly accessible, you can leak sensitive security telemetry (account activity, API calls, identity usage patterns) and you also weaken chain-of-custody confidence for forensic review. CIS AWS Foundations calls for the bucket used to store CloudTrail logs to be non-public, and AWS Security Hub maps the benchmark requirement into a testable control so you can track drift and remediation centrally ¹.

For a Compliance Officer, CCO, or GRC lead, the goal is not “make the finding green once.” The goal is to operationalize a repeatable control that: (1) standardizes how CloudTrail log buckets are configured across accounts/environments, (2) prevents teams from accidentally opening access via bucket policies or ACLs, and (3) produces audit-ready evidence on demand.

This page translates the benchmark requirement into concrete steps you can assign to Cloud/Platform Engineering, validate through independent checks, and package as artifacts for auditors.

Regulatory text

Excerpt (provided): “Implement CIS AWS Foundations Benchmark v1.2 requirement 2.3 as mapped in AWS Security Hub.” ²

Operator interpretation: You must implement the CIS AWS Foundations v1.2 control that checks whether the S3 bucket configured as the CloudTrail log destination is publicly accessible. In practice, this means:

• The bucket must not allow public access via S3 ACLs or bucket policy statements.
• Account/bucket “Block Public Access” settings must be enabled so later changes do not accidentally expose the bucket.
• You must be able to show this is enforced and monitored, using AWS Security Hub’s benchmark mapping and your own evidence collection ¹.

Plain-English interpretation of the requirement

Your CloudTrail logs must be stored in an S3 bucket that the public internet cannot read from or list. “Public” includes anonymous access and overly broad grants (for example, allowing access to Principal: "*") even if you believe nobody knows the bucket name. Auditors will treat “publicly accessible” as a configuration state, not an intent.

Who it applies to

Entities: Any organization operating workloads in AWS and using CloudTrail, including regulated businesses and SaaS providers with security baseline obligations ³.

Operational scope:

• All AWS accounts where CloudTrail is enabled.
• All regions where trails deliver logs to S3 (including multi-region trails).
• Centralized logging architectures (one “log archive” account) and decentralized ones (per-account buckets).

Control owners (typical):

• Platform/Cloud Security: defines the standard and guardrails.
• Cloud/Infrastructure Engineering: implements baseline configuration and IaC.
• GRC/Compliance: defines evidence requirements and runs periodic attestation.

What you actually need to do (step-by-step)

Step 1: Identify the CloudTrail log destination bucket(s)

1. Inventory all trails (organization trails and account-level trails).
2. For each trail, record:
   • S3 bucket name
   • S3 key prefix (if any)
   • KMS encryption configuration (if enabled)
3. Confirm there are no “legacy” trails writing to forgotten buckets.

Evidence tip: Export the trail configuration list (screenshot or CLI output) and store it with the control’s evidence packet.

Step 2: Turn on S3 Block Public Access (guardrail)

For each CloudTrail log bucket:

1. Enable Block Public Access at the bucket level.
2. Prefer enabling Block Public Access at the account level as a preventive baseline for logging accounts, then carve out exceptions through a formal exception process.

What you’re guarding against:

• Someone applying a public-read ACL.
• Someone adding a permissive bucket policy later during troubleshooting.

Evidence tip: Capture the bucket’s Block Public Access configuration state.

Step 3: Remove ACL-based public exposure

1. Set Object Ownership to prefer bucket owner enforced controls where your operating model supports it.
2. Ensure the bucket ACL does not grant access to:
   • AllUsers
   • AuthenticatedUsers

Even if you rely on bucket policies, ACLs can still create exposure or audit confusion.

Evidence tip: Retain current bucket ACL output and Object Ownership configuration.

Step 4: Harden the bucket policy (least privilege)

Your bucket policy should:

• Allow cloudtrail.amazonaws.com to write logs to the bucket (and only to the correct bucket/prefix).
• Restrict access for reads to named roles (for example, Security/IR, SIEM pipeline roles), not broad principals.
• Avoid any statements that effectively allow public access (for example, Principal: "*" without tight conditions).

Also check for common “accidental public” patterns:

• s3:GetObject allowed to *
• s3:ListBucket allowed to *
• Conditions missing or too loose

Evidence tip: Store the bucket policy JSON as an artifact in your GRC repository (versioned).

Step 5: Validate with an independent signal (AWS Security Hub)

1. Enable the CIS AWS Foundations benchmark in AWS Security Hub if you use Security Hub for posture management ¹.
2. Track the mapped control that corresponds to this requirement (AWS Security Hub maps CIS AWS Foundations checks, including CloudTrail-related checks) ¹.
3. Establish an alerting workflow:
   • Findings route to the ticketing system.
   • Remediation SLA defined by severity and environment (prod vs non-prod).

Evidence tip: Retain a Security Hub screenshot or exported finding history showing the control passing, plus your remediation workflow artifact (runbook or ticket templates).

Step 6: Add drift prevention (policy-as-code where possible)

To keep the bucket private over time:

• Implement guardrails using AWS Organizations SCPs (where applicable) to prevent disabling Block Public Access in protected accounts.
• Use IaC (CloudFormation/Terraform) to define the bucket and policy as code.
• Add config monitoring to detect changes to bucket policy, ACLs, and public access settings.

Operational note: Most “public S3” incidents come from later change, not initial build. Treat drift control as part of the requirement, even if your benchmark tool only flags current state.

Required evidence and artifacts to retain

Store evidence in a way an auditor can replay without console access.

Minimum evidence set (recommended):

• CloudTrail trail configuration inventory showing the destination S3 bucket(s) (screenshot or CLI output).
• S3 Block Public Access settings (bucket-level, and account-level if enforced).
• Bucket policy JSON (versioned).
• Bucket ACL output and Object Ownership configuration.
• Security Hub CIS mapping status or exported findings showing pass state ¹.
• Change management artifacts:
  • Ticket/PR for the baseline change
  • Approval record for any exception
  • Post-change validation results

Common exam/audit questions and hangups

Auditors and assessors usually focus on these friction points:

1. “Which bucket is the CloudTrail bucket?”
   If you have multiple trails or org trails, show a clear mapping from trail to bucket.

2. “How do you prove it’s not public?”
   They may ask for more than one control layer: Block Public Access + policy + ACL posture.

3. “How do you prevent regression?”
   Expect questions about monitoring and alerting, not just point-in-time screenshots.

4. “Who can read CloudTrail logs?”
   Least privilege matters. Show a tight list of roles/principals and why they need access.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails audits	How to avoid it
Relying only on “we don’t have a public policy”	Public access can come from ACLs or later changes	Enforce S3 Block Public Access and check ACLs
Using broad principals in bucket policy	Principal: "*" patterns are a red flag	Restrict to CloudTrail service principal and named roles
Only configuring one region/trail	Logs can land in a different bucket or region	Inventory all trails and destinations
No evidence retention process	You scramble during audits	Standardize an evidence packet and update it after changes
Exceptions handled informally	Exceptions become permanent exposure	Require approved, time-bound exceptions with compensating controls

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific CIS requirement, so this page does not cite or summarize enforcement actions.

Risk still maps cleanly to operator concerns:

• Confidentiality risk: CloudTrail logs may expose sensitive operational metadata (identity activity, service usage, and event patterns).
• Integrity and investigation risk: If access is broad, you face harder questions about who could access logs and whether access controls were consistently enforced.
• Assurance risk: If you cannot show layered controls and monitoring, you may pass once and fail later due to drift.

Practical 30/60/90-day execution plan

Days 0–30: Baseline and quick wins

• Assign control ownership (Cloud Security + Platform Engineering + GRC evidence owner).
• Inventory all CloudTrail trails and their destination buckets.
• Remediate any buckets with public access findings immediately:
  • Enable S3 Block Public Access
  • Remove public ACL grants
  • Tighten bucket policies
• Create the “evidence packet” template and store initial artifacts.

Days 31–60: Standardize and prevent drift

• Convert bucket configuration to infrastructure-as-code where feasible.
• Implement a monitoring workflow:
  • Security Hub benchmark enabled and routed to tickets ¹.
  • Change notifications for S3 policy/ACL/public access changes routed to Security.
• Document an exception process for any non-standard access patterns (for example, third-party SIEM ingestion roles).

Days 61–90: Operational maturity and audit readiness

• Add preventive org controls (for example, SCP guardrails) in protected logging accounts where your AWS governance model supports it.
• Run an internal audit-style test:
  • Randomly sample accounts and trails
  • Recreate the “trail → bucket → non-public proof” chain from stored artifacts
• Automate evidence refresh on a defined cadence (for example, evidence export after any change and on a periodic schedule).

Operational mapping notes (how teams usually implement this)

• Central log archive account: Strong model for control consistency. Treat the log archive as a protected zone with stricter guardrails.
• Application accounts writing their own logs: Higher drift risk. Compensate with stronger detection, IaC enforcement, and account-level Block Public Access.

Where Daydream fits (without changing your AWS architecture)

Teams commonly struggle with two things: proving the control continuously, and packaging evidence consistently across accounts. Daydream can track the requirement, map it to the underlying AWS checks (including the AWS Security Hub CIS mapping), and keep evidence requests, exports, and review notes in one place so audits don’t turn into screenshot hunts ¹.

Frequently Asked Questions

Does “not publicly accessible” mean the bucket can’t be shared with any third party?

You can share access with a third party when needed, but access must be explicitly granted to named principals and not open to the public. Treat third-party access as a least-privilege exception with formal approval and tight scope.

If the bucket is in a dedicated log archive account, do I still need bucket-level Block Public Access?

Yes. Centralization reduces sprawl, but it doesn’t prevent misconfiguration. Bucket-level Block Public Access provides a direct control on the specific log bucket.

Will AWS Security Hub automatically prove compliance for this requirement?

Security Hub helps by mapping CIS AWS Foundations checks into findings you can monitor ¹. Auditors still expect supporting configuration evidence, plus proof you respond to findings.

Can I allow public access if the objects are encrypted?

Encryption does not make public access acceptable for this requirement. Public access still exposes metadata and creates a control failure state.

What evidence is the fastest to produce during an audit?

A saved trail configuration export plus the bucket’s Block Public Access configuration and bucket policy JSON usually answers most questions. Keep them versioned and tied to a change record.

What’s the most common “gotcha” after remediation?

Drift from later policy edits. Put alerts on bucket policy/ACL/public access changes and require PR-based review for modifications.

Related compliance topics

• 03.01.18: Access Control for Mobile Devices
• 03.01.19: Withdrawn
• 03.01.20: Use of External Systems
• 03.01.21: Withdrawn
• 03.01.22: Publicly Accessible Content

Footnotes

1. AWS Security Hub CIS AWS Foundations mapping table

2. CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table

3. CIS AWS Foundations Benchmark