Everything you need to know about cloning with Edge Encryption

[iris_geist]

When cloning while using Edge Encryption on your clone source instance and / or the clone target instance, there are many things to consider to ensure success. But first, let's start with how a clone works.

Overview of cloning

During a clone, you take a dump of your source database — minus the excluded tables from your clone configuration — and move it into your target database. Afterwards, you restore the preserved data — data that was copied before the clone — into your target database.

Get a more detailed overview of how cloning works in the product documentation: System clone

Three ways to handle keys on a clone with Edge Encryption

In connection with clones and Edge Encryption, it is important to understand that your encrypted data was copied over from target to source. So, how will you be able to read that encrypted data on the target system? To solve this issue, you have three options depending on the state of your data.

Option 1 — Source and target can use the same encryption key

This is the easiest way to perform the clone and still being able to access encrypted data. If both source and target my use the same encryption key, use the following community article by martygrinstead as a reference: Cloning an instance when Edge Encryption is Active

Option 2 — Only attachments are encrypted. Fields are not encrypted and tokenization is not used OR the data you have encrypted can be excluded from the clone

If you clone with the exclusion of attachments (meaning your encrypted data is not part of the clone), you can contact Customer Support to preserve the Edge Encryption keys during the clone.

Option 3 — Source and target cannot use the same encryption key.

Use Option 1 as a stepping stone. Once the data is in your sub-production instance, and your edge proxies can connect to the sub-production system using the production key, start a key rotation to re-encrypt your data with the sub-production key. Once the key rotation jobs are finished, you can delete the old production key from the sub-production instance.

For more information on key rotation, see the product documentation: Rotate Encryption Keys

While there is a theoretical Option 4 — decrypt data before the clone — this option would be counterproductive and not discussed here.

Managing signature keys

Now that we have covered possible options regarding the encryption keys, we also have to discuss possible signature issues during the clone. Many customers use the same signature key for all instances. If for some reason you are using different signature keys in your different instances, you will have to re-sign all edge configuration items as well.

You have three options for managing signature keys:

Option 1 — Copy the signature key from the clone source to the clone target

This can be done using java keytools. Visit the product documentation Configure the Signature Key for detailed steps on how to do this.

Option 2 — Correct issues after the clone

After the clone, you will have error messages that the signatures in your configuration don't match. To fix this issue, set the properties

• edgeencryption.proxy.skip.config.validate = true
• edgeencryption.proxy.signature.verify = false

as described in the knowledge article KB0621218 and restart the proxies.

Update every rule and configuration in the Edge Encryption application. For example, do this by setting the records to inactive and then back to active. This will re-sign each record. Once you have done this for all records, set

• edgeencryption.proxy.skip.config.validate = false
• edgeencryption.proxy.signature.verify = true

and restart the Edge proxies again.

Option 3 — Exclude the Edge Encryption configuration and rules from the clone

After the clone, recreate the still needed configurations. This is the most labor-intensive option and is not recommended.

Cloning with tokenization or preserving database

If you are using tokenization or have columns encrypted using equality-preserving or order-preserving encryption types, the information required to decrypt the tokens or the columns properly is stored in a MySQL database connected to your Edge proxies. For tokenized or preserved data to be properly readable after a clone, that MySQL database will have to be "cloned" with the instance, so that all data matches. The easiest way to sync the target database to the source database is to create a backup of the source MySQL database at the same time the backup is run on the parent instance (contact support for the approximate timing), since the clone will use the last backup of the parent instance to copy to the clone target instance. Before starting up the proxies again after the clone has finished, restore that backup of the clone source instance's MySQL database over the clone target instance's MySQL database.

This might be easier explained in a timeline:

	e.g. 00:30	Clone Start — X minutes	Clone Start	Clone Start + X minutes	Clone End
Clone Source Instance	Nightly Backup
Clone Target Instance		Data Preservers copy data as XML	Source's nightly backup restored	Data Preservers restored as XML
Clone Source MySQL	Create Backup
Clone Target MySQL			Shut down proxies		Restore Source MySQL backup	Start Proxies

To summarize, cloning with Edge Encryption requires some forethought, since the data that is encrypted in the source instance needs to be readable in the target instance. There are several items involved that need to be looked into:

• Encryption key
• Signature key
• Tokenization database

Always ensure that you have a plan in place before cloning the instance, and follow the steps outlined for your process plan to ensure all will work properly.