CHAPTER 1 Planning Your Configuration
Bad Login Attempts
By default, both the Crypto Officer and the Crypto user can make 10 consecutive failed login attempts before invoking
consequences. That is, the two bad-authentication counters are independent of each other.
Submissions of incorrect Partition Passwords (or Crypto Officer and Crypto User Passwords) are not counted as
incorrect black PED Key attempts.
Note:
The Luna HSM must actually receive some information before it logs a failed attempt, so
if you merely forget to insert a PED Key, or provide a wrong-color key, then that is not logged as
a failed attempt. When you successfully login, the bad-attempt counter is reset to zero.
Domain Planning
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.
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 Luna HSMs.
•
The HSM SO-space domain can be created at the HSM (therefore unique) at HSM init time, or it can be imported,
meaning that it is shared with one-or-more other HSMs.
•
The HSM partition domain can be created at the HSM (therefore unique) at partition creation time, or it can be
imported, meaning that it is shared with one-or-more other HSM partitions.
•
The partition domain can be the same as the HSM SO domain or different.
•
The partition domain can be the same as the domain of another partition on the same HSM (for HSMs that support
multiple partitions) or different.
For PED authenticated HSMs, the domain secret for the SO space or for a 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 Luna 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
Luna SA Configuration Guide
Release 5.4.1 007-011136-007 Rev C July 2014 Copyright 2014 SafeNet, Inc. All rights reserved.
15
Содержание Luna SA
Страница 1: ...Luna SA Configuration Guide ...
