Administration and Client Users

From a wide security and cryptographic perspective, a general view of Luna SA might consider ranges of operation and access, such as:

Within the client and administrative ranges, Luna SA recognizes additional useful distinctions. Luna SA recognizes 3 types of Administrative users, with each type of user possessing different access privileges and able to perform different actions on Luna SA. Those administrative users are:

When the owner of the individual partition has given permission for the partition to accept client connections (partition activate) your client can connect and authenticate to have full Client access to its registered HSM Partitions (virtual HSMs on Luna SA).

Each Administrative user plays a different role in the administration of Luna SA. Depending on your organization and security policy, one person may perform only one role, or possibly perform multiple roles. It is also possible to have multiple people sharing one role. It is important to develop a comprehensive administrative policy before establishing Administrative users - some roles cannot be revoked without re-initializing an HSM Partition or the entire HSM and deleting all data on it.

Administrative commands for Luna SA can be issued only from the lunash command line.

One “admin” account exists per Luna SA to perform administration and configuration of the Luna SA system. Some examples of the types of tasks that the Admin performs are:

When the admin logs into the HSM appliance, the lunash command line interface becomes available.

The admin account can see the full set of lunash commands, and can directly invoke the general and network-related command subsets. However, admin requires the additional authentication of the HSM Admin (next section) to perform HSM administration functions, such as creating HSM Partitions or creating NTLs. That is, lunash refuses to perform the subset of commands devoted to HSM administration until the HSM Admin is also logged in.

If the "admin" identity has more capability than you wish to give to certain persons or roles in your organization, then two other pre-defined roles or identities exist having subsets of "admin" access.

The Operator identity has access to all lunash commands except the HSM Security Officer commands. Thus the Operator can both view and maintain the network, service, logging, and other aspects of the Luna SA appliance. The admin can set an Operator password if desired.

The Monitor role is a very limited subset of the system "admin" user. In the most likely scenario, it would be an automated function on an unattended PC. That computer would open an ssh session to the Luna SA appliance, and log in as "Monitor". The Monitor would have access only to the various "show" commands in lunash ( ntls show, network show, etc).

The Monitor computer would run timed, scripted sets of "show" commands and parse the results, looking for specific error or warning conditions on the given Luna SA Server. When a triggering condition was revealed by the output of a "show" command, the Monitor computer would perform its scripted responses - such as sending an e-mail or other message to a live administrator, for appropriate action. The admin can set an Monitor password if desired.

There is one “HSM Admin” account per HSM to perform all activities related to the configuration and management of the HSM appliance's onboard HSM, including creating/deleting HSM Partitions, and creating/deleting Network Trust Links (NTL).

Your security procedures may provide for a separate HSM Admin role, or you may have one person functioning as both HSM Admin and Owner.

The HSM Admin (or SO) is an additional capability layer, assumed when needed by the HSM appliance's system “admin”. That is, the system administration account, admin, must be logged in (that is, the lunash command line must be available) before the HSM Admin (or SO) can log in. You can log in and perform system maintenance functions as admin, without logging in as HSM Admin, but you cannot log in as HSM Admin without first being logged in as admin (the lunash prompt).

You may choose to have the HSM Admin authentication held by someone other than the appliance system admin, but the HSM Admin must either know the admin password or have the cooperation of admin to reach the lunash system prompt.

For HSM with Password Authentication, the HSM Admin logs in/authenticates with a password.

For HSM with Trusted Path Authentication, the HSM Admin must connect a PED to the HSM appliance, and must authenticate by presenting the proper blue PED Key.

There is one Owner account per HSM Partition on Luna SA with PED (Trusted Path) Authentication; however, one Owner may 'own' multiple HSM Partitions. As the name implies, the Owner 'owns' a specific HSM Partition. The Owner is required to administer specific items contained within HSM Partitions, including:

The HSM Partition Owner is an additional capability layer, assumed when needed by the HSM appliance system admin. That is, the system admin account must be logged in before the HSM Partition Owner can login. You can log in and perform system maintenance functions as admin, without logging in as HSM Partition Owner, but you cannot log in as HSM Partition Owner without first being logged in as admin (at the lunash prompt).

You may choose to have the Owner authentication held by someone other than the regular HSM appliance system admin, but the Owner must either know the admin password or have the cooperation of admin to reach the lunash system prompt.

On HSMs with Password Authentication, the owner of a Partition is the Client who has the Password. The concept of an Owner entity, separate from the Client, does not apply. This contrasts with the HSM with PED (Trusted Path) Authentication, where the Partition Owner (holder of the black PED Key) has administrative access to a partition, independent of the access granted by the Client Password.

There is at least one Client per HSM Partition. The Client user allows a Client system to access and use the contents of a specific HSM Partition and perform operations with the contents of a specific HSM partition, such as digitally signing a file.

For HSMs with Password Authentication, the password that gives a Client access to a Partition is the same as the password that gives administrative access to the Partition.

The only safeguard that prevents any Client from performing Partition administration functions is the need to log in to lunash as admin to issue the commands.

For HSMs with PED (Trusted Path) Authentication, the Client accesses a Partition by presenting the Partition Password. However, that access is possible only if the Partition Owner has placed the Partition in the Activated state.

The Partition Owner accesses the Partition by logging in to the lunash command shell as the appliance admin, and then presenting the black Partition Owner's PED Key.

Thus, for HSMs with PED (Trusted Path) Authentication there are two barriers to achieving administrative access to a Partition:

the requirement to first login as admin,
the requirement to authenticate as Owner by presenting the black PED Key.