Encryption Key Hierarchy Overview
The following section provides an overview of the encryption key hierarchy used by MarkLogic Server encryption at rest to secure data. Keys in the encryption hierarchy wrap (or encrypt) those keys below them in the hierarchy. Three possible configurations of the encryption key hierarchy are described. The first is an idealized key hierarchy that provides a generic example. The second is an embedded KMS (the PKCS #11 secured wallet) configuration, and the third shows an external keystore management system (KMS) configuration.
You do not need to completely understand the details of the key hierarchy to use the encryption feature, but this section explains the general concepts involved.
![Diagram of the security encryption key hierarchy](../image/16675c8cd3b3cb.png)
The keystore contains the Master Key Encryption Key (MKEK). The keystore generates the Cluster Key Encryption Key (CKEK), which is enveloped (encrypted) with or derived from the Master Key Encryption Key. Both the Master Key Encryption Key and the Cluster Key Encryption Key reside in the keystore (key management system or KMS). These keys never leave the keystore and MarkLogic Server has no knowledge or control over these keys. The keys are referenced from the keystore by their key IDs.
The KMS can be either the internal keystore provided by MarkLogic Server or an external KMIP-compliant KMS; the same mechanism is used by both types of keystores. The configuration happens at the cluster level because there is one keystore configuration per cluster. The encryption feature is fully compliant with the KMIP standard and the Amazon KMS.
The external KMS provides even higher security. The key IDs are provided by the KMS and returned through a TLS tunnel after the MarkLogic Server-generated keys have been sent to the KMS and wrapped (encrypted). The actual encryption keys never leave the KMS.
There are multiple levels to the key hierarchy, each level wrapping (encrypting) the level below it. The KMS generates the Cluster Level Data Encryption Keys for data (CDKEK), configuration files (CCKEK), and log files (CLKEK). The corresponding key (CDKEK, CCKEK, or CLKEY) is used to encrypt (wrap) all the Object Encryption Keys (OKEY) generated by MarkLogic Server for each file, so that an encryption key protects each file, no matter what category (data, configuration files, logs).
The Object Encryption Keys (OKEY) are randomly generated per file (for stands, journals, config files, log files, and so on.) wrapped (encrypted) with the corresponding keys (CDKEK, CCKEK, or CLKEK). So, an encryption key protects each file within a category (data, configuration files, logs).
For example, the Master Key Encryption Key (MKEK) wraps (encrypts) the Cluster Key Encryption Keys (CKEK), which in turn wraps (encrypts) the Data Key Encryption Key (CDKEK). The Data Key Encryption Key encrypts the Object Encryption Key (OKEY) for a file such as a stand. The keys at the bottom of the diagram are encrypted as headers in each file, wrapped (encrypted) with each of the keys above them in the hierarchy. Each of the three categories of objects (data, configuration files, and logs) has its own key encryption hierarchy.
Database backups are encrypted using a generated backup key (BKEK). This key is then encrypted with the cluster key (CDKEK). See Backup and Restore for more information about backups.