|
Home > |
|---|
SafeNet Network HSM offers administrative roles external to the contained HSM, to oversee the management of the appliance that hosts the HSM, including network setup, system monitoring, and other tasks. Such roles are
For the SafeNet Network HSM networked-appliance HSM, the roles fall under two main hierarchies:
•roles to access the appliance that contains the HSM and that provides the network connectivity; these are accessed through SSH or local serial connection, via the Luna Shell or "lunash" command line, and include
–the highest-level, full-access administrative role, called 'admin'
–the medium-level operational administrative role, called 'operator', and
–the lowest-level observation-only administrative role, called 'monitor'
•roles that access the HSM, described in HSM Roles and Secrets
Within the SafeNet appliance, those appliance-level and HSM-level roles interact, where the access level of the role that is currently logged into the appliance, and using Luna Shell (lunash), sees either the full set or a subset of HSM-using commands.
Thus, someone logged into the appliance as 'monitor' can see only reporting-type commands for the appliance (commands that show lists and status of subsystems), and can see only reporting-type commands for the HSM within the appliance.
Someone logged into the appliance as 'operator' can see and use most of the commands that the 'admin' user can access, at both the appliance and the HSM levels.
Someone logged into the appliance as 'admin' can see and use all possible commands affecting both the appliance and the contained HSM, including all commands that create and modify other roles, and that initialize the HSM.
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"
Those three "built-in" accounts can be neither created nor destroyed, but 'admin' can enable or disable the other two as needed.
You can leave that 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" (yes, all uppercase).
Thus, you could choose to have:
•multiple admin-level users, each with a different name,
•multiple operator-level users (or none, if you prefer), again each with a different name, and
•multiple monitor-level users (or none, if you prefer), each with a different name.
Administrative users' names can be a single character or as many as 128 characters, chosen from letters a-z, or A-Z, numbers 0-9, the dash, the dot, or the underscore. No spaces.
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._
As with any secure system, no two users (regardless of role) can have the same name.
Named users empowered with the "admin" role can perform most actions that the original admin can perform.
User accounts granted the "operator" role have access to a reduced set of administrative commands.
User accounts granted the "monitor" role can take no actions on the appliance or HSM, and are restricted to commands that view, list or show.
The commands available to the roles are listed in User Accounts and Their Privileges.
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 : 172.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.
You might find other uses. Please let us know.
In addition to the pre-defined users and roles, where specific, known combinations and exclusions of actions are conferred (described above), it is possible to define additional Custom Roles with precision. The Custom Roles feature endows each named role with exactly-and-only the specific list of commands that the role is allowed to access and use, and no more.
The lists defining Custom Roles are simple text files with one command per line, as follows:
•The file is created in any text editor that can ensure that each line ends in a UNIX-style linefeed (lf) character.
•The definition file is saved and named in a way that is sensible and practical in your situation, and includes each appliance or HSM command the role is allowed to use.
•The role definition is then uploaded to an administrative user on a SafeNet Network appliance.
•The role definition is imported into an existing named role (not one of the default system roles) with the user role import command.
•The role with its definition is then assigned to a named user (not one of the default system users) with the user role add command.
•If a command is on the definition list, it can be used by any named user to which the Custom Role is applied.
•If a command is not included in the list, the user cannot access or use it.
A role can be removed from a named user with the user role clear command.
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
- the enabled/disabled status of users, at the time of the backup.
This means that:
- 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 (therefor unable to perform their tasks)
- disabled users might be enabled (therefore re-granted access that was suspended) and
- any user accounts removed since that backup will be restored.
The first three could be administrative inconveniences. The fourth and fifth outcomes could be serious security issues.
Your records should indicate when user-profile changes were made, and what those changes were, so any time that 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.
In most cases anticipated by the design and target markets for SafeNet Network HSM, both the SafeNet Network HSM appliance and any computers that make network connections for administrative purposes, would reside inside your organization's secure premises, behind well-maintained firewalls. Site-to-site connections would be undertaken via VPN. Therefore, attacks on the shell account(s) would normally not be an issue.
However, if your application requires placing the SafeNet appliance in an exposed position (the DMZ and beyond), then please see About Connection Security in the Overview document for some additional thoughts.