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

Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> 于2019年6月17日周一 下午8:30写道：

> On Fri, Jun 14, 2019 at 7:41 AM Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> > I personally find the idea of encrypting tablespaces rather strange.
> > Tablespaces are meant to define hysical location for objects, but this
> > would also use them to "mark" objects as encrypted or not. That just
> > seems misguided and would make the life harder for many users.
> >
> > For example, what if I don't have any tablespaces (except for the
> > default one), but I want to encrypt only some objects? Suddenly I have
> > to create a tablespace, which will however cause various difficulties
> > down the road (during pg_basebackup, etc.).
>
> I guess that we can have an encrypted tabelspace by default (e.g.
> pg_default_enc). Or we encrypt per tables while having encryption keys
> per tablespaces.
>

Hi Sawada-san,
I do agree with it.

>
> On Mon, Jun 17, 2019 at 6:54 AM Tomas Vondra
> <tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> >
> > On Sun, Jun 16, 2019 at 02:10:23PM -0400, Stephen Frost wrote:
> > >Greetings,
> > >
> > >* Joe Conway (mail(at)joeconway(dot)com) wrote:
> > >> On 6/16/19 9:45 AM, Bruce Momjian wrote:
> > >> > On Sun, Jun 16, 2019 at 07:07:20AM -0400, Joe Conway wrote:
> > >> >> In any case it doesn't address my first point, which is limiting
> the
> > >> >> volume encrypted with the same key. Another valid reason is you
> might
> > >> >> have data at varying sensitivity levels and prefer different keys
> be
> > >> >> used for each level.
> > >> >
> > >> > That seems quite complex.
> > >>
> > >> How? It is no more complex than encrypting at the tablespace level
> > >> already gives you - in that case you get this property for free if you
> > >> care to use it.
> > >
> > >Perhaps not surprising, but I'm definitely in agreement with Joe
> > >regarding having multiple keys when possible and (reasonably)
> > >straight-forward to do so. I also don't buy off on the OpenSSL
> > >argument; their more severe issues certainly haven't been due to key
> > >management issues such as what we're discussing here, so I don't think
> > >the argument applies.
> > >
> >
> > I'm not sure what exactly is the "OpenSSL argument" you're disagreeing
> > with? IMHO Bruce is quite right that the risk of vulnerabilities grows
> > with the complexity of the system (both due to implementation bugs and
> > general design weaknesses). I don't think it's tied to the key
> > management specifically, except that it's one of the parts that may
> > contribute to the complexity.
> >
> > (It's often claimed that key management is one of the weakest points of
> > current crypto systems - we have safe (a)symmetric algorithms, but safe
> > handling of keys is an issue. I don't have data / papers supporting this
> > claim, I kinda believe it.)
> >
> > Now, I'm not opposed to eventually implementing something more
> > elaborate, but I also think just encrypting the whole cluster (not
> > necessarily with a single key, but with one master key) would be enough
> > for vast majority of users. Plus it's less error prone and easier to
> > operate (backups, replicas, crash recovery, ...).
> >
> > But there's about 0% chance we'll get that in v1, of course, so we need
> > s "minimum viable product" to build on anyway.
> >
>
> I agree that we need minimum viable product first. But I'm not sure
> it's true that the implementing the cluster-wide TDE first could be
> the first step of per-tablespace/table TDE.
>

Yes, we could complete the per-tablespace/table TDE in version 13.
And we could do cluster-wide TDE in the next version.
But I remember you said there are so many keys to manage in the table-level.
Will we add the table-level TDE in the first version?

And I have two questions.
1. Will we add hooks to support replacing the encryption algorithms?
2. Will we add some encryption algorithm or use some in some libraries?

Regards,

--
Shwan Wang
HIGHGO SOFTWARE

> The purpose of cluster-wide TDE and table/tablespace TDE are slightly
> different in terms of encryption target objects. The cluster-wide TDE
> would be a good solution for users who want to encrypt everything
> while the table/tabelspace TDE would help more severe use cases in
> terms of both of security and performance.
>
> The cluster-wide TDE eventually encrypts SLRU data and all WAL
> including non-user data related WAL while table/tablespace TDE doesn't
> unless we develop such functionality. In addition, the cluster-wide
> TDE also encrypts system catalogs but in table/tablespace TDE user
> would be able to control that somewhat. That is, if we developed the
> cluster-wide TDE first, when we develop table/tablespace TDE on top of
> that we would need to change TDE so that table/tablespace TDE can
> encrypt even non-user data related data while retaining its simple
> user interface, which would rather make the feature complex, I'm
> concerned. We can support them as different TDE features but I'm not
> sure it's a good choice for users.
>
> From perspective of cryptographic, I think the fine grained TDE would
> be better solution. Therefore if we eventually want the fine grained
> TDE I wonder if it might be better to develop the table/tablespace TDE
> first while keeping it simple as much as possible in v1, and then we
> can provide the functionality to encrypt other data in database
> cluster to satisfy the encrypting-everything requirement. I guess that
> it's easier to incrementally add encryption target objects rather than
> making it fine grained while not changing encryption target objects.
>
> FWIW I'm writing a draft patch of per tablespace TDE and will submit
> it in this month. We can more discuss the complexity of the proposed
> TDE using it.
>
> Regards,
>
> --
> Masahiko Sawada
> NIPPON TELEGRAPH AND TELEPHONE CORPORATION
> NTT Open Source Software Center
>
>
>