Thread

1. TDE (Transparent Data Encryption) supported ?

   laurent.feron@free.fr — 2020-09-11T08:41:15Z

   Hello
   
   Just arrived in the PostgreSQL world, 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?
   
   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 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.
   
   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
   
   
   
   

2. Re: TDE (Transparent Data Encryption) supported ?

   Daniel Gustafsson <daniel@yesql.se> — 2020-09-11T11:18:52Z

   > 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
   
   
   

3. Re: TDE (Transparent Data Encryption) supported ?

   Stephen Frost <sfrost@snowman.net> — 2020-09-11T15:19:21Z

   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
   

4. Re: TDE (Transparent Data Encryption) supported ?

   laurent.feron@free.fr — 2020-09-14T08:29:32Z

   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 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
   
   
   
   

5. Re: TDE (Transparent Data Encryption) supported ?

   Hans-Jürgen Schönig <postgres@cybertec.at> — 2020-09-14T12:01:21Z

   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 GmbH
   Gröhrmühlgasse 26, A-2700 Wiener Neustadt
   Web: https://www.cybertec-postgresql.com <https://www.cybertec-postgresql.com/>
   
   
   
   
   
   
   
   
   

6. Re: TDE (Transparent Data Encryption) supported ?

   Stephen Frost <sfrost@snowman.net> — 2020-09-14T12:39:42Z

   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