User Access Control

The security of an HSM and its cryptographic contents depends on well-controlled access to that HSM. A controlled access policy is defined by:

>the set of users with valid login credentials for the appliance, the HSM and the application partition

>the actions each user is allowed to perform when logged in (the user's role)

For example, an access policy that adheres to the PKCS#11 standard requires two roles: the security officer (SO), who administers the user account(s), and the standard user, who performs cryptographic operations. When a user logs in to the HSM, they can perform only those functions that are permitted for their role.

Access to Luna Network HSM 7 is controlled through an enhanced version of the PKCS#11 hierarchy of roles, assigned to different users in your organization. Each role allows its user to execute a different set of commands to perform specialized tasks at one of the following levels:

Appliance-Level Users and Roles

Luna Network HSM 7 consists of an HSM inside a secure appliance with a hardened operating system (accessed via the LunaSH command-line interface). Administration of the appliance (including network setup, file management, and system logging) is considered separate from administration of the HSM and its cryptographic functions. This separation of duties is essential to a secure environment and it allows you to easily delegate responsibilities to personnel.

Although appliance-level roles are not security roles as defined in the PKCS#11 standard, they do provide an additional level of security by requiring that the user be logged in to the appliance before they can log in to the HSM.

When one of the default appliance roles is logged in to LunaSH on the appliance, only the commands available to that role are visible. A user with admin-level access can create custom user roles to limit access to specified commands and operations.

Table 1: Default Appliance Roles
Role Function
admin

>Can perform all administrative and configuration tasks on the appliance

>With the HSM Security Officer credential, can perform all HSM administrative tasks

>Activates other optional appliance roles and sets/resets their passwords

>Creates custom users and roles with access to a specified subset of commands

>Creates NTLS connections between the Luna Network HSM 7 appliance and Luna HSM Clients

operator

>Can perform administrative tasks on the appliance, except for some configuration tasks

>With the HSM Security Officer credential, can perform some basic HSM administration tasks

>Cannot execute any commands that affect other roles on the appliance

monitor

>Executes commands that present information about the appliance and HSM

>Cannot affect the state or contents of the appliance or HSM

audit

>Initializes the Auditor role on the HSM

>With the Auditor credential, manages HSM audit logging

Cluster Member Role Synchronization

Keyrings and their contents are synchronized across all members of the cluster, so any member can be queried by client applications for cryptographic operations. Appliance user accounts are also synchronized via the cluster, so users with admin, operator, and monitor privileges can log in to any member. In a cluster with two or more members, the users/roles configuration stored in the cluster are taken as the authority -- if an appliance with custom users/roles joins the cluster, they are overwritten by the users/roles stored in the cluster. This ensures that all cluster members have the same authorized users, and that those users can log in to any individual cluster member.

HSM/Crypto-Module-Level Roles

HSM roles are responsible for administration, configuration, and auditing of the cryptographic module within the Luna Network HSM 7 appliance. After logging in to LunaSH with the appropriate appliance-level role, you can access commands available to the HSM roles. HSM-level roles cannot perform cryptographic operations on the application partition.

Table 2: HSM Roles

HSM Security Officer (SO)

PED Key: Blue

>Initializes the HSM, creating the SO credential

>Creates/deletes the application partition

>Configures global HSM policies

>Performs updates of the HSM firmware and appliance software

>Must have admin-level access to the appliance to perform all HSM tasks

Auditor (AU)

PED Key: White

>Manages HSM audit logging

>Must have audit-level access to the appliance to perform auditing tasks

Partition-Level Roles

Partition-level roles are responsible for administration and configuration of the application partition, and using the partition to perform cryptographic functions. Partition roles log in using LunaCM, or supply their credentials via crypto applications. An application partition acts as its own virtual HSM, and has its own set of roles.

Table 3: Partition Roles

Partition Security Officer (PO)

PED Key: Blue

>Initializes the partition, creating the PO credential and setting the cloning domain

>Initializes the Crypto Officer role and can reset the CO credential (if permitted by HSM policy)

>Configures partition policies

Crypto Officer (CO)

PED Key: Black

>Creates and modifies cryptographic objects on the partition

>Manages backup and restore operations for the partition

>Performs cryptographic functions via user applications

>Creates and configures HA groups

>Initializes the Crypto User role and can reset the CU credential

Crypto User (CU)

PED Key: Gray

>Performs cryptographic functions via user applications (optional read-only role)

>Can create public objects only

>Can perform backup/restore of public objects on the partition

Keyring Roles

Each keyring has two roles that are analogous to the Partition Security Officer and Crypto Officer roles on a standard Luna partition. They are referred to here as:

>Keyring Security Officer (KRSO): initially set by the Partition Security Officer for the partition that created the cluster

>Keyring Crypto Officer (KRCO): performs cryptographic operations on the keyring

Unlike standard Luna partitions, role separation between the KRSO and KRCO roles is not enforced. Separation is enforced, however, between the keyring roles and the cluster security officer (PO of the partition where the cluster's SMK is stored).