|
Home > |
Appliance Administration Guide > Configuration without One-step NTLS > [Step 1] Planning Your Configuration > Domain Planning
|
|---|
The cloning domain is a special-purpose secret that is attached to a partition on an HSM. It determines to which, and from which, other partitions (on the same HSM or on other HSMs) the current partition can clone objects. Partitions that send or receive partition objects by means of the cloning protocol must share identical cloning domain secrets. This is important for:
• cloning in backup and restore operations and
•synchronization in HA groups.
There is no provision to clone between an application partition and an HSM administrative partition, but you can apply the same domain secret for ease of administration. Password authenticated application partitions can clone partition contents one to the other, and PED authenticated application partitions can clone partition contents one to the other, but password authenticated HSMs (and their partitions) cannot perform cloning with PED-authenticated HSMs (and their partitions).
| Cloning source | Cloning target | |||||
|---|---|---|---|---|---|---|
| HSM Administrator partition A, cloning domain A | HSM Administrator partition B, cloning domain B | application partition 1, cloning domain A | application partition 1, cloning domain B | application partition 2, cloning domain A | application partition 2, cloning domain B | |
| HSM Administrator partition A, cloning domain A | management objects | cannot clone domains not matched |
N/A | N/A | N/A | N/A |
| HSM Administrator partition B, cloning domain B | cannot clone domains not matched |
management objects | N/A | N/A | N/A | N/A |
| application partition 1, cloning domain A | N/A | N/A | yes (usually backup and restore) | |||
| application partition 1, cloning domain B | N/A | N/A | cannot clone domains not matched |
yes (usually backup and restore) | ||
| application partition 2, cloning domain A | N/A | N/A | yes (usually backup and restore) | |||
| application partition 2, cloning domain B | N/A | N/A | yes (usually backup and restore) | |||
Password authenticated HSMs have text-string cloning domains for the HSM SO space and for any partitions that are created on the HSM. HSM and Partition domains are typed at the command line of the host computer, when required. Password authentication cloning domains are created by you.
PED authenticated cloning domains are created by a SafeNet HSM, which could be the current HSM, or it could be a previously initialized HSM that you wish to be in a cloning group with the current HSM.
PED authenticated HSMs have cloning domains in the form of encrypted secrets on red PED Keys, for the HSM SO space and for any partitions that are created on the HSM. The following characteristics are common to domains on all SafeNet HSMs.
•The HSM SO-space domain can be created at the HSM (therefore unique) at HSM initialization time, or it can be imported, meaning that it is shared with one-or-more other HSMs.
•The application partition domain can be created by the current HSM at partition creation time for legacy-style partitions or Partition SO role-creation time for PPSO partitions (therefore making it unique), or it can be imported, meaning that it is shared with one-or-more other HSM partitions.
•The application partition domain can be the same as the HSM SO domain or can differ.
–For legacy-style partitions, where the HSM Administrator or Security Officer is also the SO of the application partition, it is appropriate to have the same domain for the HSM and for the partition(s).
–For PPSO partitions, where the role of Security Officer for the application partition is deliberately separate from the role of HSM SO, it is appropriate that the HSM cloning domain and the application partition cloning domain would be different, and controlled by different people.
•The application partition domain can be the same as the domain of another partition on the same HSM (for HSMs that support multiple partitions) or can differ.
For PED authenticated HSMs, the domain secret for the SO space or for an application partition can be a single red PED Key, or it can be split (by the MofN feature) over several red keys, which are then distributed among trusted personnel such that no single person is able to provide the cloning domain without oversight from other trusted personnel.
In scenarios where multiple HSM partitions are in use, it can be useful to segregate those partitions according to department or business unit, or according to function groups within your organization. This ensures that personnel in a given group are able to clone or backup/restore only the contents of partitions sharing the domain for which they are responsible. Other functional groups, even with access to the same SafeNet HSM hardware have cloning or backup/restore access to their own domain partitions, but not to those of the first group... and vice-versa.
For Password authenticated HSMs, that sort of segregation is maintained entirely by procedure and by trust, as you rely on personnel not to share the domain text strings, just as you rely on them not to share other passwords.
For PED authenticated HSMs, the segregation is maintained by physical and procedural control of the relevant PED Keys that each group is allowed to handle.
It can pay to pre-plan how you will divide and assign access to HSM SO space and Partitions. Cloning Domain is one aspect of such access. There is rarely much call to store objects on the SO space, so the SO function is normally purely administrative oversight, and the decisions are straightforward. Each SO takes care of just her/his own HSM, or each SO can have oversight of multiple HSMs.
Partition access can also be straightforward, if you have no particular need to segregate access by groups or by functions or by geography or other descriptors. But, because partitions contain the working keys, certificates, and objects that are used in your business, it is more likely that some scheme must be devised and maintained to control who can do what with each HSM partition. Also, as mentioned previously, you might wish to spread out and reinforce responsibility by using MofN to ensure that administrative partition access can never be achieved by a single person operating alone. These considerations require that you plan how access controls are to be implemented and tracked, because the decisions must be made before you create the partitions.
Have your naming conventions and allotments planned out ahead of HSM initialization and partition creation, including a well-thought-out map of who should control cloning domain access for HSM SO spaces and for application partitions.