ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@gridgain.com>
Subject Re: Transparent Data Encryption (TDE) in Apache Ignite
Date Mon, 05 Mar 2018 23:09:59 GMT
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