Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 664F0106D5 for ; Tue, 17 Sep 2013 21:14:37 +0000 (UTC) Received: (qmail 89513 invoked by uid 500); 17 Sep 2013 21:13:57 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 89482 invoked by uid 500); 17 Sep 2013 21:13:57 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 89440 invoked by uid 99); 17 Sep 2013 21:13:55 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Sep 2013 21:13:55 +0000 Date: Tue, 17 Sep 2013 21:13:55 +0000 (UTC) From: "Andrew Purtell (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (HBASE-7544) Transparent table/CF encryption MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-7544?page=3Dcom.atlassia= n.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-7544: ---------------------------------- Attachment: 7544p2.patch Patch '7544p2' introduces new protos for encryption and support in hbase-cl= ient (which hbase-server will also have available, pulled in as a dependenc= y) for protecting key material in an algorithm agnostic way. This is used f= or protecting CF keys in table schema and HFiles. =20 > Transparent table/CF encryption > ------------------------------- > > Key: HBASE-7544 > URL: https://issues.apache.org/jira/browse/HBASE-7544 > Project: HBase > Issue Type: New Feature > Components: HFile, io > Reporter: Andrew Purtell > Assignee: Andrew Purtell > Fix For: 0.98.0 > > Attachments: 7544p1.patch, 7544p2.patch, historical-7544.patch, h= istorical-7544.pdf, historical-shell.patch > > > Introduce transparent encryption of HBase on disk data. > Depends on a separate contribution of an encryption codec framework to Ha= doop core and an AES-NI (native code) codec. This is work done in the conte= xt of MAPREDUCE-4491 but I'd gather there will be additional JIRAs for comm= on and HDFS parts of it. > Requirements: > - Transparent encryption at the CF or table level > - Protect against all data leakage from files at rest > - Two-tier key architecture for consistency with best practices for this = feature in the RDBMS world > - Built-in key management > - Flexible and non-intrusive key rotation > - Mechanisms not exposed to or modifiable by users > - Hardware security module integration (via Java KeyStore) > - HBCK support for transparently encrypted files (+ plugin architecture f= or HBCK) > Additional goals: > - Shell support for administrative functions > - Avoid performance impact for the null crypto codec case > - Play nicely with other changes underway: in HFile, block coding, etc. > We're aiming for rough parity with Oracle's transparent tablespace encryp= tion feature, described in http://www.oracle.com/technetwork/database/owp-s= ecurity-advanced-security-11gr-133411.pdf as > {quote} > =E2=80=9CTransparent Data Encryption uses a 2-tier key architecture for f= lexible and non-intrusive key rotation and least operational and performanc= e 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. Eq= ually, each encrypted tablespace has its own tablespace key. Table keys are= stored in the data dictionary of the database, while tablespace keys are s= tored 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 enc= rypted with the TDE master encryption key, which is stored outside of the d= atabase 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 Sec= urity Module (HSM) device for higher assurance [=E2=80=A6]=E2=80=9D > {quote} > 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 administrato= rs For more information on JIRA, see: http://www.atlassian.com/software/jira