As long as you know the right URL, anyone with access to the internet could retrieve all the data that was left online by marketing analytics company Alteryx. This is the second major exposure of data stored and improperly managed in the Amazon Web Services S3 storage service.
In the Alteryx case, it was apparent that the firm had purchased the information from Experian, as part of a data set called ConsumerView. Alteryx uses this data to provide marketing and analytics services. It put the data in AWS S3—and forgot to lock the door.
In November, files detailing a secret US intelligence collection program were leaked in the same manner, also stored in S3. The program, led by US Army Intelligence and Security Command, a division of the National Security Agency, was supposed to help the Pentagon get real-time information about what was happening on the ground in Afghanistan in 2013 by collecting data from US computer systems on the ground. Much as in the Alteryx case, the data was exposed by a misconfigured S3 bucket.
Here’s the deal: AWS defaults to closing access to data in S3, so in both cases someone had to configure S3 to expose the data. Indeed, S3 has the option to provide data over the web, if configured to do so. So, this is not an AWS issue, but one of stupidity, naïveté, or ignorance by people running their S3 instances.
Public cloud providers often say that they are not responsible for ineffective, or in these cases nonexistent, security configurations that leave data exposed. You can see why.
In these cases, white hat hackers informed those in charge about the exposure. But I suspect that many other such mistakes have been uncovered by people who quietly collect the data and move on into the night.
The fix for this is really common sense: Don’t actively expose data that should not be exposed. You need to learn about security configurations and processes before you bring the public cloud into your life. Otherwise, this kind of avoidable stuff will keep happening.