2

We're in the process of rolling out a postgres based web app, and I'm trying to understand the value of encrypting the entire database. In postgres's case, the only way to do this is store the database files on an encrypted partition, as documented here http://www.postgresql.org/docs/8.1/static/encryption-options.html.

As far as I can tell, this is only useful if someone get's a hold of our harddrive while the server is not running. Even then, since we have to have a password to mount that partition, it's not that valuable because presumably that password has to be on the host somewhere, or get manually entered after each boot.

Is there some sort of additional attack vector I'm missing that this defends against? Or is the notion of encrypting a database like this mostly security theater?

AndrewSwerlick
  • 1,489
  • 2
  • 10
  • 7
  • possible duplicate of [Database encryption or filesystem encryption?](http://security.stackexchange.com/questions/35275/database-encryption-or-filesystem-encryption) – gowenfawr Mar 16 '15 at 14:10
  • @gowenfawr That doesn't sound like a duplicate to me, given that Postgres apparently doesn't have the ability to do database-level encryption. – user Mar 16 '15 at 14:11
  • There's no qualitative difference between whole-database and whole-disk-behind-database encryption, and they rarely make sense; I wouldn't say security theater but most of the other options are better. – gowenfawr Mar 16 '15 at 14:11
  • Thanks, I may have to do it anyways because it meets some checklist requirements that our partners have, but it helps my understanding as to what I should and should not be worrying about. I'll give this a day or so to see what other answers trickle in, but if none do I'll confirm it as a dupe. – AndrewSwerlick Mar 16 '15 at 14:16

1 Answers1

1

First off, there are ways to mount encrypted partitions without having to enter the passphrase manually or storing it on the system that is being protected. Look at Mandos for one example of this; it's basically a client/server application that stores the key to unlock the encrypted container separate from the container itself. An attacker would at the very least need to gain access to the content of both systems in order to be able to circumvent the security. An alternative to this might be something like the YubiHSM or even just a low-tech solution of a few thumb drives attached to the key rings of trusted employees. This renders your issue about having to enter the passphrase on boot or storing it on the system itself largely moot.

Second, full-disk (or even just whole-partition) encryption allows for efficient and reasonably reliable destruction of data: with any half-way competent crypto, if you throw away the keys, then the data becomes inaccessible. This can be important if you are decomissioning a hard drive that won't respond normally to host commands. It also means you don't need to worry at all about drive-level relocation of sectors in terms of data remanence (and can likely dismiss that issue entirely).

That said, obviously while the system is running the encrypted file system needs to be fully accessible, so there are many attack vectors that full-disk encryption does not at all protect against. It does, however, add an additional layer of difficulty for someone who wants to attack the data at rest, at potentially marginal cost to the defender. For many situations, especially if you can handle the key management problem, such a trade-off can make sense.

user
  • 7,670
  • 2
  • 30
  • 54