[
https://issues.apache.org/jira/browse/HBASE-9578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786114#comment-13786114
]
Larry McCay commented on HBASE-9578:
------------------------------------
Hi Andrew - I missed this JIRA until now. It is interesting. I am curious how
you would approach this from the REST client perspective.
It seems to me that the client perspective would actually move to Stargate in
this case.
I think that that will introduce some additional nuances such as:
* how does stargate know what to encrypt and how
* obviously the keying material acquisition as you already note is an issue but
is also inline with what needs to be done for Hive table and col level
encryption
- we could provide an alias based scheme that gets resolved by some
library (and optionally key mgt server).
* this won't protect it over the wire as the CLI usecase would as a side effect
but that's what SSL is for in REST
> Client side cell encryption
> ---------------------------
>
> Key: HBASE-9578
> URL: https://issues.apache.org/jira/browse/HBASE-9578
> Project: HBase
> Issue Type: New Feature
> Reporter: Andrew Purtell
>
> HBASE-7544 will protect key and value data on the server from accidental
> leakage by way of improperly disposed disks, improper direct filesystem
> access, or incorrect HDFS permissions. There are also use cases where
> sensitive data stored in a table or column family by a given user or
> application should be protected from all others, and the combination of
> transparent server-side storage encryption and transport security (SASL
> auth-conf) is still not sufficient. These instances call for a client side
> per-cell encryption feature, given the following additional observations:
> - The scope of transmission, distribution, and storage of private key
> material should be as limited as possible. The server is a centralized target
> (even in the case of an HBase cluster) where the scope of damage from a
> compromise is magnified if user key material also resides there or can be
> intercepted after compromise. Where keys are stored in hardware devices, e.g.
> smartcards, getting the keys to the server may be not possible anyway.
> - A client system is far more likely than a contended shared server resource
> to have necessary available CPU cycles for per-operation cryptographic
> overheads.
> For some cases we might not care so much about the second item, but the first
> is very important.
> I have an implementation of per cell client side encryption as an encrypting
> HTable wrapper which I could contribute if there is interest.
> This JIRA is also about brainstorming how to do better than that.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
