Cloudera Enterprise 6.3.x | Other versions

Cloudera Navigator Encrypt Overview

Cloudera Navigator Encrypt transparently encrypts and secures data at rest without requiring changes to your applications and ensures minimal performance lag in the encryption or decryption process. Advanced key management with Cloudera Navigator Key Trustee Server and process-based access controls in Navigator Encrypt enable organizations to meet compliance regulations and prevent unauthorized parties or malicious actors from gaining access to encrypted data.

For instructions on installing Navigator Encrypt, see Installing Cloudera Navigator Encrypt. For instructions on configuring Navigator Encrypt, see Registering Cloudera Navigator Encrypt with Key Trustee Server.

Navigator Encrypt features include:
  • Automatic key management: Encryption keys are stored in Key Trustee Server to separate the keys from the encrypted data. If the encrypted data is compromised, it is useless without the encryption key.
  • Transparent encryption and decryption: Protected data is encrypted and decrypted seamlessly, with minimal performance impact and no modification to the software accessing the data.
  • Process-based access controls: Processes are authorized individually to access encrypted data. If the process is modified in any way, access is denied, preventing malicious users from using customized application binaries to bypass the access control.
  • Performance: Navigator Encrypt supports the Intel AES-NI cryptographic accelerator for enhanced performance in the encryption and decryption process.
  • Compliance: Navigator Encrypt enables you to comply with requirements for HIPAA-HITECH, PCI-DSS, FISMA, EU Data Protection Directive, and other data security regulations.
  • Multi-distribution support: Navigator Encrypt supports Debian, Ubuntu, RHEL, CentOS, and SLES.
  • Simple installation: Navigator Encrypt is distributed as RPM and DEB packages, as well as SLES KMPs.
  • Multiple mountpoints: You can separate data into different mountpoints, each with its own encryption key.
Navigator Encrypt can be used with many kinds of data, including (but not limited to):
  • Databases
  • Temporary files (YARN containers, spill files, and so on)
  • Log files
  • Data directories
  • Configuration files
Navigator Encrypt uses dmcrypt for its underlying cryptographic operations. Navigator Encrypt uses several different encryption keys:
  • Master Key: The master key can be a single passphrase, dual passphrase, or RSA key file. The master key is stored in Key Trustee Server and cached locally. This key is used when registering with a Key Trustee Server and when performing administrative functions on Navigator Encrypt clients.
  • Mount Encryption Key (MEK): This key is generated by Navigator Encrypt using openssl rand by default, but it can alternatively use /dev/urandom. This key is generated when preparing a new mount point. Each mount point has its own MEK. This key is uploaded to Key Trustee Server.
  • dmcrypt Device Encryption Key (DEK): This key is not managed by Navigator Encrypt or Key Trustee Server. It is managed locally by dmcrypt and stored in the header of the device.

Process-Based Access Control List

The access control list (ACL) controls access to specified data. The ACL uses a process fingerprint, which is the SHA256 hash of the process binary, for authentication. You can create rules to allow a process to access specific files or directories. The ACL file is encrypted with the client master key and stored locally for quick access and updates.

Here is an example rule: 
"ALLOW @mydata * /usr/bin/myapp"
This rule allows the /usr/bin/myapp process to access any encrypted path (*) that was encrypted under the category @mydata.
  Note: You have the option of using wildcard characters when defining process-based ACLs. The following example shows valid wildcard definitions: 
"ALLOW @* * *"
"ALLOW @* path/* /path/to/process"

Navigator Encrypt uses a kernel module that intercepts any input/output (I/O) sent to an encrypted and managed path. The Linux module filename is navencryptfs.ko and it resides in the kernel stack, injecting filesystem hooks. It also authenticates and authorizes processes and caches authentication results for increased performance.

Because the kernel module intercepts and does not modify I/O, it supports any filesystem (ext3, ext4, xfs, and so on).

The following diagram shows /usr/bin/myapp sending an open() call that is intercepted by navencrypt-kernel-module as an open hook:



The kernel module calculates the process fingerprint. If the authentication cache already has the fingerprint, the process is allowed to access the data. If the fingerprint is not in the cache, the fingerprint is checked against the ACL. If the ACL grants access, the fingerprint is added to the authentication cache, and the process is permitted to access the data.

When you add an ACL rule, you are prompted for the master key. If the rule is accepted, the ACL rules file is updated as well as the navencrypt-kernel-module ACL cache.

The next diagram illustrates different aspects of Navigator Encrypt:



The user adds a rule to allow /usr/bin/myapp to access the encrypted data in the category @mylogs, and adds another rule to allow /usr/bin/myapp to access encrypted data in the category @mydata. These two rules are loaded into the navencrypt-kernel-module cache after restarting the kernel module.

The /mydata directory is encrypted under the @mydata category and /mylogs is encrypted under the @mylogs category using dmcrypt (block device encryption).

When myapp tries to issue I/O to an encrypted directory, the kernel module calculates the fingerprint of the process (/usr/bin/myapp) and compares it with the list of authorized fingerprints in the cache.

Encryption Key Storage and Management

The master key and mount encryption keys are securely deposited in Key Trustee Server. One MEK per mount point is stored locally for offline recovery and rapid access. The locally-stored MEKs are encrypted with the master key.

The connection between Navigator Encrypt and Key Trustee Server is secured with TLS/SSL certificates.

The following diagram demonstrates the communication process between Navigator Encrypt and Key Trustee Server:



The master key is encrypted with a local GPG key. Before being stored in the Key Trustee Server database, it is encrypted again with the Key Trustee Server GPG key. When the master key is needed to perform a Navigator Encrypt operation, Key Trustee Server decrypts the stored key with its server GPG key and sends it back to the client (in this case, Navigator Encrypt), which decrypts the deposit with the local GPG key.

All communication occurs over TLS-encrypted connections.

Page generated August 29, 2019.