Re: [HACKERS] WIP: Data at rest encryption
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] WIP: Data at rest encryption |
Дата | |
Msg-id | CA+TgmoaSOUbTAG4UYcsCMnpDtRynye9wKuO8qJBYfAPpEEKCqw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] WIP: Data at rest encryption (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Mon, Jun 19, 2017 at 12:30 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Jun 15, 2017 at 7:51 PM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: >> I thought we called it "incremental development". From the opposite >> point of view, would you say we should ban use of passphrase-protected >> SSL key files because the current user interface for them is bad? > > I think that we've got a number of features which exist in the tree > today only because either (a) our standards were lower at the time > that those features were committed than they are today or (b) we > didn't realize how much trouble those features were going to create. > Just because we don't want to hose the people already using those > features does not mean that we want more features engineered to that > same quality level. Obviously, there's room for debate in any > particular case about how reasonable it is to expect someone who wants > to implement A to also improve B, and, well, maybe handling thing as > we do SSL certificates is good enough for this feature, too. I find > myself a bit skeptical about that, though. It preclude as lot of > things we might want to do. You're not going to be able to interface > with some external key management server that way, nor do encryption > of only part of the database, nor have multiple keys for different > parts of the database using that kind of setup. > > One could argue that can all be added later, but I think there's a > question about how much that's going to affect the code structure. > Surely we don't want to install encryption v1 and then find that, by > not considering key management, we've made it really hard to get to > v2, and that it basically can't be done without ripping the whole > implementation out and replacing it. Maybe the database needs, at > some rather low level, a concept of whether the encryption key (or an > encryption key) is available yet, and maybe you get out of considering > that by deciding you're just going to prompt very early in startup, > but now when someone comes along and wants to improve things later, > and they've got to try to go find all of the code that depends on the > assumption that the key is always available and fix it. That could be > pretty annoying to validate. I think it's better to give at least > some consideration to these key management questions from the > beginning, lest we back ourselves into a corner. Whether or not the > SSL-passphrase style implementation is above or below the level we'd > consider a minimally viable feature, it's surely not where we want to > end up, and we shouldn't do anything that makes it likely that we'll > get stuck at precisely that point. > > Also, practically, I think that type of solution is going to be > extremely difficult to use for most people. It means that the > database can't be started by the system startup scripts; you'll have > to log into the PG OS user account and launch the database from there. > IIUC, that means it won't be able to be controlled by things like > systemd, that just know about start and stop, but not about ask for a > password in the middle. Maybe I'm wrong about that, though. And > certainly, there will be some users for whom starting the database > manually and prompting for a password will be good enough, if not > ideal. But for people who want to fetch the encryption key from a key > management server, which I bet is a lot of people, that's not really > going to be good enough. I'm not really sure that rushing a first > patch that "works" for sufficiently small values of "works" is > actually going ...to move us forward very much. >> I have no use for data-at-rest encryption myself, but I wouldn't stop >> development just because the initial design proposal doesn't include >> top-notch key management. I agree with that, but there's a difference between "not top-notch" and "pretty bad". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: