Now that we’ve explored the familiar form of SaaS file sharing, let’s compare it to the very different ways that storage objects in IaaS/PaaS clouds are shared (e.g., Amazon S3 buckets, Azure blobs, Google Cloud storage). All of these objects begin with a much more controlled default. Only the owner of the object has access—the opposite of the starting point for SaaS. The world is shut out; if the owner of the object wants to share any of that content with anyone else, they have to intentionally change the access control list.
Making such a change is usually very easy. The owner might log into the console and navigate to the storage object’s properties menu and select “change access control.” In many cases, the next step is too tempting to resist: thoughtlessly taking the shortcut of granting the world at least read-only access or maybe even read/write access.
Whenever you see stories in the news about leaky buckets or sensitive information discovered in Azure blobs, somebody took the shortcut and then forgot about it. They needed to make the information temporarily available—to another party or to an application—and they created a simple access control list that exposed the object to the world. Unlike with SaaS, here the security issue originates from an intentional change made to the default setting.
You could implement more sophisticated policies on these objects than just simple access control lists. Unfortunately, the more complicated policies often involve writing a small bit of JavaScript object notation (JSON) code, a difficult language to compose and parse. Its notation is inscrutable and unforgivable, and conceptualizing the effective access control is nigh impossible because you just can’t see it when you’re staring at line after line of indented curly braces. As a result, people tend to avoid JSON when not incorporating access controls into other application codes.
My suspicion is that those who take the shortcut aren’t aware of the ramifications. One is that they’re exposing sensitive information to just about anybody who might come along and find it—and don’t think there aren’t ways to do that. There are tools on the internet that will scan for open objects across the entire Amazon S3 and Azure blob storage namespaces. When attackers find these open objects, they’ll publish the URLs and sometimes even snippets of the sensitive data found inside.
While nobody intentionally overtly declares