Migrate from Data Security Manager

You can restore the following objects from a Data Security Manager (DSM) backup file:

• Agent keys, including versioned keys

• Vault keys

• Bring Your Own Key (BYOK) objects

• Domains

• KMIP managed objects

By default, the user who restores the backup file becomes the administrator of the newly created CipherTrust Manager domain(s), and has access to the restored keys within the domain(s). There is an additional option to create a key-sharing group with permissions for the restored keys in all domains. You can later add CipherTrust Manager users to this group to grant access to the keys.

The DSM Administration Guide version 6.4.4 describes creating and encrypting a backup file for CipherTrust Manager in Chapter 12 "Backing Up and Restoring".

CipherTrust Manager Changes from Thales eSecurity DSM

• No hypervisor limitation - so it can run on any cloud

• Improved User Interface

• Updated REST interface that offers both encryption and configuration in scope

• Addition of a full-featured, remote CLI interface

• Built in CipherTrust Cloud Key Manager (removes the need for seperate MongoDB instance)

• Unified Key Management with KMIP key material - integrates policy, logging and management - bringing simplified and richer capabilitiies to KMIP

• Supports CTE (renamed VTE) from version 7.0

• Supports CADP as a replacement for VAE and VKM

• All other connectors (BDT, Tokenization) are supported with latest versions

Exporting and Importing the Backup File

As part of exporting a backup file from a DSM, you create a wrapper key to encrypt the file. On the target CipherTrust Manager, you create a migration split key with the same values as the wrapper key. This migration split key is needed for CipherTrust Manager to decrypt the backup file to restore the DSM objects.

The wrapper key and migration split key divides a single key into multiple shares, with a minimum number of shares required to reassemble the key. This configuration, called M of N, provides more security as a different custodian holds and controls each share.

To migrate agent keys and vault keys from DSM

1. On your DSM appliance, create a wrapper key, and split it into key shares as described in the DSM Administration Guide version 6.4.4 Chapter 12 "Backing Up and Restoring".

   You need the following values to later create the corresponding migration split key and key shares on CipherTrust Manager:

   • The wrapper key identifier

   • The Minimum Custodians Needed to assemble the wrapper key

   • The key material from the wrapper key shares

2. Create a backup file on the DSM, using the wrapper key to encrypt the backup file.

   Note

   The backup file can include objects other than agent keys, vault keys, or domains. CipherTrust Manager skips these items and does not restore them.

3. Create a migration split key on a CipherTrust Manager to decrypt the backup file.

   Note

   You cannot directly import a DSM-created wrapper key into the CipherTrust Manager. You must re-create the wrapper key as a migration split key.

   1. Create the migration split key.

      $ ksctl migration-split-keys create --name <name> --threshold <threshold> --digest <digest>
      

      You must provide:

      • a name for the key.

      • threshold — a minimum number of keys needed to reconstruct the split key, based on Minimum Custodians Needed from the DSM wrapper key.

      • digest — the identifier from the original DSM wrapper key.

   2. Create shares for the split key. Create as many as shares as indicated in the threshold value for the migration split key.

      $ ksctl migration-split-keys shares create --name <name> --share-key <share-key>
      $ ksctl migration-split-keys shares create --name <name> --share-key <share-key>
      

      You must provide the name of the migration split key and the key material from the DSM wrapper key share.

4. Upload the backup file into the CipherTrust Manager. Take note of the ID returned in the response.

   $ ksctl migrations upload --file <filename>
   

5. Apply the backup file.

   $ ksctl migrations apply --id <id> [--user <user-name> --password <user-password>] [--domains <DSM-domains>] [--group-name <DSM group name>]
   

   You must provide the id for the backup file. This was indicated when you uploaded the backup, or you can view it with the ksctl migrations list command.

   The following parameters are optional:

   • user — The CipherTrust Manager user who will become the administrator of the created domain(s). If not specified, the user currently logged in to ksctl is granted this permission.

   • password — Password of the above CipherTrust Manager user.

   • domains — Limits the DSM domains that are restored. The accepted format is a comma-separate list of domain names.

   • group-name — Creates a new group with this name in every domain that is migrated. Users belonging to this group can access all keys in the domain.

   You can check the status of the migration with ksctl migrations status.

6. List your keys to ensure that DSM keys were successfully migrated into the CipherTrust Manager domain.

   $ ksctl --domain <domain-name> keys list