[Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
465 messages Options
1 ... 2021222324
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Stephen Frost
Greetings,

* Bruce Momjian ([hidden email]) wrote:

> On Sat, Aug 17, 2019 at 08:16:06AM +0200, Antonin Houska wrote:
> > Bruce Momjian <[hidden email]> wrote:
> >
> > > On Thu, Aug 15, 2019 at 09:01:05PM -0400, Stephen Frost wrote:
> > > > * Bruce Momjian ([hidden email]) wrote:
> > > > > Why would it not be simpler to have the cluster_passphrase_command run
> > > > > whatever command-line program it wants?  If you don't want to use a
> > > > > shell command, create an executable and call that.
> > > >
> > > > Having direct integration with a KMS would certainly be valuable, and I
> > > > don't see a reason to deny users that option if someone would like to
> > > > spend time implementing it- in addition to a simpler mechanism such as a
> > > > passphrase command, which I believe is what was being suggested here.
> > >
> > > OK,  I am just trying to see why we would not use the
> > > cluster_passphrase_command-like interface to do that.
> >
> > One problem that occurs to me is that PG may need to send some sort of
> > credentials to the KMS. If it runs a separate process to execute the command,
> > it needs to pass those credentials to it. Whether it does so via parameters or
> > environment variables, both can be seen by other users.
>
> Yes, that would be a good reason to use an external library, if we can't
> figure out a clean API like opening a pipe into the command-line tool
> and piping in the secret.
Having to install something additional to make that whole mechanism
happen would also be less than ideal, imv.  That includes even something
as install-X and then configure passphrase_command.  Our experience with
archive_command shows that it really isn't a very good approach, even
when everything can be passed in on a command line.

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Stephen Frost
In reply to this post by Bruce Momjian
Greetings,

* Bruce Momjian ([hidden email]) wrote:
> I will state whet I have already told some people privately, that for
> this feature, we have many people understanding 40% of the problem, but
> thinking they understand 90%.  I do agree we should plan for our
> eventual full feature set, but I can't figure out what that feature set
> looks like beyond full-cluster encryption, and no one is addressing my
> concerns to move that forward.  Vague complains that they don't like the
> process are not changing that.

I don't particularly care for these "40%" and "90%" characterizations
and I'm concerned that some might also, reasonably, find that to be a
way to dismiss the opinions and comments from anyone who isn't in the
clearly subjective "90%" crowd.

Regarding what the eventual feature-set is, I believe it's abundently
clear where we want to eventually go and it's surprising to me that it's
unclear- we should be aiming for parity with the other major database
vendors when it comes to TDE.  That's pretty clear and straight-forward
to define, as well, and as facts:

Oracle:
- Supports column-level and tablespace-level.
- Has a Master Encryption Key (MEK), and table keys.
- Supports having the MEK be external to the database system.
- For tablespaces, can also use an external key store with
  different keys for different tablespaces.
- Supports Triple-DES and AES (128, 192, 256 bit)
- Supports a NOMAC parameter to improve performance.
- Has a mechanism for changing the keys/algorithms for tables
  with encrypted columns.

SQL Server:
- Supports database-level encryption
- Has a Instance master key and a per-database master key
- Includes a key store for having other keys
- Provides a function-based approach for encrypting at a column level
  (imagine pgcrypto, but where the key can be pulled from a key-store in
  the database which has to be unlocked)

DB2:
- Supports a Master Key and a Data Encryption Key
- Support encryption at a per-database level

Sybase:
- Supports a key encryption key
- Supports column level encryption with column encryption keys

MySQL:
- Supports a master encryption key
- Supports having the master key in an external data store which speaks
  Oasis KMIP
- Supports per-tablespace encryption
- Supports per-table encryption

Every one of the database systems above uses at least a two-tier system
(SQL server seems to possibly support three-tier) where there is a MEK
and then multiple keys under the MEK to allow partial encryption of the
system, at *least* at a database or tablespace level but a number go
down to column-level, either directly or using a function-based approach
with a key store.

Every one has some kind of key store, and a number support an external
key store.

There is not one that uses a single key or which requires that the
enctire instance be encrypted.

Being PostgreSQL, I would expect us to shoot for as much flexibility as
we possible, similar to what we've done for our ACL system where we
support down to a column-level (and row level with RLS).

That's our target end-goal.  Having an incremental plan to get there
where we start with something simpler and then work towards a more
complicated implementation is fine- but that base, as I've said multiple
times and as supported by what we see other database systems have,
should include some kind of key store with support for multiple keys and
a way to encrypt something less than the entire system.  Every other
database system that we consider at all comparable has at least that.

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Sehrope Sarkuni
In reply to this post by Ibrar Ahmed-4
On Sat, Aug 17, 2019 at 12:43 PM Ibrar Ahmed <[hidden email]> wrote:
+1 for voice call, bruce we usually have a weekly TDE call.

Please add me to the call as well. Thanks!

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Ahsan Hadi-2
The current calendar entry for TDE weekly call will not work for EST timezone. I will change the invite so we can accommodate people from multiple time zones.

Stay tuned.


On Sun, 18 Aug 2019 at 2:29 AM, Sehrope Sarkuni <[hidden email]> wrote:
On Sat, Aug 17, 2019 at 12:43 PM Ibrar Ahmed <[hidden email]> wrote:
+1 for voice call, bruce we usually have a weekly TDE call.

Please add me to the call as well. Thanks!

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/

Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Stephen Frost
Greetings,

On Sat, Aug 17, 2019 at 18:30 Ahsan Hadi <[hidden email]> wrote:
The current calendar entry for TDE weekly call will not work for EST timezone. I will change the invite so we can accommodate people from multiple time zones.

I appreciate the thought but at least for my part, I already have regular conference calls after midnight to support Asian and Australian time zones, so I’m willing to work to support whatever has already been worked out.  (I also won’t complain about a time that’s more convenient for everyone, of course.)

Thanks!

Stephen
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Peter Eisentraut-6
In reply to this post by Antonin Houska-2
On 2019-08-17 08:16, Antonin Houska wrote:
> One problem that occurs to me is that PG may need to send some sort of
> credentials to the KMS. If it runs a separate process to execute the command,
> it needs to pass those credentials to it. Whether it does so via parameters or
> environment variables, both can be seen by other users.

You could do it via stdin or a file, perhaps.

Where would the PostgreSQL server ultimately get the KMS credentials from?

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

RE: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Smith, Peter
In reply to this post by Ibrar Ahmed-4
> From: Ibrar Ahmed <[hidden email]> Sent: Sunday, 18 August 2019 2:43 AM
> +1 for voice call, bruce we usually have a weekly TDE call. I will include you in

If you don't mind, please also add me to that TDE call list.

Thanks/Regards,
---
Peter Smith
Fujitsu Australia
Reply | Threaded
Open this post in threaded view
|

RE: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Smith, Peter
In reply to this post by Stephen Frost
> -----Original Message-----
> From: Stephen Frost <[hidden email]> Sent: Friday, 16 August 2019 11:01 AM

> Having direct integration with a KMS would certainly be valuable, and I don't see a reason to deny users that option if someone would like to spend time
> implementing it- in addition to a simpler mechanism such as a passphrase command, which I believe is what was being suggested here.

Yes. We recently made an internal PoC for FEP to enable it to reach out to AWS KMS whenever the MKEY was rotated or TDKEY was created. This was achieved by inserting some hooks in our TDE code - these hooks were implemented by a contrib-module loaded by the shared_preload_libraries GUC variable. So when no special "tdekey_aws" module was loaded, our TDE functionality simply reverts to its default (random) MDEK/TDEK keys.

Even if OSS community chooses not to implement any KMS integration, the TDE design could consider providing hooks in a few appropriate places to make it easy for people who may need to add their own later.

Regards,
---
Peter Smith
Fujitsu Australia



Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Ahsan Hadi-2
In reply to this post by Smith, Peter


On Mon, 19 Aug 2019 at 6:23 AM, Smith, Peter <[hidden email]> wrote:
> From: Ibrar Ahmed <[hidden email]> Sent: Sunday, 18 August 2019 2:43 AM
> +1 for voice call, bruce we usually have a weekly TDE call. I will include you in

If you don't mind, please also add me to that TDE call list.

Sure will do.


Thanks/Regards,
---
Peter Smith
Fujitsu Australia
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Ahsan Hadi-2
I have shared a calendar invite for TDE/KMS weekly meeting with the members who expressed interest of joining the meeting in this chain. Hopefully I haven't missed anyone.

I am not aware of everyone's timezone but I have tried to setup a time that's not very inconvenient. It won't be ideal for everyone as we are dealing with multiple timezone but do let me know It is too bizarre for you and I will try to find another slot.    

I will share a zoom link for the meeting on the invite in due course.

-- Ahsan
 

On Mon, Aug 19, 2019 at 9:26 AM Ahsan Hadi <[hidden email]> wrote:


On Mon, 19 Aug 2019 at 6:23 AM, Smith, Peter <[hidden email]> wrote:
> From: Ibrar Ahmed <[hidden email]> Sent: Sunday, 18 August 2019 2:43 AM
> +1 for voice call, bruce we usually have a weekly TDE call. I will include you in

If you don't mind, please also add me to that TDE call list.

Sure will do.


Thanks/Regards,
---
Peter Smith
Fujitsu Australia
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Joe Conway
On 8/19/19 8:51 AM, Ahsan Hadi wrote:

> I have shared a calendar invite for TDE/KMS weekly meeting with the
> members who expressed interest of joining the meeting in this chain.
> Hopefully I haven't missed anyone.
>
> I am not aware of everyone's timezone but I have tried to setup a time
> that's not very inconvenient. It won't be ideal for everyone as we are
> dealing with multiple timezone but do let me know It is too bizarre for
> you and I will try to find another slot.    
>
> I will share a zoom link for the meeting on the invite in due course.


Please add me as well. I would like to join when I can.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Bruce Momjian
In reply to this post by Stephen Frost
On Sat, Aug 17, 2019 at 01:52:17PM -0400, Stephen Frost wrote:

> Being PostgreSQL, I would expect us to shoot for as much flexibility as
> we possible, similar to what we've done for our ACL system where we
> support down to a column-level (and row level with RLS).
>
> That's our target end-goal.  Having an incremental plan to get there
> where we start with something simpler and then work towards a more
> complicated implementation is fine- but that base, as I've said multiple
> times and as supported by what we see other database systems have,
> should include some kind of key store with support for multiple keys and
> a way to encrypt something less than the entire system.  Every other
> database system that we consider at all comparable has at least that.

Well, we don't blindly copy features from other databases.  The features
has to be useful for our users and reasonable to implement in Postgres.
This is been the criteria for every other Postgres features I have seen
developed.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Stephen Frost
Greetings,

* Bruce Momjian ([hidden email]) wrote:

> On Sat, Aug 17, 2019 at 01:52:17PM -0400, Stephen Frost wrote:
> > Being PostgreSQL, I would expect us to shoot for as much flexibility as
> > we possible, similar to what we've done for our ACL system where we
> > support down to a column-level (and row level with RLS).
> >
> > That's our target end-goal.  Having an incremental plan to get there
> > where we start with something simpler and then work towards a more
> > complicated implementation is fine- but that base, as I've said multiple
> > times and as supported by what we see other database systems have,
> > should include some kind of key store with support for multiple keys and
> > a way to encrypt something less than the entire system.  Every other
> > database system that we consider at all comparable has at least that.
>
> Well, we don't blindly copy features from other databases.  The features
> has to be useful for our users and reasonable to implement in Postgres.
> This is been the criteria for every other Postgres features I have seen
> developed.
Having listed out the feature set of each of the other major databases
when it comes to TDE is exactly how we objectively look at what is being
done in the industry, and that then gives us an understanding of what
users (and auditors) coming from other platforms will expect.

I entirely agree that we shouldn't just copy N feature from X other
database system unless we feel that's the best approach, but when every
other database system out there has capability Y for the general feature
X that we're thinking about implementing, we should be questioning an
approach which doesn't include that.

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Bruce Momjian
On Fri, Aug 23, 2019 at 07:45:22AM -0400, Stephen Frost wrote:

> Greetings,
>
> * Bruce Momjian ([hidden email]) wrote:
> > On Sat, Aug 17, 2019 at 01:52:17PM -0400, Stephen Frost wrote:
> > > Being PostgreSQL, I would expect us to shoot for as much flexibility as
> > > we possible, similar to what we've done for our ACL system where we
> > > support down to a column-level (and row level with RLS).
> > >
> > > That's our target end-goal.  Having an incremental plan to get there
> > > where we start with something simpler and then work towards a more
> > > complicated implementation is fine- but that base, as I've said multiple
> > > times and as supported by what we see other database systems have,
> > > should include some kind of key store with support for multiple keys and
> > > a way to encrypt something less than the entire system.  Every other
> > > database system that we consider at all comparable has at least that.
> >
> > Well, we don't blindly copy features from other databases.  The features
> > has to be useful for our users and reasonable to implement in Postgres.
> > This is been the criteria for every other Postgres features I have seen
> > developed.
>
> Having listed out the feature set of each of the other major databases
> when it comes to TDE is exactly how we objectively look at what is being
> done in the industry, and that then gives us an understanding of what
> users (and auditors) coming from other platforms will expect.
>
> I entirely agree that we shouldn't just copy N feature from X other
> database system unless we feel that's the best approach, but when every
> other database system out there has capability Y for the general feature
> X that we're thinking about implementing, we should be questioning an
> approach which doesn't include that.

Agreed.  The features of other databases are a clear source for what we
should consider and run through the useful/reasonable filter.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Stephen Frost
Greetings,

* Bruce Momjian ([hidden email]) wrote:

> On Fri, Aug 23, 2019 at 07:45:22AM -0400, Stephen Frost wrote:
> > Having listed out the feature set of each of the other major databases
> > when it comes to TDE is exactly how we objectively look at what is being
> > done in the industry, and that then gives us an understanding of what
> > users (and auditors) coming from other platforms will expect.
> >
> > I entirely agree that we shouldn't just copy N feature from X other
> > database system unless we feel that's the best approach, but when every
> > other database system out there has capability Y for the general feature
> > X that we're thinking about implementing, we should be questioning an
> > approach which doesn't include that.
>
> Agreed.  The features of other databases are a clear source for what we
> should consider and run through the useful/reasonable filter.
Following on from that- when other databases don't have something that
we're thinking about implementing, maybe we should be contemplating if
it really makes sense as a requirement for us.

Specifically in this case- I went back and tried to figure out what
other database systems have an "encrypt EVERYTHING" option.  I didn't
have much luck finding one though.  So I think we need to ask ourselves-
the "check box" that we're trying to check off with TDE, do the other
database system check that box?  If so, then it looks like the "check
box" isn't actually "encrypt EVERYTHING", it's more along the lines of
"make sure all regular user data is encrypted automatically" or some
such, and that's a very different requirement, which seems to be
answered by the other systems by having a KMS + tablespace/database
level encryption.  We certainly shouldn't be putting a lot of effort
into building something that is either overkill or won't be interesting
to users due to limitations like "have to take the entire cluster
offline to re-key it".

Now, that KMS has to be encrypted using a master key, of course, and we
have to make sure that it is able to survive across a crash, and it'd
sure be nice if it was indexed.  One option for such a KMS would be
something entirely external (which could potentially just be another PG
database or something) but it'd be nice if we had something built-in.
We might also want it to be replicated (or maybe we don't, as was
discussed on the call, to allow for a replica to use an independent set
of keys- of course that leads to issues with pg_rewind and such though).

Anything built-in does seem like it'd be a fair bit of work to get it to
address those requirements, but that does seem to be what the other
database systems have done.  Unfortunately, their documentation doesn't
seem to really say exactly what they've done to address that.

A couple random ideas that probably won't work, but I'll put them out
there for others to shoot down-

Some kind of 2-phase WAL pass, where we do WAL replay for the
non-encrypted bits first (which would include the KMS) and then go back
and WAL replay the encrypted stuff.  Seems terrible.

An independent WAL for the KMS only.  Ugh, do we need another walwriter
then?  and buffers, and lots of other stuff.

Some kind of flat-file based approach with a temp file and renaming of
files using durable_rename(), like what we used to do with
pg_shadow/authid, and now do with replorigin_checkpoint and such?

Something else?

Thoughts?

Thanks!

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Bruce Momjian
On Fri, Aug 23, 2019 at 10:35:17AM -0400, Stephen Frost wrote:
> > Agreed.  The features of other databases are a clear source for what we
> > should consider and run through the useful/reasonable filter.
>
> Following on from that- when other databases don't have something that
> we're thinking about implementing, maybe we should be contemplating if
> it really makes sense as a requirement for us.

Yes, that's a good point.

> Specifically in this case- I went back and tried to figure out what
> other database systems have an "encrypt EVERYTHING" option.  I didn't
> have much luck finding one though.  So I think we need to ask ourselves-
> the "check box" that we're trying to check off with TDE, do the other
> database system check that box?  If so, then it looks like the "check
> box" isn't actually "encrypt EVERYTHING", it's more along the lines of
> "make sure all regular user data is encrypted automatically" or some
> such, and that's a very different requirement, which seems to be
> answered by the other systems by having a KMS + tablespace/database
> level encryption.  We certainly shouldn't be putting a lot of effort
> into building something that is either overkill or won't be interesting
> to users due to limitations like "have to take the entire cluster
> offline to re-key it".

Well, I think they might do that to reduce encryption overhead.  I think
tests have shown that is not an issue, but we will need to test further.
I am not sure of the downside of encrypting everything, since it leaks
the least information and has a minimal user API and code impact.  What
is the value of encrypting only the user rows?  Better key control?

> Now, that KMS has to be encrypted using a master key, of course, and we
> have to make sure that it is able to survive across a crash, and it'd
> sure be nice if it was indexed.  One option for such a KMS would be
> something entirely external (which could potentially just be another PG
> database or something) but it'd be nice if we had something built-in.
> We might also want it to be replicated (or maybe we don't, as was
> discussed on the call, to allow for a replica to use an independent set
> of keys- of course that leads to issues with pg_rewind and such though).

I think the replica could use a different key for the relations, but the
WAL key would have to be the same.

> Anything built-in does seem like it'd be a fair bit of work to get it to
> address those requirements, but that does seem to be what the other
> database systems have done.  Unfortunately, their documentation doesn't
> seem to really say exactly what they've done to address that.

I do like they pgcrypto key support to be per-database so pg_dump will
dump the data encrypted, and with its locked keys.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Stephen Frost
Greetings,

* Bruce Momjian ([hidden email]) wrote:

> On Fri, Aug 23, 2019 at 10:35:17AM -0400, Stephen Frost wrote:
> > Following on from that- when other databases don't have something that
> > we're thinking about implementing, maybe we should be contemplating if
> > it really makes sense as a requirement for us.
>
> Yes, that's a good point.
>
> > Specifically in this case- I went back and tried to figure out what
> > other database systems have an "encrypt EVERYTHING" option.  I didn't
> > have much luck finding one though.  So I think we need to ask ourselves-
> > the "check box" that we're trying to check off with TDE, do the other
> > database system check that box?  If so, then it looks like the "check
> > box" isn't actually "encrypt EVERYTHING", it's more along the lines of
> > "make sure all regular user data is encrypted automatically" or some
> > such, and that's a very different requirement, which seems to be
> > answered by the other systems by having a KMS + tablespace/database
> > level encryption.  We certainly shouldn't be putting a lot of effort
> > into building something that is either overkill or won't be interesting
> > to users due to limitations like "have to take the entire cluster
> > offline to re-key it".
>
> Well, I think they might do that to reduce encryption overhead.  I think
> tests have shown that is not an issue, but we will need to test further.
I seriously doubt that's why and I don't think there's actually much
value in trying to figure out the "why" here- the question is, do those
systems answer the check-box requirement that was brought up on the call
as the justification for this feature?  If so, then clearly not
everything is required to be encrypted and we shouldn't be stressing
over trying to do that.

> I am not sure of the downside of encrypting everything, since it leaks
> the least information and has a minimal user API and code impact.  What
> is the value of encrypting only the user rows?  Better key control?

Yes, better key control, and better user API, and avoiding having an
implementation that isn't actually what people either expect or want.  I
don't agree at all that this distinction has a "minimal user API
impact"- much of the reason we were throwing out the idea of having a
proper KMS for the "bulk data encryption", at least from what I gathered
on the call, is because of the issues around having to try and bootstrap
a fully encrypted system and deal with crash recovery and hypothesized
leaks.  If we can accept that it's alright for some data to be
unencrypted, then that certainly makes life easier for us, and from what
it looks like, that's pretty typical in industry.  I daresay it seems
likely that could get us all the way to table-level encryption of whole
tuples as discussed elsewhere.  I had a further side-chat with Sehrope
where I believe I explained why the concern regarding tids and ordering
isn't actually valid too, would be great if we could discuss that at
some point as well.  I'd be happy to chat with you about it first and
then if we agree, write up the discussion for the list as well.

> > Now, that KMS has to be encrypted using a master key, of course, and we
> > have to make sure that it is able to survive across a crash, and it'd
> > sure be nice if it was indexed.  One option for such a KMS would be
> > something entirely external (which could potentially just be another PG
> > database or something) but it'd be nice if we had something built-in.
> > We might also want it to be replicated (or maybe we don't, as was
> > discussed on the call, to allow for a replica to use an independent set
> > of keys- of course that leads to issues with pg_rewind and such though).
>
> I think the replica could use a different key for the relations, but the
> WAL key would have to be the same.
This depends on how the WAL is sent to the replica-- if it's sent
unencrypted then the replica could have a different key, at least
potentially.  There are some very interesting questions around pg_rewind
support and archive_mode = always, but that's pretty far down the road
and we may have to tell the users that they have to make some choices
about if they want to have support for those features.

> > Anything built-in does seem like it'd be a fair bit of work to get it to
> > address those requirements, but that does seem to be what the other
> > database systems have done.  Unfortunately, their documentation doesn't
> > seem to really say exactly what they've done to address that.
>
> I do like they pgcrypto key support to be per-database so pg_dump will
> dump the data encrypted, and with its locked keys.

Yes, a built-in KMS would also need pg_dump support.

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Bruce Momjian
On Fri, Aug 23, 2019 at 10:04:13PM -0400, Stephen Frost wrote:
> > Well, I think they might do that to reduce encryption overhead.  I think
> > tests have shown that is not an issue, but we will need to test further.
>
> I seriously doubt that's why and I don't think there's actually much
> value in trying to figure out the "why" here- the question is, do those
> systems answer the check-box requirement that was brought up on the call
> as the justification for this feature?  If so, then clearly not
> everything is required to be encrypted and we shouldn't be stressing
> over trying to do that.

We will stress in trying _not_ to encrypt everything.

> > I am not sure of the downside of encrypting everything, since it leaks
> > the least information and has a minimal user API and code impact.  What
> > is the value of encrypting only the user rows?  Better key control?
>
> Yes, better key control, and better user API, and avoiding having an

Uh, there is no user API for all-cluster encryption except for the
administrator.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Moon, Insung-2
In reply to this post by Bruce Momjian
Dear Hackers. 
It's been a long time since I sent a mail.

On Sat, Aug 24, 2019 at 9:27 AM Bruce Momjian <[hidden email]> wrote:
On Fri, Aug 23, 2019 at 10:35:17AM -0400, Stephen Frost wrote:
> > Agreed.  The features of other databases are a clear source for what we
> > should consider and run through the useful/reasonable filter.
>
> Following on from that- when other databases don't have something that
> we're thinking about implementing, maybe we should be contemplating if
> it really makes sense as a requirement for us.

Yes, that's a good point.

> Specifically in this case- I went back and tried to figure out what
> other database systems have an "encrypt EVERYTHING" option.  I didn't
> have much luck finding one though.  So I think we need to ask ourselves-
> the "check box" that we're trying to check off with TDE, do the other
> database system check that box?  If so, then it looks like the "check
> box" isn't actually "encrypt EVERYTHING", it's more along the lines of
> "make sure all regular user data is encrypted automatically" or some
> such, and that's a very different requirement, which seems to be
> answered by the other systems by having a KMS + tablespace/database
> level encryption.  We certainly shouldn't be putting a lot of effort
> into building something that is either overkill or won't be interesting
> to users due to limitations like "have to take the entire cluster
> offline to re-key it".

Well, I think they might do that to reduce encryption overhead.  I think
tests have shown that is not an issue, but we will need to test further.
I am not sure of the downside of encrypting everything, since it leaks
the least information and has a minimal user API and code impact.  What
is the value of encrypting only the user rows?  Better key control?

Maybe my think can be very wrong. Please understand.

I think that the value of encrypting with granularity rather than 
encrypting of all clusters. Maybe it is advantageous to manageability.

Of course, encrypting of all clusters is an excellent choice because 
it has minimal impact on the code, and perhaps simply to implement and 
management APIs.

But what about Database user or DBA? I thought of the example below.

Suppose we have a system with multiple tenants
(Tenant here means table, tablespace, or database.) in one database cluster.
(I think it's similar to a cloud service. I think this is going to be a common case in the future.)

We need to encrypt for tenant A and not need encryption for tenant B.
In this case, is there a reason to encrypt until tenant B?
It is a great advantage that the user, which is a characteristic of TDE, 
is encrypted without considering encryption.
But there is no reason to encrypt even a tenant that does not require encryption.
And another example, in terms of key management, I thought to encrypt with 
granularity was a good choice (especially key rotation).

A special situation where A and B tenants need encryption and A tenant needs to 
rotate the key once every three months. And B tenant needs to rotate the key once a year. 
( Of course, maybe it is a very rare case.)

If we encrypt all clusters and do not manage of granularity encryption keys by tenants. 
And when they run to A tenant key rotated, the B tenant is also rotated together, 
which can cause operational discomfort.

Of course, encrypting of all clusters and creating the managing of 
granularity keys for each tenant will solve the problem.
But if we are implementing this part, I think it's the same as
the implementation of granular encryption.

Best Regards.
Moon.
 

> Now, that KMS has to be encrypted using a master key, of course, and we
> have to make sure that it is able to survive across a crash, and it'd
> sure be nice if it was indexed.  One option for such a KMS would be
> something entirely external (which could potentially just be another PG
> database or something) but it'd be nice if we had something built-in.
> We might also want it to be replicated (or maybe we don't, as was
> discussed on the call, to allow for a replica to use an independent set
> of keys- of course that leads to issues with pg_rewind and such though).

I think the replica could use a different key for the relations, but the
WAL key would have to be the same.

> Anything built-in does seem like it'd be a fair bit of work to get it to
> address those requirements, but that does seem to be what the other
> database systems have done.  Unfortunately, their documentation doesn't
> seem to really say exactly what they've done to address that.

I do like they pgcrypto key support to be per-database so pg_dump will
dump the data encrypted, and with its locked keys.

--
  Bruce Momjian  <[hidden email]>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +


Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Moon, Insung-2
In reply to this post by Stephen Frost
Dear Hackers.


> Specifically in this case- I went back and tried to figure out what
> other database systems have an "encrypt EVERYTHING" option.  I didn't
> have much luck finding one though.  So I think we need to ask ourselves-
> the "check box" that we're trying to check off with TDE, do the other
> database system check that box?  If so, then it looks like the "check
> box" isn't actually "encrypt EVERYTHING", it's more along the lines of
> "make sure all regular user data is encrypted automatically" or some
> such, and that's a very different requirement, which seems to be
> answered by the other systems by having a KMS + tablespace/database
> level encryption.  We certainly shouldn't be putting a lot of effort
> into building something that is either overkill or won't be interesting
> to users due to limitations like "have to take the entire cluster
> offline to re-key it".
>
> Now, that KMS has to be encrypted using a master key, of course, and we
> have to make sure that it is able to survive across a crash, and it'd
> sure be nice if it was indexed.

Sorry, Does KMS here mean key Management System(or Service)?
I may be mistaken, but I know that KMS is managing cryptographic keys.
In other words, I kept the master key(or KEK) in KMS( not kept to
PostgreSQL server-side),
and PostgreSQL fetched the master key from KMS, and then encrypt or
decrypt it on the PostgreSQL server-side.
Of course, some KMS supports encryption function,
which is the function to encrypt plain text inside KMS. Is this
project aiming to use this function?


>
> A couple random ideas that probably won't work, but I'll put them out
> there for others to shoot down-
>
> Some kind of 2-phase WAL pass, where we do WAL replay for the
> non-encrypted bits first (which would include the KMS) and then go back
> and WAL replay the encrypted stuff.  Seems terrible.

Sorry, Can you tell me an example what is the 2-phase WAL pass?
I know that WAL read process is decrypted WAL data when
reading an encrypted WAL page(per-page encrypt) or
WAL record(per-record encrypt) and then replay.
Is this a different case?

Best Regards.
Moon.

>
> An independent WAL for the KMS only.  Ugh, do we need another walwriter
> then?  and buffers, and lots of other stuff.
>
> Some kind of flat-file based approach with a temp file and renaming of
> files using durable_rename(), like what we used to do with
> pg_shadow/authid, and now do with replorigin_checkpoint and such?
>
> Something else?
>
> Thoughts?
>
> Thanks!
>
> Stephen


1 ... 2021222324