Rules

A rule determines which path (file or directory) of a client will be protected. Each rule can be linked to multiple clients using the rule identifier. An encryption key and an access policy group are needed during a client-rule association. The rule status and other parameters specific to a client-rule combination are present in the client-rule association.

Creating a Rule

The following table lists the parameters that are required when creating or managing a rule on the CipherTrust Manager:

After a rule is created, it can be applied (linked) to a single or multiple clients. This linking is referred to as client-rule-association.

ProtectFile provides options to view existing rules, view and modify their details, and delete them. However, only the rules that are not linked to any client can be modified or deleted.

ProtectFile shows the progress of cryptographic operations being performed on a path under a rule. If a rule is applied on a directory path, the progress is shown in percent of the number of files completed. For example, a rule is deployed on a directory that contains 100 files. If a cryptographic operation is complete on 50 files, the operation progress is reported as 50%.

The progress reporting is applicable to rules in the In Progress state. Reason of failed rules is also displayed.

Migration Process

Migration is the initial act of encrypting a file or directory. Once a file is migrated, it is encrypted and decrypted when accessed by authorized users. Use the ProtectFile GUI on the CipherTrust Manager to apply encryption policies to directories and files.

When applying encryption policies on local directories, ProtectFile performs move-based migration. ProtectFile supports migration of entire disks or specific directories.

Migrating Specific Directories

To migrate a specific directory on a mount, ProtectFile:

1. Creates a temporary directory (using unique rule GUID) in the directory to be migrated. For example, if /MigrateThisDir/ is to be migrated, a temporary directory /MigrateThisDir/{unique rule GUID} is created.

   Note

   When migrating a file, a temporary directory (using unique rule GUID) is created in the directory containing the file. For example, if a file, EncryptThisFile, is stored in the /UserData/ directory, then a temporary directory /UserData/{unique rule GUID} is created.

2. For every file in the directory to be migrated, ProtectFile checks for the required disk space to move the file to the temporary directory.

   • If move (rename) fails due to any reason, ProtectFile tries to copy the file into the temporary directory and then deletes it from the source path.

   • If the required disk space is unavailable, ProtectFile stops the migration process and logs warning in the log file, /var/log/safenet/PF/feadeflog.txt. The encryption status on the CipherTrust Manager becomes completed with errors. Create required space, and redeploy the policy.

3. If enough space is available, ProtectFile moves all files to the temporary directory.

4. Performs migration on the empty path.

5. Moves back the files, one by one, from the temporary directory to the protected directory.

The migration of the directory is completed and the encryption status on the CipherTrust Manager becomes Encrypted.

Migrating Entire Volumes

To migrate a full volume, ProtectFile:

1. Creates a temporary directory (using unique rule GUID) at /{unique rule GUID} on the same volume.

2. For every file in the volume to be migrated, ProtectFile checks for the required disk space on the volume to move the file to the temporary directory.

   • If move (rename) fails due to any reason (generally, Invalid cross-device link), ProtectFile tries to copy the file into the temporary directory and then deletes it from the source path.

   • If the required disk space is unavailable, ProtectFile stops the migration process and logs warning in the log file, /var/log/safenet/PF/feadeflog.txt. The encryption status on the CipherTrust Manager becomes completed with errors. Create required space, and redeploy the policy.

3. If enough space is available, ProtectFile moves all files to the temporary directory.

4. Performs migration on the empty path.

5. Moves back the files, one by one, from the temporary directory to the protected directory.

The migration of the volume is completed and the encryption status on the CipherTrust Manager becomes Encrypted.

Rule Operations

This section provides an overview of:

• Cryptographic Operations supported by ProtectFile: encryption, key rotation, and decryption.

• Non-cryptographic (no encryption) operations supported by ProtectFile.

Only one operation can be initiated on a given path at a time. While that operation is in progress, no other operations can be started on that path. Another operation can be performed only after the completion of the previous operation.

Cryptographic Operations

Cryptographic operations involve encryption keys. These operations are encryption, key rotation, and decryption.

Encryption

Encryption is the process of encrypting data using an encryption key stored on the CipherTrust Manager. The encrypted data is decrypted when an authorized entity having appropriate access permission accesses the encrypted path.

Before Proceeding with Encryption

Coordinate with the ProtectFile client administrator to ensure the following before performing migration:

• Data to be encrypted is backed up.

• All database services are stopped before deploying an encryption rule on databases.

• All open instances of a file are closed before file-level migration.

• On Windows clients:

  • No files, folders, or volumes in the targeted path are compressed or in use.

  • Disk space equal to the largest file in the path to be encrypted is free on the same drive. For example, to encrypt a 1.5 GB file on C:, 1.5 GB of disk space must be free on C:. Refer to for details on disk size requirements.

• On Linux clients:

  • SELinux policies are applied before deploying encryption rules.

  • No files, folders, or volumes in the targeted path are in use. To verify, check the output of the lsof or fuser command.

Encryption Rules

• Files in use are skipped by the migration process. ProtectFile attempts to access a file three times during the process. If the file is in use each time, the migration fails for that file. Migration of such files can be retried later when they are not in use.

• While encrypting a path containing multiple files, migration can fail. After failure in the first attempt, ProtectFile retries to deploy the rule two more times (four more times for Windows clients). If the issues are resolved before the third attempt (fifth attempt for Windows clients), the rule is deployed successfully. As there is no rollback functionality, if the rule could not be deployed in maximum attempts, it is recommended to resolve the issues, and redeploy the rule.

• Open instances of the folder to be migrated must be refreshed after migration. Refreshing the instance is as simple as changing the folder.

• Protected files and folders must not be renamed or deleted.

  Note

  It is strongly recommended to not rename an encrypted path (including higher level folders). As the renamed path will be different from the path where the rule is applied on the CipherTrust Manager, all files in the renamed path will remain encrypted and cannot be decrypted.

• On Windows clients:

  • Do not deploy encryption rules on active boot volumes. Certain files on these volumes (for example, C:) are repeatedly in use by the system processes, so these volumes should not be encrypted. To encrypt any other volume, ensure that no files or folders on the volume are compressed or in use by the system processes.

  • Do not encrypt the System Reserved Partition as it can cause unexpected results.

  • A file being migrated cannot be accessed. It is recommended to not access files until their status becomes Encrypted on the CipherTrust Manager. Any attempt to access the file being migrated results in a permission denied error.

  • When a folder level encryption rule is in progress, do not perform the create file and copy file operations on this directory. New files can be created after the migration is complete. The directory's encryption rule applies to the new file.

• On Linux clients:

  • ProtectFile scans each file and determines whether it is already encrypted or not. If a file is already encrypted by ProtectFile, then ProtectFile skips the file to avoid double encryption.

  • Individual files are migrated by moving them to a temporary directory and then copying them back to the encrypted directory (Refer to Migration Process for details.) Do not make any changes inside the temporary directory.

  • Creating new files in a directory undergoing migration fails. New files can be created after the migration is complete. The directory's encryption rule applies to the new file.

Lazy Migration (Linux Clients)

ProtectFile Linux prevents reencryption (double encryption) of encrypted files in a directory. Depending on the key used for encryption of files, the cases could be:

• The directory contains files encrypted with a key and plaintext files. If you encrypt the directory using the same key, SafeNet ProtectFile ignores the encrypted files and encrypts the remaining files. The status becomes Encrypted on the CipherTrust Manager GUI.

• The directory contains files encrypted with some keys and plaintext files. If you encrypt the directory using a different key, SafeNet ProtectFile ignores the encrypted files and encrypts the plaintext files. However, the status becomes Completed with Errors on the CipherTrust Manager GUI.

Directories Ignored by ProtectFile (Windows Clients)

Certain applications create temporary files, or rely on supplemental files when a file is accessed. In these scenarios, ensure that either all files in target file’s directory are encrypted, or the specific temporary file extension is automatically encrypted. The table below lists the applications, target file extensions, and temporary or supplemental file extensions.

Directories Ignored by ProtectFile (Linux Clients)

ProtectFile does not encrypt the following directories:

This is because these directories contain files needed to start Linux OS and ProtectFile.

These directories (and their subdirectories) will not be encrypted, even if they are included in an encryption policy. The only exception is that subdirectories under the / path can be encrypted (but the actual / path cannot be encrypted).

Likewise, files in these directories will not be encrypted, even when specifically listed in an encryption policy. (For example, the kernel and boot loader files in /boot cannot be encrypted. Files in / cannot be encrypted.)

Key Rotation

Key rotation is the act of decrypting a file using the encryption key and then re-encrypting the file with a new encryption key. ProtectFile supports the following types of key rotation:

• Deep Key Rotation: The entire file (with content and header) is first decrypted with the old key and then re-encrypted with a new key. As a result, deep key rotation consumes time that is directly proportional to the file size.

• Shallow Key Rotation: Only the file header is first decrypted with the old key and then re-encrypted with a different key created on the CipherTrust Manager. As only the file header is re-encrypted, shallow key rotation is extremely fast and independent of the file size.

An encrypted file that is restored from an archive cannot be decrypted in its original directory if the keys for that directory were rotated after the file was archived. The file must be moved into a directory with an encryption rule that uses the same key that was originally used to encrypt the file.

Before Proceeding with Key Rotation

Coordinate with the ProtectFile client administrator to ensure the following before performing key rotation:

• All database services are stopped before performing key rotation on databases.

• All open instances of a file are closed before file-level key rotation.

• On Windows clients, no files, folders, or volumes in the targeted path are compressed or in use.

• On Linux clients, no files, folders, or volumes in the targeted path are in use. To verify, check the output of the lsof or fuser command.

