I need some clarification on a question I recently faced in a practice test.
I need to check if an object put in the bucket is open for public access and proactively change the object’s ACL (to make it private).
As per the above link I can check the S3 event s3:ObjectCreated:Put and trigger a Lambda function to change the object’s permission. In the above link I can see that ‘S3 event notifications can be lost at times in rare occasions’.
But I can also use just the CloudTrail logs or CloudTrail events in CloudWatch to call a Lambda function to change the object’s ACL.
So between S3 Event Notifications VS CloudTrail (i.e. set up to log the S3 event) VS CloudTrail events in CloudWatch, which is the best option and why?
I understand that CloudTrail logs goes to a S3 bucket, which again needs to be analysed/parsed to take a retrospective action whereas CloudTrail events in CloudWatch is faster to action-on, is that right?
Can some one clarify this.
First, my brain looks at your scenario and – despite the fact that it might be a question deliberately contrived to see what you know about S3 event notification – it makes we wonder if the writer understands S3 permissions.
S3 security is probably the number one customer screw-up in AWS. As such, I now have to give mandatory security sermon.
Any object that you PUT into a bucket automatically has default ACLs, and are not publicly accessible. Period. Full stop. No need to check anything. No need to change anything to make it non-public.
"But what if I have a bucket policy that makes things public – either in the entire bucket or only a prefix of that bucket – and I don’t want a new object that I am PUT-ing in that bucket to be public?"
THEN YOU SHOULDN’T HAVE PUT AN OBJECT THAT YOU DON’T WANT PUBLICLY ACCESSIBLE IN A BUCKET THAT MAKES OBJECTS PUBLICLY ACCESSIBLE!!!
Second, (and back to S3 notification) in AWS, where there are many different ways to get something done, the "best option" varies from case to case – which is why we expect architects to know this stuff. Any one of the mechanisms you mentioned above can work. Any of the mechanisms you mentioned above are still ultimately triggered by the S3 event notification subsystem and are subject to the "rare occasions" mentioned in that doc.
If I had to implement that, my questions would be A) is which method will be the easiest to implement, and B) how aggressively do I want to build something to follow up and find any of those "rare occasions".