|
Home > |
|---|
SafeNet Luna HSM products offer multiple identities, some mandatory, some optional, that you can invoke in different ways to map to roles and functions in your organization.
The following topics offer some aspects that you might wish to consider before committing to an HSM configuration:
•Named Administrative Users and Their Assigned Roles
•Custom NTLS Registration Role
•Implications of Backup and Restore of User Profiles
•Security of Shell User Accounts
By default, the appliance has:
• One 'admin' user, with role "admin", always enabled, default password "PASSWORD"
•One 'operator' user, with role "operator", disabled until you enable, default password "PASSWORD"
•One 'monitor' user, with role "monitor", disabled until you enable, default password "PASSWORD"
•One 'audit' user, with role "audit", disabled until you enable, default password "PASSWORD"
Those four built-in accounts can be neither created nor destroyed, but 'admin' can enable or disable the others as needed. For a list of commands accessible to the default user roles, see LunaSH Command Summary in the LunaSH Command Reference Guide.
You can leave the default arrangement as-is, or you can create additional users with names of your own choice, and assign them any of the roles (and the powers that go with those roles). The default password of any created user is "PASSWORD" (all uppercase).
Thus, you could choose to have:
•Multiple admin-level users, each with a different name, that can perform most actions that the original admin can perform.
•Multiple operator-level users (or none, if you prefer), each with a different name, that have access to a reduced set of administrative commands.
•Multiple monitor-level users (or none, if you prefer), each with a different name, that are restricted to using commands that view, list or show.
•Multiple audit-level users (or none, if you prefer), each with a different name, that are restricted to HSM audit logging functions. See Audit Logging for more information on this specialized role.
Administrative users' names can be 1-32 characters, chosen from letters a-z, or A-Z, numbers 0-9, the dash, the dot, or the underscore.
No spaces are allowed. Creating a user name that begins with a number, dot, or dash is not recommended.
As with any secure system, no two users (regardless of role) can have the same name.
One reason for creating multiple named users would be for the purpose of distinguishing individual persons' activities in the logs.
For example, a user named 'john' running the LunaSH syslog tail command would show in the April 13 log as:
Apr 13 14:17:15 172 -lunash: Command: syslog tail : john : 192.20.10.133/3107
Command Result : 0 (Success)
Perhaps you have people performing similar functions at physically separate locations, or you might have staff assigned to teams or shifts for 24-hour coverage. It could be valuable (or required by your security auditors) to know and be able to show which specific person performed which actions on the system.
Named roles can be customized to have access to a specific subset of commands, allowing unique task delegation that suits organizational needs.
The custom role is defined by a list of the LunaSH commands that it can run. The role can be applied to and removed from any existing user to give them access to only the commands they require for a particular operation. This ensures that a given user does not obtain access beyond their security clearance. See LunaSH Command Summary in the LunaSH Command Reference Guide for a list of commands.
To import, add, or remove a custom user role to your HSM and its users, see the following commands in the LunaSH Command Reference Guide:
Role names can be 1-64 characters, chosen from letters a-z, or A-Z, numbers 0-9, the dash, the dot, or the underscore.
No spaces are allowed. User names cannot start with a dot or dash. Creating a role name that begins with a number is not recommended.
As with any secure system, no two roles can have the same name.
1.Create a text file on your local workstation that lists each command that you want the role to be able to access (the role definition file).
Note: All lines must end with a UNIX-style linefeed (lf) character. If you create your file in Windows, be sure to convert it to use UNIX line endings before transferring it to an HSM appliance.
2. Transfer the role definition file to the appliance using pscp (Windows) or scp (Linux/UNIX). You require the SafeNet Luna Network HSM appliance admin password to complete this step. The file is automatically placed in the appropriate directory on the appliance. Do not specify a target directory.
| Windows |
Syntax: pscp [options] <source_filename> <user>@<host>:[<target_filename>] Example:To copy the role definitionfile (myrole.txt) to the myLuna appliance, keeping the same name: pscp myrole.txt admin@myLuna: |
| Linux/UNIX |
Syntax:scp [options] <source_filename> <user>@<host>:[<target_filename>] Example: To copy the role definition file (myrole.txt) to the appliance with IP 192.168.0.123, keeping the same name: scp myrole.txt admin@192.168.0.123: |
3.Log into the appliance as the admin user.
4.Import the role definition file to create the role able to access the commands it lists:
lunash:> user role import -file <filename> -role <rolename>
5.Create the user account that you want to assign the role to, if it does not already exist:
lunash:> user add -username <username>
6.Assign the role to a user:
lunash:> user role add -username <username> -role <rolename>
For example, if you wanted the user "Alex" to be able to perform backup operations on your HSM but not restore operations, you would create a role definition file including backup commands and not including restore commands. Then you would import the file to your HSM:
lunash:>user role import -file backuprolefile -role backup
"backuprolefile" was successfully imported.
Command Result : 0 (Success)
After your file has been successfully imported, you can assign the role it defines to the user "Alex":
lunash:>user role add -username Alex -role backup
User Alex was successfully modified.
Command Result : 0 (Success)
Creating NTLS links between a client and partition using the one-step method (see Create a Network Trust Link - One-Step Setup in the Configuration Guide) usually requires administrative access to the SafeNet Luna Network HSM appliance. You can set up a custom role that allows a third party to use only the commands necessary for one-step NTLS.
1.Create a role definition .txt file on your local workstation, listing the following commands:
scp
partition list
client list
client register
client assignPartition
Note: All lines must end with a UNIX-style linefeed (lf) character. If you create your file in Windows, be sure to convert it to use UNIX line endings before transferring it to an HSM appliance.
These are the commands necessary for creating one-step NTLS links. You can include any other commands for your registration purposes. See client in the LunaSH Command Reference Guide for the complete set of client commands.
2.Transfer the role definition file (registerclient.txt in the example below) to the appliance using pscp (Windows) or scp (Linux/UNIX).
| Windows |
pscp registerclient.txt admin@<server_host/IP>: pscp registerclient.txt admin@192.168.0.123: |
| Linux/UNIX |
scp registerclient.txt admin@<server_host/IP>: scp registerclient.txt admin@192.168.0.123: |
3.Log into the appliance by SSH as the admin user.
4.Import the role definition file to create the "registerclient" role:
lunash:> user role import -file registerclient.txt -role registerclient
5.Create the "register" user account:
lunash:> user add -username register
6.Assign the role to the "register" user:
lunash:> user role add -username register -role registerclient
7.Open a new SSH connection to the appliance and login as "register" with the default password of PASSWORD:
login as: register
register@192.168.0.123's password:
You will be prompted to set a new password for the "register" user. This will be the password you provide to the third-party client. Ensure it is both secure and distinct from the "admin" user password.
8.NTLS links require access to the appliance's Server Certificate file (server.pem). Custom users do not automatically have access to the certificate, so you must transfer it from the "admin" user files to the "register" user files with pscp (Windows) or scp (Linux/UNIX). Enter the "admin" and "register" passwords when prompted:
| Windows |
pscp admin@<server_host/IP>:server.pem . pscp admin@192.168.0.123:server.pem . pscp server.pem register@<server_host/IP>: pscp server.pem register@192.168.0.123: register@192.168.0.123's password: server.pem | 1 kB | 1.1 kB/s | ETA: 00:00:00 | 100% |
|
Linux/UNIX |
scp admin@<server_host/IP>:server.pem . scp admin@192.168.0.123:server.pem . scp server.pem register@<server_host/IP>: scp server.pem register@192.168.0.123: register@192.168.0.123's password: server.pem | 1 kB | 1.1 kB/s | ETA: 00:00:00 | 100% |
Note: You will have to repeat this step anytime you regenerate the certificate with sysconf regencert.
9.Provide the "register" password and the partition name to the client operator. The client can now establish a one-step NTLS connection by specifying the "register" user and password in LunaCM:
lunacm:> clientconfig deploy -server <server_host/IP> -client <client_host/IP> -partition <name> -user register
See clientconfig deploy for full command syntax.
The commands sysconf config backup and sysconf config restore allow you to store a snapshot of the administrative user database (the names and status of all named LunaSH users) that can later be restored if desired.
CAUTION: Restoring from backup restores the database of user profiles that existed before the backup was made. This includes the set of users that existed when the backup was made, the passwords that users had at the time of the backup, and the enabled/disabled status of users at the time of the backup. You will lose any user accounts created since the backup; passwords of existing users could be reverted without their knowledge; enabled users might be disabled (therefore unable to perform their tasks); disabled users might be enabled (therefore re-granted access that was suspended); any user accounts removed since that backup will be restored.
Your records should indicate when user-profile changes were made, and what those changes were. Any time you restore a backup, be sure to reconcile the changed statuses and inform anyone who is affected. For example, users need to know to use their previous password, and to change it immediately.
Note: While the built-in 'admin', 'operator', and 'monitor' accounts are not deleted or added by a restore operation (those accounts are permanent), both their enabled/disabled status and their passwords are changed to whatever prevailed at the time the backup was originally taken.
Both the SafeNet Luna Network HSM appliance and any computers that make network connections for administrative purposes should reside inside your organization's secure premises, behind well-maintained firewalls. Site-to-site connections should be undertaken via VPN, and attacks on the shell account(s) is not normally an issue.
However, if your application requires placing the SafeNet appliance in an exposed position (e.g., the DMZ and beyond), your shell account(s) may be vulnerable to attackers. It is your responsibility to ensure that you protect your sensitive data.
Some recommendations for enhancing your security include using strong passwords, changing the SSH port number from its default to something unconventional, or using certificate-based authentication.