Cloud Data Security: Encryption at Rest Best Practices

Encryption at rest is defined as the practice of encrypting data stored in any type of volume when not in transit.

While the benefits of encryption at rest are often clear for on-premises drives and portable devices, it can be challenging to discern the added value for Cloud resources. This document is a high-level overview of good reasons to make it a standard practice.

Cloud: “It’s just someone else’s computer”

While I am not a supporter of this simplistic quote, it makes sense to call it for this topic. Cloud resources run in data centers, the same way on-premises resources do, but with a layer of sophistication to achieve abstraction and ease of usage for the customer.

Their success relies on the confidence that customers deposit in them. They comply with a shared responsibility model in which they are responsible for infrastructure, and the customer is responsible for adequate configuration and architecture. For all those reasons, compliance and controls are usually very robust.

On the other hand, they pose the same physical security concerns as any other data facility: no bureaucracy will protect stolen or improperly destroyed storage. While very improbable, incidents may happen at the physical layer, posing concerns over PII and classified information in the hands of unauthorized individuals or entities.

Threat models

The first question when it comes to encryption at rest for Cloud environments: “What is the value of it? After all, resources reside in our provider’s data centers which are well protected”.

While they are unlikely, these are examples of threat vectors when encryption at rest is inactive.

• Unauthorized access from insider agents: People with access to the infrastructure (for example, employees) may be able to access information, clone it, tamper with it…
• Hardware theft. In the event of hardware disappearances, lost or stolen material, or wrongful destruction of data devices your data may be compromised.
• Isolation failure. Your Cloud resources may share the same bare-metal hardware as other customers. In the event of an isolation failure, encrypted data will remain secure as encryption keys will often reside somewhere else.

Legal implications and compliance failure are also troubles to take into consideration: while not technical, they can impact business in a critical manner. PII leaks and regulation violations may lead to expensive fines, and depending on the amount and sensitivity of compromised records, even threaten business continuity.

What about performance?

You can expect the same IOPS performance on encrypted volumes as on unencrypted volumes, with a minimal effect on latency (directly quoted from AWS EBS Documentation).

Server-side encryption vs. Client-side encryption

We define Server-side encryption (SSE) as the encryption performed on the Cloud provider side (or the server hosting the data). All the encrypt-decrypt operations happen on those domains and are managed by them. In the case of Cloud, key management and security responsibilities are owned by the provider. This provides a high level of security while maintaining ease of use.

Client-side encryption is performed on the user’s (or client) endpoint. Here, the data is encrypted and decrypted prior to reaching the server, or after leaving it. This way, the server will never have knowledge of plaintext data. Although the complexity is significantly higher (as key management and cryptography are managed by the client), client-side encryption provides the highest level of data privacy. It is suitable for critical operations or situations where trust cannot be fully established on the provider’s side.

For most use cases, SSE is the preferred approach: it is easy to manage, yet it provides sufficient protection if the host can be trusted (which, in the case of a Cloud provider, will often be the case).

Conclusion

Some CSPs, such as Google Cloud Platform or Microsoft Azure have recently started making server-side encryption a default. While the tendency on AWS is the same, it is not the case yet. Refer to the documentation of your service: EBS, S3, EFS, RDS… for more instructions on how to enable encryption on existing resources, and to make it a default for newly created resources. For example, EBS provides an option to enforce SSE in all new resources in the same region (for existing resources, it must be enabled by other means).

Encryption at rest is a low-effort, highly valuable practice for risk reduction and security compliance. It should only be disabled under the right conditions and when sensitive information will not be compromised.