Hello. Deisgn updated [1]
Please, share your feedback [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652381 В Вт, 23/10/2018 в 21:49 +0300, Nikolay Izhikov пишет: > 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
