Zurück 
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 “I’m gonna take the shortcut,” the sense of expediency is undeniable. The common thought is, “My application needs data from that bucket. It’s just for a few minutes, so I’ll simply change the access control list and then a half hour later I’ll revert the change.” Unfortunately in today’s interrupt-driven world, by the time that half hour rolls around you’ve probably been interrupted by two or three other things; the access control list is a distant memory. Consequently, you’re likely to continue to forget until an attacker finds the object with one of these tools and publishes its presence. Now you and your leaky buckets are in the news!
How to make your buckets leak-proof
An outcome—if not an objective—of applying useful security controls is to make sure that we stay out of the news. There’s no better way to achieve this than by correctly configuring your clouds. So what can an organization do to ensure that all of its IaaS/PaaS remains restricted and follows the principle of least privilege?
Use a cloud security posture management (CSPM) tool to continually evaluate access control lists and policies across all your cloud subscriptions. CSPM will raise an alert if something looks unusual or creates unnecessary exposure. It can suggest to the security administrator or the developer if there’s a better approach to minimize risk. Some offer a visual access policy editor to compose correct JSON policies if needed.
Which CSPM? It’s a surprisingly active market, brimming with interesting startups (some of which inevitably attract the attention of big not-startups). The major IaaS/PaaS providers now offer CSPM capabilities in their own consoles. It makes sense to investigate their utility. Most organizations, though, are better served by an independent vendor who can work across multiple clouds, thus ensuring consistency. Check for that capability when vetting possible vendors for such a solution.
Next time, we’ll conclude with some observations about the internet’s killer app—and an app feature everyone seems to want to kill.
This article was originally published on Forbes Tech Council
Read the blog