Sun Management Center 3.6.1 安装和配置指南

第 3 章 配置注意事项

本章介绍了一些可对 Sun Management Center 的安装或升级产生不利影响的事项。本章提供以下主题:

安全性建议

本节提供有关 Sun Management Center 访问、服务器和代理组件以及安全密钥的安全性建议。

用户、组和角色概述

在设置 Sun Management Center 用户和用户组之前,您应当了解可以执行的管理操作的类型,以便将这些操作分配给适当的用户。认真规划用户组和角色,有助于确保配置管理的正确性,以及管理信息和系统资源的数据完整性和安全性。

如果事先不在主访问文件 /var/opt/SUNWsymon/cfg/esusers 中明确标识用户,该用户就不能访问 Sun Management Center。因此要授予用户访问 Sun Management Center 的权限,就必须在 /var/opt/SUNWsymon/cfg/esusers 文件中添加该用户的用户名。然后,该用户才能使用用户名和密码登录 Sun Management Center。

用户登录时,Sun Management Center 使用基于 PAM 的身份验证对用户进行验证。Sun Management Center 基于以下功能角色控制访问以及定义用户权限:

在大型组织中,Sun Management Center 安全性角色很可能直接对应到现有的系统管理和支持等职能。而对于其他组织,企业功能和产品角色之间的对应关系可能比较模糊,因此该过程会相对复杂一些。在有些情况下,为单个用户分配所有的逻辑角色可能会比较保险。


注 –

权限的规定十分灵活,不必局限于这四种 Sun Management Center 安全性角色。


可以在域级、拓扑容器级、代理级和模块级明确指定 Sun Management Center 权限。规定权限时可以引用任意的 UNIX 用户或用户组,上述各组仅为习惯用法。分配职能角色时,Sun Management Center 权限组允许使用现有的帐户配置。虽然建议不要在分配权限时明确指定用户,但是在已建立了 UNIX 组的环境中使用这些 UNIX 组将十分方便。

有关安全性角色、组和用户的详细信息,请参见设置用户以及《Sun Management Center 3.6.1 用户指南》中的第 18  章 “Sun Management Center 安全性”

Sun Management Center 内部安全性

本节介绍 Sun Management Center 组件之间所使用的安全设置过程。

服务器到代理的安全性

Sun Management Center 服务器与它所管理的节点之间的通信主要是使用行业标准简单网络管理协议第 2 版来执行的,采用的是用户安全模式 SNMP v2usec。SNMPv2 机制非常适合用于将用户凭据从服务器层映射到代理方操作,它是确保访问控制策略得以实施的主要机制。

Sun Management Center 也支持基于团体安全性的 SNMP v1 和 v2。虽然从安全性的角度来看不够可靠,但是支持 SNMP v1 和 v2 对于与其它设备和管理平台集成非常重要。在不需要使用这些机制的环境中,通过使用 SNMP v1 和 v2 协议,访问控制规定机制可用来限制或禁止对进程的访问。Sun Management Center 代理也能理解并响应来自第三方应用程序中的 SNMPv3 查询。

对于需要使用数据流的自定义操作,还应该采用探测机制。探测机制是由 SNMP 操作启动的。在启动探测机制时,探测操作使用流式 TCP 连接,在被管理的节点上实现可能发生的双向交互服务,例如查看日志文件。由于探测机制使用的是 SNMP 通信,因此不对数据包有效负载进行加密。

跨服务器环境的安全性

当 Sun Management Center 与本地服务器环境以外的被管理节点进行通信时,安全模式可以确保操作作为通用的 espublic SNMPv2 usec 用户执行。使用 espublic 将严格限制用户权限,并限制用户只能读取管理数据。

客户机到服务器的安全性

Sun Management Center 服务器层和客户机(如控制台和命令行界面)之间的通信是使用 Java 技术远程方法调用 (RMI) 以及特定于产品的安全模式共同执行的。安全模式允许客户机在低、中或高安全模式下进行操作,这些模式将影响系统执行的消息验证的级别。

由于较高的安全性级别会造成潜在的性能影响,所以您应该仔细考虑自己的信息鉴别要求。

模块安全性

