How to Prevent an AWS Cloud Bucket Data Leak

When it comes to public cloud services, there's Amazon's AWS and then there's everyone else. With an estimated 39% market share, it's a rare cybersecurity professional who won't encounter AWS at some point in their career. And there's no question that protecting data in AWS begins with understanding bucket security.

By the most simple definition, a bucket is a place to put stuff. You can think of a bucket as a directory or a folder (depending on your point of reference), but there are two key things to know about any bucket you create. First, unlike many cloud resources, a bucket exists somewhere — you specify the geographic region where your bucket will sit. This is important if particular regulations and jurisdictions are important to you.

Next, there are a ton of ways to get stuff into and out of your bucket. This makes buckets incredibly useful — and also presents the most obvious security risks for bucket use.

Fortunately, from Amazon and a number of other sources scattered around the Internet, there are a handful of crucial practices that, if followed, will keep your data from sloshing out of its bucket and landing all over the web.

The Cautionary Tale
Recent cloud bucket data leak catastrophes like the Capital One breach show that there both cloud users and cloud service providers like AWS have roles to play in their own security. 

Capital One "gives us a very good example of how dangerous an improperly configured cloud environment can be," said John Burke, senior IT security engineer for Iberia Bank, in a recent Dark Reading webinar. "They've been a great example of a company that is cloud-first in everything that they do ... So they're a good example of what you can do in the cloud, but they're also a good example of what can happen if things go wrong. ... The takeaway from it is that you really have to know how all of this is configured in order to protect it correctly."  

"Just because misconfigurations is a customer problem doesn't mean that the [cloud service provider] vendors can't play a role there," says Cloud Security Alliance VP of Research John Yeoh. "Are they making sure that we have safe and secure default configurations? Are they giving us notifications? The bells should be ringing if we have sensitive information in a folder that's publicly exposed."

Fortunately, Amazon and other cloud platform providers are now doing some of the things Yeoh suggests. Here's what you need to know about the opportunities and the pitfalls.

Public Means Public
If you set up your first Amazon bucket and simply use the default configuration, you will create a reasonably secure place to leave your data. By default, an S3 bucket is private: to allow anyone (or everyone) to access your data, you have to explicitly grant them permission to do so. (This was not always AWS's default, but was an improvement made by the company for security purposes.)  

The thing is, if you want to grant access to an individual, you have to know a key piece of data about them — you have to know their user ID within the AWS environment. "Bob from accounting" is rarely, if ever, a valid user ID, so many users just set the access permission to "public" and hope that no bad people (or processes) will find and access their data. Most of us will have heard that hope is not a plan. It's a darned poor access control list (ACL) as well.

There are levels of "public" access that can be granted — from simple read privileges all the way up to full bucket administration. It's a sliding scale of badness from a security perspective, but even at its most basic the lesson is quite clear: Unless you really, truly, want anyone with a computing device to be able to at least see your data, don't set the bucket access to "public," and don't allow anyone else to do so either.

"Modern authentication is not a simple switch to enable," cautioned Burke. "So configuration of it must be done correctly or malicious actors are going to figure out a way to get around it." He also recommended enabling multifactor authentication for cloud instances and applications wherever it is available.

Policies, Policies
There are policies that govern human behavior and policies that govern bucket behavior. Let's begin by looking at the former and then discuss how those can have an impact on the latter.

One of AWS's great virtues is the ease with which buckets and assets can be created and configured. This is one of its greatest vulnerabilities, as well, because individuals with no security training (and little security awareness) can create, configure, and manage buckets along with the data stored in them. Those individuals need policies to guide them toward safe digital shores.

One of the most important policies is this: Public is public, private is private, and never the twain should meet. In practice, this means that any objects (data) that will be made public should be in a public bucket. Any objects in a private bucket should themselves be private. Huge problems can arise when private and public mix and mingle because it's all too easy to encounter the accidentally public object under those circumstances.

Next up should be a policy on who gets to set up buckets and put objects into those buckets. The key here is that individuals should only be allowed to move into an S3 bucket that data for which they are responsible. It's not really that security should have an easy individual to target with blame should something go wrong, but that any individual creating and populating a bucket should feel a sense of responsibility about the data and its fate.

Finally, there should be policy-based reviews of the public/private labeling of both objects and buckets on a regular basis. There have been too many stories of buckets set to "public" for web application development or third-party partner access reasons, then left in that configuration after the project ended, to feel comfortable with the idea of leaving a configuration in an unexamined state. Mandatory status reviews at the end of projects and encounters, and on a regular calendar basis, will go a long way toward limiting the damage of unintentional public status.

Configuration Matters
And then there are the questions of how individual buckets and their objects are configured. It begins with how access is configured and goes on from there. Depending on your application and organizational needs, access can be controlled through bucket policies, identity and access management (IAM policies), and ACLs. Each has its place, but the goal should be to simplify configuration as much as possible. Keep public and private separate (see above), use ACLs when small populations need access, and make use of groups whenever possible. These will help keep the access configuration as un-complicated as possible.

When you have access figured out, encrypt the contents of the bucket. AWS offers both its own encryption and a system for managing external encryption keys. Whichever you choose, make sure that an access breach will return nothing more than useless data to the attacker.

And as with all data and application information, keep a log of changes and access. AWS offers both types of logging through its CloudTrail service. While a full transaction log could quickly get unwieldy for a large public bucket, change logs are a must for all buckets and transaction logs are critical for sensitive data stored in buckets. Whether you use an AWS service like CloudWatch or an external service to analyze the logs, having the ability to track changes and activities will go a long way toward limiting the damage that configuration challenges can cause.

"There are some new companies out there now that are helping organizations to make sure that their AWS and cloud environments are secured and configured correctly," said Burke. He also recommends, a close look at cloud access security brokers (CASBs) for help. "CASBs will help you and the security team detect things like password spray attacks, anomalous activity, login attempts from foreign or hostile nations. They can also help identify other cloud applications, so if your employees are using cloud apps that may or may not be sanctioned … you can use a CASB to identify those."

Related Content: