Migrating ProtectFile to CTE Agent

The migration process migrates only the CM configuration and encrypted data. The entire ProtectFile configuration consists of:

• Keys

• Encryption rules

• Access policies on KeySecure

• Offline policies on each file server

• Configuration files (Linux)

• Registry settings (Windows) on each file server

• Encrypted data on local disks, NAS or clusters

• Log files

Both ProtectFile and CTE provide transparent encryption, with additional access controls. However, there are several small but significant differences, in terms of deployment scenarios, policy management,encryption schemes, application access, and audit trails. This guide describes all such differences.

The Thales team has added support to ProtectFile, CTE and CM to allow migration of encrypted data in a smooth and secure manner. The migration is achieved through two main steps:

1. The CM configuration for ProtectFile is migrated to CTE through the pfmigrate utility provided for that purpose.

2. The data on the file servers is migrated. For the data migration, the CTE GuardPoints are stacked on top of ProtectFile encrypted paths and the CTE Dataxform tool is used to perform the data migration.

The following sections describe the process to follow for this approach. In a small number of cases, this approach may not be feasible and migration will require a manual approach. This is described in Manually Migrating to CTE.

Platforms Not Supported by CTE Linux

This is the list of platforms that ProtectFile Linux supports but CTE does not.

• Oracle Enterprise Linux - UEK kernels

• PowerPC 64 Little Endian (ppc64le)

File Systems Not Supported by CTE Linux

This is the list of file systems that CTE does not support.

• TRFS

• OCFS2

• GFS2

• VxFS

Expectations

Remember the following while performing the migration:

• Cipher-text backups taken with ProtectFile can no longer be restored after an encrypted path is migrated to CTE.

• Users with ReadPlain or ReadCipher access, under an extension-based rule, are not able to create encrypted files with the extension after migration to CTE.

• If you are planning to deploy any more encryption rules, deploy them as a CTE rule after the migration is completed. Do not create new ProtectFile encryption rules.

• ProtectFile and CTE can coexist on the same file server and is required to perform the migration securely. You will notice that during the migration of ProtectFile protected paths, the CTE GuardPoint are overlayed on the ProtectFile encrypted path.

• Once the path is migrated successfully and removed from the ProtectFile path, CTE ensures the protection of those paths.

• If the name of a User set, Resource set, Process set, groups, rules, or access polices in PF contains a space, those spaces are removed during migration.

  For example:

  • Before migration:

    username: pf user

  • After migration:

    username: pfuser

  Thales recommends using the underscore character in place of spaces in CTE.
  !!! note For example: pf_user.

Migration Paths

Customers with ProtectFile could be using KeySecure Classic, or have moved to CM previously. The CTE migration requires both ProtectFile and CTE to use CM.

Migration requires the following minimum versions for each product:

For installations using ProtectFile with KeySecure Classic, the migration consists of three stages:

1. Migrate the KeySecure Classic configuration to CM while still running ProtectFile on KeySecure.

2. Migrate the ProtectFile configuration elements on CM to their equivalent CTE configuration elements on CM.

3. Migrate the encrypted data for each ProtectFile encryption rule from ProtectFile format to CTE format.

The following diagram depicts the migration stages:

ProtectFile clients that have already migrated to CM do not require the first step, however they must follow the versions as mentioned above.

There is no direct migration path from KeySecure Classic to the CTE and CM platform.

Overview for Migration of ProtectFile Rules

The following list is a high-level summary overview of the steps required for migrating ProtectFile Rules on Windows or Linux file servers. The succeeding sections describe the details of the migration.

1. Run the pfmigrate utility with required parameters to migrate the CM configuration for ProtectFile.

   Note

   Thales recommends that you transform one encryption rule at a time.

2. Install CTE on the file servers and register with the CM.

3. On the CM ProtectFile encryption rule which is to be migrated, edit the access policy to give ReadWrite access to the dataxform process.

4. Check that all of the appropriate policies, rules and client/ client groups are created in CM.

5. Make sure that GuardPoints are applied properly on the Linux and Windows servers.

6. On the file server, run data transformation on each encryption rule/protected path.

7. Navigate to the ProtectFile encryption rule on the CM and disable it.

8. Disable the corresponding data transformation CTE GuardPoint on the CM.

9. Navigate to the corresponding production CTE GuardPoint on the CM and enable it.

10. After all the encryption rules are transformed then they must uninstall PF agent from the host.

Prerequisites for Migration

The following prerequisites must be performed before beginning the migration process. Refer to the CTE documentation for more information on installing and configuring CTE:

1. Ensure that the CTE release supports the OS version on which ProtectFile is installed. CTE Windows supports all of the platforms supported by ProtectFile Windows. CTE Linux supports almost all of the OS versions that ProtectFile supports. The exceptions are listed in Platforms Not Supported by CTE Linux. These ProtectFile instances cannot be migrated to CTE.

2. For Linux installations, ensure that CTE is certified for the kernel version on which ProtectFile is installed. In case the kernel version is not certified, do not proceed with the migration and contact Thales support.

3. User must have Read/Write access to DataXform.

4. For Linux installations, the default root access must be read/write. Otherwise, the system can crash.

5. For both ProtectFile Windows and Linux installations, ensure that the file system of the encrypted paths is supported by CTE. CTE Windows supports all of the file systems that are supported by ProtectFile Windows. For CTE Linux, there are some file systems which are not supported. File Systems Not Supported by CTE Linux contains the list of file systems that are not supported by CTE Linux. If the file system is not supported by CTE, the migration is not possible.

6. For ProtectFile Linux installations that protect data on NFS shares, examine the mount point of the NFS shares on each node. For ProtectFile, the NFS shares can be mounted on a different path on each node. However, in CTE, the NFS shares must be mounted on the same path on all of the nodes. Do not proceed with migration until the shares are mounted on the same path on all of the nodes.

   For example:

   Note

   /mnt_1 is a mount point

   ProtectFile

   192.168.10.150:/vol1_woodford/qatree1_reserve /mnt_1 ← host 1192.168.10.150:/vol1_woodford/qatree1_reserve /mnt_2 ← host 2

   CipherTrust Transpareant Encryption

   192.168.10.150:/vol1_woodford/qatree1_reserve /mnt_1 ← host 1192.168.10.150:/vol1_woodford/qatree1_reserve /mnt_1 ← host 2

7. Backup the data. The migration process does not preserve state across a power cycle. In the event of a power failure or intentional/ unintentional reboot of file server when migration is in progress, data must be restored from a backup.

8. Plan downtime. Downtime is required for each protected path on a file server that will be migrated. This means that the other paths can continue to be used with production workloads.

9. Downtime for an encrypted path means the following:

   1. No application can use that path. In case of NAS shares, the shares must be unmounted from all nodes except the one on which the migration is being performed.

   2. For Linux: In case of clusters, the migration is carried out on the active node and all of the other nodes must be passive.

   3. For Windows: Storage must be offline. Otherwise, failover can occur.

   4. In case an encrypted path is exported as a NAS share, you must stop the export before beginning the migration.

   5. Migration requires that ProtectFile encrypted paths must have Read/Write access to write, which allows plain text access to applications.

Using the pfmigrate Utility to Migrate ProtectFile Configuration to CTE

Thales developed the pfmigrate utility for converting the ProtectFile configuration elements on CM to their equivalent CTE configuration elements on CM. You can run the utility from any Linux or Windows system.

The pfmigrate utility migrates the following ProtectFile configuration elements:

• Keys

• Clients

• Access policies

• Access policy groups

• NAS shares

• Clusters

• Encryption rules

The utility creates equivalent CTE configuration elements and sets up the necessary linkage between them.

Prerequisites for Running pfmigrate Utility

Running the pfmigrate utility requires the following tasks:

Network Access

CipherTrust Manager must be reachable through port 443 from where you are running the pfmigrate utility. If you cannot communicate through the port, fix that issue before proceeding.

Permissions

You can run the pfmigrate utility from any Windows or Linux client that can access CM. You can run it as any user and it does not require root or administrator privileges.

It can migrate the ProtectFile to CTE configuration elements on the same CM which hosts the ProtectFile configuration. Alternatively, you can choose a different CM for the CTE configuration.

Install pfmigrate Utility

To install the pfmigrate utility:

1. Obtain the pfmigrate utility from the Thales Support portal.

2. Copy the pfmigrate utility to a directory that WILL NOT be guarded.

The pfmigrate utility creates the Client groups for the NAS, or clusters.

Create a Mapping File

The mapping file is a JSON file that associates the share names, as they are defined in CM, to their mount path on the file servers. The mapping file should contain an entry for each NAS share. A sample format for the mapping file is provided in Sample Mapping File.

If there are network shares configured on ProtectFile Linux clients, you must create a mapping file in JSON format to map pf_share_id to mount_point (on client machine). Sample mapping file is as follows:

{
    "mapping":[
        {
            "pf_share_name": "share1",
            "mount_point": "/mnt/nfs/employee"
        }
    ]
}

Running pfmigrate

The pfmigrate utility is now ready to run.

1. Navigate to the directory that you copied the pfmigrate utility into and run it:

   • In Linux, type: ./pfmigrate

   • In Windows, click on the pfmigrate.exe file

2. The utility prompts you for the following information. Provide the answers at each step:

   • Enter the IP address of the CipherTrust Manager from which you are importing ProtectFile data

   • Enter the Web Server Certificate Fingerprint, of the CipherTrust Manager server, from which you are importing ProtectFile data

   Note

   Copy the Web Server Certificate Fingerprint from CM, in Access Management > Registration Tokens.

   • Enter the user name of the CipherTrust Manager Administrator who is part of the ProtectFile Administrators and CTE Administrators group

   • Enter the password of the CipherTrust Manager

   • Enter the domain of the CipherTrust Manager (optional)

   • Are there any network shares configured with ProtectFile linux clients? (Y/N)

   • Enter the path of the PF share to the mount point mapping file

3. The pfmigrate utility runs.

The utility can take some time to finish. The utility creates a log of its operations in the file Migrations.log in the current directory. After it finishes, examine the log file for any errors. Also login to the CM and go through the configuration elements created by the utility. Refer to Production Policies for a better understanding of the CTE configuration elements.

There will be two CTE GuardPoints created by the pfmigrate utility for each ProtectFile rule:

1. Transformation GuardPoint: Created in disabled state and used for data transformation.

2. Production GuardPoint: Created in disabled state and used for applying production policy.

CTE Client Software Installation

1. Install the CTE client software on each client.

2. Make sure that in CM, in the CTE Server > Client section, you select Communication Enabled and Registration Allowed.

3. Register all of the nodes of the NAS, or cluster, to CM.

Data Transformation

CTE provides a data transformation tool called dataxform. This tool has been enhanced to convert the data from ProtectFile to CTE format, by providing it with the --migrate option.

The pfmigrate utility should have created two GuardPoints for each encryption rule, both of them in the disabled state.

• Data Transformation: Used for performing the initial data transformation.

• Production: Used for applying the production policy.This policy helps encrypt future files as well as decrypting the content of the files based on access privileges.

If the two GuardPoints exist, then you are ready to begin the data transformation. If they don’t exist, run the pfmigrate utility again.

Preparing for Data Transformation

To begin:

1. On CM, click ProtectFile/ Transparent Encryption UserSpace.

2. Click on a client name to view the rules and the access policy associated with that client.

3. Choose the rule for the migration and note the corresponding access policy.

Changing the Access Policy for Windows

1. Click Access Policies.

2. Create an access policy group for migrations(for ex: windows_migration_grp) with Read/Write access for the Administrator.

   1. Create an access policy (for ex: windows_migration).

   2. Add a access policy rule that gives the administrator user ReadWrite access permissions.

   3. Create an access policy group (for ex: windows_migration_grp) with:

      • OS: Windows

      • Group: Access Control & Encryption

      • Default Access: No Access

   4. Click on the newly created access policy group (windows_migration_gp) to open it.

   5. Search for newly created access policy (windows_migration).

   6. Click on the ellipsis and choose Add to Group.

3. The newly created access policy group looks like the following graphic. This access policy group will be used for all of the rules.

   Change the access policy group for the current rule to this newly created access policy group.

   Apply changes and wait for rules to be applied at client.

   

4. On the CM, navigate to corresponding CTE offline (Dataxform) GuardPoint and enable it:

   1. On CM, click CTE.
   2. Click Client on the relevant client name.
   3. Click on ellipses for the GuardPoint and select Enable.

Allow sometime for CM to enable the GuardPoint. When the status changes to Active, the GuardPoint is enabled. At this moment, the CTE GuardPoint would be overlaid on the ProtectFile encrypted path. Confirm this by examining the file servers.

Transforming Data in Windows

1. Open the Windows command line as an Administrator.

2. Run the pfstatus command, type: **pfstatus.exe**

   Note

   For ProtectFile file or folder policies, use absolute file/folder path with pfstatus utility to know status

3. Run the status command, type:

   secfsd –status guard –v

   The following screenshot depicts how the CTE GuardPoint is overlaid on the ProtectFile encrypted path.

4. Run the dataxform command.

   dataxform –-rekey –-migrate --gp <GuardPoint>

5. Run the dataxform command for sparse files:

   dataxform –-rekey --preserve_sparse_files -–migrate --gp <GuardPoint>

6. Exit the Windows command line tool.

7. After the dataxform has completed, navigate to the corresponding dataxform GuardPoint on the CM and disable it. Wait for the removal of the GuardPoint from the file server.

8. Navigate to the ProtectFile encryption rule on the CM and disable it. Wait for the process to complete.

9. Navigate to the corresponding production GuardPoint on CM and enable it. Wait for the operation to finish. Verify that the CTE GuardPoint is reapplied on the file server.

Manually Migrating DFS Replication Data

If you are using Distributed File System (DFS) replication, you must manually add additional GuardPoints for Replication endpoints such as a DFS Private folder.

For each DFS replication client, follow these additional, manual steps for migrating PF encrypted data to CTE encrypted data.

1. Navigate to the DFS Replication client on Transparent Encryption on CM. Note the DFS Replication protected path for the initial transformation/ production GuardPoint.

2. Click on the Policy for the DFS Replication production GuardPoint created by pfmigrate utility. Note the DFS Replication policy name.

3. Unguard both the initial transformation and production GuardPoints for DFS Replication path. Wait for these GuardPoints to be removed from the client.

4. Once both the initial transformation and production Guardpoints are removed, click Create GuardPoint and select the DFS policy.

5. Provide the DFS production GuardPoint replication path, and the DFSPrivate folder path manually, in the path field in the Create GuardPoint dialog.

   

6. Wait for the GuardPoints to become active on the file server. (It states Yes in the Enabled column.)

Manually Migrating DFS Replication Data

If you are using Distributed File System (DFS) replication, you must manually add additional GuardPoints for Replication endpoints such as a DFS Private folder.

For each DFS replication client, follow these additional, manual steps for migrating PF encrypted data to CTE encrypted data.

1. Navigate to the DFS Replication client on Transparent Encryption on CM. Note the DFS Replication protected path for the initial transformation/ production GuardPoint.

