Amazon Web Services is the juggernaut in the cloud provider space, and with any piece of technology comes the need for proper security. In this regard, AWS is no exception. In this piece, we will shortly discuss the latest breaches of public S3 buckets, provide an overview of the two ways to protect data in these storage spaces, and discuss how the new Amazon Secrets Manager utility can assist in securing AWS cloud applications.
Recent breaches
There have been a couple of recent instances in which company S3 buckets have been read by nefarious actors. Verizon and Accenture both presumably accidentally left their S3 storage areas readable to the public. All of the breaches resulted in personal data getting into the hands of bad actors, and all of the breaches were a result of a simple misconfiguration that allowed access to things that should have been walled off.
One might argue that this sort of attack is because of the nature of the S3 service: a storage repository where any connected device can put and retrieve information, whether that is logs, files, reports, databases, or any other object. By virtue of having a service readable and writeable from anywhere in the world, this sort of thing is bound to happen, one might say. But that is not true: even the lowest functionality devices, such as sensors, can be configured to authenticate via a put request to an S3 bucket.
Put simply: this shouldn’t happen. There is no reason to have a world-readable and world-writeable S3 bucket. Preventing this type of lift of private data requires making sure one simple setting is configured as is the default when setting up a new Amazon S3 instance: on step 3 of the Create Bucket wizard, make sure that under the Manage public permissions setting, the “Do not grant public read access to this bucket (recommended)” section is checked. To be honest, it is beyond me why projects make it into production with this setting at anything but its secure default, but too many breaches—and it’s a stretch to call the breaches because accessing the data is essentially as simple as browsing to a public website—have shown that for whatever reason, companies are not being careful enough in their S3 configurations.
Two ways of protecting simple storage service (S3) buckets
Of course, you will likely want a finer grained access controls than just “don’t let the public in.” There are a couple of options for protecting S3 buckets that go beyond that one selection:
- You can set up IAM policy and roles, which means you set up multiple users within your Amazon account and assign them permissions. This means that no one without the specified credentials can enter the bucket. Amazon has more information on bucket policies here
- Server-side encryption allows you to securely store data at rest, as Amazon encrypts and decrypts data based on the type of encryption key that you select: you can provide your own key, allow Amazon S3 to generate your key, or allow the sophisticated AWS key management service to provide you with enterprise class key management and audit trails
Ultimately, the best practice here is to use both IAM with well-defined policy roles and SSE encryption with a user generated key.
Looking at the Amazon Secrets Manager
Diving a little further into AWS cloud security, the Amazon Secrets Manager is a tool that allows you to enhance the security of your AWS applications. By handling secure key rotation automatically, allowing simpler access to AWS identity and access management (IAM) policies, and storing and distributing keys securely, the Secrets Manager product offers an AWS-integrated way to follow industry best practices in securing cloud applications. Inside Secrets Manager, you can store API keys, passwords, database or other credentials, and other secrets, and then track how they are used and oversee their entire lifecycle within one utility.
The real benefit of Secrets Manager is that developers can call the Secrets Manager API for credential use instead of hard coding secrets inside of their application or scripts; many breaches have occurred when sensitive credentials have been discovered in plain text within the source code of applications, configuration files, or scripts.
Currently, Secrets Manager is available in the following AWS regions and is a pay-for service that is charged per secret and per 10,000 API calls: US East (N. Virginia); US East (Ohio); US West (N. California); US West (Oregon); Asia Pacific (Mumbai); Asia Pacific (Seoul); Asia Pacific (Singapore); Asia Pacific (Sydney); Asia Pacific (Tokyo); Canada (Central); EU (Frankfurt); EU (Ireland); EU (London); South America (São Paulo).
Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.
