HP OpenVMS Systems Documentation

This chapter describes concerns for security administrators of clustered systems. Clustered systems refer to those systems using hardware and software that permit sharing of disks, resources, and a common operating system among various computers. Clusters of VAX processors are said to be joined in a VAXcluster environment; whereas clusters including both Alpha processors and VAX processors are said to be joined in a VMScluster environment. To properly secure your cluster, you should be familiar with the information in the OpenVMS Cluster Systems Manual.

The OpenVMS Cluster Systems Manual describes the tasks of the cluster manager. The cluster manager's job is the same as that of any system manager, but the cluster manager has to implement changes across many nodes. The security administrator for a cluster generally requires the same training and skills as a cluster manager, and at some cluster sites, the same person serves in the role of security administrator as well as cluster manager. At other sites, there may be one or more security administrators in addition to a cluster management team.

When a site separates the security administrator function from the cluster management function, coordination, cooperation, and communication between these functions becomes vital. As in previous chapters, this chapter uses the title of security administrator to refer to individuals who have the responsibility for system security, regardless of what other responsibilities they hold.

11.1 Overview of Clusters

Clustered systems provide a uniform computing environment that is highly scalable, highly available, and secure. It is critical that there be a single set of authorized users and that these users be able to have processes executing on any cluster member.

To achieve a uniform computing environment, a cluster relies on the following components operating across all cluster members:

• Lock manager system services ($ENQ/$DEQ) (to provide a framework for building distributed applications)
• File and record management subsystems (coordinated through the lock manager)
• Batch and print services
• Process control system services
• Security auditing system

Within a cluster, authorization data for users and the security profiles of objects must be consistent across all nodes so that each cluster member makes the same access control decision when presented with a particular user's access request for a particular object. Section 11.2 and Section 11.3 describe how to achieve a single security domain.

11.2 Building a Common Environment

Within a cluster, access control is mediated by individual nodes using a common set of authorization information. In the single security domain model, a process, acting on behalf of an authorized individual, requests access to a cluster-visible object, and a coordinating node determines the outcome by comparing its copy of the common authorization database with the security profile for the object being accessed. This model enforces security only when the authorization information and the object security profiles are consistent across all nodes in the cluster.

To achieve data consistency within the cluster, a site needs to:

• Maintain a common set of data, as described in Section 11.2.1, Section 11.2.2, and Section 11.2.3
• Execute changes to system parameters consistently When changing any LGI system parameters, use the System Management utility (SYSMAN) (see Section 11.8).

The easiest way to ensure a single security domain is to maintain a single copy of each of the files listed in Table 11-1 on one or more cluster-mounted disks. As soon as any required file is created on one node, it must be created or commonly referenced on all remaining cluster members. When a cluster is configured with multiple system disks, you can use system logical names to ensure that only a single copy of each file exists.

The files in Table 11-1 contain data that must be synchronized. If your site chooses to maintain multiple versions of these files, you must synchronize the data, as Section 11.2.3 explains.

Although Compaq does not require that the files listed in Table 11-2 be common to all cluster members, it does recommend that the data in the files be fully synchronized. Table 11-3 explains how to coordinate these files and suggests possible consequences of poor synchronization.

Some of the recommended files are created only on request and may not exist in all configurations. Note that a file may be absent on one node only if it is absent on all other nodes. As soon as any required file is created on one node, it must be created or commonly referenced on all remaining cluster members.

Using shared files is not the only way of achieving a single security domain. Some sites may have requirements for multiple copies of one or more of these system files on different nodes in a cluster. As long as the security information available to each node in the cluster is exactly the same, these sites operate in a single security domain.

Table 11-3 lists the files that require coordination, explains when to update these files, and suggests possible consequences of poor synchronization.

On a cluster, all elements of the user authorization data should exist in a common database. These authorization elements include the system user authorization files (SYSUAF.DAT and its backup SYSUAFALT.DAT), the rights database (RIGHTSLIST.DAT), the network authorization file (NETPROXY.DAT) and its object database file (NETOBJECTS.DAT), which are present on all OpenVMS systems, and optionally, the autologin file, SYSALF.DAT.

