ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Pavlov <dpavlov....@gmail.com>
Subject Re: Transparent Data Encryption (TDE) in Apache Ignite
Date Tue, 06 Mar 2018 20:43:14 GMT
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 <nizhikov@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 <nizhikov@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 <nizhikov@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 <
> > >
> > > nizhikov@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 <
> > >
> > > nizhikov@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 <
> > > > >
> > > > > nizhikov@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
> > > > > >
> > > > > >

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message