[jira] [Commented] (HBASE-9578) Client side cell encryption

["Larry McCay (JIRA)" <ji...@apache.org>]

    [ 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)