Encryption is returning to the forefront, with Microsoft claiming its approach is better than others. VMware counters with its approach, and clouds counter with theirs. None of these approaches make sense unless you understand the layers in which you can encrypt, the risks associated with those layers of encryption, and the inherent problems with encryption key management. So, a revision of an older article seems needed. Where can we encrypt within the cloud and virtual environments?

First, let’s look at encryption up and down the stack of a virtual, cloud, and container environment. A few things have changed since this diagram was first created, but to be frank, not much—just the names of things. Now, this diagram is hypervisor specific, so we will draw out those differences between clouds, containers, and virtualization. I must say, this has worked out better than I thought as a diagram, given that it is from 2013 and the previous version is from 2009.

Encryption up and down the stack
2013: Encryption Up and Down the Stack
Encryption Up and Down the Stack
2017: Encryption Up and Down the Stack

As you can see, between 2013 and 2017, not much has changed—just some names. The concepts are ideally the same. However, let us look at where each technology ends and at why we need to worry about each layer.
The least useful layers are the following:

  • Self-Encrypting Disks have the problem that once data is read off them, it is visible in the clear up and down the stack, unless other measures are taken, such as encrypted networking technologies. Key management is still an issue. The nice thing about self-encrypting disks is that in order to destroy the data, all you need to do is force the drive to forget its key.
  • Encrypting Controller moves encryption up above the drives, yet still has the same limitations as drives.
  • Encrypting Network or Fabric Switch and similar devices have many of the same limitations as the first two items. Everything above the device is not encrypted, but everything below is fully encrypted. These devices need to be as close to the network adapters and fabric devices within the hosts as is humanly possible. Even a switch between them and the line cards can open up data to being in the clear.
  • Encrypting Host Bus Adapters (HBAs) or Networking Adapters (ETH above) can also be used, but they share some of the same limitations as the previous layers. Their big advantage is that anything going over the physical network is fully encrypted. However, most people leave this functionality off, as it is difficult to manage and can impact overall performance.
  • When we move up to the Per Vol Filter Drivers, such as VMware’s vSAN Encryption or Hyper-V’s volume encryption (i.e BitLocker within the Hyper-V Host), everything below is fully encrypted. However, once data is read off the volume, regardless of by whom or by what, the data is still not encrypted. This implies that an administrator of the system can read data they should not see.
  • Per-VM Filter Drivers move encryption to the virtual machine side of the hypervisor. The advantage is that everything below the virtual machine manager is encrypted, including within the hypervisor itself. This is where VMware’s VMencrypt technology does its encryption. This implies that if a hypervisor administrator were to read data off a volume, the per-VM files would still be encrypted. This limits access of data to administrators. The keys are not stored inside the virtual machine, but outside in secure locations. However, data read by the VM itself is unencrypted.
  • Operating System (OS) Encryption encrypts all data below the OS and through the hypervisor, but it pushes the keys into the virtual machine’s memory. It is trivially easy to access the keys in memory and therefore to decrypt data without much effort. A hypervisor administrator has tools built into each hypervisor to make this even easier. This is commonly referred to as in-Guest encryption and is how BitLocker within a VM currently works.
  • Application Encryption encrypts data within the operating system and below, yet shares the same issue as OS encryption.

Clouds and containers do not change this stack anywhere, but what they do is limit your view into the stack. In both cases, you have access to just the application and operating system levels. However, if your cloud allows, you may have access to per-VM filter driver encryption or even hypervisor based per-VM disk encryption. Containers limit you to per-container or application encryption or per-volume encryption within the container host. With containers, more people have access to the secrets or even to the containers themselves than before. As such, we need to ensure adequate auditing.
You can layer encrypting technologies, but you probably shouldn’t for performance reasons. Pick one that makes the most sense and limits the access that you desire. However, no scheme alone will solve the problem. There are risks to them all. Those risks are:

  • Who can access the keys?
  • Who can access the cleartext data?
  • How are keys managed?
  • Who did what, when, where, and how?

In essence, you need to marry monitoring with key management with encryption. You absolutely need to monitor and audit who did what, when, where, and how when you are dealing with encryption. For that, you need good logs and good data on which to base your audit queries, or you need to use tools such as those from HyTrust to enhance your environment.
The problem is not with encryption, but with knowing the risks associated with encryption. Do you see any risks I did not mention?