CTE-LDT Runtime Flow

This section presents an overview of how CTE-LDT works and what to expect when CTE-LDT is enabled and running in your environment. All of the tasks mentioned here are described in more detail later in this chapter.

First, the administrator completes CTE-LDT setup:

1. Upload the CTE-LDT license on the CipherTrust Manager.

2. Register CTE-LDT hosts with the CipherTrust Manager and be sure that the hosts are licensed for CTE-LDT.

3. Create one or more versioned keys.

4. Optionally create a Key Rotation Schedule or add your new keys to an existing schedule.

5. Define Live Data Transformation policies which use the versioned key(s) and contain rules governing CTELDT operations.

6. Optionally provide Quality of Service (QoS) settings for the CTE-LDT hosts. The QoS settings control the:

   • Window of time in which CTE-LDT operations are allowed to run.

   • Percentage of CPU resources that CTE-LDT can use, or the amount of data to transform according to the QoS setting per the Administrator.

   Configuring the QoS settings is highly recommended as a best practice.

When these items are set up, CTE-LDT is ready to transform and encrypt data by applying policies to GuardPoints for live initial transformation and subsequent rekeys, as well as enforcement of security rules.

CTE-LDT goes through the following phases after the keys and Live Data Transformation policies are defined:

1. Initial data transformation starts

   CTE-LDT begins when an Live Data Transformation policy is first applied to a GuardPoint or an LDT key is automatically rotated through a key rotation schedule in CipherTrust Manager. When a client that uses the associated policy contacts CipherTrust Manager, CipherTrust Manager sends the new policy, or the the key rotation notification, to the client. (If the same versioned key is used in multiple policies, all of the clients associated with the policies that contain the key are notified when the key changes.)

2. New key version triggers a rekey on the affected GuardPoints

   On each host/client , CTE determines which GuardPoints are using the key that has just rotated to a new version. CTE starts an CTE-LDT rekey on each of those GuardPoints.

   On Windows, you must wait for the current key rotation process to finish before you can launch another rekey request. On Linux, if another rekey is already underway on that GuardPoint, the new rekey is queued for later execution. For details, see Rotating Encryption Keys While a Rekey is in Progress (Relaunch).

3. Scan for files

   On each GuardPoint where CTE has started a rekey, CTE-LDT determines which files to transform. CTE-LDT takes inventory of files encrypted with earlier versions of the rotated key and makes a persistent list of the files for transformation.

   The scan phase might be interrupted, such as by a host reboot. In this case, when the host reboots and the GuardPoint is enabled again, the scan operation starts over from the beginning.

4. Rekey/Key Rotation

   1. Each file, from the persistent list of files, is decrypted using the old version of the key. The old key is applied to each file and then re-encrypted using the new version of the key. Note that new files created during the CTE-LDT process do not need to be rekeyed, as they inherit the new version of the key. Multiple files and multiple regions of files are rekeyed simultaneously.

   2. The CTE-LDT extended attribute of each file is updated. (For more about extended attributes, see CTE-LDT Metadata in Extended Attributes.)

   3. You can suspend and resume the CTE-LDT rekey operation manually, or through the QoS schedule. This manages the impact CTE-LDT has on other applications and processes.

   If system errors occur during rekeying, such as IO errors or crashes, CTE-LDT can manage and recover from them after the system error is fixed.

5. Finish

   When all of the required files in the GuardPoint have been rekeyed, the system and storage resources used by CTE-LDT are released, except for the storage required for the extended attributes.

   CTE-LDT creates a rekey report, listing all of the files that were rekeyed. For more information, see Obtaining a Rekey Report.

   Upon completion of rekey, the Rekey Status in the GuardPoint Status window of the CipherTrust Manager Console shows Rekeyed.