|
Home > |
Administration Guide > Backup and Restore HSMs and Partitions > Backup and Restore Overview and Best Practices
|
|---|
This section provides an overview of the various ways you can backup and restore your HSM partitions, and provides some guidance for best practices to ensure that your sensitive key material is protected in the event of a failure or other catastrophic event.
The major options for a backup or restore operation, using a Backup HSM are:
•Backup or restore between a source/operational HSM and a locally connected Backup HSM; "local" can mean
–directly, physically connected to the source HSM, or
–connected via USB to a Client workstation that sees both the source HSM and the Backup HSM as selectable slots
•Backup or restore between a source/operational HSM and a remotely connected Backup HSM; "remote" always means
–the Backup HSM is physically connected to a dedicated Backup workstation/server, running the Remote Backup Service (RBS), and
–the Backup workstation is connected, via RBS, to the Client workstation, such that both the RBS slot(s) and the source HSM partitions are visible as selectable slots on the Client workstation.
This section contains the following topics:
•Backup and Restore Best Practices
•Objects are Smaller When Stored on Backup HSM
•Comparison of Backup Performance by Medium
•Compatibility with Other Devices
•Additional Operational Questions
To ensure that your data is protected in the event of a failure or other catastrophic event, Gemalto recommends that you use the following best practices as part of a comprehensive backup strategy:
•Develop and document a backup and recovery plan. This plan should include the following:
–What is being backed up
–The backup frequency
–Where the backups are stored
–Who is able to perform backup and restore operations
–Frequency of exercising the recovery test plan
•Make multiple backups. To ensure that your backups are always available, build redundancy into your backup procedures.
•Use off-site storage. In the event of a local catastrophe, such as a flood or fire, you might lose both your working HSMs and locally stored backup HSMs. To fully protect against such events, always store a copy of your backups at a remote location. You can automate off-site backups using the remote backup feature, See Backup and Restore From the Client to a Remote Backup HSM (LunaCM, RBS) for more information.
•Regularly exercise your disaster recovery plan. Execute your recovery plan at least semi-annually (every six months) to ensure that you can fully recover your key material. This involves retrieving your stored Backup HSMs and restoring their contents to a test partition, to ensure that the data is intact and that your recovery plan works as documented.
WARNING! Failure to develop and exercise a comprehensive backup and recovery plan may prevent you from being able to recover from a catastrophic event. Although Gemalto provides a robust set of backup hardware and utilities, we cannot guarantee the integrity of your backed-up key material, especially if stored for long periods. Gemalto strongly recommends that you exercise your recovery plan at least semi-annually (every six months) to ensure that you can fully recover your key material.
The available options for backing up your SafeNet Network HSM partitions include:
•Local or remote backup to a SafeNet Backup HSM (see "Local Partition Backup and Restore Using the Backup HSM" on page 1 and Backup and Restore From the Client to a Remote Backup HSM (LunaCM, RBS))
•Key synchronization among two or more SafeNet HSMs in an HA configuration (see High-Availability (HA) Configuration and Operation)
•Any combination of the above methods, to suit your needs
The backup operation looks a lot like the restore operation, because they are basically the same event, merely in different directions.
HSM partition backup securely clones partition objects from a named HSM partition, to a SafeNet Backup HSM (supports remote or local backups). This allows you to safely and securely preserve important keys, certificates, etc., away from the primary SafeNet HSM. It also allows you to restore the backup device's contents onto more than one HSM partition, if you wish to have multiple partitions with identical contents.
To back up a partition, you must own it and be able to see it. You can use LunaSH to back up any partitions you own on a SafeNet Network HSM appliance, or LunaCM to backup any SafeNet Network HSM partitions that are visible as slots.
When you backup a partition, the contents of your HSM partition are copied to a matching partition on the SafeNet Backup HSM. You can add to, or replace, objects in the backup archive, as follows:
•Partition backups initiated with the add or append option add new or changed objects to the partition archive, leaving existing objects intact.
•Partition backups initiated with the replace option replace all existing objects in the partition archive with current contents of the partition, destroying the existing objects.
The backup operation can go from a source partition on a SafeNet HSM to an existing partition on the Backup HSM, or if one does not exist, a new partition can be created during the backup. The restore operation, however, cannot create a target partition on a SafeNet HSM; it must already exist.
You can restore a partition backup to the original source HSM or to a different SafeNet HSM. The HSM you restore to must already have a suitable partition created for the restored objects. The partition can have any name - it does not need to match the name of the archive partition on the backup device.
You can back up all of your partitions to a SafeNet Backup HSM:
Note: The word "Remote" in the product name merely indicates that the SafeNet Backup HSM provides remote backup capability. It also supports local backup and restore. The SafeNet Backup HSM is commonly referred to as the Backup HSM.
The SafeNet Backup HSM (Backup HSM) is a separately powered unit that you can connect as follows:
•To the USB port of a a SafeNet Network HSM appliance. This allows a SafeNet Network HSM administrator to use LunaSH to back up any partitions on the appliance that they own (non-PSO partitions).
•To the USB port of a local SafeNet HSM client workstation. This allows the workstation administrator to use LunaCM to back up any SafeNet PCIe HSM devices installed in the workstation or any SafeNet Network HSM partitions registered to the workstation.
•To the USB port of a remote SafeNet HSM client workstation running the Remote Backup Service (RBS). You can then register the Remote Backup HSM with a local SafeNet HSM client workstation so that the it sees the Remote Backup HSM as a slot in LunaCM. This allows the administrator of the local SafeNet HSM client workstation to use LunaCM to back up any local slots to the remote Backup HSM.
To perform a backup, you identify the partition to be backed up (source), and the partition that will be created (or added to) on the Backup HSM. You can specify whether to add/append only unique objects (objects that have not previously been saved onto the target partition), or to replace (overwrite) the objects on the target partition.
If you are using LunaSH to backup a partition on a SafeNet Network HSM, use:
partition backup -partition <partition_label> -tokenpar <backup_label> -serial <backup_HSM_SN> [-add] [-replace]
More options are available. See partition backup in the LunaSH Command Reference Guide for full command syntax.
If you are using LunaCM on a Client workstation, first login to the partition as Crypto Officer.If the backup device is
•a slot in the current system, use:
partition archive backup -slot <backup_slot> -partition <name_for_backup> [-append] [-replace]
•in a remote workstation, use:
partition archive backup -slot remote-hostname <hostname> -port <portnumber> -partition <name_for_backup> [-append] [-replace]
•a USB-attached HSM, use:
partition archive backup -slot direct -partition <backup_partition> [-append] [-replace]
More options are available. See partition archive backup in the LunaCM Command Reference Guide for full command syntax.
LunaCM assumes that the target partition already exists with the appropriate domain
If a matching target partition exists and the source partition is being incrementally backed up, choosing the add/append option in the command - then the target partition is not erased. Only source objects with unique IDs are copied to the target (backup) partition, adding them to the objects already there.
If a matching target partition exists and the source partition is being fully backed up, choosing the replace option in the command. The existing partition is erased and a new one created.
Objects stored on the Backup HSM may be smaller than the same objects stored on the SafeNet Network HSM. For example, symmetric keys are 8 bytes smaller when stored on the Backup HSM. This size difference has no effect on backup and restore operations.
For reference, this table shows examples of time required for a backup operation for one partition containing 25 RSA 2048-bit keypairs, or 50 objects in total. The source is a SafeNet Network HSM appliance. The destination backup devices and paths are listed in the table.
| Backup Destination | Time Required for Operation | Comment |
|---|---|---|
| SafeNet Backup HSM (PW-auth), local | 5 seconds | Password is supplied with the command |
| SafeNet Backup HSM (PED-auth), local | 5 seconds plus... | Add any time required for PED key operations |
Backup can co-exist with PKI Bundle operation. That is, multiple devices can be connected simultaneously to a SafeNet appliance (three USB connectors). Thus, you could connect a SafeNet Backup HSM, a SafeNet DOCK 2 (with migration-source tokens in its reader slots), and a SafeNet USB HSM to the three available USB connectors on the SafeNet Network HSM.
In general, a SafeNet HSM or HSM partition is capable of being backed up to a SafeNet Backup HSM. The backup capability is considered a good and desirable and necessary thing for keys that carry a high cost to replace, such as Certificate Authority root keys and root certificates.
However, backup devices are an optional equipment for SafeNet HSMs. There are at least two reasons for this:
1.Some customers
don't care. They may be using (for example) SSL within a controlled boundary
like a corporation, where it is not a problem to simply tell all employees
to be prepared to trust a new certificate, in the event that the previous
one is lost or compromised. In fact it might be company policy to periodically
jettison old certificates and distribute fresh ones.
Other customers might be using software that manages lost profiles,
making it straightforward to resume work with a new key or cert. The certificate
authority that issued the certificates would need backup, but the individual
customers of that certificate authority would not. In summary, it might not be worthwhile to backup keys that are low-cost
(from an implementation point of view) to replace. Keys that carry a high
cost to replace should be backed up.
2.Some countries do not permit copying of private keys. If you are subject to such laws, and wish to store encrypted material for later retrieval (perhaps archives of highly sensitive files), then you would use symmetric keys, rather than a private/public keypair, for safe and legal backup.
SafeNet HSMs have onboard volatile memory meant for temporary data (disappears when power is removed), and onboard flash memory, used to store permanent material, like PKI Root keys, and critical key material, and the firmware that makes the device work.
No electronic storage is forever. If your SafeNet HSM is operated within an ambient temperature range of 0 degrees Celsius to +40 degrees Celsius, or stored between -20 degrees Celsius and +65 degrees Celsius, then (according to industry-standard testing and estimation methods) your data should be retrievable for twenty years from the time that the token was shipped from the factory. This is a conservative estimate, based on worst-case characteristics of the system components.
For example, if we had two SafeNet Network HSM appliances each with two partitions, or if we had four SafeNet PCIe HSMs, could we backup all four partitions to a single Backup HSM? If yes, do they need to be under the same domain?
One SafeNet Backup HSM can back up multiple SafeNet HSMs. The domains on those SafeNet HSMs do not need to match each other (although they can, if desired), since domains can be partition-specific. The only domains that must match are those on any given SafeNet HSM partition and its backup partition on the SafeNet Backup HSM. With that said, the limits on quantity of backup of partitions from multiple appliances or embedded HSMs is:
•the remaining space available on the Backup HSM, and
•the remaining number of partitions (base configuration for SafeNet Backup HSM is 20 partitions - you can purchase additional capability).
For example, could we perform a backup of an application partition one month and then back it up again next month without overwriting the previous month?
Yes, you can do this as long as each successive backup partition (target) is given a unique name.