Re: Internal key management system
От | Masahiko Sawada |
---|---|
Тема | Re: Internal key management system |
Дата | |
Msg-id | CA+fd4k5yutSH0qe5A=r6xSPpMoAS4Mj9QvpdcqQx7zK0e6NHXQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Internal key management system (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: Internal key management system
|
Список | pgsql-hackers |
On Thu, 11 Jun 2020 at 16:07, Fabien COELHO <coelho@cri.ensmp.fr> wrote: > > > Hello Bruce, > > Sorry for the length (yet again) of this answer, I'm trying to make my > point as clear as possible. Thank you for your explanation! > > >> Obviously it requires some more thinking and design, but my point is that > >> postgres should not hold a KEK, ever, nor presume how DEK are to be managed > >> by a DMS, and that is not very difficult to achieve by putting it outside of > >> pg and defining how interactions take place. Providing a reference/example > >> implementation would be nice as well, and Masahiko-san code can be rewrapped > >> quite easily. > > > > Well, the decrypted keys are already stored in backend memory, > > The fact that if the pg process is compromised then the DEK and data > encrypted are compromised is more or less unavoidable (maybe only the data > could be compromised though, but not the DEK, depending on how the > encryption/decryption operates). > > > so what risk does haveing the KEK in memory for a brief period avoid? > > My understanding is that the KEK does not protect one key, but all keys, > thus all data, possibly even past or future, so it loss impacts more than > the here and now local process. > > If the KEK is ever present in pg process, it presumes that the threat > model being addressed allows its loss if the process is compromised, i.e. > all (past, present, future) security properties are void once the process > is compromised. Why we should not put KEK in pg process but it's okay for other processes? I guess you're talking about a threat when a malicious user logged in OS (or at least accessible) but I thought there is no difference between pg process and other processes in terms of the process being compromised. So the solution, in that case, would be to outsource encryption/decryption to external servers as Bruce mentioned. Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: