Amazon S3: How safe is your bucket?

Earlier this summer, multiple companies discovered leaks of data they had stored on Amazon S3.

• Verizon confirmed a leak of data, including phone numbers, names, and some PIN codes, of some six million customers.
• World Wrestling Entertainment (WWE) leak exposed three million wrestling fans’ addresses, educational backgrounds, earnings, and ethnicities.
• Data analytics firm, Deep Root Analytics, inadvertently leaked the personal data of nearly 200 million Americans.

These leaks were mainly due to poorly configured S3 bucket permissions. It may sound simple to configure S3 access control so that only authorized personnel can have access to the appropriate data. And yet, we hear from so many of our customers that there are several aspects of Amazon S3 configuration that easily confuse their admins.

“Authenticated users” may not be who you think they are

For example, the AWS S3 built-in group Authenticated Users includes any user who has an Amazon AWS account. You may not want these users to be authorized to access your data on S3, and yet they will if your administrators grant access to Authenticated Users thinking that they are authorized users from your company.

It’s time to review your S3 security policies

Many Loggly customers archive their log data to Amazon S3. Based on the recent data leaks, we recommend that all Amazon S3 users review your configuration of S3 security policies, especially the access control. Here are some things to look for:

1. Amazon buckets are private by default. Carefully think through all possible implications before making them shared or public.
2. Create S3 bucket names that are not obvious or guessable.
3. Always encrypt your data in the bucket (e.g., your log data archived from Loggly).
4. Examine your identity and access management (IAM) policies and bucket policies to see who has access and if they really need it. Less is better.
5. Check if you can use Query String Authentication for your use case. A key benefit of such pre-signed URLs is that you can grant temporary access to your Amazon S3 resources.
6. Log all configuration changes using AWS CloudTrail, and set up alerts to fire when some S3 bucket in your account is made public or when encryption settings are changed. Send CloudTrail logs to Loggly to correlate and find all data across your stack that may be compromised if there is an S3 breach.
7. Periodically review your S3 policies when your team grows and as new team members come on board.

Here is some additional reading:

1. Amazon S3 access control overview
2. Amazon S3 bucket permission configuration

Loggly’s approach to log data and security

At Loggly, we take customer data security very seriously. All log data is transmitted securely from your system to ours using HTTPS or Transport Layer Security (TLS), with encryption using the latest SHA-256 certificate. Your account access is also authenticated using strong credentials. All interactions are held within secure sessions encrypted using TLS. You can also turn on multi-factor authentication (2FA/MFA) to add more security to your accounts. Loggly offers role-based access control for you to control which features and configuration settings each user is allowed to access. We are always on the lookout to make sure your data are protected.

Secure your S3 now

Amazon S3 is a powerful service, and it’s easy to use. But if you don’t pay attention to the security, there can be serious consequences. The steps I have described above don’t take a lot of resources to implement, so there’s no excuse for waiting!

Learn how using Loggly for AWS Log Analysis can help you run AWS better.

The Loggly and SolarWinds trademarks, service marks, and logos are the exclusive property of SolarWinds Worldwide, LLC or its affiliates. All other trademarks are the property of their respective owners.