Solved

Importing encryption keys to inbuilt key Management Server

  • 16 January 2022
  • 5 replies
  • 563 views

Badge +1

Hi All,

Currently we are using KeySecure (version is 8.4.3) for managing encryption keys for backup and restore in CommVault. We will be decommissioning the KeySecure soon and would like to know if its possible to import the keys to CommVault inbuilt key management system for existing backups before decommissioning the Keysecure so that we could still recover from existing backups using inbuilt KMS.  Also for future backups we would like to use the inbuilt key management server of CommVault which I think can be simply done by changing the key management server to be used in the Storage policy settings from external one to inbuilt.

 Thanks, Nazish

icon

Best answer by Mike Struening RETIRED 17 February 2022, 23:49

View original

5 replies

Userlevel 7
Badge +15

Hi @Nazish 

Reading through documentation, we don’t have any steps for exporting keys from one KMS and importing into another, so I’m not sure this operation is supported.

Configuring Encryption Key Management using Third-party Key Management Server

Important:

If you enabled third-party key management server on a deduplicated storage policy or copy, do not delete the third-party key associated with the deduplicated storage policy because for deduplicated data, the data blocks are referenced by multiple jobs. For more information, see How Deduplication Works.

If the key is deleted, the data associated with the deduplicated storage policy or copy will not be recoverable. In this situation, you need to create a new storage policy or copy and re-associate all subclients to new storage policy. For instructions on re-association, see Associating Subclients to a Different Storage Policy.

 

Deleting a Key Management Server

Prerequisite

If the key management server that you want to delete is associated with a storage policy copy, then, to delete the server, you must do one of the following things:

  • Disassociate the server from the storage policy copy.

  • Associate a different key management server with the storage policy copy.

 

There are a few warnings around deleting KMS, suggesting that backup job history may not be recoverable without access to the existing keys.

I would suggest rather than a remove and replace strategy, it would be safer phase out the current KMS and phase in a new one.

As in, leave the current storage policies in place with the current KMS, but disassociate the clients from this storage policy and associate with a new storage policy and a new KMS.

That way the existing KMS will only be used for historic backups on a storage policy that will no longer be used and will age out naturally over time. The current KMS will eventually become redundant with no jobs.

The new KMS will be used for new backup jobs going forward on a new storage policy with clients associated.

Thanks,

Stuart

Badge +1

Hi @Nazish 

Reading through documentation, we don’t have any steps for exporting keys from one KMS and importing into another, so I’m not sure this operation is supported.

Configuring Encryption Key Management using Third-party Key Management Server

Important:

If you enabled third-party key management server on a deduplicated storage policy or copy, do not delete the third-party key associated with the deduplicated storage policy because for deduplicated data, the data blocks are referenced by multiple jobs. For more information, see How Deduplication Works.

If the key is deleted, the data associated with the deduplicated storage policy or copy will not be recoverable. In this situation, you need to create a new storage policy or copy and re-associate all subclients to new storage policy. For instructions on re-association, see Associating Subclients to a Different Storage Policy.

 

Deleting a Key Management Server

Prerequisite

If the key management server that you want to delete is associated with a storage policy copy, then, to delete the server, you must do one of the following things:

  • Disassociate the server from the storage policy copy.

  • Associate a different key management server with the storage policy copy.

 

There are a few warnings around deleting KMS, suggesting that backup job history may not be recoverable without access to the existing keys.

I would suggest rather than a remove and replace strategy, it would be safer phase out the current KMS and phase in a new one.

As in, leave the current storage policies in place with the current KMS, but disassociate the clients from this storage policy and associate with a new storage policy and a new KMS.

That way the existing KMS will only be used for historic backups on a storage policy that will no longer be used and will age out naturally over time. The current KMS will eventually become redundant with no jobs.

The new KMS will be used for new backup jobs going forward on a new storage policy with clients associated.

Thanks,

Stuart

 

Hi @Stuart Painter , thanks a lot for your response. In our environment we have enabled encryption using third party KMS at global dedup storage policy level, and then we have some storage policies which follow the encryption settings from this Global Dedupe storage policy to encrypt the data. But we also have some other storage policy which use the same global dedupe storage policy but have the option of “Override the encryption setting from Global Dedupe Policy”, we use such storage policy to backup clients which do not require encryption. So in this kind of setup what will be your recommendation?

With both encrypted and non encrypted storage policy pointing to same global dedupe storage policy will they be referring to same data blocks due to deduplication? Will the non encrypted backups would also be impacted if due to some reason the third party KMS is offline or removed?

Sorry for too many questions but the setup which we have seem to be complex and I’m just trying to come out with the safest approach.

Thanks,

Nazish

Badge +1

@Stuart Painter - I opened a support ticket on this, and they checked with the Dev team and below is the reply I got.

“Just change the Key Management server from Key Secure to Built-in from copy properties. You need not to import the keys. New keys will be created, and existing backups can be restored.

Please make sure to change ( Key Secure to Built-in ) for all the copies currently mapped with Key Secure before decommissioning that”.

So once the KMS is changed to Built-in in all Storage policy and copies we dont need to import the keys of existing backups which were encrypted using the third party KMS. But this change to Built-in has to be done before decommissioning the third party KMS.

Just thought to share this for everyone’s benefit.

Thanks,

Nazish

 

Userlevel 7
Badge +23

Thanks, @Nazish !  Can you confirm everything is working now?

Userlevel 7
Badge +23

Sharing case resolution:

Just change the Key Management server from Key Secure to Built-in from copy properties. You need not to import the keys. New keys will be created, and existing backups can be restored.

Please make sure to change ( Key Secure to Built-in ) for all the copies currently mapped with Key Secure before decommissioning that.

Reply