By Gilad Parann-Nissany | Article Rating: |
|
May 13, 2013 09:00 AM EDT | Reads: |
6,253 |

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.
Read the original blog entry...
Published May 13, 2013 Reads 6,253
Copyright © 2013 Ulitzer, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Gilad Parann-Nissany
Gilad Parann-Nissany, Founder and CEO at Porticor is a pioneer of Cloud Computing. He has built SaaS Clouds for medium and small enterprises at SAP (CTO Small Business); contributing to several SAP products and reaching more than 8 million users. Recently he has created a consumer Cloud at G.ho.st - a cloud operating system that delighted hundreds of thousands of users while providing browser-based and mobile access to data, people and a variety of cloud-based applications. He is now CEO of Porticor, a leader in Virtual Privacy and Cloud Security.
- Database Security in the Cloud
- Disruptive Innovations and the 'Internet of Things' | @ThingsExpo [#IoT]
- Securing Cloud Data from Cybercrime, Intrusion and Surveillance
- Cloud Computing Security Issues and Challenges By @GiladPN | @CloudExpo [#Cloud]
- MySQL in the Cloud
- Cloud Security – Implementing a Secure Cloud Backup Case Study
- Four Great Tips: Cloud Security for Big Data
- Sixteen Tips for Moving Your Workloads to the Cloud By @GiladPN | @CloudExpo [#Cloud]
- Securing Your ‘Data at Rest’ in the Cloud
- Encrypted Cloud Storage – The Missing Piece