A secure cluster requires that the authorization data be synchronized across all nodes. If a site chooses to maintain multiple versions of these files, then you must synchronize the data. Each user should have the same UIC, group number, and set of identifiers defined on every node. Coordination of privileges and access rights is also critical. A shared disk is protected only as much as its least protected node. If you maintain separate authorization files on each node in the cluster, ensure that user privileges are common across all copies of the system user authorization file (SYSUAF.DAT). Table 11-4 lists the fields of SYSUAF.DAT that must be identical on each node.

Use SYSMAN if you choose to create an autologin file and maintain the file in the common authorization database with your authorization files and rights database. On clustered systems, the autologin file must include the cluster node name as a prefix to the terminal name. For example, the terminal TTA0 on node WILLOW would be represented as WILLOW$TTA0. See Section 11.8 for an overview of SYSMAN.

11.4 Managing the Audit Log File

The audit server database VMS$AUDIT_SERVER.DAT contains information about events to be audited, the location of the audit log file, and information used to monitor its consumption of resources.

The audit log file resides in SYS$COMMON:[SYSMGR]. If you should decide to redirect the audit log off the system disk, it is important to redirect it uniformly across all nodes on the cluster. You use the command SET AUDIT/JOURNAL=SECURITY/DESTINATION=filename. Make sure that the file name you assign resolves to the same file throughout the cluster, not a file unique to each node. The OpenVMS Cluster Systems Manual describes the procedure in detail.

11.5 Protecting Objects

A single security domain is one in which each cluster member must make the same access control decision when presented with a particular user's access request for a particular object. The operating system provides this level of protection for files, queues, and other cluster-visible objects such as devices, disk and tape volumes, and resource domains. Table 11-5 summarizes the behavior of each object class and explains where each stores security profiles. See Chapter 5 for a description of each object class.

The audit server creates and maintains the security elements of clusterwide objects in a database called VMS$OBJECTS.DAT, located in SYS$COMMON:[SYSEXE]. You should ensure that the object database is present on each node in the cluster by specifying a file name that resolves to the same file through the cluster, not to a file that is unique to each node.

To reestablish the logical name after each system boot, define the logical in SYSECURITY.COM. The command procedure SYSECURITY.COM has to be defined before the audit server starts up.

The object database contains the following information:

• Audit and alarm settings for all objects, established through the DCL command SET AUDIT
• Template profiles for all security profiles, as described in Chapter 5
• Security profiles for all resource domain objects, all security class objects, and all cluster-visible devices (see Section 11.5)

This database is updated whenever characteristics are modified, and the information is distributed so that all nodes participating in the cluster share a common view of the objects.

You cannot change security profiles or create protected objects when the object server is absent and cannot update the cluster database VMS$OBJECTS.DAT. However, you can modify the system parameter SECURITY_POLICY to allow security profile changes to protected objects on a local node (bit 4) or the creation of protected objects on a local node (bit 5).

11.7 Cluster-Wide Intrusion Detection

Cluster-wide intrusion detection extends protection against attacks of all types throughout the cluster. Intrusion data and information from each system is integrated to protect the cluster as a whole.

You can set the SECURITY_POLICY system parameter on the member systems in your cluster to maintain either a local or a cluster-wide intrusion database of unauthorized attempts and the state of any intrusion events.

If bit 7 in SECURITY_POLICY is cleared, all cluster members are made aware if a system is under attack or has any intrusion events recorded. Events recorded on one system can cause another system in the cluster to take restrictive action. (For example, users attempting to log in are monitored more closely and are limited to a certain number of login retries within a limited period of time. Once users exceed either the retry or time limitation, they cannot log in.)

For information on the system services $DELETE_INTRUSION, $SCAN_INTRUSION, and $SHOW_INTRUSION, see the OpenVMS System Services Reference Manual.

For information on the DCL commands DELETE INTRUSION and SHOW INTRUSION, see the OpenVMS DCL Dictionary.