Creating LDT Policies or converting a Standard Policy to an LDT Policy

LDT uses a single Live Data Transformation encryption policy to address both data transformation and ongoing protection. In contrast, if you do not use LDT, you need a separate policy for initial data transformation, or rekey, and another policy to protect the data while it is in production use. For more information about LDT policies, see LDT Policies.

To create an Live Data Transformation encryption policy:

1. In a web browser, navigate to the URL of the CipherTrust Manager you want to use and log in with CipherTrust Manager Administrator credentials.

2. If the client you want to protect is registered to the default domain (root), proceed to the next step. If you need to change to a different domain, do the following:

   1. In the top menu bar, click the domain/user name (default: root/admin) on the right-hand side.

   2. Select Switch Domains, then select the domain in which the client is registered.

   3. The logged in user now shows the new domain name/user name.

      

3. In the CipherTrust Manager Applications Page, open the CTE application.

4. In the left-hand menu bar on the Clients page, click Policies.

5. Click Create Policy. CipherTrust Manager displays the Create Policy Wizard.

6. On the General Info page, set the following options:

   Field	Description
   Name	A unique name for the policy. Make sure you use a name that is descriptive and easy to remember so that you can find it quickly when you want to associate it with a GuardPoint. For example: LDT-Policy-West
   Policy Type	Select Live Data Transformation.
   Description	A user-defined description to help you identify the policy later. For example: LDT policy for the West Coast Datacenter.
   Learn Mode	Learn Mode provides a temporary method for disabling the blocking behavior of CTE/LDT policies. While useful for quality assurance, troubleshooting, and mitigating deployment risk, Learn Mode is not intended to be enabled permanently for a policy in production. This prevents the policy Deny rules from functioning as designed in the policy rule set. Ensure that the policy is properly configured for use in Learn Mode. Any Security Rule that contains a Deny effect must have Apply Key applied as well. This is to prevent data from being written in mixed states, resulting in the loss of access or data corruption. Apply Key will have no effect when combined with a Deny rule unless the policy is in Learn Mode.

7. Click Next.

8. On the Security Rules page, define the security rules you want to use.

   CipherTrust Manager automatically adds a default security access rule with an action of key_op and the effects Permit and Apply Key. This rule permits key operations on all resources, without denying user or application access to resources. This allows it to perform a rekey operation whenever the encryption key rotates to a new version. This rule is required by LDT, so you cannot edit it, move it, or delete it.

   To add additional security rules, click Create Security Rule and enter the requested information. If you want to grant user and application access to files at all times, including during initial LDT and subsequent key rotations, add a security rule with the action all_ops and the effects Permit and Audit.

9. On the Create Key Rule page, click Create Key Rule and enter the following information:

   Field	Description
   Resource Set	If you want to select a resource set for this key rule, click Select and either choose an existing resource set or create a new one. Resource sets let you specify which directories or files will either be encrypted with the key or will be excluded from encryption with this key.
   Current Key Name	Click Select to choose an existing key or create a new one. Current key is the key applied to data that you want to protect using LDT. This is either a non-versioned key from a standard policy or a clear_key. You must use clear_key when data is not currently encrypted. When migrating a standard policy to LDT, you must enter the encryption key from the key rule of the standard policy, as the current key of LDT policy.
   Transformation Key Name	Click Select to choose an existing versioned key or to create a new one. Transformation key is the versioned key that LDT applies to transform the data. For the initial transformation, the data is transformed from the Current key, to the Transformation key. If the data is currently encrypted, CTE decrypts it using the key specified in the Current Key Name field and re-encrypts it using the key specified in this field. When rotating the Transformation key, LDT transforms the data from a previous version of the transformation key to a new version.

   Note

   LDT now supports dynamic resource sets. This means that you can alter the resource set, and the policy will pick up the changed resource set and apply it. However, make sure that you do not mix encryption keys in your edited resource set. This will cause corruption.

   When you are done specifying key rules, click Next.

10. On the Confirmation page, review the information you entered and click Save when you are ready to save the policy.

The following example shows a simple LDT policy that encrypts clear-text files using a versioned key named LDT-Key-1. The key_op and all_ops actions in the Security Rules panel grant user and application access to files at all times, including during initial LDT and subsequent key rotations.

Security Rule Ordering for Polices

If you want to enforce restrictions when guarding NFS/CIFS shares using an LDT or standard policy with a CBC-CS1 key, note the following:

CipherTrust Transparent Encryption embeds the LDT and/or IV (initialization vector) attributes in the first 4K of files for NFS/CIFS shares guarded with an LDT or standard policy with a CBC-CS1 key. Embedding CipherTrust Transparent Encryption attributes increases the actual file size by 4K. CTE hides that extra 4K when reporting the file size to users, or processes, that access the file with the Apply Key effect.

If you need the actual file size, or read/write access on the embedded header, for backup/restore processes for example, then you need a rule that permits access without Apply Key.

LDT Policies

Example 1: Permits Backup and Restore

A policy that allows backup and restore of encrypted data, clear-text access to certain processes, and denies access to all others:

Example 2: Permits access to certain Processes

A policy that only allows certain processes clear-text access but allows all others to see the OS file attributes.

Standard Policies

Example 1: Permits access to certain Processes

A policy that allows backup and restore of encrypted data, clear-text access to certain processes, and denies access to all others:

Example 2: Permits access to certain Processes

A policy that only allows certain processes clear-text access but allows all others to see the OS file attributes.

For more information, see Adding Security Rules in the CipherTrust Manager documentation.

Using Auto Mount with LDT Policies

