---
title: S3 bucket policies should restrict access from other AWS accounts
description: Datadog, the leading service for cloud-scale monitoring.
breadcrumbs: >-
  Docs > Datadog Security > OOTB Rules > S3 bucket policies should restrict
  access from other AWS accounts
---

# S3 bucket policies should restrict access from other AWS accounts
 
## Description{% #description %}

S3 bucket policies should restrict principals in other AWS accounts from performing risky administrative actions on the bucket. When a bucket policy contains unconditioned `Allow` statements granting cross-account access to security-sensitive actions, it creates a risk of security control manipulation, privilege escalation, or audit trail tampering by external accounts.

This rule flags unconditioned `Allow` statements where the statement's account differs from the bucket's account and the granted actions include any of the following:

- **Access control manipulation:** `s3:PutBucketPolicy`, `s3:DeleteBucketPolicy`, `s3:PutBucketAcl`, `s3:PutObjectAcl`
- **Security control weakening:** `s3:PutEncryptionConfiguration`, `s3:PutBucketPublicAccessBlock`, `s3:PutBucketVersioning`
- **Audit and retention bypass:** `s3:PutBucketLogging`, `s3:BypassGovernanceRetention`, `s3:PutObjectRetention`, `s3:PutObjectLegalHold`
- **Wildcards:** `s3:*`, `*`

A bucket **passes** this rule when every `Allow` statement in the bucket policy meets at least one of the following:

- The statement's account matches the bucket's account (same-account access).
- The granted actions do not include any of the risky actions listed above.
- The statement includes a condition (e.g., `aws:PrincipalOrgID`, `aws:SourceVpce`).

A bucket **fails** when any `Allow` statement grants a risky action to a different account without a condition.

`Deny` statements are not evaluated.

### Blind spots{% #blind-spots %}

- Conditioned `Allow` statements granting risky actions to other accounts are not flagged. If the condition does not adequately restrict access, cross-account privilege escalation may go undetected.
- This rule flags any cross-account access regardless of [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) membership. Legitimate same-org cross-account access that grants risky actions is flagged.

## Remediation{% #remediation %}

Review the S3 bucket policy and remove or restrict unconditioned `Allow` statements that grant risky administrative actions to other AWS accounts.

1. Open the [Amazon S3 console](https://console.aws.amazon.com/s3/) and select the affected bucket.
1. Navigate to the **Permissions** tab and under **Bucket policy**, choose **Edit**.
1. Identify any `Allow` statements where the principal belongs to a different AWS account and the granted actions include risky administrative operations such as `s3:PutBucketPolicy`, `s3:PutBucketAcl`, `s3:DeleteBucketPolicy`, `s3:PutBucketPublicAccessBlock`, `s3:PutBucketVersioning`, `s3:PutBucketLogging`, `s3:BypassGovernanceRetention`, or wildcards (`s3:*`, `*`).
1. Either remove the cross-account principal, restrict the granted actions to non-administrative operations, or add a condition key such as `aws:PrincipalOrgID` to scope access. For guidance on condition-based restrictions, refer to [AWS Organizations condition keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid).
1. Save the updated policy.

For a broader overview of S3 bucket policy management, refer to [Adding a bucket policy using the Amazon S3 console](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html).