The Hosting News) – In this article we look at how to ensure your data storage is robust, secure and kept private in IaaS clouds. Keeping data private and secure is a key concern of many looking to move to a public cloud. Its important to separate real dangers and how to avoid them from natural psychological reactions to moving data away from in-house provision.
We see data storage in the cloud breaking down into three distinct areas; keeping data private/secure, vendor transparency and data portability.
Each area is critically important to understanding the issues surrounding data in the cloud and must be clearly appreciated by customers using the cloud in order to form meaningful data handling policies that fit the specific needs of each cloud user.
Data Leakage in the cloud: the real danger
Fundamentally, when moving to a public cloud there are two big changes for customers and their data. Firstly, the data will be stored remotely from the customer’s location; this can have legal implications which we unpack a bit more closely later in this post. Secondly, the data is usually moving from a single tenant to a multi-tenant environment and that’s where the problem of data leakage comes in.
Data leakage is simply the movement of data from one customer to another. Essentially each user in the cloud should only have access to their own data and not be able to access the data of others. We’ve already looked at cloud networking and seen how this is achieved securely through traffic separation and giving customers the control they need to apply networking policies that directly address their needs. For storage, client data is stored in virtual block devices. Essentially virtual drives sitting on larger storage arrays (see cloud storage and the future for more info). These are then accessed by the CPU/RAM of each cloud server.
The data leakage problem comes when a customer deletes their drive and then a new customer creates a new drive. The areas on the physical disks used for the old and new drives can overlap. Its therefore possible for the new customer to try and image off previously written data from other customers. That in a nutshell is the problem and its one that many IaaS clouds are exposed to today. For the most part customers using those platforms don’t actually appreciate the danger. For us that’s a little scary which is why prior to ever launching we took steps to make customers aware of the issue and to provide them with tools that protect them against data leakage.
Solving Data Leakage with IaaS
This problem can been addressed in a couple of key ways. The first approach is to make sure that any confidential data is stored encrypted within the operating system or that the entire operating system/file structure itself is fully encrypted. This can be done using LVM under most Linux distributions or products like Truecrypt for Windows environments. The good news is that it works. Encryption doesn’t avoid the issue of data leakage, it just ensures that any data that does leak is completely meaningless and unusable to others.
Performing encryption in this way from within a cloud server does however have a couple of key drawbacks. Firstly it relies on customers making an explicit effort to use encryption which in a dynamic cloud environment with servers being created and destroyed with high regularity is not that feasible. Secondly, if a server using encryption in this way crashes, on reboot it will require manual intervention from the customer to<!–pagebreak–> input the necessary password to enable access to the encrypted data. In reality such an approach just isn’t very feasible for most users and can result in severe disruption to computing.
The second way of solving this problem is at the vendor level. Its possible to save the virtual block devices i.e. the virtual hard drives, fully encrypted; this can be achieved below the level of the cloud server. As a result drives can be stored fully encrypted implicitly within the system and the data decrypted and served on the fly to customer cloud servers as it is accessed. This approach needs no manual intervention or set-up on the part of the customer and is completely robust to server crashes, restarts etc.
This is how CloudSigma has enabled customers to avoid data leakage. When a customer creates a new drive (via our API or web console), they have the ability to choose whether to store the data encrypted or not. We use a 256bit AES triple encryption cascade to encrypt complete drive images as marked by customers. The impact on performance is limited to between 10%-15% performance reduction in most cases
We see data storage in the cloud breaking down into three distinct areas; keeping data private/secure, vendor transparency and data portability.
Each area is critically important to understanding the issues surrounding data in the cloud and must be clearly appreciated by customers using the cloud in order to form meaningful data handling policies that fit the specific needs of each cloud user.
Data Leakage in the cloud: the real danger
Fundamentally, when moving to a public cloud there are two big changes for customers and their data. Firstly, the data will be stored remotely from the customer’s location; this can have legal implications which we unpack a bit more closely later in this post. Secondly, the data is usually moving from a single tenant to a multi-tenant environment and that’s where the problem of data leakage comes in.
Data leakage is simply the movement of data from one customer to another. Essentially each user in the cloud should only have access to their own data and not be able to access the data of others. We’ve already looked at cloud networking and seen how this is achieved securely through traffic separation and giving customers the control they need to apply networking policies that directly address their needs. For storage, client data is stored in virtual block devices. Essentially virtual drives sitting on larger storage arrays (see cloud storage and the future for more info). These are then accessed by the CPU/RAM of each cloud server.
The data leakage problem comes when a customer deletes their drive and then a new customer creates a new drive. The areas on the physical disks used for the old and new drives can overlap. Its therefore possible for the new customer to try and image off previously written data from other customers. That in a nutshell is the problem and its one that many IaaS clouds are exposed to today. For the most part customers using those platforms don’t actually appreciate the danger. For us that’s a little scary which is why prior to ever launching we took steps to make customers aware of the issue and to provide them with tools that protect them against data leakage.
Solving Data Leakage with IaaS
This problem can been addressed in a couple of key ways. The first approach is to make sure that any confidential data is stored encrypted within the operating system or that the entire operating system/file structure itself is fully encrypted. This can be done using LVM under most Linux distributions or products like Truecrypt for Windows environments. The good news is that it works. Encryption doesn’t avoid the issue of data leakage, it just ensures that any data that does leak is completely meaningless and unusable to others.
Performing encryption in this way from within a cloud server does however have a couple of key drawbacks. Firstly it relies on customers making an explicit effort to use encryption which in a dynamic cloud environment with servers being created and destroyed with high regularity is not that feasible. Secondly, if a server using encryption in this way crashes, on reboot it will require manual intervention from the customer to<!–pagebreak–> input the necessary password to enable access to the encrypted data. In reality such an approach just isn’t very feasible for most users and can result in severe disruption to computing.
The second way of solving this problem is at the vendor level. Its possible to save the virtual block devices i.e. the virtual hard drives, fully encrypted; this can be achieved below the level of the cloud server. As a result drives can be stored fully encrypted implicitly within the system and the data decrypted and served on the fly to customer cloud servers as it is accessed. This approach needs no manual intervention or set-up on the part of the customer and is completely robust to server crashes, restarts etc.
This is how CloudSigma has enabled customers to avoid data leakage. When a customer creates a new drive (via our API or web console), they have the ability to choose whether to store the data encrypted or not. We use a 256bit AES triple encryption cascade to encrypt complete drive images as marked by customers. The impact on performance is limited to between 10%-15% performance reduction in most cases
ـــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــــ
