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
>

Reply via email to