# Ensure the CloudTrail S3 bucket ACL does not grant access to everyone - Source: https://support.icompaas.com/support/solutions/articles/a_1793292192531827-ensure-the-cloudtrail-s3-bucket-acl-does-not-grant-access-to-everyone - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224) - Last updated: 2026-10-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Description** Ensure that the access control list (ACL) of the S3 bucket to which each AWS CloudTrail trail delivers its log files does not grant any permission to the public AllUsers group (shown in the console as **Everyone (public access)**). **Rationale** CloudTrail logs describe all API activity in the account, including users, roles, resources and source IP addresses. If the log bucket is public, anyone can read this information to map the environment and plan attacks. If public write is allowed, logs can be altered or deleted, which destroys evidence and hinders investigations. The log bucket should be private, protected with S3 Block Public Access, and accessible only to CloudTrail and authorized users. **Impact** - Prevents public read or write access to CloudTrail log files - Protects the confidentiality and integrity of the audit trail - Any user or tool relying on anonymous access to the bucket loses access and must use authenticated, authorized access instead **Default Value** New S3 buckets are private, have ACLs disabled (Bucket owner enforced) and have S3 Block Public Access enabled by default. A public ACL grant exists only if it was explicitly added. **Pre-Requisites** - IAM permissions: cloudtrail:DescribeTrails, s3:GetBucketAcl, s3:PutBucketAcl and s3:PutBucketPublicAccessBlock - Confirmation that no legitimate process depends on anonymous access to the bucket **Remediation** **Test Plan** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the CloudTrail console, select **Trails** and note the S3 bucket of each trail. 3. Open the Amazon S3 console and select that bucket. 4. Open the **Permissions** tab and review the **Access control list (ACL)** section. 5. Check whether **Everyone (public access)** has any permission. 6. Repeat for the bucket of each trail in each region in use. 7. If any bucket grants permissions to **Everyone (public access)**, follow the implementation steps. **CLI:** List the trails with their S3 bucket: aws cloudtrail describe-trails --region --query "trailList\[\].\[Name,HomeRegion,S3BucketName\]" --output table Show any ACL grants to the public AllUsers group: aws s3api get-bucket-acl --bucket --query "Grants\[?Grantee.URI=='http://acs.amazonaws.com/groups/global/AllUsers'\]" The bucket fails if the second command returns any grant. If the bucket belongs to another account (for example a central logging account), check it in that account. **Implementation Steps** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon S3 console and select the bucket used by the trail. 3. Open the **Permissions** tab and, in **Access control list (ACL)**, choose **Edit**. 4. Clear all permissions for **Everyone (public access)**. 5. Choose **Save changes**. 6. In **Block public access (bucket settings)**, choose **Edit**, select **Block all public access** and choose **Save changes**. 7. Repeat for each affected CloudTrail bucket. **CLI:** Replace the bucket ACL with the private canned ACL. This removes all existing grants except full control for the bucket owner, so re-add any other non-public grant that is still needed: aws s3api put-bucket-acl --bucket --acl private Block public access on the bucket: aws s3api put-public-access-block --bucket --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true **Backout Plan** Before making changes, save the current ACL and public access block settings: aws s3api get-bucket-acl --bucket > acl-backup.json aws s3api get-public-access-block --bucket > public-access-block-backup.json To roll back: 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon S3 console and select the bucket. 3. In the **Permissions** tab, edit **Block public access (bucket settings)** and restore the saved settings. 4. Edit **Access control list (ACL)** and restore the grants from the saved backup. 5. Choose **Save changes**. **CLI:** aws s3api put-bucket-acl --bucket --access-control-policy file://acl-backup.json Note: rolling back makes the CloudTrail logs publicly accessible again. Do this only if absolutely required. **Reference** - [https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html) - [https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-s3-bucket-public-access-prohibited.html](https://docs.aws.amazon.com/config/latest/developerguide/cloudtrail-s3-bucket-public-access-prohibited.html) - [https://docs.aws.amazon.com/awscloudtrail/latest/userguide/create-s3-bucket-policy-for-cloudtrail.html](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/create-s3-bucket-policy-for-cloudtrail.html) - [https://docs.aws.amazon.com/cli/latest/reference/s3api/put-bucket-acl.html](https://docs.aws.amazon.com/cli/latest/reference/s3api/put-bucket-acl.html) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.