“Data encrypted at rest” has become one of the most familiar statements in cyber security.
It appears in security questionnaires, procurement documents, compliance assessments and SaaS marketing material. It sounds reassuring — and it is an important security control.
But what does encryption at rest actually protect against?
More importantly, what doesn’t it protect against?
Understanding the distinction is increasingly important because many modern data breaches don’t involve somebody physically stealing a server or copying an unprotected hard drive. Attackers increasingly compromise identities, applications and privileged accounts.
In those circumstances, data can be encrypted at rest and still be stolen.
Data is generally considered “at rest” when it is stored rather than being transmitted between systems.
Examples include data held in:
Encryption transforms that information into ciphertext using a cryptographic key.
Without the appropriate key, someone obtaining the underlying data should not be able to read it.
Modern encryption algorithms such as AES-256, when properly implemented and with appropriately protected keys, provide extremely strong protection. Attempting to recover the original information simply by brute-forcing the encryption is computationally impractical.
That makes encryption at rest extremely valuable.
But it is important to understand which problem it solves.
Imagine an organisation has a database containing 100,000 customer records.
An attacker manages to obtain a backup of that database.
If the backup contains plaintext information, the attacker may immediately have access to names, addresses, email addresses and other confidential information.
If the backup is strongly encrypted and the attacker doesn’t possess the encryption key, the situation is very different.
The attacker may possess the file, but not the information it contains. This is encryption at rest doing exactly what it is designed to do.
The same principle applies if somebody steals a physical disk, accesses an improperly secured cloud snapshot, copies raw database files or obtains discarded storage hardware.
In each case, encryption can turn a potentially serious disclosure of information into possession of unreadable ciphertext.
Suppose instead that an attacker steals the credentials of someone authorised to access the application.
The attacker logs in and requests:
“Show me customer record 12345.”
Behind the scenes, the application accesses the encrypted database, retrieves the information, decrypts it and displays it to the supposedly authorised user.
The encryption worked perfectly.
Unfortunately, so did the application.
If the compromised account has sufficient privileges, the attacker might repeat the process thousands of times — or simply use an export function.
The attacker could potentially leave with 100,000 plaintext customer records from a database that was encrypted at rest throughout the entire attack.
This isn’t a failure of encryption. It is a limitation of what encryption at rest was designed to protect against.
This distinction is fundamental.
There is a significant difference between:
data being encrypted while it is stored
and
data being inaccessible to a compromised system or identity.
When legitimate applications need to use encrypted information, there has to be some mechanism through which that information can be decrypted.
That introduces another critical element of the security architecture:
key management.
If an attacker obtains both the encrypted information and access to the keys or systems capable of decrypting it, much of the benefit of storage encryption disappears.
This is why statements such as “we use AES-256 encryption” tell only part of the security story.
The next questions should be:
Where are the encryption keys? Who or what can access them? What happens if an administrator account is compromised? And how much of the wider environment can that compromised identity reach?
Its effectiveness varies significantly according to the type of attack.
|
Scenario |
Protection provided by encryption at rest |
|
Physical disk is stolen |
Very strong |
|
Encrypted backup is stolen |
Very strong |
|
Cloud snapshot is accidentally exposed |
Strong, provided the keys remain protected |
|
Attacker copies raw database files |
Strong |
|
Storage infrastructure is compromised but keys aren’t |
Potentially strong |
|
Authorised user’s credentials are stolen |
Limited |
|
Application server is compromised |
Limited to moderate |
|
Administrator/root access and encryption keys are compromised |
Potentially little |
|
Attacker uses legitimate application functions to export data |
Usually little |
Encryption at rest therefore remains an essential security control.
It just shouldn’t be confused with a complete data-security architecture.
There is another issue that becomes particularly important with cloud applications.
Imagine two SaaS architectures.
There are 1,000 customers operating on shared infrastructure.
All customer data is encrypted at rest.
An attacker compromises something within that shared environment.
The critical question becomes:
How many customers could that compromise potentially expose?
Now consider a different approach.
Each customer operates within an isolated environment.
Customer A’s application and database credentials cannot simply provide access to Customer B’s environment.
Each customer has its own security boundary, with encryption and access controls operating within that boundary.
If Customer A is compromised, the architecture itself is designed to prevent that compromise propagating across customers.
This introduces another extremely important security principle:
reducing the blast radius.
Instead of relying solely on controls intended to prevent a breach occurring, the architecture also assumes that breaches are possible and asks:
If something is compromised, how far can the attacker get?
That is a very different security philosophy.
The strongest systems don’t depend upon any single security control.
They combine multiple independent layers.
Together, these create defence in depth.
The important word is independent.
If compromising one credential defeats every other security control, there may appear to be many layers of security when in reality there is only one.
This is particularly relevant when designing systems intended to remain available during cyber incidents.
At YUDU Sentinel, for example, we use a single-tenant architecture in which each customer operates within its own ring-fenced cloud environment, with mirrored infrastructure across separate AWS Availability Zones.
Encryption at rest and in transit are important parts of that architecture.
But we don’t regard encryption alone as the security proposition.
The architectural objective is also to ensure that compromise or failure affecting one customer’s environment does not provide a route into another customer’s environment.
That becomes especially important for an out-of-band crisis-management platform.
If the system is intended to be available when an organisation’s normal communications or IT infrastructure has been compromised, it makes little sense for the resilience platform to depend upon exactly the same security boundaries.
When evaluating a cloud provider, asking:
“Is our data encrypted at rest?”
is worthwhile.
But the answer will increasingly be “yes”.
A much more revealing set of questions is:
What happens if an attacker gets through?
Can they access the encryption keys?
Can they use the application itself to retrieve decrypted information?
Can they move laterally through the infrastructure?
Can a compromised administrator access multiple customers?
Does compromising one customer potentially expose another?
And what is the maximum possible blast radius of a successful attack?
Those questions tell you much more about the underlying security architecture.
Encryption at rest is an important part of protecting data.
But encryption is a control, not an architecture.
Perhaps the simplest way to remember the distinction is:
Encryption protects the data from certain forms of theft. Isolation limits who can reach it - and how far a successful attacker can travel.
The strongest security architecture does both.