Is data encrypted at rest really more secure?

One of the key differentiators between Corrected Cloud and other security configuration analysis tools is that we give you a straight forward, no-nonsense list of priorities to improve your security posture. We make it clear where you should prioritize your effort to get the biggest improvements.

A question that often arises when people first review the list of recommendations we have is why missing encryption at rest (aka on-disk encryption) is so far down the list. “Isn’t encryption at rest a minimum requirement? Shouldn’t everything be encrypted on disk?” the argument typically goes.

The response is pretty simple - yes, you should be using on disk encryption. But doing so provides little extra security, and so to spend time doing this before resolving more practical avenues for attack does not make sense.

What does encryption at rest do for us?

In a traditional data centre environment, there are some clear problems that having unencrypted data on disk presents. There is potential for a disk to end up in the wrong hands. A technician could forget to wipe a disk before it is disposed of, or perhaps an inability to do so due to a hardware failure that nevertheless allows the data to be recovered. Thefts from data centres happen on both a small and large scale. With this being the case, it’s easy to see how “Data encrypted at rest?” has become a standard question on an auditors checklist.

When using cloud, none of these risks apply in the same way. One of the many advantages of cloud that tends to get forgotten, particularly when comparing costs, is that in cloud you are paying for a team of world class experts to do these tasks. Cloud providers have regular audits that verify they are following proper data destruction procedures.

In addition, storage simply does not work the same way as it does in a traditional data centre environment. Your data is not stored in a linear manner on a single or mirrored disk - it is distributed across multi-tenant arrays, with data distributed across a large number of devices. For an attacker to reconstruct even unencrypted data would be a serious technical undertaking requiring them to have physical access to a large number of disks - potentially one or more racks worth of equipment.

If you do not believe that your cloud provider can be trusted to not carelessly leave whole racks of equipment lying around, you might want to consider whether they can be trusted to encrypt your data for you. What proof do you have that your data is encrypted at all? What proof do you have that they do not carelessly allow access to your encryption keys? If you don’t trust your cloud provider and their auditors, using your cloud provider’s encryption doesn’t really solve anything.

So should we bother with encryption at rest at all?

With all this said, there are still reasons to utilize encryption at rest.

Encryption at rest can be useful in that it can provide an extra means of data control. Because access to the stored data needs not only appropriate IAM privileges for the data store (EBS, S3, etc) but also to the KMS key used for encryption, even users and roles with overly permissive IAM privileges can be prevented from accessing restricted data. For example, sensitive data can be encrypted with a specific KMS key which has a policy attached only allowing the specific entities which needs access. Even users with full IAM privileges can be prevented from accessing this sensitive data.

Lastly, the reality is that “Is your data encrypted at rest?” is almost certain to be on an auditor’s checklist. For many people, avoiding the hassle of having to argue about the merits of encryption in the event they ever need to talk to an auditor will outweigh the small cost of implementing it.