Amazon S3 is an object storage service in the Amazon Web Services (AWS) cloud. S3 lets users create storage “buckets,” which are virtual containers for data. Users can upload virtually any type of information into the buckets, and each bucket can accommodate a nearly unlimited number of storage objects and total data capacity.

Unlike file systems, S3 buckets don’t have a hierarchy. Instead, you simply “dump” data into them (hence the “bucket” terminology) without having to worry about organizing the data in a particular way or creating folders or subfolders. Each data object receives a unique identifier, which human users and applications can use to view or modify data.

S3 isn’t the only data storage service on AWS. Other important AWS storage solutions include Elastic Block Storage, or EBS, which is designed primarily for providing persistent storage for virtual machines, and various database services, like Aurora and RDS.

However, whereas these other storage services are designed for specific use cases, S3 is the main general-purpose storage service that can accommodate almost any type of data in any format. That’s part of the reason why S3 is commonly used to store data in the AWS cloud. The fact that it costs just pennies per gigabyte to store data in S3 also contributes to its popularity.

Is S3 Secure?

There is nothing inherently insecure about AWS S3 itself. The underlying physical infrastructure used to host S3 buckets is just as secure as the rest of the infrastructure on the Amazon cloud. So is the software that Amazon uses to expose S3 storage infrastructure to users. Amazon manages the security of both the underlying infrastructure and the S3 delivery software as part of the AWS shared responsibility model.

However, Amazon doesn’t take responsibility for securing data that users upload to S3. That job falls to users, since only users can determine exactly what they store in S3 and how they manage their data once it’s in S3 buckets.

S3 Security Risks and Challenges

When working with S3, users can make a variety of mistakes that compromise the security of data stored in S3 buckets:

• Misconfigured access controls: The most serious security risk for S3 is access controls that allow sensitive data to be viewed or modified by parties that shouldn’t have access. For instance, if you accidentally configure an S3 bucket to be accessible to anyone on the Internet, you could expose sensitive data to the world at large.
• Lack of encryption: Data stored in S3 isn’t encrypted by default, and not all data stored in S3 should necessarily be encrypted. But in cases where there is no reason for data to remain unencrypted at risk, it should be encrypted. Failure to encrypt the data makes it easier for malicious actors to abuse it.
• Lack of data visibility: Sometimes, users may lose track of which data they are storing in S3 buckets. Or, they might mix sensitive and non-sensitive data in the same bucket, making it challenging to apply the appropriate security policies to the data. Issues like these result from a lack of visibility into how S3 is being used inside an organization and how data is organized inside S3 buckets.
• Malware inside S3 buckets: Since S3 is a storage service rather than a compute service, it can’t actually execute malware. However, malware that attackers manage to insert into storage buckets can be imported into VMs or other cloud resources where it can be executed. In that respect, malware poses a risk to S3.
• Insecure S3 integrations and connections: Any application or service that is configured to have access to your S3 buckets could serve as a vector of attack against S3 in the event that the application or service is compromised. For that reason, it’s critical to maintain visibility into which resources can connect to or integrate with S3 as well as to monitor them for vulnerabilities.

How to Secure S3

Securing S3 boils down to three key processes: configuring strong access controls, maintaining data visibility, and checking for insecure S3 connections.

1. Configure – and Validate – Strong S3 Access Controls

When configuring access policies for S3, adhere to the principle of least privilege by granting the fewest permissions necessary. Restrict data read and write privileges only to those specific users who need those permissions, and avoid granting public access to S3 buckets except where you have a specific reason to do so.

Just as important, scan your S3 access configurations on an ongoing basis to check for configuration oversights that could introduce risks. Even if you work hard to establish strong configurations from the start, mistakes as simple as a single errant keystroke when defining an Identity and Access Management (IAM) rule for S3 could cause policies to be applied to the wrong storage buckets or objects, leading to exposure of sensitive data.

In addition, because access requirements for data may change over time, ongoing S3 scans and audits help to ensure that your access control policies remain as secure as possible even as access needs evolve.

2. Know Your Data

A second key principle of S3 security is to gain visibility into what you’re storing in S3 and where your sensitive data lies. While you can, and should, endeavor to restrict sensitive data to S3 buckets that are locked down with strong access controls, there’s always a risk that users might inadvertently upload private information to S3 buckets designed to store public data, or that changes to access control configurations could expose sensitive data that was previously secure.

To guard against risks like these, continuously monitor the data inside S3 buckets to check for sensitive data and to assess whether the access controls in place over each bucket or data object are adequate based on the sensitivity of the data. Scanning can also help to identify malware inside your S3 buckets.

3. Monitor S3 Integrations and Connections

As noted above, it’s not just improperly managed data inside S3 that could create security risks. Problems could also arise if insecure applications, integrations, or plugins are able to access that data.

For this reason, it’s important to know which applications or other resources can connect to S3 data and what they can do with it. You’ll also want to know whether the applications that have access to your S3 buckets are themselves secure, because if an attacker compromises an app that can connect to sensitive S3 data, the attacker will be able to take control of the data in addition to the app.

AWS S3 Security Best Practices

Beyond the S3 security processes described above, there are several best practices to keep in mind when designing and managing S3:

• Configure multiple buckets: Although you can store a virtually unlimited number of data objects inside a single S3 bucket, it’s a better idea to configure multiple buckets – one for each type of data you need to manage. That way, you can apply granular access controls and security configurations to each bucket rather than having to try to secure each data object individually. The only downside to configuring multiple buckets is that most AWS accounts are limited to a total of 100 buckets – but in the majority of cases, that’s more than enough buckets to cover multiple data collections with varying security requirements.
• Enable encryption: As we noted, S3 doesn’t encrypt data by default, but you can choose to encrypt data. In most cases, you should set up encryption for data stored in S3 because encryption ensures that even if malicious parties do access your data, they won’t be able to read it. You should only leave data unencrypted if the users or applications that depend on the data require access to it in unencrypted form.
• Restrict write permissions: You can configure S3 access permissions such that users or applications can view but not modify data. In other words, you can give them read-only access. Configuring read-only access except for users who explicitly need to be able to modify data is a best practice because read-only access prevents malicious parties from injecting malware into S3 buckets or modifying the contents of sensitive buckets.
• Use S3 access logs: S3 access logs store records of who accessed data in S3 and what they did with it. Although access logging won’t prevent abuse of S3 data, it provides crucial visibility for detecting malicious activity inside S3 buckets quickly.

These practices will help you to ensure that your S3 storage environment is as secure as possible by default, but securing only your S3 storage may not be enough even in this context. You can dig in more on which are the AWS cloud security best practices and which ones to adopt in production.

Conclusion

S3 is a great solution for storing data. But because S3 doesn’t guarantee the security of data that users or applications upload, it’s essential to have a strategy in place for protecting against the various types of security risks – like misconfigured access controls or malware lurking inside storage buckets – that can impact S3.