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 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.
| 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
|
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 >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.
|
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 on a cluster 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 the PSO and CO roles on standard Luna partitions, the KRSO and KRCO roles on each keyring are intended to be held by the same individual, and use the same password. When the password for one role is changed, the change is applied to the other role as well. Consider this distinction when planning your cluster deployment and setting your KRSO passwords. Separation is enforced, however, between the keyring roles and the cluster security officer (PO of the partition where the cluster's SMK is stored).
