Gilad Parann-Nissany

As the infrastructure cloud market (IaaS and PaaS) continues to grow rapidly, we are seeing quite a few customers who are delivering an application – whether it is a mission-critical or SaaS application – and basing their solution on VMware.

Some of these are deploying VMware in their private data center, while others are leveraging the cloud model and “renting” capacity from a public VMware-based cloud provider. In a way, both of these scenarios are public: in many of the cases the “private cloud” scenario serves users who belong to different organizations, so from the user point of view the scenario is “public”. As a result, these customers have many of the same security concerns (see here for a deeper discussion of that point).

When considering deployment of a cloud encryption solution in these environments, we have seen several options.

Physical solutions

Physical boxes are a solution that exists a long time in the market. The idea is to put a physical box between the ESX rack and the SAN – plug in the network – and let the box encrypt everything that comes from the ESX rack.

The upside of the physical box is it is tried and tested. Downsides include

• Physical boxes increase TCO and up-front costs, while losing the flexibility of virtualized solutions
• It is an al-or-nothing solution for the entire ESX rack; it is not possible to provide finer-granular control that is sensitive to the needs of a particular application or customer.

Especially in the cloud world, where tenants are a common concept, it is necessary to create strong separation and segregation between different applications and customers – on the same infrastructure. That is why more and more solutions need to be software controlled and virtualized.

Deployment models for a Virtual Solution

A virtual cloud encryption solution – whether for public or private cloud – can have several deployment models.

• A virtual appliance “close to the storage”
• A virtual appliance “close to the customer account or to the application”
• A software agent
• A hook on the ESX level

Each of these is good for different cases.

Virtual appliances close to the storage

This involves a virtual machine image which is deployable so it sees the LUNs, VMFSs and VMDKs exposed by the VMware infrastructure, and encrypts them before they are allocated to a specific application or specific customer account. It is accessible from multiple network segments in the environment and has a tenancy concept which is well integrated with the management concepts of VSpehere and VCloud – and then this is an extremely flexible solution serving a wide range of scenarios.

A virtual machine image is deployable in the customer account, within the network segments used by that customer. It is logically “close” to the application and under possibly under tenant control. Again it should be well integrated with the management concepts of VSpehere and VCloud – allowing its placement in the customer account – and again this is an extremely flexible solution serving a wide range of scenarios.

Software agents

These are typically installed as software on the customer or application VMs. Their advantage is that they are fully contained within the customer guest OS, giving a sense of complete control. Disadvantages include their footprint and upgrade needs.

ESX hooks

ESX is evolving a number of hooking mechanisms that allow functionality to be hooked below the guest OS level. The advantage is that such hooks can be shared by several guests on one ESX instance, and VMware helps deploy them. A security disadvantage is that they may create a sharing situation between guest OS’s that belong to different applications or customers.

The ideal solution

The best of all possible worlds is a solution that can work in several of these deployment models, not just one. Such solutions do exist today. Software-defined security for the virtual world is becoming a reality.

The post Cloud Encryption deployment for VMware-based application services appeared first on Porticor Cloud Security.