Hi Nikolay,

Please note there is cluster-auto activation when it reaches baseline
topology.

As far as I remember to be PCI-DSS compliant it is sufficient to use
encryption at file system level. But it needs to be double-checked. It
requires encrypt transmission of cardholder data across open, public
networks. Could you point me where does it require DB data to be encrypted?

Would this solution have pros in the point of view of security compared
with encrypted FS usage?

Please keep me posted, I would like to join this review.

Sincerely,
Dmitriy Pavlov

вт, 6 мар. 2018 г. в 13:29, Nikolay Izhikov <nizhi...@apache.org>:

> Alexey,
>
> Yes, administrator has to enter password before cluster *activation*(not
> start).
>
> В Вт, 06/03/2018 в 13:27 +0300, Alexey Goncharuk пишет:
> > Nikolay,
> >
> > Does it mean that administrator must enter the MEK password upon Ignite
> > start?
> >
> > 2018-03-06 13:24 GMT+03:00 Nikolay Izhikov <nizhi...@apache.org>:
> >
> > > Hello, Alexey.
> > >
> > > Thank you for very helpfull feedback.
> > > We certainly consider all the issues you written.
> > >
> > > > How encryption keys will be stored and accessed?
> > >
> > > *MEK(Master encryption key)* will be stored in regular java key store
> JKS
> > > [1].
> > > To access it admin must enter key store password.
> > >
> > > *CEK(Cache encryption key)* will be stored inside regular Ignite cache.
> > > It will be encrypted by MEK.
> > > So access to CEK may be done only after one got the MEK.
> > >
> > > Please, see IEP draft for futher information [2].
> > >
> > > > Will pages be encrypted on disk or also in memory?
> > >
> > > Current understanding that only on disk pages will be encrypted.
> > > PCI DSS standart requires only on disk encryption.
> > >
> > > > How do you make sure that encrypted page fits the page size
> > >
> > > AFAIK encryption doesn't affect data size.
> > >
> > > > This significantly increases success of known-plain-text attacks.
> > > > How will you write WAL delta records for encrypted pages?
> > >
> > > I don't have an answer to this questions for now.
> > > So, prior to starting an implementation we returns with answers.
> > >
> > > [1]
> https://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.html
> > > [2] https://1drv.ms/w/s!AqZdfua4UpmuhneoVhOCiXSUBGIf
> > >
> > >
> > > В Вт, 06/03/2018 в 13:04 +0300, Alexey Goncharuk пишет:
> > > > Guys,
> > > >
> > > > I think this TDE proposal is not thought through enough yet. Please
> > > > consider the following points when writing the IEP:
> > > >
> > > >  * How encryption keys will be stored and accessed? If the
> encryption key
> > > > is stored with the same permissions as the main data storage, the
> whole
> > > > exercise with encryption is self-deception
> > > >  * Will pages be encrypted on disk or also in memory?
> > > >  * How do you make sure that encrypted page fits the page size (I am
> not
> > >
> > > an
> > > > expert in encryption, so I am not sure if it adds an overhead)
> > > >  * As Dmitriy Pavlov mentioned, currently data and index pages are
> highly
> > > > redundant and some of the fields in certain pages are known in
> advance.
> > > > This significantly increases success of known-plain-text attacks.
> How are
> > > > you planning to fix it?
> > > >  * How will you write WAL delta records for encrypted pages? If a
> change
> > >
> > > in
> > > > a single byte will potentially change the whole page, this will
> induce a
> > > > huge write amplification on WAL. How do you encrypt WAL data
> records? How
> > > > will this work with this optimization: [1]
> > > >
> > > > [1] https://ggsystems.atlassian.net/browse/IGN-7789
> > > >
> > > > --AG
> > > >
> > > > 2018-03-06 8:55 GMT+03:00 Nikolay Izhikov <nizhi...@apache.org>:
> > > >
> > > > > Thank you, it's - nizhikov
> > > > >
> > > > > В Пн, 05/03/2018 в 15:09 -0800, Denis Magda пишет:
> > > > > > Nikolay, what's your Wiki ID? I'll grant you required
> permissions.
> > > > > >
> > > > > > --
> > > > > > Denis
> > > > > >
> > > > > > On Sun, Mar 4, 2018 at 11:00 PM, Nikolay Izhikov <
> > >
> > > nizhi...@apache.org>
> > > > >
> > > > > wrote:
> > > > > > > Hello, Denis.
> > > > > > >
> > > > > > > > I would encourage you creating an IEP
> > > > > > >
> > > > > > > That is exactly what we want to do :)
> > > > > > >
> > > > > > > But seems I have not sufficient privileges to do it on Ignite
> wiki.
> > > > > > >
> > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/
> > >
> > > Active+Proposals
> > > > > > >
> > > > > > > Can you or someone give me such rights?
> > > > > > >
> > > > > > > В Чт, 01/03/2018 в 22:23 -0800, Denis Magda пишет:
> > > > > > > > Dmitriy R., Nilokay,
> > > > > > > >
> > > > > > > > Thanks for the analysis and handout of the architectural
> design.
> > >
> > > No
> > > > >
> > > > > doubts,
> > > > > > > > it would be a valuable addition to Ignite.
> > > > > > > >
> > > > > > > > I would encourage you creating an IEP on the wiki and break
> the
> > >
> > > work
> > > > >
> > > > > into
> > > > > > > > pieces discussing specific part with the community.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Denis
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, Mar 1, 2018 at 9:29 PM, Nikolay Izhikov <
> > >
> > > nizhi...@apache.org>
> > > > >
> > > > > wrote:
> > > > > > > >
> > > > > > > > > Hello, Dmitriy.
> > > > > > > > >
> > > > > > > > > Thank you for feedback!
> > > > > > > > >
> > > > > > > > > > Will it be supported?
> > > > > > > > >
> > > > > > > > > Yes.
> > > > > > > > >
> > > > > > > > > TDE shouldn't broke any of existing Ignite features.
> > > > > > > > > It adds some encrypt/decrypt level when we writing and
> reading
> > > > >
> > > > > pages
> > > > > > > > > in/from PDS.
> > > > > > > > >
> > > > > > > > > В Пт, 02/03/2018 в 07:29 +0300, Dmitriy Setrakyan пишет:
> > > > > > > > > > I have looked at the design, but could not find anything
> > >
> > > about
> > > > >
> > > > > running
> > > > > > > > >
> > > > > > > > > SQL
> > > > > > > > > > queries against the encrypted data. Will it be supported?
> > > > > > > > > >
> > > > > > > > > > D.
> > > > > > > > > >
> > > > > > > > > > On Thu, Mar 1, 2018 at 8:05 PM, Nikolay Izhikov <
> > > > >
> > > > > nizhi...@apache.org>
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hell, Dima!
> > > > > > > > > > >
> > > > > > > > > > > Thank you for document!
> > > > > > > > > > >
> > > > > > > > > > > I'm ready to implement this feature with you.
> > > > > > > > > > >
> > > > > > > > > > > Igniters, please, share you thoughts about proposed
> design
> > > > > > > > > > >
> > > > > > > > > > > [1] https://1drv.ms/w/s!AqZdfua4UpmuhneoVhOCiXSUBGIf
> > > > > > > > > > >
> > > > > > > > > > > В Чт, 01/03/2018 в 15:46 +0300, Дмитрий Рябов пишет:
> > > > > > > > > > > > Hello, Igniters!
> > > > > > > > > > > >
> > > > > > > > > > > > I investigated the issue and wrote some details in a
> > >
> > > draft
> > > > >
> > > > > document
> > > > > > > > > > > > [1]. I think we should made IEP for TDE because it
> is a
> > >
> > > big
> > > > >
> > > > > change
> > > > > > > > >
> > > > > > > > > and
> > > > > > > > > > > > should be described in a single place, but not in a
> > >
> > > message
> > > > > > > > > > > > conversation.
> > > > > > > > > > > > Please, look it and write your thoughts. What is not
> > > > >
> > > > > understandable,
> > > > > > > > > > > > what should be detailed or described?
> > > > > > > > > > > >
> > > > > > > > > > > > > Where are we going to store keys (MEK) physically?
> > >
> > > Would
> > > > >
> > > > > it be
> > > > > > > > >
> > > > > > > > > PKCS#11
> > > > > > > > > > > > > storage? Where we will store passwords to unlock
> > >
> > > storage
> > > > >
> > > > > or it
> > > > > > > > >
> > > > > > > > > will be
> > > > > > > > > > > > > responibilty of user?
> > > > > > > > > > > >
> > > > > > > > > > > > I think we should provide interface for MEK storage
> to
> > >
> > > let
> > > > >
> > > > > users use
> > > > > > > > > > > > storages they want. I suppose at the first step we
> should
> > > > >
> > > > > provide
> > > > > > > > >
> > > > > > > > > very
> > > > > > > > > > > > simple implementation, which will store MEK on every
> node
> > > > >
> > > > > and MEK
> > > > > > > > >
> > > > > > > > > will
> > > > > > > > > > > > be extracted by administrator during cluster
> activation
> > > > >
> > > > > process. Once
> > > > > > > > > > > > MEK is extracted from key store, we decrypt CEKs and
> > >
> > > destroy
> > > > >
> > > > > open
> > > > > > > > >
> > > > > > > > > MEK,
> > > > > > > > > > > > leaving open only cache keys.
> > > > > > > > > > > >
> > > > > > > > > > > > I think external storage is user's worry and we
> shouldn't
> > > > >
> > > > > give users
> > > > > > > > > > > > built-in external storage like Oracle Wallet or
> Microsoft
> > > > >
> > > > > Azure Key
> > > > > > > > > > > > Vault because it will increase Ignite's complexity
> too
> > >
> > > much.
> > > > > > > > > > > >
> > > > > > > > > > > > And yes, we should to comply with the standards like
> > >
> > > PKCS#11.
> > > > > > > > > > > >
> > > > > > > > > > > > > One more thing is how "node gets MEK from
> > >
> > > coordinator", if
> > > > >
> > > > > we send
> > > > > > > > > > > > > cleartext MEK, such security becomes useless also.
> > > > > > > > > > > >
> > > > > > > > > > > > Yeah, that's why we should use secured connection.
> As I
> > > > >
> > > > > know, we have
> > > > > > > > > > > > SSL implementation over JDK implementation, am I
> right?
> > >
> > > But
> > > > >
> > > > > we must
> > > > > > > > > > > > ensure to use latest SSL/TLS version.
> > > > > > > > > > > >
> > > > > > > > > > > > [1] https://1drv.ms/w/s!AqZdfua4UpmuhneoVhOCiXSUBGIf
> > > > > >
> > > > > >

Reply via email to