[throwaway38375]

This might sound like a stupid question, but I'll ask anyway:

What benefit does encryption at rest solve for something which is never intended to actually rest?

For example, a MySQL database powering a web application is expected to be alive and responding to requests 24/7. It's never really intended to be at rest.

So what benefit does encryption at rest bring? Won't a hacker be attempting to take data when it's online (and therefore not resting)?

[nielsole]

Your RAID reports an issue with one of the disks. You disable it and have the DC staff swap it. What happens to the disk? It might be resold. It might be put into the next server. It might land in an office drawer with a label "to be wiped".

[jgalt212]

so funny. I look below my monitor, and there rests a hard disk with "MUST WIPE" post-it on it. Thanks for the reminder.

[throwaway38375]

Good point.

[mholt]

> What benefit does encryption at rest solve for something which is never intended to actually rest?

That's the point of the article, luckily enough. "Disk Encryption is important for disk disposal and mitigating hardware theft, not preventing data leakage to online attackers."

> So what benefit does encryption at rest bring? Won't a hacker be attempting to take data when it's online (and therefore not resting)?

Yes (again, illustrated in the article).

[JackSlateur]

Data at rest = data persisted somewhere = anything written on your hard disk drive

I am pretty sure your database stores things into /var/lib/mysql : this is what would be encrypted (without support from the software)

So, if you lose your SSD, nobody is able to read your database's content

[Horffupolde]

Data is both at rest and in memory. It’s not mutually exclusive. Binary backups or images of data encrypted at rest will continue to be encrypted.

[DougBTX]

"At rest" is used to contrast with "in flight", where the data is being transferred between computers. So data "in flight" is protected by HTTPS etc, once it has been transferred it is "at rest" on the destination computer (even if that computer is still online).

[throwaway38375]

Ah, I see. Thank you for explaining. This is much clearer.

[bravetraveler]

Intention becomes victim to reality easily, often with no input.

I haven't read the post yet, but I feel like expecting a perfectly well-defined model is kind of in bad faith. Defense in depth is established, FDE is one tool among many.

By focusing on the hacker we forget about the person who may get the equipment downstream; procedures/processes fail, and so on.

It's preparing for the unknowns. Sounds like paranoia? That's the job! Defending against human nature - malice, forgetfulness, etc.

I guess I'll close with this: you're the only one who can make your security assessment. What's important, what's at risk, and so on. It's trade-offs all the way down.

[throwaway38375]

I should clarify that I see the value of encryption at rest for something like an employee laptop, which could be left at a bar (while powered off) by accident.

I just don't get the value of it for always online servers.

[JackSlateur]

How are online servers differents ?

You can remove storage devices from online servers, without interruption. Said devices will contains data that could be "lost" that way. Hence: encryption at rest.

[nine_k]

An intruder gains access to an API box, and could try to read sensitive data from a DB. But the interesting fields are encrypted, and the key is somewhere in RAM. Not impossible to exfiltrate, but takes much longer time and more skill, thus cannot be made an unattended malware payload. Also, a key for one customer won't give access to data of other customers, even if the common database access credentials are obtained.

[tetha]

I've written a whitepaper about our encryption at rest at work, which includes a bit of considerations about the threats considered.

The first important part is: Encryption at rest protects higher levels of the stack from access by lower levels of the stack. If your attack is working at an application level - e.g. you have a database connection - encryption at rest is no tool to deal with this. Encryption at rest is more about protecting the database from an attacker with physical access.

The second consideration is: There will always be a tradeoff between availability and security when dealing with encryption at rest. Manually decrypting a system is very secure, but if that system goes offline at 3am, it'll be offline until the device is decrypted. Automatically decrypting a system using Clevis/Tang, TPM, Bitlocker and such gives you more availability but could make it possible for an attacker to access your data if they have sufficient control.

And that's the third consideration: If an attacker has sufficient control, they can defeat automated decryption of encryption at rest, and they may have ways to start attacking manual decryption of encryption at rest as well. Like, you might be able to start looking at memory contents, disk writes and start doing some differential cryptoanalysis to attack encrypted data and such.

But with all of these three together, you arrive at the goal and security level we have formulated for our encryption at rest:

Our encryption at rest is supposed to defend us against employees of our hosters getting access to one or two of our virtual or physical storage devices. If they have access to one or two storage devices, they must not be able to access customer data on the devices.

Naturally, the question is: But what happens if they have more drives?

Well, the simple answer from the whitepaper is: That's a problem for the lawyers.

Handling 1-2 of our drives is entirely arguable as daily business. Swapping drives via remote hands or dismissing dedicated servers with 2 drives at a specific hoster happens a lot and then they handle 1-2 drives, and our goal ensures they cannot gain access to customer data then.

However, if a datacenter tech starts pulling 3 or more drives and starts analyzing data on them together, that's outside of normal operational procedures and we can start considering that an attack and start sueing them. Or they are being directed by law enforcement. Both are issues for the legal teams though.

At least that's our view. Encryption at rest works in a very different set of circumstances and mindset than other security topics in a software stack.

[algernonramone]

My thought here is that not all of the data in the database is being accessed at the same time, so the un-accessed data is "at rest". Is that correct, or am I barking up the wrong tree?

[kbolino]

Assuming full-disk encryption is in use (LUKS, TrueCrypt/VeraCrypt, BitLocker, etc.), there is enough information held in RAM to decrypt the entire disk. If the attacker gains access to a privileged user, or at least to a user allowed to read the file system (such as the user running the database), they can exfiltrate the unencrypted contents of the disk, regardless of what the DB software is actively accessing.

[algernonramone]

Ah, OK, makes sense. Thanks for the clarification!