Nikolay, Can you explain why such restriction is necessary ? Most likely having a currently re-encrypting node serving only demand requests will have least preformance impact on a grid.
пн, 25 мая 2020 г. в 11:08, Nikolay Izhikov <nizhi...@apache.org>: > Hello, Alexei. > > I think we want to implement this feature without nodes restart. > In the ideal scenario all nodes will stay alive and respond to the user > requests. > > > 24 мая 2020 г., в 15:24, Alexei Scherbakov <alexey.scherbak...@gmail.com> > написал(а): > > > > Pavel Pereslegin, > > > > I see another opportunity. > > We can use rebalancing to re-encrypt node data with a new key. > > It's a trivial procedure for me: stop a node, clear database, change a > key, > > start node and wait for rebalancing to complete. > > Data will be re-encrypted during rebalancing. > > > > Did I miss something ? > > > > пт, 22 мая 2020 г. в 16:14, Ivan Rakov <ivan.glu...@gmail.com>: > > > >> Folks, > >> > >> Just keeping you informed: I and my colleagues are highly interested in > TDE > >> in general and keys rotations specifically, but we don't have enough > time > >> so far. > >> We'll dive into this feature and participate in reviews next month. > >> > >> -- > >> Best Regards, > >> Ivan Rakov > >> > >> On Sun, May 17, 2020 at 10:51 PM Pavel Pereslegin <xxt...@gmail.com> > >> wrote: > >> > >>> Hello, Alexey. > >>> > >>>> is the encryption key for the data the same on all nodes in the > >> cluster? > >>> Yes, each encrypted cache group has its own encryption key, the key is > >>> the same on all nodes. > >>> > >>>> Clearly, during the re-encryption there will exist pages > >>>> encrypted with both new and old keys at the same time. > >>> Yes, there will be pages encrypted with different keys at the same > time. > >>> Currently, we only store one key for one cache group. To rotate a key, > >>> at a certain point in time it is necessary to support several keys (at > >>> least for reading the WAL). > >>> For the "in place" strategy, we'll store the encryption key identifier > >>> on each encrypted page (we currently have some unused space on > >>> encrypted page, so I don't expect any memory overhead here). Thus, we > >>> will have several keys for reading and one key for writing. I assume > >>> that the old key will be automatically deleted when a specific WAL > >>> segment is deleted (and re-encryption is finished). > >>> > >>>> Will a node continue to re-encrypt the data after it restarts? > >>> Yes. > >>> > >>>> If a node goes down during the re-encryption, but the rest of the > >>>> cluster finishes re-encryption, will we consider the procedure > >> complete? > >>> I'm not sure, but it looks like the key rotation is complete when we > >>> set the new key on all nodes so that the updates will be encrypted > >>> with the new key (as required by PCI DSS). > >>> Status of re-encryption can be obtained separately (locally or cluster > >>> wide). > >>> > >>> I forgot to mention that with “in place” re-encryption it will be > >>> impossible to quickly cancel re-encryption, because by canceling we > >>> mean re-encryption with the old key. > >>> > >>>> How do you see the whole key rotation procedure will work? > >>> Initial design for re-encryption with "partition copying" is described > >>> here [1]. I'll prepare detailed design for "in place" re-encryption if > >>> we'll go this way. In short, send the new encryption key cluster-wide, > >>> each node adds a new key and starts background re-encryption. > >>> > >>> [1] > >>> > >> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase-3.Cachekeyrotation.-Copywithre-encryptiondesign > >>> . > >>> > >>> вс, 17 мая 2020 г. в 18:35, Alexey Goncharuk < > alexey.goncha...@gmail.com > >>> : > >>>> > >>>> Pavel, Anton, > >>>> > >>>> How do you see the whole key rotation procedure will work? Clearly, > >>> during > >>>> the re-encryption there will exist pages encrypted with both new and > >> old > >>>> keys at the same time. Will a node continue to re-encrypt the data > >> after > >>> it > >>>> restarts? If a node goes down during the re-encryption, but the rest > of > >>> the > >>>> cluster finishes re-encryption, will we consider the procedure > >> complete? > >>> By > >>>> the way, is the encryption key for the data the same on all nodes in > >> the > >>>> cluster? > >>>> > >>>> чт, 14 мая 2020 г. в 11:30, Anton Vinogradov <a...@apache.org>: > >>>> > >>>>> +1 to "In place re-encryption". > >>>>> > >>>>> - It has a simple design. > >>>>> - Clusters under load may require just load to re-encrypt the data. > >>>>> (Friendly to load). > >>>>> - Easy to throttle. > >>>>> - Easy to continue. > >>>>> - Design compatible with the multi-key architecture. > >>>>> - It can be optimized to use own WAL buffer and to re-encrypt pages > >>> without > >>>>> restoring them to on-heap. > >>>>> > >>>>> On Thu, May 14, 2020 at 1:54 AM Pavel Pereslegin <xxt...@gmail.com> > >>> wrote: > >>>>> > >>>>>> Hello Igniters. > >>>>>> > >>>>>> Recently, master key rotation for Apache Ignite Transparent Data > >>>>>> Encryption was implemented [1], but some security standards (PCI > >> DSS > >>>>>> at least) require rotation of all encryption keys [2]. Currently, > >>>>>> encryption occurs when reading/writing pages to disk, cache > >>> encryption > >>>>>> keys are stored in metastore. > >>>>>> > >>>>>> I'm going to contribute cache encryption key rotation and want to > >>>>>> consult what is the best way to re-encrypting existing data, I see > >>> two > >>>>>> different strategies. > >>>>>> > >>>>>> 1. In place re-encryption: > >>>>>> Using the old key, sequentially read all the pages from the > >>> datastore, > >>>>>> mark as dirty and log them into the WAL. After checkpoint pages > >> will > >>>>>> be stored to disk encrypted with the new key (as usual, along with > >>>>>> updates). This strategy requires store the identifier (number) of > >> the > >>>>>> encryption key into the encrypted page. > >>>>>> pros: > >>>>>> - can work in the background with minimal performance impact > >> (this > >>>>>> impact can be managed). > >>>>>> cons: > >>>>>> - page duplication in the WAL may affect performance and > >> historical > >>>>>> rebalance. > >>>>>> > >>>>>> 2. Copy partition with re-encryption. > >>>>>> This strategy is similar to partition snapshotting [3] - create > >>>>>> partition copy encrypted with the new key and then replace the > >>>>>> original partition file with the new one (see details [4]). > >>>>>> pros: > >>>>>> - should work faster than "in place" re-encryption. > >>>>>> cons: > >>>>>> - re-encryption in active cluster (and on unstable topology) can > >> be > >>>>>> difficult to implement. > >>>>>> > >>>>>> (See more detailed comparison [5]) > >>>>>> > >>>>>> Re-encryption of existing data is a long and rare procedure (It is > >>>>>> recommended to change the key every 6 months, but at least once > >> every > >>>>>> 2 years). Thus, re-encryption can be implemented for maintenance > >> mode > >>>>>> (for example, on a stable topology in a read-only cluster) and in > >>> such > >>>>>> case the approach with partition copying seems simpler and faster. > >>>>>> > >>>>>> So, what do you think - do we need "online" re-encryption and which > >>> of > >>>>>> the proposed options is best suited for this? > >>>>>> > >>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12186 > >>>>>> [2] > >>> https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf > >>>>>> [3] > >>>>>> > >>>>> > >>> > >> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-43%3A+Cluster+snapshots#IEP-43:Clustersnapshots-Partitionscopystrategy > >>>>>> [4] > >>>>>> > >>>>> > >>> > >> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase-3.Cachekeyrotation.-Copywithre-encryptiondesign > >>>>>> . > >>>>>> [5] > >>>>>> > >>>>> > >>> > >> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384#TDE.Phase-3.Cachekeyrotation.-Comparison > >>>>>> > >>>>> > >>> > >> > > > > > > -- > > > > Best regards, > > Alexei Scherbakov > > -- Best regards, Alexei Scherbakov
