In the last exciting episode, doom@xxxxxxxxxxxxxxxxx (Joseph Brenner) wrote: > I was talking to someone just recently who was saying that they > were thinking about going with Oracle rather than Postgresql > because Oracle has a their story in place about how to do > disk encryption. So I am of course, looking into how to do it > with Postgresql... > > (As to why you would *care* about disk encryption, I would guess > the scenario is you've got a bunch of guys in the back room > hot-swapping RAID drives, and you'd rather not post armed guards > there to watch what happens to the older units.) > > contrib/pgcrypto looks pretty interesting, but I gather it's > intended to let you encrypt particular fields inside a database, > rather than the whole ball of wax. > > Maybe the right way to do it is to just get the OS to encrypt > everything, and not make postgresql jump through any extra hoops? > I see there's a general Linux disk encryption FAQ out there: > > http://www.telenovela-world.com/~spade/linux/howto/Disk-Encryption-HOWTO/index.html > > Doing some searches of the archives, I haven't turned up much > discussion more recent than about a year ago, e.g. > > http://archives.postgresql.org/pgsql-admin/2004-03/msg00049.php > > Is there anything new on this front? If your threat model indicates that encrypting data at the disk level represents protection against some attack involving theft of disk drives, you would presumably find that using some form of OS loopback device with a crypto layer to be useful, and that would not require any particular support from PostgreSQL. Note that this model cannot protect against threats from system administrators as, in order for them to mount the filesystems, they must have access to the crypto keys. Furthermore, it cannot protect _at all_ against attacks that can take place while the database is up and running. A second approach, using pgcrypto, requires that you entrust the database process, and hence anyone with access to the relevant Unix user, with the cryptographic keys. That can allow some portions of the data to be encrypted, and others to remain plain text, and may again be suitable if you trust the system administrators with the keys. It has the merit that the sensitive data stays encrypted on disk at all times; it is only in plain text form in memory and possibly as it is being transmitted between server and client (protect against that using SSL connections). A third approach is for the cryptographic layer to stay purely on the application/client side. Encrypted data is encrypted on the client side, and is only ever decrypted there. If you have any reason to be concerned about threats that target the server, then you must not trust either of the first two approaches, but must look to client-side processing. Google for _Translucent Databases_ for more on this approach... -- output = ("cbbrowne" "@" "gmail.com") http://linuxdatabases.info/info/slony.html They are called computers simply because computation is the only significant job that has so far been given to them. -- Louis Ridenour
