About the Exclusion Attribute for Files Matching an Exclusion Key Rule

Files matching an exclusion key rule have the status rekey_excluded in the CTE-LDT attribute. For more information about CTE-LDT attributes, see CTE-LDT Metadata in Extended Attributes. To check for the exclusion attribute on a file, see Determining if a File is Included in an Exclusion Key Rule.

The Exclusion Attribute is Persistent

Exclusion from rekey is a persistent property. A file excluded from rekey is not rekeyed regardless of changes that may seem to disassociate the file from the exclusion key rule. For example, if you rename a file to a new name within the same GuardPoint that no longer matches the exclusion key rule that the original name matched, the file with the new name retains the encryption type (non-versioned key or clear_key) of the exclusion key rule. To remove the exclusion attribute from a file you must copy the file rather than move or rename it (see Removing the Exclusion Attribute From a File).

Determining if a File is Included in an Exclusion Key Rule

Use the voradmin ldt attr get <path to file> command to check whether a file is associated with an exclusion key rule.

• On Linux, an excluded file will include the status rekey_excluded in the voradmin output. For example:

   voradmin ldt attr get /oxf-fs1/gp1/foo.txt
  CTE-LDT attributes: rekeyed_size=0, rekey_status=rekey_excluded
  

• On Windows, an excluded file will include the attribute Rekey Status Excluded in the voradmin output. For example:

  C:\> voradmin ldt attr get c:\gp1\foo.txt
  CTE-LDT attributes:
  Rekey Status Excluded
  Initial Rekeyed Size 9 Bytes
  Data Transformed 0 Bytes
  
  Key:
  Current Key Name/Version (Clear_Key)
  New Key Name/Version (Clear_Key)
  

Removing the Exclusion Attribute From a File

To disassociate a file from an exclusion key rule, you must copy the file to a new file not associated with the resource set of the same or another exclusion key rule as the source file. You can then remove the original file. The new file is created under the default key rule of whatever policy applies to the new file. Moving or renaming a file does not disassociate a file from an exclusion key rule (see The Exclusion Attribute is Persistent).

For example, assume the following exclusion key rule where Key_TextFiles is a non-versioned key:

Exclusion Key Rule: Resource set =*.txt, Key = Key_TextFiles

If you copy the file test1.txt to test1.foo, test1.foo is created with whatever key is specified in the policy that matches the new file. The key for the new file could be a non-versioned key, versioned key, clear_key, or, no key at all if the new file is outside of a GuardPoint. The original file test1.txt remains unchanged and encrypted with the Key_TextFiles non-versioned key because the file remains in the exclusion key rule.

Removing the Exclusion Attribute From a File in an NFS Share GuardPoint

For a CTE-LDT NFS share GuardPoint, in order to disassociate a file from an exclusion key rule you need to migrate from the existing LDT policy to a new LDT policy that does not contain the exclusion key rules and that encrypts the previously-excluded files using the same encryption key as the the rest of the files in the GuardPoint.

For example, if the existing LDT NFS GuardPoint /mnt/HR-Data/ has the following exclusion key rules:

• Resource set =*.log, Key = clear_key

• Resource set =*.txt, Key = Key_TextFiles

You would do the following to remove all exclusion key rules:

1. Stop all applications or clients from accessing the LDT NFS GuardPoint /mnt/HR-Data/.

2. In the CipherTrust Manager, unguard the LDT NFS GuardPoint /mnt/HR-Data/.

3. Create a new policy that defines the same encryption key for all files without any exclusions. In this example, you would specify:

   1. Key Rule 1: Resource set =*.log, Current Key = clear_key, Transform key= ldt_key2

   2. Key rule 2: Resource set =*.txt, Current Key = Key_TextFiles, Transform key=ldt_key2

   3. Key rule3: Current Key= clear_key, Transform key=ldt_key2

4. On the host, remove the embedded attributes on the existing files in the NFS directory.

   voradmin ldt attr delete /mnt/HR-Data/
   

   Make sure you verify that this command has completed successfully for all files in the GuardPoint before you continue with this procedure. You must remove the embedded attributes from the files before you remove the embedded attributes from the GuardPoint itself.

5. On the host, after voradmin ldt attr delete has completed, remove the embedded attributes on the existing NFS directory.

   voradmin ldt rmldt /mnt/HR-Data/
   

6. On the CipherTrust Manager, create a GuardPoint for /mnt/HR-Data/ using the newly created policy that has no exclusion key rules.

   • For an auto-guarded GuardPoint, the NFS guarded directory will automatically go through data transformation once the CTE Agent receives the policy push from the CipherTrust Manager.

   • For a manual GuardPoint, enable the GuardPoint using secfsd -guard <gp> to begin data transformation to convert all existing exclusion files to the new ldt_key2.

     secfsd -guard /mnt/HR-Data/
     

7. Verify that none of the files in the CTE-LDT NFS GuardPoint are being excluded using the voradmin ldt attr get command.

   For example, let's say there is an excluded file called example-file.txt in the NFS share /mnt/HR-Data/.

   Before the procedure, when the file is still excluded:

   voradmin ldt attr get /mnt/HR-Data/example-file.txt
   LDT attributes: rekeyed_size=100003840, rekey_status=rekey_excluded
           Key:    name=clear_key, version=none
   

   After the procedure, when the file is no longer excluded:

   voradmin ldt attr get /mnt/HR-Data/example-file.txt
   LDT attributes: rekeyed_size=100003840, rekey_status=none
           Key:    name=ldt-key2, version=5
   

Rename and Restore Operations (Linux)

The effect of rename or backup/restore operations involving files associated or not associated with exclusion key rules is mixed and somewhat confusing. In some cases, the operations to restore or rename cause conflicts between the key associated with the source file and the key associated with the target file. For example, the result of a rename operation involving a source file not associated with an exclusion key rule and target file name associated with a resource set of an exclusion key rule is different from the result of the same operation when target file name is associated with the resource set of an exclusion key rule with clear_key.

Be sure to review the effect of the operations below and avoid administrative operations that cross associations of files across multiple resource sets with conflicting key rules.

Backup/Restore

The table below illustrates the status and the key effect of restore operations involving mixed keys associated with source files from backup image and existing target files inside GuardPoint.

The table below illustrates the status and the key effect of restore operations involving mixed keys associated with source files from backup image and new target files not present inside GuardPoint.

Rename Operation

The table below illustrates the status and the key effect of rename operations for different combinations of versioned, exclusion key, and exclusion clear key.