Re: TDE (Transparent Data Encryption) supported ? - Mailing list pgsql-hackers

Thank for your responses
I come back to your comments about vestor attacks. I know that TDE protects against disk thefts, not really more ..
But compagnie has some internal rules and some of them require "At Rest" encryption, nothing more is mentionned.
Then, even if TDE is not THE solution in term of security, it is something that companies want.
Laurent

----- Mail original -----
De: "Stephen Frost" <sfrost@snowman.net>
À: "laurent feron" <laurent.feron@free.fr>
Cc: pgsql-hackers@lists.postgresql.org
Envoyé: Vendredi 11 Septembre 2020 17:19:21
Objet: Re: TDE (Transparent Data Encryption) supported ?

Greetings,

* laurent.feron@free.fr (laurent.feron@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
thissolution has an impact on the application too. And if there are two applications pointing to the same database I am
wonderinghow 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