hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-7544) Transparent HFile encryption
Date Fri, 11 Jan 2013 20:34:12 GMT
Andrew Purtell created HBASE-7544:

             Summary: Transparent HFile encryption
                 Key: HBASE-7544
                 URL: https://issues.apache.org/jira/browse/HBASE-7544
             Project: HBase
          Issue Type: New Feature
          Components: HFile, io
    Affects Versions: 0.96.0
            Reporter: Andrew Purtell
            Assignee: Andrew Purtell

Introduce transparent encryption of HBase on disk data.

Depends on a separate contribution of an encryption codec framework to Hadoop core and an
AES-NI (native code) codec.

I have an experimental patch that introduces encryption at the HFile level, with all necessary
changes propagated up to the HStore level. For the most part, the changes are straightforward
and mechanical. After HBASE-7414, we can introduce specification of an optional encryption
codec in the file trailer. The work is not ready to go yet because key management and the
HBCK pieces are TBD.

- Mechanisms not exposed to or modifiable by users
- Transparent encryption at the CF or table level
- Built-in key management
- Flexible and non-intrusive key rotation
- Two-tier key architecture for consistency with best practices for this feature in the RDBMS
- Transparent encryption of sensitive application columns
- Protect against all data leakage from files at rest
- Hardware security module integration (via Java KeyStore)
- HBCK support for transparently encrypted files (+ plugin architecture for HBCK)

We're aiming for rough parity with Oracle's transparent tablespace encryption feature, described
in http://www.oracle.com/technetwork/database/owp-security-advanced-security-11gr-133411.pdf
“Transparent Data Encryption uses a 2-tier key architecture for flexible and non-intrusive
key rotation and least operational and performance impact: Each application table with at
least one encrypted column has its own table key, which is applied to all encrypted columns
in that table. Equally, each encrypted tablespace has its own tablespace key. Table keys are
stored in the data dictionary of the database, while tablespace keys are stored in the header
of the tablespace and additionally, the header of each underlying OS file that makes up the
tablespace.  Each of these keys is encrypted with the TDE master encryption key, which is
stored outside of the database in an external security module: either the Oracle Wallet (a
PKCS#12 formatted file that is encrypted using a passphrase supplied either by the designated
security administrator or DBA during setup),  or a Hardware Security Module (HSM) device for
higher assurance […]”

Further design details forthcoming in a design document and patch as soon as we have all of
the clearances in place.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message