Auto Mount is supported with LDT policies, with CBC/CBS-CS1 keys, on both NFS and local file systems. It is an option provided for guarding a GuardPoint. When selected, it enables automatic guarding of the GuardPoint when accessed, rather than immediately after policy deployment.

Configuring and Guarding an Automount GuardPoint

1. Add this newly created directory as a GuardPoint on CipherTrust Manager using an LDT policy. A GuardPoint configured with a LDT policy using auto mount must use GuardPoint type: Auto Directory. The Auto Mount option is not supported with GuardPoint type: manual. When you select GuardPoint type: Auto Directory in a LDT policy, the Auto Mount option displays.

   

   Note

   For GuardPoint type: Auto raw, see File System Mount Points on Linux.

2. Once the GuardPoint displays on the agent, mount the device on the GuardPoint. This should trigger guarding.

3. Verify that the GuardPoint has been enabled, that the policy is in effect, and rekey is in progress.

   voradmin ldt attr get /nfs-oxf-fs1/gp
   

   Example

   LDT stats: version=7, rekey_status=rekeyed
   Number of times rekeyed:                1 time
   Rekey start time:                       2025/03/27 07:05:19
   Last rekey completion time:             2025/03/27 07:05:19
   Estimated rekey completion time:        N/A
   Policy key version:                     21
   Pushed Policy key version:              21
   Policy ID:
           6a4b49bd-6f34-4646-ae95-8e60e2824ff6
   Data stats:
           total=0.0MB, rekeyed=0.0MB
           truncated=0.0MB, sparse=0.0MB
   File stats:
           total=0, rekeyed=0, failed=0
           passed=0, skipped=0, created=0, removed=0, excluded=0
   

4. Verify that all files are rekeyed to completion as per policy key rules.

    voradmin ldt attr get /nfs-oxf-fs1/gp
   

   Example

   LDT stats: version=7, rekey_status=rekeyed
   Number of times rekeyed:                2 times
   Rekey start time:                       2025/03/27 07:21:52
   Last rekey completion time:             2025/03/27 07:22:14
   Estimated rekey completion time:        N/A
   Policy key version:                     22
   Pushed Policy key version:              22
   Policy ID:
           6a4b49bd-6f34-4646-ae95-8e60e2824ff6
   Data stats:
           total=1.0GB, rekeyed=1024.0MB
           truncated=0.0MB, sparse=0.0MB
   File stats:
           total=1, rekeyed=1, failed=0
           passed=0, skipped=0, created=0, removed=0, excluded=0
   

5. Unmount. The unmount should trigger an unguard of the GuardPoint, the way it does for regular auto mount GuardPoints.

   Note

   Manually unmounting displays a busy error. This is the expected behavior, as the unguard operation is in progress. Once unguard completes, the mount point is unmounted automatically.

   Example

   umount /nfs-oxf-fs1/gp
   

   Response

   umount: /nfs-oxf-fs1/gp: target is busy.
   

Behavior of Auto Mount GuardPoints

After you push a policy on a CTE agent, if you check the status, you'll find that the auto mount GuardPoint is not yet guarded because the guard operation is not yet triggered:

secfsd -status guard

Response

GuardPoint      Policy                  Type        ConfigState Status Reason
------------------------------------------------------------------------------
/nfs-oxf-fs1/gp VMFSODT40-AUTOMOUNT-POL auto mount guarded not guarded Not auto-mounted

In the CTE CLI, Auto Mount is controlled by autofs. When autofs is enabled, accessing the GuardPoint triggers the guard operation.

Example

ls /nfs-oxf-fs1/test

secfsd -status guard

Response

${gp} Policy Type ConfigState Status Reason
------ ---- ----------- ------ ------
/nfs-oxf-fs1/gp VMFSODT40-AUTOMOUNT-POL auto mount guarded guarded N/A

Running Recovery on Automount GuardPoint with LDT policy

When a system crashes during an active rekey operation, the GuardPoint may enter a state that requires recovery.

secfsd -status guard

Response

GuardPoint       Policy                   Type       ConfigState  Status       Reason
----------       ------                   ----       -----------  ------       ------
/nfs-oxf-fs1/gp  VMFSODT40-AUTOMOUNT-POL  automount  unguarded    not guarded  GuardPoint needs LDT recovery

The GuardPoint is not guarded, displays the GuardPoint status, and aborts the guard operation, while leaving the mount point mounted. This enables the admin to manually run the voradmin ldt recover command.

voradmin ldt recover /nfs-oxf-fs1/gp

Response

Enter YES to disregard failures in LDT recovery as the result of inconsistencies in underlying file system -> YES
/nfs-oxf-fs1/gp - recovered without failure(s) - status 1
/nfs-oxf-fs1/gp - GuardPoint rkea flags 10032
Unmounted Automount GuardPoint /nfs-oxf-fs1/gp

After recovery, the auto mount mount point is unmounted, and the admin is prompted accordingly.

Collecting Agent Information

• Do not use voradmin ldt list all with the -force-mount option. This could create more issues.

• Change the GuardPoint type from automount to manual to enable the GuardPoint and collect the Agent information.

Limitations

• CTE does not support nested GuardPoints with auto mount enabled

• Auto mount with LDT policies only supports auto-fs mount points.

• The GuardPoint path must be at the same level as the mount point when enabling auto mount on an autofs mount point. This ensures that auto mount unguards when the autofs mount point times out. If the GuardPoint path is set at any level deeper than the configured autofs mount point, the autofs mount point will never timeout because the GuardPoint will continue to keep the mount point in a busy state.

• CTE does not remove the shadow directory created after unmount.

• CTE does not support auto-fs configured using direct mount with an LDT policy.

• CTE does not support systemd automount with an LDT policy.