[
https://issues.apache.org/jira/browse/HBASE-9578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786256#comment-13786256
]
Andrew Purtell commented on HBASE-9578:
---------------------------------------
bq. I sort of feel like client machines are probably more easily compromised
than server - no?
The difference is as far as leaking secrets a client compromise affects one
user or application, while a server compromise can affect them all.
bq. So, you see REST clients as having to do the encryption however is
appropriate for each particular client.
Yes, but more like I see REST as really suitable for layering - do the basic
data access protocol in something like Stargate, and then do caching, access
control, and data security on top with specialist components. For a RESTful
stack that's the way to go.
Also, there is the OP on this JIRA and then that rather long winded follow up
comment. If pursuing the bulk of the latter, then there would be a fair amount
of tooling needed that could be used for doing something for REST and Thrift
clients as well as the Java API.
> 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)
