Security implications of public vs. private clouds

Nothing it seems is more confusing than the differences between public and private clouds, and beyond that, the safety and security implications of using either type of service. So in this article, we run through some of the basics.

It never fails. People are fascinated by the cloud. Whether it's my doctor trying to get a free consultation on making health care IT choices (while at the same time, charging me $150 to tap my knee with a hammer) or the local car dealer trying to optimize repair scheduling (while at the same time, trying to charge me extra for floor mats), everyone is interested in the cloud.

Once you get past the idea that the cloud isn't a place full of soft, fuzzy foam, but is a wide array of really huge datacenters with thousands of servers and a power load to rival a small city, cloud concepts start confusing people.

Nothing, it seems, is more confusing than the difference between public and private clouds, and beyond that, the safety and security implications of using either type of service. So in this article, I'll run through some of the basics.

The cloud datacenter environment

Let's first take a second and describe what a cloud datacenter environment is. It's a datacenter with a bunch of servers all running services (like email, CRM, ERP, etc). These services can be accessed via the internet, and they can be both instantly deployed and metered. In other words, a new user can be spun up quickly, and the cloud operator can charge that user based on how much he or she uses the service.

Many cloud providers also provide their customers access to compute power with very granular scalability. In other words, if you're buying cloud services, you don't have to buy a new server, rack, or datacenter to add users to the service. You just add accounts, user by user, resource by resource, and pay for just how much you use. This is great when you don't want a huge amount of capital investment to be tied up in compute-based physical gear.

So to summarize: Instantly deployed, metered, scalable, available online.

Public vs. private cloud

A public cloud is this sort of service, offered to everyone. Gmail is a public cloud. Office 365 is a public cloud. Amazon Web Services (AWS) is a series of public cloud services. Dropbox is a public cloud service. Why? Because anyone can use these services, as long as they pay for what they use.

A private cloud is pretty much exactly this same sort of service, except you own it and it runs in your datacenter. Instead of offering instantly deployed, metered services to the world at large, you offer these services to your internal customers, the various departments and organizations in your company.

The big difference, of course, between a public and private cloud is that if you're running a private cloud, you're physically managing the machines, paying for them, and operating all the infrastructure, including the software that does the instant deployment and billing of services.

Security implications

Given what you now know, it's pretty obvious that there's at least one major security difference between private and public clouds. With private clouds, you control the physical servers and access to the servers. With a public cloud not only do you not control the machines or access to them, you're unlikely to ever touch one physically.

As an end-user, if you store your data in the cloud, you're trading off physical security for data security. For example, if you lose your thumb drive or a laptop, your data is still secured in the cloud. But since your data is in the cloud, you're pretty much one exposed ID and password away from datamageddon.

From an enterprise point of view, there are some security benefits to a private cloud. Your information lives behind your firewall (unless you've co-located your servers somewhere else, and even then, you can add some firewall protection). Here are some other benefits:

Your data also can live behind your own locked doors

You don't have to connect to the internet and can completely isolate your data infrastructure

You know exactly where your data lives

You design the architecture for your exact needs

You know exactly who is granted physical access

There is absolute clarity of ownership

There is no risk if your cloud provider shuts down

On the other hand, there are some disadvantages as well:

Your employees have physical access

You are on your own when defending attacks

You are subject to the whims of nature

You are subject to the whims of your ISP

You are subject to the whims of your local power grid

Your security is entirely your responsibility.

Now let's contrast that with the security benefits of keeping your data in a public cloud:

Your data lives behind an enterprise-class firewall

Your data lives in a very secure facility, often with multiple degrees of physical security

Thieves intent on stealing your data may not know where your data lives

Your gear is not at risk from disgruntled employees

You gain security expertise from your vendor

You are not alone when defending against DDoS

You are protected from hardware failures

You are protected from sudden surges in demand.

But as we've discussed, there are also some security disadvantages of using a public cloud. These include:

Access can be granted from anywhere

Your data must travel "in the wild" over the open internet to your cloud provider

Your vendor might grant physical site access to other tenants

You may be subject to jurisdictional issues, especially when you're dealing with international issues

There is very little established case law

You are dependent on the responsiveness of vendor

You are dependent on the whims or quality of vendor.

It's the last one that can be a big concern. If you agree to one set of terms of service, but the vendor suddenly changes those terms of service, you could find yourself almost instantly cut off from your data and your customers.

I've heard a whole bunch of horror stories about agreements that companies had with their cloud vendors, and then suddenly, because of one minor problem (or even a database script run amok), they found themselves completely cut off from their data or completely shut down. Given that many cloud vendors aren't reachable by phone, it's entirely possible that the silver lining in cloud services could suddenly become a black hole.

You should also investigate how secure your vendor is. Is this a new, venture-funded startup that's one bad quarter away from closing doors? Or is this a company with deep resources that will clearly be around for the long haul? Does the company store your data across multiple datacenters, in multiple locations, and what sort of backup and recovery strategy do they offer?

What I do

Back when I started ZATZ, there really wasn't a "cloud". You had to buy your own servers and your own connectivity. We started with an ISDN line, then went T1 around 1999. I ran an entire rack of servers, and at one time, had to convince Verizon to put a T1 line into my apartment.

We were feeding bandwidth through my bedroom, over my bathroom mirror, down the hall, and into a former linen closet. I was told that we consumed the same bandwidth as the local college campus, and it took a few weeks of explaining to convince them that I really did need to feed a few million page views a month from a series of hand-built Linux boxes in my apartment.

However, when I got married and moved to Florida, I realized that Florida weather could knock our servers back to the Stone Age on a moment's notice. So I contracted with a co-location provider in Illinois (who operates out of a former nuclear bunker), and put four machines there.

That approach continues to work well. But as I've personally moved away from having to manage a publishing company, I've wanted to let others do more and more of the work. It started with moving our bookkeeping off the local share to Quickbooks in the cloud (that was 2005 or so), and has recently ended up with moving our email to Office 365.

My strategy now is to offload everything I can to the cloud that's not either bandwidth constrained (my media asset library needs to be fast, so it has to be managed inside the firewall on our tank) or based on a unique solution, like the CMS I wrote and that runs all the ZATZ archives.

Final thoughts

There's a lot more to cloud-based security, but this brief introduction should at least get you started.

Now if only I could convince my doctor to stop trying to get free advice from me while making me cool my heels for two hours in his waiting room because, while he has a cloud-based scheduling tool, he never actually pays any attention to it.