CHAPTER 1 Planning Your Configuration
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 Partitions.
Luna PED Planning
Plan your PED Key options and choices before you begin the actions that will invoke PED Keys.
The various PED Keys contain secrets that are created by an HSM, and are imprinted on the PED Key at the time that
a triggering action is called - for example,both the HSM and a blue SO PED Key are imprinted with the HSM SO secret
at the time the HSM is initialized. With the exception of the purple SRK PED Key, all of the other PED Key types can
take a newly-created secret that is unique in the world at the time the HSM creates it.
Optionally, the PED dialog allows you to present a key with an existing secret (of the appropriate type for the current
action) that was previously created by this HSM or by some other HSM. In that second case, the secret from the key is
imprinted on the HSM, and that key can now unlock its function (example: allow the SO to log in) on both the previous
HSM and the current HSM. This can be repeated for any number of HSMs that you wish accessible by the one secret.
What each PED prompt means
Some questions/prompts from the PED when any key/access secret is first invoked are:
Reuse
- do you wish to have the current HSM generate this secret, and imprint it on the PED Key (the "No" or do not
reuse option), or do you wish to accept a secret (of the correct type) from the currently inserted PED Key, and imprint
that secret onto the current HSM, making that secret common for this HSM and any others that recognize the same
PED Key (the "Yes" or do reuse option)?
The decision is: do you wish this HSM to be accessed by the same secret that accesses this function/role on one or
more other HSMs? Or do you wish this HSM to have a new, unique secret that is recognized by no previous HSM.
Sometimes, it is advantageous to have a single secret for a group of HSMs managed by a single person. Sometimes,
security or operational rules require that each HSM must have a different secret (for the role being configured).
The option to reuse an existing secret applies only within the same type of secret, so for example you cannot tell a
partition to accept a secret from a blue SO PED Key. At partition creation, a partition must be imprinted either with a
unique new key that also goes on a PED Key, or with a secret from an already-imprinted black PED Key.
The only exception, among the various PED Keys is the purple SRK PED Key, each of which is unique to its own
HSM. No HSM can accept an SRV (the secret on the SRK) from outside. Each HSM creates its own.
M of N
- do you wish to split the current secret over quantity N same-color PED Keys, such that quantity M of them will
always be needed to assemble the full secret and authenticate that role? You invoke M of N by providing the M value
and the N value using the PED Keypad, when prompted. You refuse M of N by setting the M value and the N value both
to "1". M of N is the more secure choice, when you require multiple persons to be present (with their splits of the role
secret) in order to access that role and perform its functions. No M of N is the more convenient choice, as only one
secret-carrying key must be carried and tracked, per role.
Overwrite
- during create/initialize/imprint events, when the PED has received answers to its preliminary questions, it
prompts you to insert a key and press [Enter] on the keypad. This is the first point at which it actually looks at the
inserted key. The PED then tells you what is on the inserted key (could be blank, could be any of several authentication
secrets) and asks if you wish to overwrite. This is an opportunity to reconsider the key that you have inserted, before
something irreversible happens. You can say "No" (don't overwrite what was found ), remove the key, and go back to
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc. All rights reserved.
16
Содержание Luna SA
Страница 1: ...Luna SA Configuration Guide ...
