Configuring CloudFront to Securely Serve Confidential Documentation on AWS
Question
You are building a large-scale confidential documentation web server on AWS and all of the documentation for it will be stored on S3
One of the requirements is that it cannot be publicly accessible from S3 directly, and you will need to use CloudFront to accomplish this.
Which of the methods listed below would satisfy the requirements as outlined? Choose an answer from the options below.
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D.Answer - B.
If you want to use CloudFront signed URLs or signed cookies to provide access to objects in your Amazon S3 bucket, you probably also want to prevent users from accessing your Amazon S3 objects using Amazon S3 URLs.
If users access your objects directly in Amazon S3, they bypass the controls provided by CloudFront signed URLs or signed cookies, for example, control over the date and time that a user can no longer access your content and control over which IP addresses can be used to access the content.
In addition, if users access objects both through CloudFront and directly by using Amazon S3 URLs, CloudFront access logs are less useful because they're incomplete.
Option A is invalid because you have to create a CloudFront identity and not an IAM user.
Options C and D are invalid because individual policies and bucket policies cannot be used to restrict access via CloudFront.
For more information on Origin Access Identity, please see the below Link:
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.htmlTo prevent direct access to the S3 bucket holding confidential documentation and allow access only through CloudFront, we need to use CloudFront as a content delivery network (CDN) to distribute content from the S3 bucket. To accomplish this, we have to create a CloudFront distribution and configure it to use the S3 bucket as its origin.
To satisfy the requirement that the documentation cannot be publicly accessible from S3 directly, we need to implement appropriate access control mechanisms. One way to achieve this is to use an Origin Access Identity (OAI) for CloudFront and grant access to the objects in your S3 bucket to that OAI.
Option B is the correct answer. Here's a more detailed explanation of the other options:
Option A: Creating an IAM user for CloudFront and granting access to the S3 bucket objects is not a recommended approach because the IAM user has to be authenticated to access the objects. CloudFront doesn't use IAM user credentials to access S3 bucket objects, so this method won't work.
Option C: Creating individual policies for each bucket where the documents are stored is not scalable, especially if you have many buckets. It's also not recommended because it's difficult to manage policies for multiple buckets, and you can't easily update the policies.
Option D: Creating an S3 bucket policy that lists the CloudFront distribution ID as the Principal and the target bucket as the Amazon Resource Name (ARN) is not recommended. This is because the CloudFront distribution ID can be easily guessed or discovered, making it possible for an attacker to gain direct access to the S3 bucket. It's also difficult to manage bucket policies for multiple buckets, and you can't easily update the policies.
In summary, the recommended approach is to create an OAI for CloudFront and grant access to the S3 bucket objects to that OAI. This approach ensures that the S3 bucket is not publicly accessible and allows secure access to the confidential documentation via CloudFront.