Encryption Rules

• A file undergoing key rotation cannot be accessed. It is recommended to not access files until their status becomes Encrypted on the CipherTrust Manager. Any attempt to access the file undergoing key rotation results in a permission denied error.

• Files in use are skipped by the key rotation process. ProtectFile attempts to access a file three times during the process. If the file is in use each time, the key rotation fails for that file. Retry the key rotation when the files are not in use.

• On Windows clients, when a folder level rule is in progress, do not perform the create file and copy file operations on this directory. New files can be created after the key rotation is complete.

• On Linux clients, creating new files in a directory undergoing key rotation fails. The newly added files are migrated with the key used for rotation. However, the file on which key rotation is in progress cannot be accessed.

Decryption

Decryption is the act of permanently removing a rule from an encrypted path. After the rule is removed, the file returns to plaintext and is no longer encrypted or decrypted by ProtectFile.

Before Proceeding with Decryption

Coordinate with the ProtectFile client administrator to ensure the following before decrypting a path:

• All database services are stopped before deploying an encryption rule on databases.

• All open instances of a file are closed before file-level migration.

• On Windows clients, no files, folders, or volumes in the targeted path are compressed or in use.

• On Linux clients, no files, folders, or volumes in the targeted path are in use. To verify, check the output of the lsof or fuser command.

• Enough disk space is available on the client.

  • For Linux clients, refer to the "Space Requirements" section in the ProtectFile Clients Administrator Guide.

  • For Windows clients, disk space equal to the largest file in the path to be decrypted must be free on the same drive. For example, to decrypt a 1.5 GB file on C:, 1.5 GB of disk space must be free on C:. Refer to the "Space Requirements" section in the ProtectFile Clients Administrator Guide for details.

Decryption Rules

• Files in use are skipped by the decryption process. SafeNet ProtectFile attempts to access a file three times during the process. If the file is in use each time, decryption fails for that file. Retry decryption of such files when they are not in use.

• While decrypting a path containing multiple files, decryption can fail. After failure in the first attempt, ProtectFile retries to deploy the encryption rule two more times. If the issues are resolved before the third attempt, the rule is deployed successfully. As there is no rollback functionality, if the rule could not be deployed in three attempts, it is recommended to resolve the issues, and redeploy the rule.

• On Linux clients:

  • Individual files are unencrypted by moving them to a temporary directory and then copying them back to the old directory, which is now plaintext. Do not make any changes inside the temporary directory or the old directory during unencryption.

  • Creating new files in a directory undergoing unencryption fails. New files can be created after the unencryption is complete.

  • If the target path is in use, ProtectFile leaves the path mounted as safenetfs and logs show an unmount failure. When the target path is no longer in use, the path must be unmounted. Refer to "Unmounting the safenetfs Mounts" in the ProtectFile Clients Administrator Guide for details.

• On Windows clients:

  • A file being decrypted cannot be accessed. It is recommended to not access files until they are removed from the CipherTrust Manager. Any attempt to access the file being decrypted results in a permission denied error.

  • When a folder level encryption rule is in progress, do not perform the create file and copy file operations on this directory. New files can be created after the decryption is complete.

Non-Cryptographic Operations

ProtectFile provides an option to enforce non-cryptographic (no encryption) policies on a path. This is referred to as applying "no encryption" policies. These policies can be removed any time from the protected path. This is referred to as removing "no encryption" policies.

Applying

This operation enforces "no encryption" access policies on the path defined in a rule.

Removing

This operation removes "no encryption" access policies from a protected path.

Ignoring Subdirectories

ProtectFile can skip cryptographic operations (encryption or decryption) recursively on specific subdirectories. This is applicable for encryption, key rotation, decryption, and file operations. When creating a rule for a path, use the Ignore Directory option to specify the subdirectory to skip. To skip multiple subdirectories, specify semicolon-separated directories (for example, skipFolder1;skipFolder2). ProtectFile skips all the files recursively inside the specified directory.

For example, ExcludeThisDir is specified in the "Ignore Directory" parameter, and rule is deployed on a path containing this directory. ProtectFile does not encrypt files recursively inside the ExcludeThisDir directory. However, ProtectFile encrypts all other directories on the encryption path.

Rules and Recommendations

• The Ignore Directory option is case-sensitive; for example, excludethisdir is different than ExcludeThisDir.

• Wildcard characters are not supported. ProtectFile only skips directories that exactly match the value specified for Ignore Directory. For example, if ExcludeThisDir is specified, then files under the directories such as ExcludeThis and ThisDir are not excluded. Only files under the ExcludeThisDir directory are excluded.

• Rename in the following scenarios is not permitted for directories under the protected paths:

  • From directory name matching the value of Ignore Directory to any other name.

  • From any other name to the value of Ignore Directory.

• Parent folder encryption is not supported.

• Directories on NFS mounts can be skipped. CIFS is not supported.