Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

Migration

VTS to CT-VL

search

VTS to CT-VL

Prerequisites

Note

If you are running an unsupported version, upgrade your environment to a supported version before proceeding. Refer to the corresponding product documentation for upgrade instructions.

Supported Versions

Current Setup

ProductVersion
VTS/CTS2.6.0 or higher
DSM6.4.5 or higher

Target Setup

ProductVersion
CT-VL2.6.0 or higher
CipherTrust Manager2.4 or higher

Note

If you are using CT-VL version lower than 2.6.0, or version higher than or equal to 2.3.0, you need to upgrade to the minimum supported CT-VL version 2.6.0 for the CipherTrust Manager.

Refer to Migrating from CT-VL Lower Versions to 2.9.0 for details on how to migrate to CT-VL 2.9.0.

Migration Approaches

Use either of the following migration approaches:

Setting up New CT-VL Cluster

This is the recommended approach. It allows you to retain an existing CT-VL cluster if the migration fails and roll back the migration.

  1. Migrate your DSM to the CipherTrust Manager. Refer to Migrate from Data Security Manager for details.

  2. After successful migration from DSM to CM, reconfigure existing VTS cluster with CM.

  3. Back up the existing VTS cluster. Refer to the VTS Documentation for details.

  4. Create a new CT-VL virtual machine (VM).

  5. Restore the VTS backup to the newly created VM (created in above step).

    Note

    You can only restore tokenization and crypto configurations from the backup. Configurations such as LDAP, remote Syslog, and SNMP cannot be restored. These configurations must be configured on each node in the CT-VL cluster.

  6. Create another VM and join it to the first VM to create a cluster. Similarly, based on your requirement, you can create multiple VMs and add them to the cluster.

  7. Verify that all the nodes in the cluster are replicating correctly.

  8. Log on to the CLI of the first node in the CT-VL cluster. Configure that node to connect to and register with the CipherTrust Manager. Refer to the CT-VL Documentation for details.

  9. Repeat previous step for all the remaining nodes in the cluster.

  10. (If Random Mode tokenization is used) Verify that the random tables are successfully generated on all the nodes.

  11. Verify that the migration is successful. Perform the following steps:

    • Test tokenization and cryptographic operations on each node. For example, you can perform tokenization on one node and detokenization on another node. This ensures the cluster is operating correctly.

    • Take some tokenized or encrypted data from the existing VTS cluster (tokenized or encrypted using DSM) and detokenize or decrypt it using the newly created CT-VL cluster. This ensures successful migration of DSM keys to the CipherTrust Manager.

    If the migration is not successful or you run into any issues with the CipherTrust Manager, you can roll back the migration. Refer to Rolling Back Migration (New Cluster) for details.

  12. Switch the load balancer from the old VTS cluster to the new CT-VL cluster.

Migrating Existing VTS Cluster

To migrate an existing VTS cluster:

  1. Migrate your DSM to the CipherTrust Manager. Refer to Migrate from Data Security Manager for details.

  2. After successful migration from DSM to CM, reconfigure existing VTS cluster with CM.

  3. Disconnect the VTS cluster from the load balancer.

    Note

    Do not perform tokenization or cryptographic operations until all the nodes of the VTS cluster are migrated and configured to use the CipherTrust Manager.

  4. Back up the VTS cluster. Refer to the VTS Documentation for details.

  5. Verify that all the nodes in the cluster are replicating correctly.

  6. Log on to the CLI of each node in the cluster. Configure them to connect to and register with the CipherTrust Manager. Refer to the CT-VL Documentation for details.

  7. Verify that all the nodes in the cluster now point to the CipherTrust Manager, not the DSM. To ensure this, shut down the DSM.

  8. Restart the vts service on all the nodes to ensure that DSM caching is not being used.

  9. Verify that the migration is successful. Perform the following steps:

    • Test tokenization and cryptographic operations on each node. For example, you can perform tokenization on one node and detokenization on another node. This ensures the cluster is operating correctly.

    • Take some tokenized or encrypted data from the existing VTS cluster (tokenized or encrypted using DSM) and detokenize or decrypt it using the newly created CT-VL cluster. This ensures successful migration of DSM keys to the CipherTrust Manager.

    If the migration is not successful or you run into any issues with the CipherTrust Manager, you can roll back the migration. Refer to Rolling Back Migration (Existing Cluster) for details.

  10. Add the load balancer to the CT-VL cluster.

    Note

    It is not necessary to break the CT-VL cluster. But, if a node fails to replicate, remove that node from the cluster and rejoin it.

Rolling Back Migration (Undo Migration)

Rolling Back Migration (New Cluster)

  1. Discard the newly created CT-VL cluster.

  2. Activate the old VTS cluster and restore the load balancer.

Rolling Back Migration (Existing Cluster)

  1. If VTS is using DSM, log on to the CLI of each node in the cluster and disable icapi. This step automatically reestablishes the connection between VTS and DSM.

  2. Verify that each node in the cluster is connected to the DSM. Run the CLI vae show --status command to check the status of each node. If any node is unable to connect to the DSM, reregister that node to the DSM.

  3. If VTS is using the CipherTrust Manager, reconfigure the VTS node to connect to and register with the CipherTrust Manager.

  4. Run the icapi test command to verify that each node in the VTS cluster is connected to the CipherTrust Manager.

  5. Verify that tokenization and cryptographic operations are successfully performed on all the nodes.

  6. Restore the load balancer.

Limitations

Cryptographic Services and Key Management Services are not supported with the CipherTrust Manager.

The following Cryptographic Services and Key Management Services are not supported with the CipherTrust Manager:

  • Custom attributes for symmetric and asymmetric keys

  • Opaque objects

  • Key alias feature

  • NIST key states

  • AES-CTR and AES-GCM modes of encryption

  • Encrypt, decrypt, sign, and verify with RSA keys

The following Cryptographic Services and Key Management Services are not supported with the CipherTrust Manager:

  • Custom attributes for symmetric and asymmetric keys

  • Opaque objects

  • Key alias feature

  • NIST key states

  • AES-CTR and AES-GCM modes of encryption

  • Deletion of key chains

The following Cryptographic Services and Key Management Services are not supported with the CipherTrust Manager:

  • Custom attributes for symmetric and asymmetric keys

  • Opaque objects

  • Key alias feature

  • NIST key states

  • Deletion of key chains

The following algorithms are not supported with the CipherTrust Manager:

  • Sign/Verify: HS1

  • Digest: MD5 and S1

  • Encrypt/Decrypt: AES-ECB (for non 16-byte plaintext/ciphertext)

Note

  • For running the import key API with DSM, CT-VL requires that the first letter of a key label is an alphabet. However, with the CipherTrust Manager, CT-VL doesn't have this restriction.

  • While running the patch key API with DSM, CT-VL returns errors for invalid scenarios. However, with the CipherTrust Manager, CT-VL doesn't return any error.

  • While running the decrypt API with DSM, CT-VL decrypts the ciphertext with any random IV successfully. However, with the CipherTrust Manager, CT-VL returns an error. It requires the IV that was used for encryption.

On this page