# Ensure CloudWatch log groups are not in a public resource policy

- Source: https://support.icompaas.com/support/solutions/articles/a_1793292236810809-ensure-cloudwatch-log-groups-are-not-in-a-public-resource-policy
- 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 no Amazon CloudWatch Logs resource policy makes a log group publicly accessible. A log group is considered public when a resource policy contains an Allow statement with the principal \* (any AWS account or anonymous user), without a condition that restricts access to your account, and the statement's Resource is \* or includes the log group's ARN.

**Rationale**

Public access to log groups lets anyone read the log data, which can reveal secrets, personal data and details about the environment that help attackers. If the policy also allows write or configuration actions, attackers can inject false log events or change subscriptions, undermining the integrity and availability of audit evidence. Resource policies should grant only the required actions to specific principals and specific log group ARNs, with conditions such as aws:SourceAccount where AWS services are involved.

**Impact**

-   Prevents unauthorized users and accounts from reading or modifying log data
    
-   Protects the integrity of logs used for auditing and investigations
    
-   Deleting or narrowing a resource policy can stop log delivery from AWS services that relied on it (for example, Route 53 query logging or other services that write to CloudWatch Logs), so the required access must be granted again in a restricted form
    

**Default Value**

No CloudWatch Logs resource policies exist by default. Some AWS services create a resource policy automatically when log delivery to CloudWatch Logs is configured; these policies grant access to a service principal rather than to \*.

**Pre-Requisites**

-   IAM permissions: logs:DescribeLogGroups, logs:DescribeResourcePolicies, logs:PutResourcePolicy and logs:DeleteResourcePolicy
    
-   A list of the AWS services and accounts that legitimately need to write to or read from the affected log groups
    

**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 **AWS CloudShell** from the console toolbar in the region to review.
    
3.  Run the CLI command below and review each resource policy.
    
4.  Repeat for each region in use.
    
5.  If any policy allows principal \* on \* or on a log group ARN without restricting conditions, follow the implementation steps.
    

**CLI:**

List the CloudWatch Logs resource policies in a region:

aws logs describe-resource-policies --region <REGION> --query "resourcePolicies\[\].\[policyName,policyDocument\]" --output text

A log group fails if a policy contains an Allow statement whose Principal is \* (or {"AWS": "\*"}) without a condition limiting access to your account, and whose Resource is \* or includes the log group's ARN.

**Implementation Steps**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open **AWS CloudShell** from the console toolbar in the affected region.
    
3.  Identify the resource policy that grants public access, using the Test Plan command.
    
4.  If the access is not needed, delete the policy with the CLI command below.
    
5.  If an AWS service or account still needs access, replace the policy with one that names the specific principal, the specific log group ARN and a condition such as aws:SourceAccount.
    
6.  Repeat for each affected policy in each region in use.
    

**CLI:**

Delete the public resource policy:

aws logs delete-resource-policy --region <REGION> --policy-name <POLICY\_NAME>

If access is still needed, save the following restricted policy as policy.json (example for a service that writes logs):

{"Version": "2012-10-17", "Statement": \[{"Effect": "Allow", "Principal": {"Service": "<SERVICE\_PRINCIPAL>"}, "Action": \["logs:CreateLogStream", "logs:PutLogEvents"\], "Resource": "<LOG\_GROUP\_ARN>", "Condition": {"StringEquals": {"aws:SourceAccount": "<ACCOUNT\_ID>"}}}\]}

Create or replace the policy with the restricted version:

aws logs put-resource-policy --region <REGION> --policy-name <POLICY\_NAME> --policy-document file://policy.json

**Backout Plan**

Before making changes, save the current policy document:

aws logs describe-resource-policies --region <REGION> --query "resourcePolicies\[?policyName=='<POLICY\_NAME>'\].policyDocument" --output text > policy-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 **AWS CloudShell** from the console toolbar in the affected region.
    
3.  Restore the saved policy with the CLI command below.
    

**CLI:**

aws logs put-resource-policy --region <REGION> --policy-name <POLICY\_NAME> --policy-document file://policy-backup.json

Note: restoring the original policy makes the log groups publicly accessible again. Use it only as a temporary measure while restricted access is arranged.

**Reference**

-   [https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-access-control-overview-cwl.html](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-access-control-overview-cwl.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/logs/put-resource-policy.html](https://docs.aws.amazon.com/cli/latest/reference/logs/put-resource-policy.html)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/logs/describe-resource-policies.html](https://docs.aws.amazon.com/cli/latest/reference/logs/describe-resource-policies.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.