2. Click on the Policy for the DFS Replication production GuardPoint created by pfmigrate utility. Note the DFS Replication policy name.

3. Unguard both the initial transformation and production GuardPoints for DFS Replication path. Wait for these GuardPoints to be removed from the client.

4. Once both the initial transformation and production Guardpoints are removed, click Create GuardPoint and select the DFS policy.

5. Provide the DFS production GuardPoint replication path, and the DFSPrivate folder path manually, in the path field in the Create GuardPoint dialog.

   

6. Wait for the GuardPoints to become active on the file server. (The Enabled values change to Yes)

Changing the Access Policy for Linux

1. Click Access Policies.

2. Create an access policy group, (for ex: linux_migration_grp) with:

   • OS: Linux

   • Group: Access Control & Encryption

   • Default Access: Read/Write

3. The newly created access policy group will look like the following picture. This access policy group will be used for all of the rules. Change access policy group for the current rule with this newly created policy group. Apply changes and wait for rules to be applied at client.

   

4. On the CM, navigate to the corresponding CTE offline (Dataxform) GuardPoint and enable it:

   1. On CM, click CTE.

   2. Click Client on the relevant client name.

   3. Click on ellipses for the GuardPoint and select Enable.

Allow sometime for CM to enable the GuardPoint. When the status changes to Active, the GuardPoint is enabled. At this moment, the CTE GuardPoint would be overlaid on the ProtectFile encrypted path. Confirm this by examining the file servers.

Transforming Data in Linux

1. On Linux, use the mount command to confirm that the CTE GuardPoint is overlaying the ProtectFile encrypted path. The following screenshot depicts how the CTE GuardPoint is overlayed on the ProtectFile encrypted path.

   

2. For file servers, login directly as root. Do not execute a switch user command before starting the data transformation.

3. Run the dataxform tool as follows:

   dataxform -–rekey -–migrate --gp <GuardPoint>

   For transformation to preserve the original timestamps, run it with the following additional option:

   dataxform –-rekey --migrate --preserve_access_time –preserve_modified_time --gp <GuardPoint>

   Note

   The logs are stored in /var/log/vormetric.

4. Exit the terminal which was used to run dataxform.

5. After the data transformation has completed, navigate to the corresponding Dataxform GuardPoint on the CM and disable it. Wait for the GuardPoint to unmount on the file server.

6. For the encryption rule, navigate to the ProtectFile encryption rule on the CM and disable it. Wait for the encryption rule to unmount on the file server.

7. For Access only rule, navigate to the ProtectFile encryption rule on the CM and remove it. Wait for the rule to unmount on the file server.

8. Navigate to the corresponding production GuardPoint on CM and enable it. Wait for the operation to finish. Verify that the CTE GuardPoint is reapplied on the file server.

Post Migration

At this point, the migration for this encryption rule is completed. The data is converted to the CTE format and the access rules are enforced. The encrypted path is now ready for production use.

1. Verify the integrity of the data for each ProtectFile encrypted path. Consult the CTE product documentation for information on how to verify the data integrity.

   Linux File Server: After data migration, close existing login sessions/terminals and then verify the integrity of the data for each protected path.

   Windows File Server: After data migration, reboot the file server. Once the file server is rebooted, verify the integrity of the data for each protected path.

2. If you need to migrate other encryption rules immediately, do that now.

3. If you are not migrating any other encryption rules, make the full cluster nodes, and all of the NAS clients, active.

4. Repeat the steps for all encryption rules for the ProtectFile client.

5. Delete the ProtectFile client entry from the CM once all of the rules are migrated to CTE.

6. On Windows ProtectFile clients, backup the registry.

7. Uninstall the ProtectFile software from the file server.

8. Take a backup of the CM Configuration and the protected data now encrypted with CTE.

9. On Linux clients, backup the folder /etc/safenet and save all of the logs in /var/log/safenet.

CM does not support offline mode so you cannot back up offline policies.