By Ken Smith
I have had a number of clients reach out to me about how to implement whole disk encryption, SQL transparent data encryption, and encryption of VMware VMDK files in order to satisfy “data at rest” security requirements. My response is usually something like “Say that again?”
These types of encryption approaches are designed to better protect data at rest on media that may be accessible to individuals who are not authorized to access such data. This is usually some form of portable media such as a hard drive in the notebook computer, a portable USB hard drive, a USB stick, a backup tape, etc. And by “at rest” we are talking about files that have been saved to media and are not currently open or active. So to summarize, these types of encryption solutions are intended to protect data at rest on some form of portable media or media that is generally accessible to individuals that should not have access to sensitive data stored on that media. What I’m seeing, however, is that this type of encryption is being adopted to address “encrypt sensitive data” compliance requirements such as PCI DSS.
The intent of such “encryption of data at rest” requirements is to protect specific data from unauthorized access whether it be via application access, network file system access, or physical access. If the sensitive information is on storage media that is physically secured in a data center and this data is protected with appropriate network file system access controls, then the only thing remaining is to render the data unreadable to any unauthorized party at the application access level. This is where column or field level encryption comes in. Only authorized individuals or processes have access to the sensitive information in unencrypted form, and only authorized individuals or processes have access to the decryption keys that allow such access.
Let’s switch back to whole disk encryption and SQL transparent data encryption. When a system that’s running either of these is brought online, all users of the system have access to unencrypted data. Not just specific users who have been authorized to access specific sensitive information, but all users. When a server running BitLocker has finished booting, every process and user running on that host has access to data that BitLocker is decrypting for them on the fly every time it’s read from disk. A SQL database server running TDE makes all of its data accessible to all processes and users that have access to the database. While the database is running, the encrypted data is decrypted on-the-fly for all to see. The decryption keys are automatically presented regardless of who is requesting them. This isn’t really “protecting specific data from unauthorized access with encryption” is it?
With the proliferation of virtualization and cloud-based systems, we are now seeing this same thinking applied to protecting sensitive virtual systems. For a VMware environment, VMDK files can be encrypted to protect them from unauthorized access and use, but this is also a method that’s identical to solutions like whole disk encryption and SQL TDE. The data is only protected after it’s been written to disk, the VM is not actually running, and the decryption keys are only accessible to specific services and users that require access to the sensitive data. In most environments, this is not the case.
This type of encryption does have its place. For example, in multi-tenant or public cloud environments, it may be desirable to only allow specific authorized hypervisors to use certain virtual instances. It may make sense for SQL TDE to encrypt every database write to disk if you are using a public cloud providers’ storage and backup solutions. It might be a good idea to use whole disk encryption on a system that is physically at risk of being stolen. But just throwing these types of solutions at a system because they have the word encryption in them and they are easy doesn’t always mean that you’re actually doing a better job protecting sensitive information.
