|
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, SafeNet 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 offsite storage. In the event of a local catastrophe, such as a flood or fire, you may 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 offsite 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 SafeNet 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. SafeNet 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 Luna PCI-E and Luna SA partitions include:
•Local or remote backup to a Luna 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 Luna PED (see "Small Form Factor Backup")
•Key synchronization among two or more Luna 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.
Note: The Luna G5 and the Luna Remote Backup HSM are not compatible. To backup the contents of a Luna G5 HSM, you clone the HSM contents to another Luna G5, which can then be stored as a backup. In the event that the primary/source HSM has problems, the backup Luna G5 can be retrieved from storage and connected, to immediately become the working HSM.
HSM partition backup securely clones Partition objects from a named HSM partition, to a Luna Remote Backup HSM (supports remote or local backups) or to a Small Form Factor USB Backup (SafeNet eToken 7300) plugged into a Luna PED. This allows you to safely and securely preserve important keys, certificates, etc., away from the primary Luna 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 Luna SA appliance, or LunaCM to backup any PCI-E or Luna SA 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 Luna Remote Backup HSM. You can add to, or replace, objects in the backup archive, as follows:
•partition backups initiated with the add 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 Luna SA) 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 Luna SA; it must already exist.
You can restore a partition backup to the source HSM or to a different Luna SA 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 source partition on the backup HSM.
You can back up all of your partitions to a Luna 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 Luna Remote Backup HSM provides remote backup capability.It also supports local backup and restore. The Luna Remote Backup HSM is commonly referred to simply as the Backup HSM.
The Luna Remote Backup HSM (Backup HSM) is a separately powered unit that you can connect as follows:
•to the USB port of a a Luna SA appliance. This allows a Luna SA 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 Luna client workstation. This allows the workstation administrator to use LunaCM to back up any Luna PCI-E devices installed in the workstation or any Luna SA partitions registered to the workstation.
•to the USB port of a remote Luna client workstation running the Remote Backup Service (RBS). You can then register the remote Backup HSM with a local Luna client workstation so that the it sees the remote Backup HSM as a slot in LunaCM. This allows the administrator of the local Luna client workstation to use LunaCM to back up any local slots to the remote Backup HSM.
The SafeNet eToken 7300 is a small form factor USB Backup Device is a that connects to the PED Key port on a Luna 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 - 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 Luna Shell (lunash:>) on Luna SA, the command is:
lunash:>partition backup -partition <name> -tokenPar <name> [-password <password>] [-tokenPw <password>] [-domain <domain>] [-add] [-replace] [-force]
If you are using lunacm:> on a workstation, the command is:
lunacm:> partition archive backup -slot <slot> -pas <password> -par <backup 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 Luna SA appliance. The destination backup devices and paths are listed in the table.
| Backup Destination | Time Required for Operation | Comment |
|---|---|---|
| Luna Backup HSM (PW-auth), local | 5 seconds | Password is supplied with the command |
| Luna 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 Luna SA | 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 the Luna appliance (three USB connectors). Thus, you could connect a Luna Remote Backup HSM, a Luna DOCK 2 (with migration-source tokens in its reader slots), and a Luna G5 HSM to the three available USB connectors on the Luna SA.
In general, a Luna HSM or HSM partition is capable of being backed up to a Luna Backup Token. 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 tokens are optional equipment for Luna 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 Luna 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.
Luna 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 Luna 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 Luna SA devices each with two partitions, could we backup all four partitions to a single Backup HSM? If yes, do they need to be under the same domain?
One Luna Remote Backup HSM can back up multiple Luna SAs. The domains on those Luna SAs 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 Luna SA partition and its backup partition on the Luna Remote Backup HSM. With that said, the limits on quantity of backup of partitions from multiple appliances is the remaining space available on the Backup HSM, and the remaining number of partitions (base configuration for Luna Backup HSM is 20 partitions - you can purchase additional capability).
For example, could we perform a backup of a 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 Luna 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.