Thread: TDE (Transparent Data Encryption) supported ?
Hello Just arrived in the PostgreSQL world, and I'm looking for a solution to encrypt the database by using a TDE feature. Apparentlythis feature does not exist. Is it expected in the roadmap? There is a fork named PostgreSQL 12.x TDE from Cybertec. The issue is that there is no key management at all. Using pgcrypto has an impact on the application then I have to give up this way. 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. The last point is about the backups, whatever the solution, the data has to be in an encrypted format when "backuping". Any suggestions are welcome :). Thanks
> On 11 Sep 2020, at 10:41, laurent.feron@free.fr wrote:
> Just arrived in the PostgreSQL world,
Welcome!
> and I'm looking for a solution to encrypt the database by using a TDE feature. Apparently this feature does not
exist.Is it expected in the roadmap?
Being entirely community driven, there is no roadmap per se. Individual
developers can have personal roadmaps, but at the end of the day it's the
collective development community that decide what goes in.
There is a wiki page which contains a lot of material on the attempts made so
far, with lots of links to discussions which may be of interest:
https://wiki.postgresql.org/wiki/Transparent_Data_Encryption
> The last point is about the backups, whatever the solution, the data has to be in an encrypted format when
"backuping".
There are several backup tools which support PostgreSQL which can also encrypt
the data at rest in the archive. If thats what you're looking for then there
should be options available.
cheers ./daniel
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
Attachment
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
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 <sfrost@snowman.net> wrote: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 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 GmbHGröhrmühlgasse 26, A-2700 Wiener Neustadt Web: https://www.cybertec-postgresql.com
Greetings, We'd prefer it if you didn't top-post (just write some stuff at the top) when you respond and post to these mailing lists. * laurent.feron@free.fr (laurent.feron@free.fr) wrote: > I come back to your comments about vestor attacks. I know that TDE protects against disk thefts, not really more .. That is a data-at-rest concern and TDE is one approach to addressing it. > 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. Disk-based encryption is available for basically all operating systems and PostgreSQL works reasonably well on top of encrypted filesystems or block devices. That's all available today, works quite well to deal with the "someone stole the disk" or "someone forgot to wipe the drive before throwing it away" attack vectors. In particular, I'd encourage you to look at Linux with LUKS for data at rest encryption. You can then simply run PostgreSQL on top of that and be protected without any of the complications which TDE introduces. Thanks, Stephen