For the most part, cloud security is exactly the same as your existing concerns for the security of your servers.
One major, difference, however, is the ultra-powerful provisioner of your cloud services. That’s the person in your organization who can deploy new cloud resources. But they can do more, and therein lies the risk.
Let’s say you are a typical cloud customer with multiple applications or projects running on Amazon EC2 instances. (I’ll use Amazon and their terminology because they’re by far the biggest IaaS provider, but analogous risks exist in other IaaS environments.)
You might use region-specific SSH keys to compartmentalize access: Project #1 runs in US-East and Project #2 in US-West-2. Not because you have any special affinity for Virginia and Oregon, but because you can separate SSH authentication with region-specific keys.
That controls access to your server through the conventional SSH service. The problem is that anyone who can provision instances has two means of ultimate access to your cloud resources. They can authenticate into the AWS console web interface with your corporate e-mail address and password and then manipulate things through the graphical dashboard. Or, they could use the Access Key ID and Secret Access Key to do things through the AWS Command Line Interface.
Let’s say that one of your project leads is concerned about the high sensitivity of their data and said, “Thanks for setting up the cloud server but I have generated my own SSH keys and replaced those that came on the server.” That’s good, they can still get in but no one else can — at least not through SSH. But what about an insider with access to your AWS provisioning identity?
Here’s how it can go horribly wrong, quickly and silently:
Your trusted-but-untrustworthy insider authenticates as the provisioner, either through the graphical dashboard or by running the commands. Either way, they make a snapshot image of a running instance holding the sensitive data. When that is finished, in about 15 minutes or less, they make it a publicly accessible AMI or runnable image.
They then sign in to their personal AWS account and start an instance of that image. Since they are starting it, their personal SSH key is pushed into place so they will be able to log into it. Once that is running, maybe 30 seconds later, they go back to your corporate AWS identity and remove the image they had created. Now they can make an image of their own running copy and start more at will. Total exposure time, just over 15 minutes in which you could have — but let’s face it, you won’t — notice that extraneous image.
You argue that your sensitive data is protected by ownerships and permissions on the running images? Recall that they can simply do the following on their new instance as
$ sudo bash
In Learning Tree’s Cloud Security Essentials course we talk about the tradeoff between availability and confidentiality. In many situations, like this one, the requirement for data availability leads to an increased risk for violating confidentiality. This one happens to be a risk peculiar to the cloud!