10 S3 Best Practices for Improving AWS Security

by Hannah Grace Holladay / April 4th, 2022

The Amazon Simple Storage Service (Amazon S3) celebrated its 15th birthday in 2021. S3 was conceived as a straightforward scalable object storage system developers could use without concerning themselves with files systems—everything on S3 is an addressable object in a bucket.

S3 quickly rose to dominate the object storage space. Because it is used everywhere, AWS S3 security as well as the privacy and confidentiality of the data businesses store in it are critical. A vulnerability in S3 would inevitably lead to data exposure on an unprecedented scale. Amazon understands this and has built security features into S3 and integrated it with security and privacy services such as AWS Identity and Access Management (IAM).

But, as with all cloud services, security is partially the responsibility of users. If S3 buckets are poorly configured, sensitive data may be exposed. This article explores ten S3 best practices your business can implement to avoid becoming the star of the next big S3 data leak story.

Ensure S3 Buckets are Not Publicly Accessible

Data leaks from S3 buckets often occur because a bucket containing sensitive files is configured to allow public access. This means anyone on the internet who knows where the bucket is can access the files. Bad actors have created tools that make it straightforward to discover buckets with public read permissions.

When buckets are first created, they are not publicly accessible. However, rather than setting up secure Bucket Policies or managing access with IAM identities, users often configure buckets for public access. This is often done for convenience: the user wants a group of people to access the data and doesn’t understand how to provide that access securely.

To check whether your buckets are publicly accessible, log into the S3 Console, click on a bucket, and select the permissions tab. Access permissions are displayed at the top. The prominent “Block public access” setting revokes the bucket’s public access configuration immediately.

You can also use the KirkpatrickPrice AWS Security Scanner to check for insecure S3 bucket permissions and other AWS cloud security vulnerabilities.

Configure Least Privilege Access

Removing public access is an essential step towards better AWS S3 security, but it is only the first step. In addition to ensuring that data can’t be accessed by everyone, you should ensure it can only be accessed by those who need the data. For example, if you want to share data in a bucket with a third party, they may only need read permissions and not write permissions. 

There are several ways to configure access permissions on buckets, but you should ordinarily use either bucket policies or IAM identities.

Both methods improve Amazon S3 security, but IAM identities are more flexible and granular. As a general rule, it is preferable to use IAM identities as part of a comprehensive identity and access management strategy. A third access control option is Access Control Lists (ACLs); however, Amazon recommends using bucket policies or IAM identities instead.

Implement S3 Encryption At Rest

Data stored in S3 buckets should be encrypted. Encryption ensures the data cannot be read if it is exposed through a vulnerability or misconfiguration. S3 provides three server-side encryption options:

  • SSE-S3 — encryption with keys managed by the S3 service.
  • SSE-KMS — encryption using keys stored in AWS Key Management Service.
  • SSE-C — encryption using keys provided by the customer.

Any of these options significantly improve security compared to storing unencrypted data in S3. However, SSE-KMS gives the user more control over their keys, allowing them to, for example, rotate keys as required.

Implement S3 Encryption in Transit

In addition to encrypting data at rest in Amazon S3, it should be encrypted in transit as it moves over the network. Data is automatically encrypted within the AWS network, but users should consider leveraging SSL/TLS when moving data across external networks, including the internet.

Store S3 Credentials Securely

If your applications access data stored in S3 buckets via the API, they will need to authenticate. To do so, they will use an AWS access key, a long-term credential associated with an IAM user that is used for programmatic authentication.

Improper use of AWS access keys can create security vulnerabilities. One common mistake is to embed access keys in code. Access keys embedded into code and then shared on version control platforms have been the root cause of many data leaks.

AWS access keys should be securely stored in AWS Secrets Manager, as we discussed in depth in How to Keep AWS Access Keys and Other Secrets Safe.

Use IAM Roles for Temporary S3 Access

Roles are IAM identities with a set of permissions. However, roles are not associated with an individual user, although users and other entities can assume a role to take on its permissions. In this context, the main benefit of roles is that they can be used to create temporary credentials which expire after a specified period, in contrast to IAM users’ access keys, which are permanent until deleted.

Enable Multi-Factor Authentication for IAM Users

Multi-factor authentication adds an extra layer of security to the standard username and password authentication. With MFA enabled, users must supply an additional factor of authentication—a one-time code or a hardware security key. Usernames and passwords can leak or be shared inappropriately. TFA ensures that accounts remain secure even if credentials are exposed.

Enable S3 Access Logs

Access logs allow administrators to identify unusual and unexpected access patterns that may indicate a security breach. They are also useful when analyzing security incidents to discover which data has been exposed, information that may be essential to fulfilling regulatory requirements.

S3 does not ordinarily log who has accessed data and which data they have accessed, but users can activate access logs. Amazon will log access requests and store the resulting log files in a different S3 bucket. The log storage bucket should have strict access permissions to ensure bad actors can’t alter the log or use the information it contains to plan an attack.

Classify Data Stored in S3 Buckets

Many regulatory standards govern the secure storage of sensitive data, particularly health data, financial data, and personally identifiable information (PII). S3 is a viable option for storing sensitive data, if correctly configured. But to be compliant, it’s important to know which data you’re storing in the first place—accidentally dumping a database full of PII in a bucket with broad access permissions is likely to result in compliance and audit failures.

Before data is stored in S3, it should be classified and subject to a risk assessment so that businesses are aware of what they are storing and the associated risks. Amazon provides a service that can help businesses to discover sensitive information in S3 buckets. Amazon Macie is a data privacy service that uses machine learning and pattern matching to automatically identify sensitive data and alert users about insecure access permissions.

Verify S3 Bucket Configurations

Our last Amazon S3 security best practice is to check bucket configurations and IAM permissions regularly. Over time, your AWS environment will evolve from its initial conditions. 

Partner with KirkpatrickPrice to Improve Your S3 Security

The KirkpatrickPrice AWS Security Scanner and cloud security audits help businesses verify their cloud security and privacy. To learn more, browse our extensive cloud security resources or contact an information security specialist today.

Share Tweet Share Email

Related Posts