Hello, Anton. Thank you for your very usefull feedback!
I accept your proposals. Seems it makes this feature more robust and clear. Will update design in confluence in a couple of hours. В Вт, 23/10/2018 в 19:18 +0300, Anton Vinogradov пишет: > Nikolay, > > I have some comments. > > 1) Master key setup and removal is a responsibility of system administrator. > No matter how he will set a new master key or remove an old. > The only need it to have both keys, new and old, installed before starting > the rotation process. > > 2) Master Key rotation is a process of cache's keys re-encryption. > > So, we should send a message contains a new master key id only. > We also have to check that "Master Key rotation" allowed to the user by > checking it has SecurityPermission#ADMIN_OPS permission. > > During this message handling, we have to re-encrypt keys and to set new > master key id. > > 3) We should provide recovery mode for nodes unexpectedly leaved cluster > during "Master Key rotation" process. > We have to have a special "node start" command allows to change node's > master key before joining the cluster. > > пн, 22 окт. 2018 г. в 22:39, Nikolay Izhikov <nizhi...@apache.org>: > > > Hello, Igniters. > > > > As you may know, we successfully implement TDE. Phase-1 feature. [1] > > This improvement allows users to use an encrypted cache. > > > > To make TDE production ready I propose to extend it with two things: > > > > * Master key rotation. > > * Cache key rotation. > > > > Such features required by many security standards such as PCI DSS [2] and > > GDPR [3] > > > > I think it would be easier to discuss, implement and review both features > > separately. > > So my plan is the following: > > > > * TDE. Phase-2 - Master key rotation [4] > > * TDE. Phase-3 - Cache key rotation. [5] > > > > I prepared designs for both parts. > > I want to specifically discuss Phase-2 design. > > Phase-3 design state is [EARLY DRAFT]. > > I propose to use Phase-3 design as a reference to make sure we have a > > consistent view of all aspects of TDE > > and can be implemented without significant changes in earlier parts. > > > > Below, my design. > > Following changes will be made in confluence [4]. > > Please, share your feedback. > > > > *TDE. PHASE-2. MASTER KEY ROTATION* > > Key rotation required in case of it compromising or at the end of > > crypto period(key validity period). > > > > Goal: > > To implement the ability to rotate master encryption key. > > > > New processes: > > 1. Master key rotation. > > 2. Removal of a master key. > > > > New administrator commands: > > 1. Master keys view: node -> master key hash > > 2. Cache group keys view: node -> group name -> encryption key > > hash > > > > MASTER KEY ROTATION: > > Process start: > > Administrator initiates key rotation via some kind of > > user interface(CLI, Visor, Web Console, JMX, etc). > > > > Process description: > > Message is sent by discovery. > > A Message should contain: > > * Master cache key encrypted with the current > > master key. > > > > When server node processed message following actions are > > executed: > > * Blocks creation of encrypted cache key. > > * Encrypt cache group keys with new master key. > > * Unblock creation of encrypted cache key. > > > > New joining node should also change the current master key > > with the new one. > > > > Process completion: > > The administrator initiates process completion via the > > interface by using “master key removal” command. > > Design assumes an administrator will check that all nodes > > successfully change master key and all required nodes are alive. > > > > MASTER KEY REMOVAL: > > Process start: > > Administrator initiates process via some kind of user > > interface(CLI, Visor, WebConsole, JMX, etc), > > > > Process description: > > Message is sent by discovery. > > Message should contain: > > * New master key hash. > > When a server node processed message following actions are > > executed: > > Received master key hash compared with known master key > > hash. > > Previous master key removed using configured > > EncryptionSPI. > > > > NEW COMMANDS: > > Master key hashes. > > Input: nothing > > Output: List of Tuples3 > > * Node ID > > * Current key hash > > * Previous key hash or null. > > Cache key hashes. > > Input: cache id. > > Output: List of Tuples3 > > * Node ID > > * Current key hash > > * Previous key hash or null. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-8260 > > [2] https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf > > [3] https://gdpr-info.eu/ > > [4] > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652381 > > [5] > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652384 > >
signature.asc
Description: This is a digitally signed message part
