|
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 in which you can backup and restore your HSM partitions, and provides some guidance for best practices you can use to ensure that your sensitive key material is protected in the event of a failure of other catastrophic event. It contains the following topics:
•Backup and Restore Best Practices
•Comparison of Backup Performance by Medium
•Compatibility with Other Devices
•Additional Operational Questions
In order to ensure that your data is protected in the event of a failure or other catastrophic event, Gemalto recommends that you adhere to 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 Remote Application-Partition Backup and Restore Using the Backup HSM 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/or SFF tokens 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 PCI-E HSM and SafeNet Network HSM partitions include:
•Local or remote backup to a SafeNet Remote Backup HSM (see Local Application-Partition Backup and Restore Using the Backup HSM and Remote Application-Partition Backup and Restore Using the Backup HSM)
•Backup to a SafeNet eToken 7300 small form factor (SFF) USB backup token, through a SafeNet PED (see Small Form Factor Backup)
•Key synchronization among two or more SafeNet HSMs in an HA configuration (see High-Availability (HA) Configuration and Operation)
•Direct cloning between two HSMs locally connected to one host
•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 Remote Backup HSM (supports remote or local backups) or to a Small Form Factor USB Backup (SafeNet eToken 7300) plugged into a SafeNet PED. 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.
In order to back up a partition you must own it and be able to see it. This means that you can use LunaSH to back up any partitions you own on a SafeNet Network HSM appliance, or LunaCM to backup any SafeNet PCI-E HSM or SafeNet USB HSM or 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 Remote Backup HSM or SFF eToken. 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 SFF eToken, 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 Remote Backup HSM, or a single partition to a SafeNet eToken 7300 (SFF token):
Note: The word "Remote" in the product name merely indicates that the SafeNet Remote Backup HSM provides remote backup capability. It also supports local backup and restore. The SafeNet Remote Backup HSM is commonly referred to simply as the Backup HSM.
The SafeNet Remote 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-PPSO 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 PCI-E 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.
You can backup an application partition in SafeNet PCI-E HSM or a SafeNet USB HSM to another SafeNet USB HSM that is directly connected to the same host, by means of the command partition clone between the respective slots.
The SafeNet eToken 7300 is a small form factor USB Backup Device that connects to the PED Key port on a SafeNet PED, which connects to the HSM remotely, via Remote PED connection. The Small Form Factor USB Backup is described in Small Form Factor Backup. SFF backups are supported in LunaCM only.
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 or SFF eToken - the Token Partition Name - and then specify whether to add only unique objects (objects that have not previously been saved onto the target partition), or to completely replace the target partition (overwrite it).
If you are using lunacm:> on a workstation, the command is:
lunacm:> partition archive backup -slot <slot> -pas <password> -par <backup partition> or lunacm:> partition archive backup -slot <etoken> -label <label_for_SFF_token>
If backing up to an SFF device, you can optionally specify a comma-delimited list of handles for specific objects to backup; otherwise, the default is to backup all objects in the source partition.
The lunacm:> version assumes that the target partition already exists with the appropriate domain, while the lunash:> version expects you to provide the domain, or prompts for it if it is not provided (for Password-authenticated HSMs).
If a matching target partition exists and the source partition is being incrementally backed up, choosing the add 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.
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 |
| SafeNet eToken 7300 (SFF device) connected to Remote PED on workstation, distant from SafeNet Network HSM | 7 minutes 13 seconds | Approximately 130 seconds is initialization of the SafeNet eToken 7300 device; remainder is secure copying of partition objects |
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 Remote 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 or SafeNet Small Form-Factor Backup eToken. 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 optional equipment for SafeNet HSMs. There are at least three 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.SIM (Secure Identity Management or Multi-Million Keys) does not co-exist with standard SafeNet cloning function. The SIM Master Secret Key on the HSM can be backed up, but HSM Partitions are not used in the SIM configuration, so there are no contents to backup.
3.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 PCI-E 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 Remote Backup HSM can back up multiple SafeNet Enterprise HSMs or SafeNet PCI-E 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 Remote 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.
One Small Form Factor USB Backup device can back up one SafeNet HSM partition. Backup operations are overwrites, not incremental or additive. To use the same Small Form Factor USB Backup device to backup a different HSM partition, you lose any data or objects that were already on the SFF Backup device.