By using AWS re:Post, you agree to the Terms of Use
/Avoid recursive S3 server access logging + TrustedAdvisor warning/

Avoid recursive S3 server access logging + TrustedAdvisor warning

2

Hi, I'm enabling server access logging on all S3 buckets, as per SecurityHub recommendations. But now it also wants access logging on the access logging buckets and it warns (very good) that source and destination bucket cannot be the same. What is the preferred solution, here, then? Because even when one would send server access logs for the server access log buckets to another bucket in the same account, it still remains a recursion problem. It seems a bit odd to need to have access logging enabled on the access logging buckets.

Another issue I don't understand iss that, although S3 server access logs are appearing as they should in the designated server access log buckets, I notice that TrustedAdvisor points out a problem that there is a problem of "Write Not Enabled" for all of the S3 buckets and that, therefore, Server Access Logging is wrongly configured for all S3 buckets in the account (even though it actually works perfectly well). The permissions on the server access logging buckets also correctly give PutObject access to logging.s3.amazonaws.com. Is this a known problem, in any way?

Thanks!

1 Answers
0

Hello, thank you for your post.

For your first question, you can safely ignore the SecurityHub recommendation due to the recursion scenario you described.

As for your second question about the warning in Trusted Advisor, to make the "Write Not Enabled" alert go away, please try enabling the following ACL permissions for the affected buckets for the "S3 log delivery group":

Objects: Write (WRITE)
Bucket ACL: Read (READ_ACP)

You can read more about managing S3 bucket ACLs in our documentation[1].

Please let me know if you have any questions.

References: [1] https://docs.aws.amazon.com/AmazonS3/latest/userguide/managing-acls.html

answered 3 months ago
  • Thanks for the answer! I'll ignore the SecurityHub recommendation.

    As for the second one, hmm, I'd rather stay away from ACLs in my S3 buckets, though, considering "A majority of modern use cases in Amazon S3 no longer require the use of ACLs, and we recommend that you disable ACLs except in unusual circumstances where you need to control access for each object individually." (which I had read before and also quoted in the link you sent). I'd rather do everything with Bucket Policies, which seems to be the recommended approach.

    If TrustedAdvisor cannot deal with this, then so be it, I guess. Then TrustedAdvisor has a problem, which I should report.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions