S3 access control: bucket policies, Block Public Access, ACLs

Try 3 questions on this

Pick an answer to see why each option is right or wrong.

1. A company lets each team edit the bucket policies of its own Amazon S3 buckets in one AWS account, and some policies grant access to partner accounts, which must keep working. The security team must make sure that no one who can edit a bucket policy can make a bucket public, even with full permissions on that bucket. Two buckets already have public statements that must stop granting public access. Which combination of steps should a solutions architect take to meet these requirements? (Select TWO.)

   Right. In the game that’s Renown for your Design Secure Architectures building.

   Not that one: D,E is right. In the game your Design Secure Architectures building would lose a little Renown, and this question would come back later.

   Your answerA.Apply the Bucket owner enforced setting to every bucket so that policies cannot grant public access.Bucket owner enforced disables ACLs. Bucket policies keep working exactly as before, including public ones.Your answerB.Turn on BlockPublicPolicy in each bucket's own Block Public Access settings, so that every team's bucket rejects any new bucket policy that allows public access.A bucket-level setting can be undone through the bucket itself: "users who have permission to change a bucket policy could insert a policy that allows them to disable the block public access settings for the bucket."Your answerC.Turn on BlockPublicAcls in the account-level Block Public Access settings, so that any bucket policy that grants public access is rejected.BlockPublicAcls rejects public ACLs in PutBucketAcl, PutObjectAcl and PutObject calls. It does not evaluate bucket policies.Your answerD.Turn on BlockPublicPolicy in the account-level Block Public Access settings, so that PutBucketPolicy calls with public policies are rejected for every bucket.Your answerE.Remove the public statements from the two existing bucket policies, and keep the statements that grant access to the partner accounts.

   Show the full explanation and doc quotes

   BlockPublicPolicy causes Amazon S3 "to reject calls to PutBucketPolicy if the specified bucket policy allows public access", and the page is specific about where it must be set: "To use this setting effectively, we recommend that you apply it at the account level." "If this setting is enabled for the entire account, rather than for a specific bucket, Amazon S3 blocks public policies even if a user alters the bucket policy to disable this setting." Existing policies are untouched - "Enabling this setting doesn't affect existing access point or bucket policies" - so the public statements have to be removed, which also keeps partner access, since a policy granting fixed accounts is not public.

   Written from docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html

2. A partner account uploads to a bucket whose Object Ownership is Bucket owner enforced, with all four account-level Block Public Access settings on and a bucket policy granting the partner s3:PutObject. The partner's tool sends a canned ACL of bucket-owner-read with every PutObject, and every upload fails. Uploads must succeed and the bucket must not become public. Which approach will meet these requirements?

   Right. In the game that’s Renown for your Design Secure Architectures building.

   Not that one: B is right. In the game your Design Secure Architectures building would lose a little Renown, and this question would come back later.

   Your answerA.Change Object Ownership to Object writer for the bucket, because that setting accepts and honours the ACLs the partner's tool sends.Makes the uploads succeed and hands ownership of every object to the partner account, which is what Bucket owner enforced was chosen to avoid.The answerB.Have the partner send no ACL, or the bucket-owner-full-control canned ACL, and leave both settings as they are.Two features can reject an upload that carries an ACL, and the one rejecting this upload is the quieter of the two. Block Public Access rejects ACLs that are PUBLIC: "PutObject calls fail if the request includes a public ACL"Your answerC.Grant the partner s3:PutObjectAcl in the bucket policy, so that the ACL the tool sends is allowed alongside the upload.A permission does not re-enable a disabled mechanism. With ACLs disabled, requests to set ACLs fail whatever the policy allows.Your answerD.Turn off BlockPublicAcls for the account, because that setting is what makes a PutObject call fail when the request includes an ACL.Loosens the account's public-access protection to fix an error it is not causing. bucket-owner-read is not a public ACL.

   Show the full explanation and doc quotes

   And public means an ACL that "grants any permissions to members of the predefined AllUsers or AuthenticatedUsers groups". bucket-owner-read grants nothing to either. Object Ownership is what is failing the call: with Bucket owner enforced, "your bucket accepts only PUT requests that do not specify an ACL or PUT requests with bucket owner full control ACLs... PUT requests that contain other ACLs (for example, custom grants to certain AWS accounts) fail and return a 400 error with the error code AccessControlListNotSupported." Held alone, the ownership fact suggests re-enabling ACLs; held alone, the Block Public Access fact suggests weakening the account. The upload itself is the thing to change, and both settings stay.

   Written from docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html

3. A partner must be able to upload one file to an S3 bucket at any point over the next five days, without an AWS account of their own. A service running on an EC2 instance generates a presigned URL with an expiration of five days and emails it to them, and the partner reports that the link stops working after a few hours. Which solution meets these requirements?

   Right. In the game that’s Renown for your Design Secure Architectures building.

   Not that one: A is right. In the game your Design Secure Architectures building would lose a little Renown, and this question would come back later.

   The answerA.Presign the URL with delegated IAM user credentials and Signature Version 4, which allows up to seven days.A presigned URL has two clocks and the team is only watching one. The requested expiration is capped by the credential behind it: "Temporary security credentials - Can't be valid for longer than the credentials themselves... IAM role credentials used by Amazon EC2 instances - Valid for the duration of the role credentials (typically 6 hours)"Your answerB.Raise the maximum session duration on the instance's role to five days, so that the credentials outlast the presigned URL.A role session cannot be stretched to five days, and the URL's ceiling comes from the credential's lifetime rather than a setting on the role.Your answerC.Generate the presigned URL from the Amazon S3 console instead, choosing five days as the validity when the URL is created.A presigned URL created in the console is capped at 12 hours from creation, which is shorter than what they have now.Your answerD.Keep generating the URL from the instance's role and set the expiration to five days, because the expiration you specify is what governs the URL's life.That is what the team is already doing; the URL dies with the instance role's credentials whatever expiration is requested.

   Show the full explanation and doc quotes

   And "in general, a presigned URL expires when the credential you used to create it is revoked, deleted, or deactivated. This is true even if the URL was created with a later expiration time." Only one credential type reaches five days: "IAM user - Valid up to 7 days when you're using AWS Signature Version 4. To create a presigned URL that's valid for up to 7 days, first delegate IAM user credentials (the access key and secret key) to the method you're using to create the presigned URL."

   Written from docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html