Security Recommendations

This section provides security recommendations for Sun Management Center access, server and agent components, and security keys.

Users, Groups, and Roles Overview

Before you set up Sun Management Center users and user groups, you should understand the types of management operations that are possible so you can assign these operations to the appropriate user classes. Careful planning of user groups and roles helps ensure proper configuration management, and data integrity and security of management information and system resources.

No user may gain access to Sun Management Center without first being explicitly identified in the master access file /var/opt/SUNWsymon/cfg/esusers. To grant access to Sun Management Center, the user name must be added to /var/opt/SUNWsymon/cfg/esusers. The user may then log into Sun Management Center using the user name and password.

When a user logs in, Sun Management Center uses PAM based authentication to authenticate users. Sun Management Center controls access and defines the user privileges based on the following functional roles:

• Domain Administrators – This role is the highest-level role, which permits members to create top-level domains in a server context and to assign privileges for other Sun Management Center users within these domains. The domain administrator can create customized configurations for specific topology environments by creating specific domains and assigning user privileges for those domains. Users are considered domain administrators if the users are members of the esdomadm UNIX user group.

• Administrators – This role is the administration role for all operations outside the topology system. Administrators can perform privileged operations, including the loading of modules and the configuration of managed objects and data properties. Administrators can also specify access control at the agent and module level. This control makes this role instrumental in the establishment and maintenance of entitlement policies. Users are considered administrators if the users are members of the esadm UNIX user group.

• Operators – This role allows system users to configure their own domains and topology containers. The operator role also allows the users to configure managed objects with respect to their data acquisition and alarms, and to view management information. Although operators may enable or disable management modules, operators cannot, by default, load modules or alter access control privileges. Operators therefore represent a class of user that can effectively use the product and fine-tune its operation but who cannot affect major configuration or architectural changes. Users are considered operators if the users are members of the esops UNIX user group.

• General Users – This role is for users who are not explicitly members of the above three groups. General users are not granted extensive privileges and can by default only view management information and acknowledge alarms. The general user role is well suited for first-level support, in which problem identification, re-mediation, and escalation are the primary goals.

In large organizations, the Sun Management Center security roles are likely to map directly onto existing systems administration and support functions. For others, the process could be more involved, as the mapping between a corporate function and a product role could be less clear. In some cases, assignment of all logical roles to a single user could be warranted.

Specification of privileges is flexible and does not need to be confined to the four Sun Management Center security roles.

Sun Management Center privileges can be explicitly specified at the domain, topology container, agent, and module levels. The privileges specification can reference any arbitrary UNIX user or group, with the groups named above being used only by convention. The Sun Management Center privileges groups allow the use of existing account configurations when assigning functional roles. Although naming explicit users when assigning privileges is not recommended, the use of UNIX groups can be convenient in environments where such UNIX groups are already established.

For further information on security roles, groups, and users, see Setting Up Users andChapter 18, Sun Management Center Security, in Sun Management Center 3.6.1 User’s Guide.

Sun Management Center Internal Security

This section describes the security process that is used between Sun Management Center components.

Server-to-Agent Security

Communication between the Sun Management Center server and its managed nodes is primarily performed using the industry standard Simple Network Management Protocol version 2, employing the User Security model SNMP v2usec. The SNMPv2 mechanism is well suited to mapping the user credentials from the server layer to agent-side operations. SNMPv2 is the primary mechanism for ensuring that access control policies cannot be circumvented.

Sun Management Center also supports SNMP v1 and v2 with community-based security. Although not as robust from a security standpoint, support for SNMP v1 and v2 is important for integration with other devices and other management platforms. In environments where the use of these mechanisms is undesirable, the access control specification mechanism can be used to restrict or forbid access to processes using the SNMP v1 and v2 protocols. The Sun Management Center agent can also understand and respond to SNMPv3 queries from third-party applications.

For customized operations where data streaming could be a requirement, a probe mechanism is also employed. The probe mechanism is initiated by SNMP operations. When initiated, probe operations use a streaming TCP connection to implement bidirectional, potentially interactive services on the managed node, for example, log file viewing. Since the probe mechanism uses SNMP communication, no encryption of the packet payload is performed.

Cross-Server Context Security

When Sun Management Center communicates with managed nodes outside the local server context, the security model ensures that operations are performed as the generic public SNMPv2 usec user. Use of public greatly restricts privileges and limits users to the perusal of management data.

Client-to-Server Security

Communication between the Sun Management Center server layer and clients such as consoles and command-line interfaces is performed using Java Technology Remote Method Invocation (RMI) in conjunction with a comprehensive product-specific security model. The security model allows clients to operate in either low, medium or high security modes, which affects the level of message authentication that is performed.

• Low: No message authentication. Only the user password is checked at time of login.

• Medium (default): Console-to-server authentication only, for example, server authentication of incoming console messages.

• High: Both console and server authenticate messages.

Because of the potential performance impact of the higher security levels, you should carefully consider your message authentication requirements.

Module Security

Sun Management Center provides module level security for Service Management Facility(SMF), Module Configuration Propagation (MCP), and Solaris Container Manager modules. Any user will be able to load any module on the Sun Management Center agent. However, for setting/changing actions or values on the module, the user needs to have prior permissions. Module security is provided in two ways: RBAC (Role Based Access Control) and local file access.

RBAC is based on profiles. Users having the required profiles can perform profile-specific tasks. RBAC can be implemented by running Solaris system administration commands.

Local file access is independent of the OS. The users need to have the required permissions to be added to the local access file. Security through local file access can implemented by using the es-config command. For more information refer to Using es-config.

Security Keys and SNMP Community String

When you install and then set up the Sun Management Center agent on a separate machine, you are prompted to provide a password that is used to generate the security key for the agent. The password should be the same password as the password you specified during setup of the Sun Management Center server. The Sun Management Center server and agent cannot communicate with each other if the server and agent have different security keys. For information on how to regenerate security keys, see Regenerating Security Keys.

During setup, you are also prompted to either accept the default SNMP community string (public), or specify a private community string. The SNMP community string is essentially a password for a privileged internal account. As such, this string potentially can be used to mimic the server layer if used with generic SNMPv2 usec tools. Therefore, do not use the default community string. Specify a separate, private community string for each server context.

Treat the security password and the SNMP community string with the same significance as a superuser password.