AWS AmazonS3 medium security documentation change
Summary
Expanded documentation about prerequisites for disabling ACLs, including detailed guidance on migrating ACL permissions to bucket policies, identifying ACL-dependent requests, and updating policies with ACL-related conditions. Added examples and explicit warnings about required configuration changes.
Security assessment
The changes address security implications of ACL usage by emphasizing migration to bucket policies and preventing misconfigurations that could lead to access control failures. Specific security evidence includes warnings about failed requests due to invalid ACL configurations and guidance to prevent unintended access through policy updates.
Diff
diff --git a/AmazonS3/latest/userguide/about-object-ownership.md b/AmazonS3/latest/userguide/about-object-ownership.md index f3322f579..dc63542eb 100644 --- a/AmazonS3/latest/userguide/about-object-ownership.md +++ b/AmazonS3/latest/userguide/about-object-ownership.md @@ -98 +98 @@ Before you disable ACLs for an existing bucket, complete the following prerequis - * [Review bucket and object ACLs and migrate ACL permissions](./object-ownership-migrating-acls-prerequisites.html#object-ownership-acl-permissions) +### Review bucket and object ACLs and migrate ACL permissions @@ -100 +100 @@ Before you disable ACLs for an existing bucket, complete the following prerequis - * [Identify requests that required an ACL for authorization](./object-ownership-migrating-acls-prerequisites.html#object-ownership-acl-identify) +When you disable ACLs, permissions granted by bucket and object ACLs no longer affect access. Before you disable ACLs, review your bucket and object ACLs. @@ -102 +102 @@ Before you disable ACLs for an existing bucket, complete the following prerequis - * [Review and update bucket policies that use ACL-related condition keys](./object-ownership-migrating-acls-prerequisites.html#object-ownership-bucket-policies) +If your bucket ACLs grant read or write permissions to others outside of your account, you must migrate these permissions to your bucket policy before you can apply the Bucket owner enforced setting. If you don't migrate bucket ACLs that grant read or write access outside of your account, your request to apply the Bucket owner enforced setting fails and returns the [InvalidBucketAclWithObjectOwnership](./object-ownership-error-responses.html#object-ownership-error-responses-invalid-acl) error code. @@ -103,0 +104 @@ Before you disable ACLs for an existing bucket, complete the following prerequis +For example, if you want to disable ACLs for a bucket that receives server access logs, you must migrate the bucket ACL permissions for the S3 log delivery group to the logging service principal in a bucket policy. For more information, see [Grant access to the S3 log delivery group for server access logging](./object-ownership-migrating-acls-prerequisites.html#object-ownership-server-access-logs). @@ -104,0 +106 @@ Before you disable ACLs for an existing bucket, complete the following prerequis +If you want the object writer to maintain full control of the object that they upload, object writer is the best Object Ownership setting for your use case. If you want to control access at the individual object level, bucket owner preferred is the best choice. These use cases are uncommon. @@ -105,0 +108,72 @@ Before you disable ACLs for an existing bucket, complete the following prerequis +To review ACLs and migrate ACL permissions to bucket policies, see [Prerequisites for disabling ACLs](./object-ownership-migrating-acls-prerequisites.html). + +### Identify requests that required an ACL for authorization + +To identify Amazon S3 requests that required ACLs for authorization, you can use the `aclRequired` value in Amazon S3 server access logs or AWS CloudTrail. If the request required an ACL for authorization or if you have `PUT` requests that specify an ACL, the string is `Yes`. If no ACLs were required, or if you are setting a `bucket-owner-full-control` canned ACL, or if the requests are allowed by your bucket policy, the `aclRequired` value string is "`-`" in Amazon S3 server access logs and is absent in CloudTrail. For more information about the expected `aclRequired` values, see [aclRequired values for common Amazon S3 requests](./acl-overview.html#aclrequired-s3). + +If you have `PutBucketAcl` or `PutObjectAcl` requests with headers that grant ACL-based permissions, with the exception of the `bucket-owner-full-control` canned ACL, you must remove those headers before you can disable ACLs. Otherwise, your requests will fail. + +For all other requests that required an ACL for authorization, migrate those ACL permissions to bucket policies. Then, remove any bucket ACLs before you enable the bucket owner enforced setting. + +###### Note + +Do not remove object ACLs. Otherwise, applications that rely on object ACLs for permissions will lose access. + +If you see that no requests required an ACL for authorization, you can proceed to disable ACLs. For more information about identifying requests, see [Using Amazon S3 server access logs to identify requests](./using-s3-access-logs-to-identify-requests.html) and [Identifying Amazon S3 requests using CloudTrail](./cloudtrail-request-identification.html). + +### Review and update bucket policies that use ACL-related condition keys + +After you apply the Bucket owner enforced setting to disable ACLs, new objects can be uploaded to your bucket only if the request uses bucket owner full control ACLs or doesn't specify an ACL. Before disabling ACLs, review your bucket policy for ACL-related condition keys. + +If your bucket policy uses an ACL-related condition key to require the `bucket-owner-full-control` canned ACL (for example, `s3:x-amz-acl`), you don't need to update your bucket policy. The following bucket policy uses the `s3:x-amz-acl` to require the `bucket-owner-full-control` canned ACL for S3 `PutObject` requests. This policy _still_ requires the object writer to specify the `bucket-owner-full-control` canned ACL. However, buckets with ACLs disabled still accept this ACL, so requests continue to succeed with no client-side changes required. + + + { + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "Only allow writes to my bucket with bucket owner full control", + "Effect": "Allow", + "Principal": { + "AWS": [ + "arn:aws:iam::111122223333:user/ExampleUser" + ] + }, + "Action": [ + "s3:PutObject" + ], + "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", + "Condition": { + "StringEquals": { + "s3:x-amz-acl": "bucket-owner-full-control" + } + } + } + ] + } + +However, if your bucket policy uses an ACL-related condition key that requires a different ACL, you must remove this condition key. This example bucket policy requires the `public-read` ACL for S3 `PutObject` requests and therefore must be updated before disabling ACLs. + + + { + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "Only allow writes to my bucket with public read access", + "Effect": "Allow", + "Principal": { + "AWS": [ + "arn:aws:iam::111122223333:user/ExampleUser" ] + }, + "Action": [ + "s3:PutObject" + ], + "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", + "Condition": { + "StringEquals": { + "s3:x-amz-acl": "public-read" + } + } + } + ] + }