Importing encryption keys to inbuilt key Management Server

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

@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

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