> Or alternatively is this a problem that's better / just as viably solved with an encrypted filesystem?
Yes and no. They discuss this on page 2.
> An oft-cited threat to DB security is disk theft, i.e., theft of persistent storage [2,16,20,32,37,42,47,50]. Full-disk encryption (FDE) can mitigate this threat, but EDBs aim to protect data even in the absence of FDE. Without FDE, this attack yields the persistent OS and DB state, but not any volatile state.
Even with FDE, an attacker who can do some sort of software exploitation can still grab all the data they need out of the filesystem.
It's worth reading the whole paper if you're interested in the topic. It's only 6.5 pages of content, and it's written in a way that makes the technical stuff pretty accessible to a general CS audience.
> Any good recommendations for running Postgres transparently as a fully encrypted database (not just on a table by table basis)?
Hard to tell what you're asking here. You can't just encrypt all the data inside Postgres, or it won't be able to perform queries anymore. You can read the CryptDB paper cited here to learn about the trade-offs that some encrypted databases have made in order to re-enable queries on encrypted data. In a nutshell, they use much weaker encryption that reveals a lot more information about the contents of the DB. Then read up on the attacks also cited here to see why that's generally a bad idea.
(Full disclosure: I'm an author of one of the attack papers.)
And don't forget the theft of back-ups. Back-ups tend to be secured much less well than the originals and are a frequent cause of data landing where it shouldn't.
Another way in which disks end up in places where they shouldn't be is faulty decommissioning processes.
Yes and no. They discuss this on page 2.
> An oft-cited threat to DB security is disk theft, i.e., theft of persistent storage [2,16,20,32,37,42,47,50]. Full-disk encryption (FDE) can mitigate this threat, but EDBs aim to protect data even in the absence of FDE. Without FDE, this attack yields the persistent OS and DB state, but not any volatile state.
Even with FDE, an attacker who can do some sort of software exploitation can still grab all the data they need out of the filesystem.
It's worth reading the whole paper if you're interested in the topic. It's only 6.5 pages of content, and it's written in a way that makes the technical stuff pretty accessible to a general CS audience.
> Any good recommendations for running Postgres transparently as a fully encrypted database (not just on a table by table basis)?
Hard to tell what you're asking here. You can't just encrypt all the data inside Postgres, or it won't be able to perform queries anymore. You can read the CryptDB paper cited here to learn about the trade-offs that some encrypted databases have made in order to re-enable queries on encrypted data. In a nutshell, they use much weaker encryption that reveals a lot more information about the contents of the DB. Then read up on the attacks also cited here to see why that's generally a bad idea.
(Full disclosure: I'm an author of one of the attack papers.)