|
Home > |
|---|
This section describes what you can do with the Luna Remote Backup HSM (Backup HSM) and outlines the various ways, both local and remote, that you can connect the Backup HSM to perform backup and restore operations. It contains the following topics:
•"Functionality of the Luna Remote Backup HSM"
•"Backup and Restore Options and Configurations"
Note: The word "Remote" in the product name merely indicates that the Backup HSM provides remote backup capability. You can use the Luna Remote Backup HSM to back up the contents of your HSM to a locally attached Backup HSM, or to a remotely located Backup HSM. The Luna Remote Backup HSM is referred to as the Backup HSM in this section.
You can use the Luna Remote Backup HSM to backup multiple partitions from one or more a Luna SA or Luna PCI-E HSMs. Partition domain and authentication attributes are maintained when you back up a partition, which impacts how you can use the Backup HSM.
Backup is performed on a per-partition basis. Luna PCI-E HSM supports one application partition. The Luna SA HSM supports multiple application partitions. The size of a Luna SA partition is configurable, but since all partitions share the HSM memory, the more partitions you create, the smaller they must be.
The base configuration for Luna Backup HSM is 20 partitions and 15.5 Mb of space, allowing you to backup a Luna SA with up to twenty partitions, or any combination of partitions on individual Luna HSMs, up to the maximum memory available on the Backup HSM. Luna SA at firmware 6.22.0 or newer can be updated via capability update to support 50 or 100 partitions. You have the option of purchasing and adding capability upgrades for 50 or 100 partitions to Luna SA, as well as to the Luna Backup HSM.
Note: The size of the partition header is different for a Luna SA partition and its equivalent backup partition stored on a Luna Remote Backup HSM. As a result, the value displayed in the Used column in the output of the partition list command (for the backed up Luna SA partition) is different than the value displayed in the Used column in the output of the token backup partition list command (for the backup partition on the Backup HSM).
The 50 Partitions Capability Upgrade and the 100 Partitions Capability Upgrade are provided in the form of CUFs (capability update files) that can be applied to a Luna Backup HSM connected to your workstation, in the same fashion as upgrades are applied to an installed Luna PCI-E HSM or to a USB-connected Luna G5 HSM.
The 50 Partitions Capability Upgrade and the 100 Partitions Capability Upgrade are provided in the form of a secure package (.spkg file) that can be uploaded (via scp or pscp) for processing by Luna SA to upgrade Luna SA HSM partition limit, or to upgrade the partition limit of a Luna Backup HSM connected directly to the Luna SA appliance for local backup.
When your Luna Backup HSM is connected locally to a Luna SA appliance, use the upgrade instructions at "Applying Luna HSM Capability Upgrades" to apply an upgrade to increase the number of HSM partitions that can be backed up to the device.
If the target partition exists on the Backup HSM, then it must already share its partition domain with the source partition.
If the target partition is being created, then it takes the domain of the source partition.
Multiple partitions, with different domains, can exist on a single Backup HSM.
As with backup operations, restore operations can take place only where the source and target partitions have the same domain.
•Full/replace backup or restore creates a new target partition with the same domain as the source partition.
•Partial (additive/incremental) backup or restore requires the existing source and target partitions to have the same domain before the operation can start.
No cross-domain copying (backup or restore) is possible - there is no way to "mix and match" objects from different domains.
The Backup HSM creates a partition with matching authentication type to the Luna HSM partition that is being backed up. That does not work in the opposite direction, however. The Backup HSM can restore a partition (or contents of a partition) only to a Luna HSM of matching authentication type.
You cannot mix partition authentication types on one backup device. That is, if you have a PED-authenticated HSM and a Password-authenticated HSM, you require two Backup HSMs in order to have a backup of each HSM's partitions. There is no possibility of backing up data from a higher-security device (Trusted Path, PED-authenticated, FIPS-3) onto a lower-security device (Password protected, FIPS-2). Normally this is not a concern because a given installation is likely to employ all Luna HSMs of the same authentication type.
However, for HSMs of the same authentication type, you could backup (or restore) partitions from different HSMs onto a single Luna Remote Backup HSM, as long as there is sufficient room. Given that the type matches, the authentication (domain) is handled at the partition level.
The Luna Remote Backup HSM supports local or remote HSM backup. The options for backup of primary/source Luna HSMs are:
•Local backup of any Luna HSM, where all components are co-located. This is a possible scenario with all Luna HSMs, but is more likely with direct-connect, local-to-the-client HSMs such as Luna PCI-E. It is unlikely for Luna SA, simply because Luna SA normally resides in a server rack, distant from its administrators.
•Local backup of Luna SA, where Luna SA is located remotely from a computer that has the Luna Backup HSM. This is one of the likely scenarios with Luna SA, but requires that the administrator performing backup must have client authentication access to all Luna SA partitions.
•Remote backup of any Luna HSM, where the Luna HSM is located remotely from the computer that has the Luna Backup HSM. This scenario requires that the administrator of the Luna Backup HSM's host computer must connect (via SSH or RDP) to the clients of each HSM partition that is to be backed up. The client performs the backup (or restore) under remote direction.
In local mode, you connect the Backup HSM directly, via USB, to a Luna SA appliance or Luna PCI-E host server. That is, local backup is local to the HSM being backed-up, not necessarily local to the administrator who is directing the process, who might be far away.
For remote backup, you connect the Backup HSM via USB to a computer running vtl and the driver for the device. Backup and restore are then performed over the secure network connection. For PED-authenticated HSMs, you must have a copy of the appropriate red (domain) PED Keys to use with the Backup HSM in order to perform the copy/cloning (backup and restore) operation between the HSMs.
The simplest way to backup your Luna SA is to connect the Backup HSM directly to the Luna SA appliance. To perform a backup/restore, you open an SSH or serial connection from your workstation to the appliance, and then launch LunaSH in a terminal session to perform the backup, as illustrated in the following figure:
The workstation is simply a display terminal for LunaSH running on the appliance. It does not require the Luna client software.
The PEDs are required only if the Luna SA is PED-authenticated. The appropriate SO (blue), partition (black) and domain (red) PED keys are required.
The following diagram depicts the elements and connections of the local backup (and restore) operation, where everything is in one room.
| 1 | LunaCM on the client (host) system sees the primary and backup slots and controls the backup/restore operation. |
|---|---|
| 2 | Backup HSM is a slot visible to the client (host) system when it runs LunaCM. |
| 3 | Working HSMs are slots visible to the client (host) system when it runs LunaCM. |
| 4 | Every slot on the backup must have same domain (red PED Key) as matching slot on the primary HSMs. |
The other two backup and restore options, local backup of a distant Luna SA and remote backup of any Luna HSM require that PED operations be performed remotely. For that reason, HSMs must be prepared (locally) in advance by having orange Remote PED Keys created and matched with each HSM.
The diagram below summarizes the elements and setup for backing up partitions of a remote Luna SA HSM to a Backup HSM that is attached to the local host. For this example, the system administrator (admin) for the Luna SA appliance is also the person doing the backup. The local host is configured as follows:
•the Luna client software with the Remote PED options is installed.
•a Remote Luna PED is connected.
•the Luna Backup HSM is connected.
Before performing a backup, the admin must open an SSH session to the Luna SA appliance and perform a certificate exchange and registration for each Luna SA partition to be backed up to make the local host a client of the partitions.
| 1 | The admin must have client access to each partition being backed up. In this scenario, the admin must have black PED Keys and passwords for the partitions. |
|---|---|
| 2 | The local host is used to control the backup/restore. The Luna client vtl software is used to generate and trade certificates with Luna SA, to create an NTLS link. The Luna PEDServer software running on the local host, in conjunction with the PEDClient software running on the Luna SA, provides remote PED access to the Luna SA. |
| 3 | The local host can see the Luna SA partitions as slots in LunaCM. The Luna PEDClient software runs on the Luna SA when it needs to access the Remote PED via the Luna PEDServer software running on the local host. |
| 4 | Every slot on the Backup HSM must have same domain (red PED Key) as the matching slot on the working HSM. The domain (red) PED Keys can be different for each partition or they can share one common domain, re-used for all partitions. The important consideration is that whatever domain situation exists on the primary HSM must be matched on the Backup HSM. |
| 5 | The local host can see the Backup HSM as a slot in LunaCM. Because the local host views the backup/restore operation in this scenario as a local transaction, between two slots visible to LunaCM on the local host, the remote backup service (RBS) is not needed. |
This scenario avoids the complication of an intermediary computer (as would be needed for true remote backup), but at the cost of giving the authentication keys for all client partitions to an administrator. Your security protocol determines whether this is acceptable.
This section describes how to backup a remote HSM to a Backup HSM that is connected over the network to a remote host. In this configuration, you require an orange PED key, imprinted with the Remote PED Vector (RPV) for the HSM you want to back up. To create the orange PED key, you must temporarily connect a PED directly to the HSM you want to back up, as illustrated in the following figure. The figure shows a local admin session to the HSM. You could administer remotely, but this operation nevertheless requires a local PED connection to the HSM and someone there to insert PED Keys and press buttons on the PED keypad, so we depict the most likely connection situation - one person doing all jobs at one location. Once the HSM has been matched to an orange Remote PED Key, all future authentications can be performed with Remote PED, and the HSM can safely be shipped to its distant location.
Figure 1: Creating an orange PED key imprinted with the remote PED vector (RPV) for the HSM
After you have created the orange (RPV) PED Key and have the appropriate red (domain) PED keys for the partitions you want to back up, you are ready to configure and use your Remote Backup HSM. In this scenario, you could have as many as three different computers (we depict two for our example) connecting to the Luna SA:
•one to run the ssh administrative connection to Luna Shell (lunash:>) on the Luna SA appliance
•one to run the Remote PED server, with the Luna PED2 (in remote mode) connected via USB to the computer and separately connected to the mains electrical power source
•one to run a client session with vtl and the Luna Remote Backup driver, and with the Luna Remote Backup HSM with its own local Luna PED attached
As noted previously, the orange PED Keys contain a Remote PED Vector (RPV) that matches the RPV inside the Luna SA HSM. It is the presence of that RPV at both ends that allows the connection to be made between the HSM and the Remote PED. At the same time, the Luna SA and the Luna Remote Backup HSM must share the same cloning domain, in order for backup and restore (cloning) operations to take place between the two HSMs. Therefore, red PED Keys with that cloning domain must be available.
As of Luna HSM 5.2, Luna HSMs use Remote Backup Service (RBS) to facilitate Remote Backup. Where formerly we ran the remote backup from the "vtl" utility, we now use vtl only for the certificate exchange that makes a computer a client of a distant Luna SA partition.
LunaCM is required on both the Client (Host) System and on the System Admin computer, but is run on Client (Host) System to launch and manage the backup and restore activity. PEDClient is needed on both the Client (Host) System and the System Admin computer, as well as on any Luna SA.
PedClient is needed on any host that must reach out to a pedserver instance and a Remote PED. PedClient instances can also communicate with each other to facilitate RBS
PedServer must reside (and run, waiting for calls) on any computer connected to a Remote PED.
RBS is required on the computer connected to the Luna Remote Backup HSM. RBS is not needed on any other computer in the scenario.
The following figure provides an example configuration for backing up a remote HSM to a backup HSM connected to a remote host. This scenario adds an intermediate computer (Client (Host) System) to broker the remote backup of the HSM partitions. That could be a special-purpose computer, or it could simply mean that the Admin on the computer with the Remote Backup HSM is given remote access to each client that normally uses a Luna HSM partition.The tradeoff is that those clients already have access to their registered partitions, so there is no need for the Remote Backup HSM admin to have client access (PED Keys) for those partitions. Your security protocol dictates which scenario is appropriate for you.
Figure 2: Configuration for backing up a remote HSM to a backup HSM connected to a remote host
| 1 | "Client (Host) System" (1a) is a client of the Luna SA being backed up, but "System Admin" (1b) is not a client of Luna SA. |
|---|---|
| 2 | LunaCM on "Client (Host) System" (2a) sees the primary (2b) and backup (2c) slots and controls the backup/restore. |
| 3 | Each Luna SA (3a) partition is a slot visible to a "Client (Host) System" (3b) when Client (Host) System runs LunaCM. |
| 4 | Every slot on the backup (4a) must have same domain (red PED Key) as matching slot on the primary HSMs (4b). |
| 5 | Every primary HSM slot (partition) that is to be backed up or restored must be in login or activated state (black PED Keys (5)), so that the Client (Host) System can access it with LunaCM backup or restore commands. |
| 6 | Backup HSM (6a) is a slot visible to "Client (Host) System" (6b) when Client (Host) System runs LunaCM. |