There is a widely held myth that using private clouds alleviates all the security concerns that come with the public cloud. While private clouds are a great way to get your feet wet in the cloud and do greatly help manage risk, such an assumption can come back to bite you in the end.
There are three essential problems with these conversations that I am going to try and address here:
- There is no such thing as a uniform “private cloud” even when they are labeled as such: The definition of private cloud is by no means uniform. The “type” of private cloud you are using will define what security changes you will have to make. Unfortunately some of the confusion comes from traditional hardware vendors and some outsourcing organizations slapping the private cloud label on leased equipment in a traditional architecture in order to get into the budgetary pockets of their customers (because it's called Cloud). I personally think a private cloud is defined as using services of a cloud provider who has an infrastructure built around a hardware layer running their hypervisor, in their data centers, but whose segmentation and dedication of resources can be carved off separately from other customers in the cloud. But by no means is this agreed upon definition. We will cover some of the taxonomy a little later here. My point is that almost every variation of private cloud has some security risk — so not having a handle on your unique flavor of private cloud has fundamental security implications.
- Your private cloud will inherit some of the public cloud security risks: After all, you are changing your IT practice enough to call this something, re-architect something, and budget for something so it stands to reason that this something will have different security issues that what you did before a private cloud project. In fact, the different definitions of private cloud are more or less incremental steps towards a public cloud that match whatever intermediary needs an organization needs- so likewise they will inherit some of the evolutionary security issues along that path. The closer your model is to the traditional data center the less changes there are, the more it has attributes of a public cloud the more security change you'll address.
- Everyone goes to the cloud to live large, no one limits their options: Organizations are going to spend money on private clouds as a safe proving ground for the technology, benefits, use, and risk. Organizations will walk down this path and build private clouds consistent with the changes and benefits they expect for the public cloud. In essence the private cloud becomes a safe experimental ground for organizations to figure out all the painful parts of the cloud (scaling, addressing, load distribution, automation, etc.) so it makes sense that this should be an incremental place to build in the right security architectures. Doing this upfront will pay dividends in the end. Let’s take for example the new PCI 2.0 Virtualization Guidelines. There is an extremely adamant suggestion that PCI instances be placed into hypervisor/network tiers (see section 4.2 in the guidelines). Building these tiers from day 0 is relatively easy architectural decision to make when organizations design for the private cloud. Making these changes after a company is in a public cloud is several orders of magnitude more difficult. So you might as well make the smart security decisions upfront and save some hassle and money on the backend.
So where do we go from here? In part 2, I’ll try and define some incremental steps, the issues that come up, and what security controls you may want to think about at those stages –Dean
