No matter how many times I am told public cloud is the future, I just can’t see it. Call me a Luddite if you wish, but at least continue to read this and find out why my glasses are tinted with distrust and my Kool-Aid mug is empty.
Public cloud cannot be trusted with your data. Why? Your data comprises the keys not just to your kingdom, but to your business as well. Sure, your hosting providers will give you service credits for an outage, but what use is that if your data is gone? If your data is gone, your business is gone. You don’t believe me? Well, it has happened already. Code Spaces was a company that operated out of the cloud. It had to shut up shop when its EC2 control panel was compromised and the hacker started to delete artifacts.
“Well, they should have backed up their data,” I hear you cry. Unfortunately, the fact is they did, and they duplicated those backups across several data centers across multiple continents. You would think that they were safe. Not so. A delete in your control panel is a delete. Amazon, Google, and others are not responsible for your data. You are. Yes, read that sentence again. You are responsible for your data.
What did Code Spaces do wrong? Nothing! Nothing other than put trust in an independent third party to look after its business needs. Its cloud provider did everything it was obligated to. It hosted Code Spaces’ virtual machines on its infrastructure. It distributed its data from data center to data center for redundancy. It did the backups and snapshots as and when required, and it followed the “authorised” requests for deletion of data that came from the customer’s “private” control panel.
All in all, the cloud provider did nothing wrong. But still, Code Spaces went out of business. Why? Because it had all its eggs in one basket. It had no off-site backup or archive. Everything was with the same provider, protected by the same control panel.
Once that had been compromised, the keys to its kingdom were taken and the door to its proverbial vault was open. Think about that when you next read your cloud provider’s SLA. What good are credits when the horse has bolted and destroyed the stable in the process?
So how do you as an SMB or even an LME protect yourself? Just go back to your basics. Remember to protect your core. Make sure that your control panels are protected with two-factor authentication. Remember least privilege. Keep your number of administrators with global permissions to an absolute minimum. Keep a separation of roles—in this case, not just personal. If you are an Amazon customer, make sure that your backups and archives are either on site, or if you have no infrastructure capable of servicing that requirement, then with a completely different cloud provider, say Google, and make sure that they are protected with a completely different set of credentials.
Alternatively, consider hybrid or even private cloud for your needs. You will still get all the flexibility and elasticity benefits (that statement is not very sexy or hip, but you know, I really do not care). There are plenty of multi on-premises cloud management tools out there; companies like Virtustream, Enstratius, and Scalr provide solutions that allow multi-cloud management.
I ask you, who is the best person or entity to look after your data? And I ask you to remember that when your provider gives you your service credits.
This was no more than a failure to follow best practices wrt least privilege. It might have been catalyzed by the level of automation that cloud services enable, but the cloud wasn’t the cause. If Code Space’s systems had been forklifted unmodified into a private data center an attacker could, likely as not, cause similar damage with similar results.
I had my brush with failure to embrace least privilege in 1994. The feeling of being potentially responsible for the loss of an entire businesses data, even for the day it took to restore from tape, was very unpleasant and I’ve never forgotten the lesson. Unfortunately, personal experience is too often the only way that the message gets home.