|
Home > |
|---|
You have options when you need to back up the contents of your SafeNet USB HSM.
If you have a small number of SafeNet USB HSMs in service, the recommended backup procedure is to simply clone to another SafeNet USB HSM that sits on a shelf until you need it. If the working unit fails, you simply plug in the clone and it works immediately, with no delay, while you work with Technical Support to fix the problem or to send the defective unit back for repair.
Cloning "backup" of SafeNet USB HSMs uses the cloning feature and the hsm clone or partition clone commands. Cloning takes place from hardware to hardware (from one SafeNet USB HSM connected to your computer to another SafeNet USB HSM connected to the same computer) in secure fashion.
If you have a larger number of SafeNet USB HSMs in service, then it begins to become uneconomical to have a separate SafeNet USB HSM as backup for each in-service unit. In that situation, it makes more sense to have just a reasonable number of spare "blank" HSMs in storage, and to use SafeNet Backup HSM to backup the contents of the production units, since one SafeNet Backup HSM can have many partitions. In the event that an in-service HSM fails, you can restore its backup onto one of the blank units and have the replacement in operation.
When backing up the contents of an HSM or a partition on an HSM, the source and target HSMs must share the same cloning domain (red PED Key for PED Authenticated HSMs), if cloning is to take place. The domain is set at initialization time, and cannot be altered without initializing the HSM again. During the transfer, all data is encrypted with the domain secret. See saw.
Roughly equivalent backup and restore options exist for the HSM Adminstrator / SO space of the HSM, and for the User Partition. These are handled separately.
For the HSM level, if you clone to a second HSM you wipe that target (initialize it) and fill it with the HSM Adminstrator / SO objects from the source HSM. In most cases there would not be any HSM Adminstrator / SO-only objects - you would be cloning the structure (authentication, etc.) Similarly, if you restore to an HSM, you initialize it in the process. This means that you cannot incrementally or selectively restore HSM SO-owned objects via cloning, so you cannot keep any changes that you made in the original HSM after the backup (clone) was made.
Normally, this is not an issue, because there is usually little need to backup HSM Administrator / SO-owned objects at the HSM level. The HSM Administrator / SO level is usually only administrative on the HSM.
The more usual requirement is to backup the working contents of a User Partition, which is the level where the real work of your Client applications takes place, and the working keys and certificates and other objects are stored.
For partitions, the cloning can include all partition objects or a subset that you indicate by a (comma-separated) list of object handles.
Your cloning backup and restore operations are "lunacm partition clone", in either direction (to the target HSM's partition for the backup operation, or from it for the restore operation).
The authentication for the Backup Tokens can match that of the HSM or Partition, or it can be different. This is a decision that should be referred to your organization's security policies. However, the HSM and the backup token must share the same domain.