ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Transparent Data Encryption (TDE) in Apache Ignite
Date Fri, 02 Mar 2018 04:29:27 GMT
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