Re: [HACKERS] WIP: Data at rest encryption - Mailing list pgsql-hackers
From | Stephen Frost |
---|---|
Subject | Re: [HACKERS] WIP: Data at rest encryption |
Date | |
Msg-id | 20170613132416.GD3151@tamriel.snowman.net Whole thread Raw |
In response to | Re: [HACKERS] WIP: Data at rest encryption (Ants Aasma <ants.aasma@eesti.ee>) |
Responses |
Re: [HACKERS] WIP: Data at rest encryption
(Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
|
List | pgsql-hackers |
Ants, all, * Ants Aasma (ants.aasma@eesti.ee) wrote: > Yes, the plan is to pick it up again, Real Soon Now(tm). There are a > couple of loose ends for stuff that should be encrypted, but in the > current state of the patch aren't yet (from the top of my head, > logical decoding and pg_stat_statements write some files). The code > handling keys could really take better precautions as Peter pointed > out in another e-mail. And I expect there to be a bunch of polishing > work to make the APIs as good as they can be. Very glad to hear that you're going to be continuing to work on this effort. > To answer Peter's question about HSMs, many enterprise deployments are > on top of shared storage systems. For regulatory reasons or to limit > security clearance of storage administrators, the data on shared > storage should be encrypted. Now for there to be any point to this > endeavor, the key needs to be stored somewhere else. This is where > hardware security modules come in. They are basically hardware key > storage appliances that can either output the key when requested, or > for higher security hold onto the key and perform > encryption/decryption on behalf of the user. The patch enables the > user to use a custom shell command to go and fetch the key from the > HSM, for example using the KMIP protocol. Or a motivated person could > write an extension that implements the encryption hooks to delegate > encryption/decryption of blocks to an HSM. An extension, or perhaps even something built-in, would certainly be good here but I don't think it's necessary in an initial implementation as long as it's something we can do later. > Fundamentally there doesn't seem to be a big benefit of implementing > the encryption at PostgreSQL level instead of the filesystem. The > patch doesn't take any real advantage from the higher level knowledge > of the system, nor do I see much possibility for it to do that. The > main benefit for us is that it's much easier to get a PostgreSQL based > solution deployed. Making it easier to get a PostgreSQL solution deployed is certainly a very worthwhile goal. > I'm curious if the community thinks this is a feature worth having? > Even considering that security experts would classify this kind of > encryption as a checkbox feature. I would say that some security experts would consider it a 'checkbox' feature, while others would say that it's actually a quite useful capability for a database to have and isn't just for being able to check a given box. I tended to lean towards the 'checkbox' camp and encouraged people to use filesystem encryption also, but there are use-cases where it'd be really nice to be able to have PG doing the encryption instead of the filesystem because then you can do things like backup the database, copy it somewhere else directly, and then restore it using the regular PG mechanisms, as long as you have access to the key. That's not something you can directly do with filesystem-level encryption (unless you happen to be lucky enough to be able to use ZFS, which can do exporting, or you can do a block-level exact copy to an exactly identically sized partition on the remote side or similar..), and while you could encrypt the PG files during the backup, that requires that you make sure both sides agree on how that encryption is done and have the same tools for performing the encryption/decryption. Possible, certainly, but not nearly as convenient. +1 for having this capability. Thanks! Stephen
pgsql-hackers by date: