Greetings, * Chris Travers (chris.trav...@gmail.com) wrote: > From the documentation, the primary threat model of TDE is to prevent > decryption of data from archived wal segments (and data files), for example > on a backup system. While there are other methods around this problem to > date, I think that this feature is worth pursuing for that reason. I want to > address a couple of reasons for this and then go into some reservations I > have about how some of this is documented.
Agreed, though the latest efforts include an option for *authenticated* encryption as well as unauthenticated. That makes it much more difficult to make undetected changes to the data that's protected by the authenticated encryption being used. > There are current workarounds to ensuring encryption at rest, but these have > a number of problems. Encryption passphrases end up lying around the system > in various places. Key rotation is often difficult. And one mistake can > easily render all efforts ineffective. TDE solves these problems. The > overall design from the internal docs looks solid. This definitely is > something I would recommend for many users. There's clearly user demand for it as there's a number of organizations who have forks which are providing it in one shape or another. This kind of splintering of the community is actually an actively bad thing for the project and is part of what killed Unix, by at least some pretty reputable accounts, in my view. > I have a couple small caveats though. Encryption of data is a large topic > and there isn't a one-size-fits-all solution to industrial or state > requirements. Having all this key management available in PostgreSQL is a > very good thing. Long run it is likely to end up being extensible, and > therefore both more powerful and offering a wider range of choices for > solution architects. Implementing encryption is also something that is easy > to mess up. For this reason I think it would be great if we had a > standardized format for discussing encryption options that we could use going > forward. I don't think that should be held against this patch but I think we > need to start discussing it now because it will be a bigger problem later. Do you have a suggestion as to the format to use? > A second caveat I have is that key management is a topic where you really > need a good overview of internals in order to implement effectively. If you > don't know how an SSL handshake works or what is in a certificate, you can > easily make mistakes in setting up SSL. I can see the same thing happening > here. For example, I don't think it would be safe to leave the KEK on an > encrypted filesystem that is decrypted at runtime (or at least I wouldn't > consider that safe -- your appetite for risk may vary). Agreed that we should document this and make clear that the KEK is necessary for server start but absolutely should be kept as safe as possible and certainly not stored on disk somewhere nearby the encrypted cluster. > My proposal would be to have build a template for encryption options in the > documentation. This could include topics like SSL as well. In such a > template we'd have sections like "Threat model," "How it works," > "Implementation Requirements" and so forth. Again I don't think this needs > to be part of the current patch but I think it is something we need to start > thinking about now. Maybe after this goes in, I can present a proposed > documentation patch. I'm not entirely sure that it makes sense to lump this and TLS in the same place as they end up being rather independent at the end of the day. If you have ideas for how to improve the documentation, I'd certainly encourage you to go ahead and work on that and submit it as a patch rather than waiting for this to actually land in core. Having good and solid documentation is something that will help this get in, after all, and to the extent that it's covering existing topics like TLS, those could likely be included independently and that would be of benefit to everyone. > I will also note that I don't consider myself to be very qualified on topics > like encryption. I can reason about key management to some extent but some > implementation details may be beyond me. I would hope we could get some > extra review on this patch set soon. Certainly agree with you there though there's an overall trajectory of patches involved in all of this that's a bit deep. The plan is to discuss that at PGCon (On the Road to TDE) and at the PGCon Unconference after. I certainly hope those interested will be there. I'm also happy to have a call with anyone interested in this effort independent of that, of course. Thanks! Stephen
signature.asc
Description: PGP signature
