Creating LDT Policies

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. If the data has not yet been encrypted, select clear_key. Otherwise select the name of the non-versioned key that is currently being used to encrypt the data.
   Transformation Key Name	Click Select to choose an existing versioned key or to create a new one. CTE uses the versioned key specified in this field to encrypt the data in the GuardPoint. 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.

   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 shares using an LDT or standard policy with a CBC-CS1 key, note the following:

CipherTrust Transparent Encryption embeds and hides LDT and/or IV (initialization vector) attributes in the first 4K of files for NFS 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, and CTE hides that extra 4K when reporting the file size. The exception to this is when a backup/restore process reads/writes such files. This requires embedded attributes to be read/restored by the backup/restore process. In such cases, CipherTrust Transparent Encryption does not hide the 4K attribute space in the file. The backup user/process views the actual file size. Non-backup users/applications view the file size as less than 4K.

If you want a security rule to enforce restricted access for reading file level attributes on such GuardPoints, you must specify the Apply Key effect. Alternatively, you can place the security rule that is enforcing the restricted access after the rule granting read/write access. This avoids application failure if the Apply key effect is not desired. For example, the order of the two rules in a policy that does not hide the user user-name would be:

• Security Rule n

  Rule	Value
  User	<user-name>
  Action	Read-file-attribute and/or Read directory
  Effect	permit

• Security Rule n + 1

  Rule	Value
  User	<user-name>
  Action	all_ops
  Effect	permit, apply-key

Assuming <user-name> is not affiliated with backup/restore operations, <user-name> would view the actual file size which is 4K larger than the size of the user data in the file. The returned file size can result in failure when user-name attempts to read/write files. By reordering rules n and n + 1, <user-name> will view the correct size hiding the 4K attribute space in the target file.

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