HP NonStop Server Security

3

Authentication; User Administration

The joke goes that the only secure computer is the one without users. This section out-

lines the principles for securing the system, even with users! These principles include a

good user schema based on the principles of Least Privilege, Separation of Duties and

Individual Accountability.

User Administration

This chapter discusses administering userids and aliases on an HP NonStop server.

Userids

Users are defined by assigning a unique user name and number to each user:

<GroupName>.<MemberName>

<GroupNumber>,<MemberNumber>

The Group Name or Number identifies the user’s administrative group. The

Member Name or Number identifies the user within the group. The combination

must be unique for a single system and unique over the network of systems if the user

will have access to multiple nodes.

Groups

On the HP NonStop server, there are two types of user groups:

Administrative

File-sharing

81

Administrative Groups

Administrative Groups exist primarily for user management but can also be used for

file-sharing in Safeguard software . Administrative Groups are used in both the Guard-

ian and Safeguard environments.

Administrative Group Names are made up of 1 to 8 alphanumeric characters. The

first character must be a letter. Groups with numbers ranging from 0 to 255 may be

used as Administrative Groups.

Administrative Groups can be thought of as Job Function Groups because they are

the primary unit that categorizes a given user’s job function. Users with similar job

descriptions and tasks require the same access to system resources. They should be

given userids in the same Administrative Group.

File-sharing Groups

File-Sharing Groups can only be created in Safeguard software. They are used to grant

access to disk files and other objects on the system. They are used primarily in the OSS

environment and will be discussed in detail in the OSS Chapters.

Groups numbered above 255 exist solely for file-sharing purposes.

Members

Member Names are made up of 1 to 8 alphanumeric characters. The first character

must be a letter. Member Numbers must be between 0 and 255.

A secure system requires a well organized and well thought out userid schema.

Users must be given userids in appropriate administrative groups and uniquely identi-

fied to the system.

In general, userids can be broken down into two categories:

Personal IDs

Privileged IDs

Privileged IDs fall into 3 categories:

IDs with inherent Guardian privileges

Application Owner IDs

Job-Function IDs

Privileged IDs will be discussed later in this section.

82 User Administration

Aliases

Aliases are only available in Safeguard environments.

An alias is an alternate user name that can be used to log on to the system. Each

alias has its own Alias Authentication Record and set of user attributes. Users may be

assigned one or more aliases.

Alias names can contain between 1 and 32 alphanumeric characters. Some special

characters such as dots(.),hyphens(-)andunderscores(_)canalso be included in

alias names.

Unlike userids, which TACL automatically upshifts, aliases are case sensitive.

AP-ADVICE-ALIAS-01 Use good naming conventions when creating aliases.

If a two or three character job-function descriptor is used at the beginning of

each alias name, researching alias configuration and audit activity is easier.

AP-ADVICE-ALIAS-02 Don’t create alias names that look like Guardian

userids. It makes it difficult to read audit and other user-related reports. In gen-

eral, don’t make aliases all upper case and don’t include dots (.).

For example, use oper-joe or operjoe instead of OPER.JOE.

Each alias has a specific underlying userid, for example oper-joe is mapped to

210,5. Each underlying userid can have multiple aliases mapped to it.

RISK Aliases cannot be included in Safeguard Protection Records. An alias’s

access to system resources is based solely on that of the underlying userid.

RISK An alias gains all of its underlying userid’s privileges.

RISK Safeguard software provides limited auditing of alias activity.

Aliases to privileged userids such as SUPER.SUPER or the application owner IDs

should be used only as a last resort. The most secure way to grant the necessary access to

users who must ‘act’ as a privileged userid in order to perform their job function is with

a third party access control product which can make access to resources much more

granular and provide comprehensive auditing.

3P-ADVICE-ALIAS-01 If aliases are required, use third party products to

both limit their privileges and provide more extensive auditing.

Part 3

User Administration 83