Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > I wonder what the proper extent of "encryption at rest" should be. If > you encrypt just on a file or block level, then someone looking at the > data directory or a backup can still learn a number of things about the > number of tables, transaction rates, various configuration settings, and > so on. In the scenario of a sensitive application hosted on a shared > SAN, I don't think that is good enough.
If someone has access to the SAN, it'd be very difficult to avoid revealing some information about transaction rates or I/O throughput. Being able to have the configuration files encrypted would be good (thinking particularly about pg_hba.conf/pg_ident.conf) but I don't know that it's strictly necessary or that it would have to be done in an initial version. Certainly, there is a trade-off here when it comes to the information which someone can learn about the system by looking at the number and sizes of files from using PG-based encryption vs. what information someone can learn from being able to look at only an encrypted filesystem, but that's a trade-off which security experts are good at making a determination on and will be case-by-case, based on how easy setting up filesystem-encryption is in a particular environment and what the use-cases are for the system. > Also, in the use case you describe, if you use pg_basebackup to make a > direct encrypted copy of a data directory, I think that would mean you'd > have to keep using the same key for all copies. That's true, but that might be acceptable and possibly even desirable in certain cases. On the other hand, it would certainly be a useful feature to have a way to migrate from one key to another. Perhaps that would start out as an off-line tool, but maybe we'd be able to work out a way to support having it done on-line in the future (certainly non-trivial, but if we supported multiple keys concurrently with a preference for which key is used to write data back out, and required that checksums be in place to allow us to test if decrypting with a specific key worked ... lots more hand-waving here... ). Thanks! Stephen
signature.asc
Description: Digital signature