hi …
well, the reason why there is no key management is that we wanted to keep the
interface open so that people
can integrate with everything they want. i have seen keymanagement tools come
and go.
postgresql is certainly gonna live longer than many of those things.
thus we intentionally decided to be flexible here.
as for postgresql 14: we are certainly willing to push that into 14 but the
past couple of years
on the TDE front have been a little frustrating for us.
it seems we cannot reach consensus so it is pretty likely that we have to
keep maintaining it separately. i would love to see it in core but i don’t
expect that to happen
under current circumstances.
many thanks,
hans
> On 11.09.2020, at 17:19, Stephen Frost <sfr...@snowman.net> wrote:
>
> Greetings,
>
> * laurent.fe...@free.fr (laurent.fe...@free.fr) wrote:
>> There is a fork named PostgreSQL 12.x TDE from Cybertec. The issue is that
>> there is no key management at all.
>
> Key management is definitely an understood issue in the community and
> there was a fair bit of work put into trying to solve that problem last
> year and hopefully that'll continue and perhaps be to a point where we
> have a solution in v14. With that, perhaps we can also get TDE in, but
> there certainly aren't any guarantees.
>
> What really needs to be considered, however, is what your attack vectors
> are and if TDE would really address them (often it doesn't, as with any
> TDE the keys end up at least in the memory of the database server and
> therefore available to an attacker, not to mention that the data ends up
> being sent to the application unencrypted, and no, TLS/SSL doesn't help
> that since an attacker on the server would be able to get at the data
> before it's wrapped in TLS).
>
>> Using pgcrypto has an impact on the application then I have to give up this
>> way.
>
> pgcrypto is an option but, again, the keys end up on the database server
> and therefore it may not be very helpful, depending on what the attack
> vector is that you're concerned about.
>
>> There is another alternative named "Client-Side Encryption'' that I have not
>> looked at in detail yet. I'm afraid that this solution has an impact on the
>> application too. And if there are two applications pointing to the same
>> database I am wondering how the encryption key is shared between the two
>> nodes.
>
> Performing encryption of the sensitive data as early as possible is
> certainly the best answer, and that means doing it in the application
> before it ever reaches the database server. Yes, that means that
> changes have to be made to the application, but it's a much better
> solution which will actually address real attack vectors, like the
> database server being compromised.
>
> In general, as it relates to multiple applications connecting to the
> same database- I'd just downright discourage that. PG is much lighter
> weight than other RDBMS solutions and you don't need to have 100
> different applications connecting to the same database server- instead
> have an independent cluster for each application and use certificates or
> other strong authentication mechanism to make sure that app A can only
> connect to the PG cluster for app A and not to any others- this
> completely removes the concern about an SQL injection attack on app A
> allowing the attacker to gain access to app B's data.
>
> Another advantage of this is that the individual clusters are smaller,
> and they can be scaled independently, backed up independently, and
> restored independently, all of which are really good things.
>
>> The last point is about the backups, whatever the solution, the data has to
>> be in an encrypted format when "backuping".
>
> Use a backup technology that provides encryption- pgbackrest does, and
> some others probably do too.
>
> Thanks,
>
> Stephen
--
Cybertec PostgreSQL International GmbH
Gröhrmühlgasse 26, A-2700 Wiener Neustadt
Web: https://www.cybertec-postgresql.com <https://www.cybertec-postgresql.com/>
