If you encounter problems with an HA group, refer to this section.
Administration Tasks on HA Groups
Do not attempt to run administrative tasks on an HA group virtual slot (such as altering partition policies). These virtual slots are intended for cryptographic operations only. It is not possible to use an HA group to make administrative changes to all partitions in the group simultaneously; the exception is partition changepw [for HA] from Luna HSM Client 10.6.1 onward.
Unique Object IDs (OUID)
If two applications using the same HA group modify the same object using different members, the object fingerprint might conflict.
Client-Side Limitations
New features or abilities, or new cryptographic mechanisms added by firmware update, or previously usable mechanisms that become restricted for security reasons, can have an impact on the working of an HA group, when the Luna HSM Clientversion is older. Luna Clients are "universal" in the sense that they are able to work fully with current Luna HSMs/partitions, and with earlier versions, as well as with cloud crypto solutions (DPoD Luna Cloud HSM service), but a client version cannot be aware of HSM versions that were not yet developed when the Client was released.
Client-Side Failures
Any failure of the client (such as operating system problems) that does not involve corruption or removal of files, should resolve itself when the client is rebooted.
If the client workstation seems to be working fine otherwise, but you have lost visibility of the HSMs in LunaCM or your client, try the following remedies:
>verify that the Thales drivers are running, and retry
>reboot the client workstation
>restore your client configuration from backup
>re-install Luna HSM Client and re-configure the HA group
For Luna PCIe HSM 7, the client is the HSM host. If HA has been working, any sudden failure is likely to be OS or driver related (restart) or file corruption (re-install). If a re-installation is necessary, you must recreate and reconfigure the HA group.
Avoid direct access to individual HA group members when securing with STC
Effect of Luna PED Operations
Luna PED operations can block some cryptographic operations, so that while a member of an HA group is performing a PED operation, it could appear to the HA group as a failed member. When the PED operation is complete, failover and recovery HA logic are invoked to return the member to normal operation.
Some security settings and implications
TIP Security Note -Cloning policies (0 and 4) permit or deny the ability to securely copy keys and objects into and out of a partition.
The Key Management Functions policy (28) controls the ability to create, delete, generate, derive, or modify cryptographic objects in the current partition.
These controls are independent of each other. With Key Management functions denied, you can still clone objects in and out of partitions where Cloning policy is allowed. Thus HA (high availability) operation can clone keys into a partition that disallows Key Management functions (creation, deletion, etc.). Cloning a key or object into a partition is not considered creation - the key or object already existed within the security / cloning domain that encompasses the partition.
Ultimately the security administrators define where keys can exist by controlling distribution of the security / cloning domain, and by defining policies around those keys.
Additionally, key owners can choose to make their keys non-modifiable and non-extractable, if those options are indicated by your use-case.
