Masahiko Sawada <sawada.m...@gmail.com> 于2019年6月17日周一 下午8:30写道：
> On Fri, Jun 14, 2019 at 7:41 AM Tomas Vondra > <tomas.von...@2ndquadrant.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.von...@2ndquadrant.com> wrote: > > > > On Sun, Jun 16, 2019 at 02:10:23PM -0400, Stephen Frost wrote: > > >Greetings, > > > > > >* Joe Conway (m...@joeconway.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 > > >
