ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Дмитрий Рябов <somefire...@gmail.com>
Subject Re: Transparent Data Encryption (TDE) in Apache Ignite
Date Mon, 26 Mar 2018 17:27:30 GMT
Hi!

> 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?

PCI DSS [1] have 12 requirements, but you are asking about "Requirement 3:
Protect stored cardholder data". It's description doesn't say anything
about way of protection.

But there is point 3.4.1 which says that we can use any way to protect data:
"If disk encryption is used (rather than file- or column-level database
encryption), logical access must be managed separately and independently of
native operating system authentication and access control mechanisms (for
example, by not using local user account  databases or general network
login credentials). Decryption keys must not be associated with user
accounts. Note: This requirement applies in addition to all other PCI DSS
encryption and key-management requirements."

> Joined node should be activated (included to baseline) by activation
> request contains node-password.

Agree, this is safer.

> Any reason to keed data crypted in memory?

Only if we want to protect data from something like spectre and meltdown,
but I think they are trouble of hardware, but not software.

> PCI DSS require this?

PCI DSS requires to "protect stored data". That means we *can* encrypt data
to keep it safe in memory, but we don't need it.



[1]
https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss

2018-03-26 19:57 GMT+03:00 Anton Vinogradov <av@apache.org>:

> Folks,
>
> I've checked presentation.
>
> 1) It's a bad idea to allow automatic node join (sending decripted cache's
> keys on join).
>
> Each node join should be allowed by administrator.
> We have to use two-step verification in that case.
> - admitistrator set keystore password for each node
> - another administrator use this password on node join.
>
> My vision is:
> - each node should keep master key in keystore
> - each keystore should have *own* keystore password
> - on cluster activation we have to specify list of pairs node-password.
> This will provide us guarantee that only allowed nodes are in cluster.
> - TDE should be available only in case baseline used.
> Joined node should be activated (included to baseline) by activation
> request contains node-password.
>
> So, on initial activation or BLT join, each node will gain keystore
> password and encrypted cache's passwords.
> This case will guarantee data safe even on SSL issues.
>
> 2) Any reason to keed data crypted in memory? PCI DSS require this?
> Data shoud be crypted on eviction and rebalancing, I think.
> In that case we can implement TDE and data compression in same way.
>
> Thoughts?
>
>
> 2018-03-12 17:58 GMT+03:00 Denis Magda <dmagda@apache.org>:
>
> > Nikolay, please try on more time.
> >
> > --
> > Denis
> >
> > On Sun, Mar 11, 2018 at 11:20 PM, Nikolay Izhikov <nizhikov@apache.org>
> > wrote:
> >
> > > Hello, Denis.
> > >
> > > Did you give me the permissions?
> > > Seems, I still can't create IEP on the IGNITE Wiki.
> > >
> > > https://cwiki.apache.org/confluence/display/IGNITE/Active+Proposals
> > >
> > > В Вт, 06/03/2018 в 08:55 +0300, Nikolay Izhikov пишет:
> > > > 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