Security best practices

I realize the problem with giving S3stat full access to a bucket in the event something happens over there which compromises security so I've created a new bucket on S3 which contains the log files from another web enabled bucket. I've created a new IAM user (and keys) specifically for a3stats and added it to a new AWS group that only has access to the logging bucket and not the bucket serving out the website.

This seems like a pretty solid way to restrict s3stats but perhaps I'm missing something and need to investigate self managed mode. Can you see any potential security flaws with such a setup? Am I overlooking some other serious access flaw with this setup?


JB

Thursday, February 16, 2012




Sounds like at this point you're actually most of the way to being set up as Self Managed. In some ways you've actually done more work than you would have needed to for a Self Managed set up.

You might want to look into simply giving the s3stat@s3stat.com account the read/write permissions it needs for that new logging/reporting bucket and setting yourself up that way.

Unfortunately, the way you've done it won't actually help us out all that much. An account with access to that one bucket would only be able to set up logging on that one bucket (which is what we do with standard accounts, even if logging is already running). Without a way to see your other buckets, we wouldn't even be able to give you a list of them to pick which one you'd like to report on.

Making matters worse, IAM doesn't have a way to specify "this account can touch logging" permission, which makes them less helpful for our purposes.a

Jason Kester
Monday, February 20, 2012

[ reply to this topic ]   [ return to topic list ]

© 2024 Expat Software Back to Top