Sun Management Center 为 Service Management Facility(SMF)、Module Configuration Propagation (MCP) 和 Solaris Container Manager 提供了模块级安全性。任何用户都可以在 Sun Management Center 代理上装入任何模块。但是,对于在模块上设置/更改操作或值而言,用户需要事先得到许可。模块安全性有两种表现形式:RBAC(Role Based Access Control,基于角色的访问控制)和本地文件访问。

RBAC 基于配置文件。拥有所需配置文件的用户可以执行配置文件特定的任务。通过运行 Solaris 系统管理命令可实现 RBAC。

本地文件访问是独立于操作系统的。用户必须具有所需的访问权限,该权限要添加到本地访问文件。使用 es-config 命令可以实现通过本地文件访问来提供安全性。有关更多信息,请参阅使用 es-config

安全密钥和 SNMP 团体字符串

当您在一个单独的计算机上安装并设置 Sun Management Center 代理时,系统将提示您提供一个密码以便为代理生成安全密钥。该密码应该与您设置 Sun Management Center 服务器时指定的密码相同。如果 Sun Management Center 服务器和代理的安全密钥不同,两者之间将无法通信。有关如何重新生成安全密钥的信息,请参见重新生成安全密钥

在设置过程中,还将提示您接受缺省的 SNMP 团体字符串(公用),或者指定一个私用的团体字符串。SNMP 团体字符串实际上就是具有特权的内部帐户的密码。因此,与通用的 SNMPv2 usec 工具一起使用时,该字符串可用于模拟服务器层。因此,请勿使用默认的团体字符串。而应该为每个服务器环境指定一个单独的私用团体字符串。

应该象对待超级用户口令那样,非常重视安全性口令和 SNMP 团体字符串。

管理策略

本节概要介绍 Sun Management Center 管理方法。了解管理所基于的系统及其实现有助于成功地部署和使用 Sun Management Center。

服务器环境

管理信息组织结构的最高级别的构造块是服务器环境。每台 Sun Management Center 服务器只提供一个服务器环境。每个服务器环境可能拥有一个或多个向其报告的被管理系统,而每个被管理系统只能向一个服务器环境报告。

服务器环境之间的通信通常会受到限制,而且管理事件也不会在服务器之间转发。服务器环境的使用应当与使用 Sun Management Center 的组织中的组结构并行,服务器环境还应当与涉及系统管理的组的职责并行。拥有服务器的管理组也拥有该服务器中的管理数据。这个组可以控制对由 Sun Management Center 服务器管理的所有系统和网络资源进行的全部访问。

域策略

域是服务器环境中级别最高的结构。它提供了可供您创建自定义拓扑配置的各种环境。域极为通用。您可以创建一个域来代表特定用户、环境或其他逻辑部分特有的信息。被管理系统可以出现在多个域中,使得多个域可以重叠存在,因此您可以为相同的管理信息和系统资源构造多种不同的表示方法。

域通常包含了 Sun Management Center 组的分层结构集合,可用于收集一系列被管理系统、Sun Management Center 管理模块或被管理对象。这种分层结构定义了用户界面内可见的信息分类,还定义了收集管理状态并将此状态提供给高级别汇总的规则。这项功能及其提供的灵活性使得域和域中的容器成为在特定环境中构建逻辑管理模式的强大工具。

组织策略

Sun Management Center 包含一个功能强大的搜索管理器, 可以自动定期检查本地环境,以标识所有被管理节点。搜索管理器沿着基于物理网络的线路构建管理信息,有助于配置 Sun Management Center。

由于环境的特性不同,使用搜索管理器可能不是查看管理信息和收集状态信息的最有效方法。相反,在组织 Sun Management Center 环境之前标识所有被管理系统时,搜索管理器非常有用。有关搜索管理器的详细信息,请参见《Sun Management Center 3.6.1 用户指南》中的第 4  章 “使用搜索管理器将对象添加到拓扑数据库”

组织 Sun Management Center 环境的其他方法包括:

