[
https://issues.apache.org/jira/browse/HBASE-9578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786168#comment-13786168
]
Larry McCay commented on HBASE-9578:
------------------------------------
I see. Well, I mostly wanted to see what your sense was for REST clients.
So, you see REST clients as having to do the encryption however is appropriate
for each particular client.
I assume that the HTable wrapper that you talk about is a client side thing
available to client application development - correct?
We could potentially build something into the Knox DSL for REST client access
to HBase - if this were to be a desirable feature for REST - but of course that
is but one potential REST client.
Just trying to make sure we have REST on par with CLI.
> 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)
