Transparent data encryption¶

Requirements¶

TDE requires a secure local file system to be effective. The encryption certificates are stored locally; therefore, an invasion of the local file system invalidates encryption.

Options¶

To get the full capabilities of TDE, download and install the Java Cryptography Extension (JCE), unzip the jar files and place them under $JAVA_HOME/jre/lib/security. JCE-based products are restricted for export to certain countries by the U.S. Export Administration Regulations.

Limitations and recommendations¶

Data is not directly protected by TDE when accessed using the following utilities.

The local file system could be protected through a third party whole-disk encryption solution. You choose ssl, kerberos authentication, encrypted file system, or other ways to secure nodes.

DataStax recommends that you do not export local file systems if possible. If you must export a local file system, ensure that mounting the file system on the node is a server-side capability.

Compression and encryption introduce performance overhead.

Encrypting Data¶

You designate encryption on a per table (column family) basis. When using encryption, each node generates a separate key used for only that node’s sstables.

For example, log in as the default superuser:

./cqlsh -3 -u cassandra -p cassandra

The ALTER TABLE syntax for setting encryption options is the same as the syntax for setting data compression options.

For example, to set compression options in the chores table:

ALTER TABLE chores
  WITH compression_parameters:sstable_compression = 'DeflateCompressor'
  AND compression_parameters:chunk_length_kb = 64;

To set encryption options in the chores table using CQL 3, for example:

ALTER TABLE chores
  WITH compression_parameters:sstable_compression = 'Encryptor'
  AND compression_parameters:cipher_algorithm = 'AES/ECB/PKCS5Padding'
  AND compression_parameters:secret_key_strength = 128;
  AND compression_parameters:chunk_length_kb = 1;

Designating data for encryption using ALTER TABLE doesn't encrypt existing SSTables, just new SSTables that are generated. When setting up data to be encrypted, but not compressed, set the chunk_length_kb option to the lowest possible value, 1, as shown in the previous example. Setting this option to 1 improves read performance by limiting the data that needs to be decrypted for each read operation to 1 KB.

Setting encryption and compression together¶

Encryption and compression occur locally, which is more performant than trying to accomplish these tasks on the Cassandra-side. Encryption can be set together with compression using a single statement. The single statement in CQL 3 is:

ALTER TABLE chores
  WITH compression_parameters:sstable_compression = 'EncryptingSnappyCompressor'
  AND compression_parameters:cipher_algorithm = 'AES/ECB/PKCS5Padding'
  AND compression_parameters:secret_key_strength = 128
  AND compression_parameters:chunk_length_kb = 128;

Encryption/compression options and sub-options¶

Using encryption, your application can read and write to SSTables that use different encryption algorithms or no encryption at all. Using different encryption algorithms to encrypt SSTable data is similar to using different compression algorithms to compress data. This section lists the options and sub-options.

The high-level container option for encryption and/or compression used in the ALTER TABLE statement are:

• Encryptor
• EncryptingDeflateCompressor
• EncryptingSnappyCompressor
• DeflateCompressor
• SnappyCompressor (default)

ALTER TABLE chores
  WITH compression_parameters:sstable_compression = 'EncryptingSnappyCompressor'
  AND compression_parameters:cipher_algorithm = 'AES/ECB/PKCS5Padding'
  AND compression_parameters:secret_key_strength = 128
  AND compression_parameters:iv_length = 16;

Using nodetool to complete encryption operations¶

Use the nodetool upgradesstables utility to rewrite all the SSTables. Use nodetool flush to flush to disk all new data using the current settings for encryption.

About the keytab file¶

After designating the data to be encrypted, a keytab file is created in the directory set by the secret_key_file. If the directory doesn’t exist, it is created. A failure to create the directory probably indicates a permissions problem.

Example values in the keytab file are:

AES/ECB/PKCS5Padding:256:bxegm8vh4wE3S2hO9J36RL2gIdBLx0O46J/QmoC3W3U= AES/CBC/PKCS5Padding:256:FUhaiy7NGB8oeSfe7cOo3hhvojVl2ijI/wbBCFH6hsE= RC2/CBC/PKCS5Padding:128:5Iw8EW3GqE6y/6BgIc3tLw==

Deleting, moving, or changing the data in the keytab file causes errors when the node restarts and you lose all your data. Consider storing the file on a network server or encrypting the entire file system of the nodes using a third-party tool.

CassandraFS¶

The CassandraFS (Cassandra file system) is accessed as part of the Hadoop File System (HDFS) using the configured authentication. If you encrypt the CassandraFS keyspace's sblocks and inode tables, all CassandraFS data gets encrypted.

Using SolrJ-Auth¶

Follow instructions in the solrj-auth-README.md file to use the SolrJ-Auth libraries to implement encryption. The SolrJ-auth-README.md file is located in the following directory:

Debian installations: /usr/share/doc/dse-libsolr*

RHEL-based installations: /usr/share/doc/dse-libsolr

Binary installations: resources/solr

These SolrJ-Auth libraries are included in the DataStax Enterprise distribution:

Debian installations: /usr/share/dse/clients

Binary installations: <install_location>/clients