在每个 Sun Management Center 环境中都应该非常重视完整性。其涵盖范围必须足以主动处理系统问题,或至少能立即识别出系统问题。如果对环境至关重要但不受 Sun Management Center 监视的设备、主机、服务或进程出现故障,可能会导致覆盖间隙,从而影响实现的整体效果。因此,在构建 Sun Management Center 管理环境时,需要考虑的内容应当包括自定义的模块、代理解决方案、甚至其它服务器环境中的信息。

物理结构

被管理系统的物理位置可能与系统所在的网络不相符。在这种情况下,您可能需要创建一个新的域,使其中的 Sun Management Center 组按照物理线路进行构建。城市、街区、建筑物、楼层、服务器操作间甚至是设备机架都很容易表示出来。位于这些位置的系统可以从域中复制并粘贴,而在该域中的搜索操作是使用搜索管理器执行的。

要按照物理线路配置 Sun Management Center 环境,需要了解系统的物理位置。这种结构成为一种有效且易于访问的引用。物理结构还定义了一个状态汇总路径,它能使问题在物理线路上被分离出来,从而有助于标识常见的故障。例如,本地的电源中断将影响位于若干个网络上但出现在一个物理区域中的系统。


注意 – 注意 –

您必须自己更新此信息。执行搜索时,此信息不会自动更新。搜索进程不会自动跟踪在物理上被重新定位的资产。


环境策略

您的组织可能有几个逻辑环境,这些环境的位置和资源重叠,但各自的逻辑功能并不相同。逻辑环境包括企业组(如销售与工程)、功能组(如零售与公关)、甚至是逻辑软件环境(如用户接收与生产)。

在所有这些情况下,应该考虑构造单独的 Sun Management Center 拓扑组,以隔离每个组的元素。分开的拓扑组能够防止一个组中的问题在另一个组中引发警报。在为包含多域服务器的系统配置 Sun Management Center 环境时,这种隔离尤为重要。不同的域可以为完全不同的组或环境执行功能。在一个拓扑组中包含不同的域可能会导致不正确的信息和警报通知。

应用程序结构

在系统管理中,应用程序是复杂的实体。从管理的角度确定应用程序由什么组成比较困难,如果应用程序是分布式的并依赖于许多外部服务才能正常运行,则更加难以确定。因此,您应当在安装 Sun Management Center 之前组织好应用程序,而不要等到真的发生问题后再考虑引发问题的起因及其连带影响。在开始时进行一些分析,有助于提高解决应用程序级问题的效率。

配置面向应用程序的 Sun Management Center 环境时,拓扑容器通常包含主机、模块和特定对象。有些主机可能完全是应用程序专用的,而其它主机可能只是部分负责应用程序的适当操作。例如,对于使用了企业目录服务的应用程序,该目录服务的运作情况对于应用程序的运行非常重要,而服务器上其他服务的运作情况对该应用程序却不重要或不是必需的。

服务职责

在有些环境中,组或管理员负责特定的服务而不负责基本资源。例如,数据库管理员可能负责维护数据库服务的可用性和数据完整性,但不负责硬件或操作系统的管理。专为数据库服务创建的 Sun Management Center 域可以帮助数据库管理员执行必要的任务,而一般用户角色权限通过对一般系统和网络状态的访问来协助管理员工作。

管理大型企业

Sun Management Center 中的某些工具可以帮助您简化大型企业的管理工作。其中一个工具是引用域,它允许组跨服务器环境共享管理信息。另一个工具是分组操作系统,在执行大的、高度分散的管理操作时能够发挥重要作用。

分组系统可用于设置数据特性值和修改数据特性属性。您还可以在 Sun Management Center 服务器环境中加载、卸载、启用和禁用模块,所有这些操作都可以应用到大量被管理系统和节点。使用现有的拓扑结构或使用灵活的搜索式过滤器可以定义这些组。可以保存和多次重复执行分组操作。自动分组操作可以使用安排程序。分组操作还包括模块配置传播 (MCP),该工具可以对一个引用节点的完整配置进行克隆,方法是先将其拖到服务器,然后将其放到所有相似的节点上。

有关引用域的详细信息,请参见《Sun Management Center 3.6.1 用户指南》中的“监视远程管理域”一节。有关组操作的详细信息,请参见《Sun Management Center 3.6.1 用户指南》中的第 13  章 “管理与组相关的作业”