Kerberos 守护进程
第26 章• Kerberos 服务（参考） 503
Kerberos 术语
下一节介绍了Kerberos 术语及其定义。这些术语可用于整个Kerberos 文档。要理解
Kerberos 概念，必须先了解这些术语。
特定于Kerberos 的术语
要管理KDC，您需要了解本节中的术语。
Key Distribution Center, KDC（密钥分发中心）是负责颁发凭证的Kerberos 组件。这些凭证是
使用KDC 数据库中存储的信息创建的。每个领域至少需要两个KDC，一个主KDC 以及至
少一个从KDC。所有KDC 都可生成凭证，但仅有主KDC 才能处理对KDC 数据库所做的任
何更改。
stash file（存储文件）包含KDC 的主密钥。当重新启动服务器以便在启动kadmind 和
krb5kdc 命令之前自动验证KDC 时，将使用此密钥。由于此文件包含主密钥，因此应将此
文件及其所有备份安全保存。此文件是使用root 的只读权限创建的。要确保此文件安全，
请勿更改相应的权限。如果此文件已被破坏，则其他用户可能会使用主密钥来访问或修改
KDC 数据库。
特定于验证的术语
要了解验证过程，您需要理解本节中的术语。程序员和系统管理员应熟悉这些术语。
client（客户机）是在用户工作站上运行的软件。在客户机上运行的Kerberos 软件会在此过
程中发出许多请求。因此，区分此软件的操作和用户非常重要。
术语server（服务器）和service（服务）通常可互换使用。具体而言，术语服务器用于定义
运行Kerberos 软件的物理系统。术语服务对应于服务器支持的特定功能（例如ftp 或
nfs）。文档通常会将服务器描述为服务的一部分，但此定义会混淆了这些术语的含义。因
此，术语服务器是指物理系统，而术语服务则是指软件。
Kerberos 产品使用两种类型的密钥。一种密钥类型是口令派生密钥。口令派生密钥会被指
定给每个用户主体，并仅对该用户和KDC 公开。Kerberos 产品使用的另一种密钥类型是与
口令无关联的随机密钥，因此不适合用户主体使用。随机密钥通常用于在密钥表中具有相
应项并具有KDC 生成的会话密钥的服务主体。服务主体可以使用随机密钥，因为服务可以
访问密钥表中允许其以非交互方式运行的密钥。会话密钥由KDC 生成，并在客户机和服务
之间共享，可用于在两者之间提供安全事务。
ticket（票证）是一种信息包，用于将用户身份安全地传递到服务器或服务。一个票证仅对
一台客户机以及某台特定服务器上的一项特殊服务有效。票证包含以下内容：
服务的主体名称
用户的主体名称
用户主机的IP 地址
Kerberos 术语
504 系统管理指南：安全性服务• 2006 年9 月
时间标记
定义票证生命周期的值
会话密钥的副本
所有此类数据都使用服务器的服务密钥进行加密。请注意，KDC 可颁发嵌入在以下介绍的
凭证中。颁发票证之后，可重用票证直到其到期为止。
credential（凭证）是一种信息包，其中包含票证和匹配的会话密钥。凭证使用发出请求的
主体的密钥进行加密。通常，KDC 会生成凭证以响应客户机的票证请求。
authenticator（验证者）是服务器用于验证客户机用户主体的信息。验证者包含用户的主体
名称、时间标记和其他数据。与票证不同，验证者只能使用一次，通常在请求访问服务时
使用。验证者使用客户机和服务器共享的会话密钥进行加密。通常，客户机会创建验证
者，并将其与服务器或服务的票证一同发送，以便向服务器或服务进行验证。
票证类型
票证具有可管理其使用方式的属性。这些属性是在创建票证时指定给票证的，但稍后可修
改票证的属性。例如，可将票证从forwardable 更改为forwarded。可以使用klist 命令查
看票证属性。请参见第487 页中的“查看Kerberos 票证”。
以下一个或多个术语对票证进行了描述：
Forwardable（可转发）/forwarded（已转发）
可转发票证可以从一台主机发送到另一台主机，从而使客户机无需对其自身进行重新验
证。例如，如果用户david 在用户jennifer 的计算机上时获取了一个可转发票证，则前
者可登录到自己的计算机，而不必获取新的票证（从而对自身进行重新验证）。有关可
转发票证的示例，请参见第486 页中的“示例－创建Kerberos 票证”。
Initial（初始）
初始票证是一种直接颁发的票证，而并非基于票证授予票证的票证。某些服务（如用于
更改口令的应用程序）可能会要求将票证标记为初始，以便向这些程序本身确保客户机
可知道其私钥。初始票证表明客户机最近已进行了自我验证，而并非依赖于已长期使用
的票证授予票证。
Invalid（未生效）
无效票证是一个尚未变为可用的未生效的票证。应用程序服务器会拒绝无效票证，直到
其经过验证为止。要进行验证，必须在票证开始时间已过之后由客户机将设置了
VALIDATE 标志的票证放置在票证授予服务请求的KDC 中。
Postdatable（可以后生效）/postdated（以后生效）
以后生效的票证是一种在其创建之后的某个指定时间之前不会生效的票证。例如，此类
票证对于计划在深夜运行的批处理作业非常有用，因为如果该票证被盗，则在运行批处
理作业之前，将无法使用该票证。颁发以后生效的票证时，该票证未生效，并在其开始
时间已过且客户机请求KDC 进行验证之前一直保持此状态。通常，以后生效的票证在票
证授予票证的到期时间之前会一直有效。但是，如果将以后生效的票证标记为可更新，
则通常会将其生命周期设置为等于票证授予票证的整个生命周期的持续时间。
Kerberos 术语
第26 章• Kerberos 服务（参考） 505
Proxiable（可代理）/proxy（代理）
有时，主体需要允许服务代表其执行操作。创建该票证时，必须指定代理的主体名称。
Solaris 发行版不支持可代理票证或代理票证。
可代理票证与可转发票证类似，但前者仅对单个服务有效，而可转发票证授予服务对客
户机身份的完全使用权限。因此，可以将可转发票证视为一种超级代理。
Renewable（可更新）
由于拥有很长生命周期的票证存在安全风险，因此可将票证指定为可更新票证。可更新
票证具有两个到期时间：票证当前实例的到期时间以及任意票证的最长生命周期（一
周）。如果客户机要继续使用票证，则可在第一个到期时间之前更新票证。例如，某个
票证的有效期可为一个小时，而所有票证的最长生命周期为10 个小时。如果持有该票证
的客户机要将该票证再保留几个小时，则此客户机必须在有效的小时数内更新票证。如
果票证到达最长票证生命周期（10 个小时），则该票证将自动到期且无法更新。
有关如何查看票证属性的信息，请参见第487 页中的“查看Kerberos 票证”。
票证生命周期
每当主体获取包括票证授予票证(Ticket–Granting Ticket, TGT) 在内的票证时，都会将票证的
生命周期设置为以下生命周期值中的最小值：
通过kinit 的-l 选项指定的生命周期值，前提是使用kinit 获取票证。缺省情况下，
kinit 使用最长生命周期值。
kdc.conf 文件中指定的最长生命周期值(max_life)。
Kerberos 数据库中为提供票证的服务主体指定的最长生命周期值。如果使用kinit，则
服务主体为krbtgt/realm。
Kerberos 数据库中为请求票证的用户主体指定的最长生命周期值。
图26–1 说明了如何确定TGT 的生命周期以及四个生命周期值的来源。虽然该图说明的是如
何确定TGT 的生命周期，但所有主体获取票证时的情况基本相同。唯一的区别在于，kinit
不提供生命周期值，而提供票证的服务主体（非krbtgt/realm 主体）会提供最长生命周期
值。
Kerberos 术语
506 系统管理指南：安全性服务• 2006 年9 月
图26–1 如何确定TGT的生命周期
可更新票证生命周期也是由四个值中的最小值确定的，但是使用的却是可更新的生命周期
值，如下所示：
通过kinit 的-r 选项指定的可更新生命周期值，前提是使用kinit 获取或更新票证。
kdc.conf 文件中指定的最长可更新生命周期值(max_renewable_life)。
Kerberos 数据库中为提供票证的服务主体指定的最长可更新生命周期值。如果使用
kinit，则服务主体为krbtgt/realm。
Kerberos 数据库中为请求票证的用户主体指定的最长可更新生命周期值。
Kerberos 主体名称
每个票证都使用主体名称进行标识。主体名称可以标识用户或服务。以下是一些主体名称
的示例：
表26–4 Kerberos 主体名称示例
主体名称说明
更改口令时，允许访问KDC 的主KDC 服务器的主体。
kclient 安装实用程序使用的主体。
ftp 服务使用的主体。此主体可用于替代host 主体。
Kerberos 术语
第26 章• Kerberos 服务（参考） 507
表26–4 Kerberos 主体名称示例（续）
主体名称说明
基于Kerberos 的应用程序（例如klist 和kprop）和服务
（例如ftp 和telnet）使用的主体。此主体称为host 主体
或服务主体，用于验证NFS 挂载。
主密钥名称主体。一个主密钥名称主体可与每个主KDC 关
联。
一种主体，其中包含用于保存其他主体的口令历史记录的
密钥。每个主KDC 都具有这些主体之一。
允许使用kadmind 访问KDC 的主KDC 服务器的主体。
一种主体，用于接受来自未运行Solaris 发行版的客户机的
口令更改请求。
生成票证授予票证时使用的主体。
此主体是跨领域的票证授予票证的示例。
NFS 服务使用的主体。此主体可用于替代host 主体。
与客户机的root 帐户关联的主体。此主体称作root 主体，
用于向已挂载NFS 的文件系统提供root 访问权限。
用户的主体。
admin 主体，可用于管理KDC 数据库。
Kerberos 验证系统的工作方式
如果您可以提供证明您身份的票证和匹配的会话密钥，则应用程序允许您登录到远程系
统。会话密钥包含特定于用户以及要访问的服务的信息。所有用户首次登录时，KDC 都会
为其创建票证和会话密钥。票证和匹配的会话密钥可组成凭证。使用多个网络服务时，用
户可以收集许多凭证。对于在特定服务器上运行的每个服务，用户都需要拥有一个凭证。
例如，访问名为boston 的服务器中的ftp 服务需要凭证。访问其他服务器中的ftp 服务需
要对应于该服务的凭证。
创建和存储凭证的过程是透明的。凭证是由将凭证发送到请求程序的KDC 创建的。收到凭
证后，会将其存储在凭证高速缓存中。
Kerberos 验证系统的工作方式
508 系统管理指南：安全性服务• 2006 年9 月
使用Kerberos 获取服务访问权限
要访问特定服务器上的特定服务，用户必须获取两个凭证。第一个凭证用于票证授予票证
（称为TGT）。票证授予服务对此凭证进行解密之后，该服务即可为用户请求访问的服务
器创建第二个凭证。然后，可使用第二个凭证来请求访问该服务器中的相应服务。该服务
器成功解密第二个凭证后，便会授予用户访问权限。以下各节详细介绍了此过程。
获取用于票证授予服务的凭证
1. 要启动验证过程，客户机需要向验证服务器发送针对特定用户主体的验证请求。该请求
在发送时未加密。由于请求中未包含安全信息，因此无需加密。
2. 验证服务收到该请求后，将在KDC 数据库中查找该用户的主体名称。如果主体与数据
库中的项匹配，则验证服务可获取该主体的私钥。然后，验证服务将生成一个供客户机
和票证授予服务使用的会话密钥（称为会话密钥1），以及一个用于票证授予服务的票
证（票证1）。此票证也称作票证授予票证(Ticket-Granting Ticket, TGT)。会话密钥和票
证均使用该用户的私钥进行加密，并且会将信息发回客户机。
3. 客户机通过该用户主体的私钥，使用此信息对会话密钥1 和票证1 进行解密。由于该私
钥仅对此用户和KDC 数据库公开，因此包中的信息应是安全的。客户机将该信息存储
在凭证高速缓存中。
在此过程中，通常会提示用户输入口令。如果用户指定的口令与用于生成存储在KDC 数据
库中的私钥的口令相同，则客户机可以成功解密验证服务发送的信息。现在，客户机便拥
有了用于票证授予服务的凭证。客户机现在可以请求用于服务器的凭证。
使用Kerberos 获取服务访问权限
第26 章• Kerberos 服务（参考） 509
图26–2获取用于票证授予服务的凭证
获取用于服务器的凭证
1. 要请求访问特定服务器，客户机必须首先从验证服务获取用于该服务器的凭证。请参见
第509 页中的“获取用于票证授予服务的凭证”。然后，客户机会向票证授予服务发送
请求，其中包含服务主体名称、票证1 以及使用会话密钥1 加密的验证者。票证1 最初
是由验证服务使用票证授予服务的服务密钥加密的。
2. 由于票证授予服务的服务密钥对票证授予服务公开，因此可以解密票证1。票证1 中的
信息包括会话密钥1，因此票证授予服务可以解密验证者。此时，可使用票证授予服务
验证用户主体。
3. 成功验证后，票证授予服务将为用户主体和服务器生成一个会话密钥（会话密钥2），
以及一个用于服务器的票证（票证2）。然后，使用会话密钥1 加密会话密钥2 和票证
2。由于会话密钥1 仅对该客户机和票证授予服务公开，因此此信息是安全的并可在网
络上安全发送。
4. 客户机收到此信息包后，将使用存储在凭证高速缓存中的会话密钥1 解密此信息。客户
机即获取用于服务器的凭证。现在，客户机可以请求访问该服务器中的特定服务。
使用Kerberos 获取服务访问权限
510 系统管理指南：安全性服务• 2006 年9 月
图26–3获取用于服务器的凭证
获取对特定服务的访问权限
1. 要请求访问特定服务，客户机必须首先从验证服务器获取用于票证授予服务的凭证，然
后从票证授予服务获取服务器凭证。请参见第509 页中的“获取用于票证授予服务的凭
证”和第510 页中的“获取用于服务器的凭证”。然后，客户机可将包含票证2 和另一
个验证者的请求发送到该服务器。该验证者使用会话密钥2 进行加密。
2. 票证2 是由票证授予服务使用该服务的服务密钥进行加密的。由于服务密钥对服务主体
公开，因此该服务可以解密票证2 并获取会话密钥2。然后，可使用会话密钥2 解密验
证者。如果成功解密验证者，则可授予客户机对该服务的访问权限。
图26–4获取对特定服务的访问权限
使用Kerberos 获取服务访问权限
第26 章• Kerberos 服务（参考） 511
使用Kerberos 加密类型
加密类型可标识执行加密操作时要使用的加密算法和模式。使用aes、des3-cbc-sha1 和
rc4–hmac 加密类型可以创建用于较高强度加密操作的密钥。这些较高强度的操作可增强
Kerberos 服务的整体安全性。
注– 如果安装了非随附的强加密软件包，则可以将aes256-cts-hmac-sha1-96 加密类型用于
Kerberos 服务。
客户机从KDC 请求票证时，KDC 必须使用其加密类型与客户机和服务器兼容的密钥。尽管
Kerberos 协议允许客户机请求KDC 对客户机的票证回复部分使用特定的加密类型，但该协
议不允许服务器为KDC 指定加密类型。
注– 如果安装了未运行Solaris 10 发行版的主KDC，则在升级主KDC之前，必须将从KDC
升级到Solaris 10 发行版。Solaris 10 主KDC 将使用新的加密类型，而较早版本的从KDC 将
无法处理这些加密类型。
以下列出了更改加密类型之前必须考虑的一些问题：
KDC 假定服务器支持与主体数据库中的服务器主体项关联的第一个密钥/加密类型。
在KDC 上，应确保生成的主体密钥与将验证主体的系统兼容。缺省情况下，kadmin 命
令将为所有支持的加密类型创建密钥。如果验证主体的系统不支持该缺省加密类型集，
则在创建主体时应限制加密类型。通过在kadmin addprinc 中使用-e 标志，或在
kdc.conf 文件中将supported_enctypes 参数设置为此子集，可以限制加密类型。如果
Kerberos 领域中的大多数系统都支持缺省加密类型集的子集，则应使用
supported_enctypes 参数。如果设置supported_enctypes，则将指定kadmin addprinc 在
为特定领域创建主体时使用的加密类型的缺省集。一般情况下，最好使用这两种方法之
一来控制Kerberos 使用的加密类型。
确定系统支持的加密类型时，请考虑系统中运行的Kerberos 版本，以及为其创建服务器
主体的服务器应用程序所支持的加密算法。例如，创建nfs/hostname 服务主体时，应将
加密类型限制为相应主机中的NFS 服务器所支持的类型。请注意，在Solaris 10 发行版
中，NFS 服务器也支持所有受支持的Kerberos 加密类型。
kdc.conf 文件中的master_key_enctype 参数可用于控制加密主体数据库中各项的主密钥
的加密类型。如果已创建KDC 主体数据库，请勿使用此参数。可在创建数据库时使用
master_key_enctype 参数，以便将缺省主密钥加密类型从des-cbc-crc 更改为更强的加
密类型。配置从KDC 时，请确保所有从KDC 都支持选择的加密类型，并且其kdc.conf
中具有相同的master_key_enctype 项。另外，如果在kdc.conf 中设置了
supported_enctypes，则还应确保将master_key_enctype 设置为supported_enctypes 中
的加密类型之一。如果未正确处理其中任一问题，则主KDC 可能无法使用从KDC。
在客户机上，可以控制客户机在通过krb5.conf 中的多个参数从KDC 获取票证时请求的
加密类型。default_tkt_enctypes 参数用于指定客户机在通过KDC 请求票证授予票证
(Ticket-Granting Ticket, TGT) 时要使用的加密类型。客户机可使用TGT 以一种更有效的
方式获取其他服务器票证。如果客户机使用TGT 请求服务器票证（称为TGS 请求），
则设置default_tkt_enctypes 将提供客户机对加密类型（用于保护客户机和KDC 之间
使用Kerberos 加密类型
512 系统管理指南：安全性服务• 2006 年9 月
的通信）的部分控制。请注意，default_tkt_enctypes 中指定的加密类型必须至少与
KDC 中存储的主体数据库中的一种主体密钥加密类型匹配。否则，TGT 请求将会失
败。在大多数情况下，最好不要设置default_tkt_enctypes，因为此参数会导致互操作
性问题。缺省情况下，客户机代码会请求所有受支持的加密类型，而KDC 会基于在主
体数据库中找到的密钥来选择加密类型。
default_tgs_enctypes 参数可限制客户机在其TGS 请求（用于获取服务器票证）中请求
的加密类型。另外，此参数还可限制KDC 在创建客户机和服务器共享的会话密钥时使
用的加密类型。例如，如果客户机要在执行安全NFS 时仅使用3DES 加密，则应将
default_tgs_enctypes 设置为des3-cbc-sha1。请确保客户机主体和服务器主体在主体数
据库中具有des-3-cbc-sha1 密钥。与default_tkt_enctype 一样，在大多数情况下，最
好不要设置此参数，因为如果在KDC 和服务器上未正确设置凭证，则此参数会导致互
操作性问题。
在服务器上，可使用kdc.conf 中的permitted_enctypes 来控制服务器可接受的加密类
型。此外，还可指定创建keytab 项时使用的加密类型。同样，一般情况下最好不要使
用其中任一方法来控制加密类型，而应由KDC 来确定要使用的加密类型，因为KDC 不
会与服务器应用程序进行通信以确定要使用的密钥或加密类型。
使用gsscred 表
如果缺省映射不满足要求，则NFS 服务器尝试标识Kerberos 用户时，将使用gsscred 表。
NFS 服务使用UNIX ID 来标识用户。这些ID 不属于用户主体或凭证。gsscred 表提供从
GSS 凭证到UNIX UID 的其他映射（通过口令文件）。填充KDC 数据库后，必须创建和管
理该表。有关更多信息，请参见第360 页中的“将GSS 凭证映射到UNIX 凭证”。
接收到客户机请求时，NFS 服务便会尝试将凭证名称映射到UNIX ID。如果映射失败，则
会检查gsscred 表。
Solaris Kerberos 和MIT Kerberos 之间的显著差异
Kerberos 服务的Solaris 10 版本基于MIT Kerberos 版本1.2.1。以下列出了Solaris 10 发行版中
提供的增强功能，在MIT 1.2.1 版本中不会提供这些功能：
Solaris 远程应用程序的Kerberos 支持
KDC 数据库的增量传播
客户机配置脚本
已本地化的错误消息
BSM 审计记录支持
Kerberos 通过GSS-API 安全使用线程
使用密码学的加密框架
此版本还包括某些已发布的MIT 1.2.1 错误修复。特别是，添加了1.2.5 二叉树错误修复和
1.3 TCP 支持。
Solaris Kerberos 和MIT Kerberos 之间的显著差异
第26 章• Kerberos 服务（参考） 513
514
Solaris 审计
本部分提供有关Solaris 审计子系统的配置、管理和使用方法的信息。
第7 部分
515
516
Solaris 审计（概述）
Solaris 审计保留系统使用情况的记录。审计服务包括帮助分析审计数据的工具。
本章介绍在Solaris 操作系统中审计如何工作。以下是本章中信息的列表：
第517 页中的“什么是审计？”
第518 页中的“审计如何工作？”
第519 页中的“审计如何与安全相关？”
第519 页中的“审计术语和概念”
第524 页中的“Solaris 10 发行版中的Solaris 审计增强功能”
有关规划建议，请参见第28 章。有关在站点上配置审计的过程，请参见第29 章。有关参考
信息，请参见第30 章。
什么是审计？
审计是指收集有关系统资源使用情况的数据。审计数据提供与安全相关的系统事件的记
录。以后便可以使用此数据来指定主机上执行的操作的职责。成功的审计应包括两个安全
功能：识别和验证。每次登录时，在用户提供用户名和口令之后，都将生成一个与此用户
的进程关联的唯一审计会话ID。登录会话期间启动的每个进程都会继承此审计会话ID。即
使用户在单个会话期间更改了身份，也会使用同一个审计会话ID 跟踪所有的用户操作。有
关更改身份的更多详细信息，请参见su(1M) 手册页。
使用审计服务可以：
监视主机上发生的与安全相关的事件
记录网络范围内审计跟踪中的事件
检测误用或未经授权的活动
查看访问模式以及个人和对象的访问历史记录
发现绕过保护机制的尝试
发现用户更改身份时权限的扩展使用
在系统配置期间，可以预先选择要监视的审计记录类。还可以微调针对单个用户执行审计
的程度。
27 第2 7 章
517
收集完审计数据之后，便可使用后选工具来减少和检查所需的审计跟踪部分。例如，您可
以选择查看单个用户或特定组的审计记录。可以在特定日期检查某个事件类型的所有记
录。或者，可以选择在特定时间生成的记录。
安装非全局区域的系统可以从全局区域以相同的方式审计所有区域。还可以配置这些系
统，使其收集非全局区域中的不同记录。有关更多信息，请参见第579 页中的“审计和
Solaris Zones”。
审计如何工作？
审计在指定事件发生时生成审计记录。通常，生成审计记录的事件包括：
启动系统和关闭系统
登录和注销
创建进程或损毁进程，或者创建线程或损毁线程
打开、关闭、创建、销毁或重命名对象
使用权限功能或基于角色的访问控制(role-based access control, RBAC)
识别操作和验证操作
由进程或用户执行的权限更改
管理操作，例如安装软件包
特定于站点的应用程序
审计记录从以下三个源生成：
应用程序
异步事件的结果
进程系统调用的结果
一旦捕获相关的事件信息，便会将此信息格式化为审计记录。然后将此记录写入审计文
件。完整的审计记录以二进制格式存储。对于Solaris 10 发行版，也可使用syslog 实用程序
记录审计记录。
以二进制格式存储的审计文件可以存储在本地分区中，也可以存储在挂载了NFS 的文件服
务器中。存储位置可以是同一系统上的多个分区、不同系统上的分区，或者相互链接的不
同网络中系统上的分区。相互链接的审计文件的集合称为审计跟踪。审计记录在审计文件
中按时间顺序累积。每条审计记录都包含识别事件的信息、导致事件的原因、事件发生的
时间，以及其他相关信息。
审计记录还可以使用syslog 实用程序进行监视。这些审计日志可以在本地存储。或者，可
以通过UDP协议将这些日志发送到远程系统。有关更多信息，请参见第522 页中的“审计
文件”。
审计如何工作？
518 系统管理指南：安全性服务• 2006 年9 月
审计如何与安全相关？
Solaris 审计通过显示可疑的或异常的系统使用模式来帮助检测潜在的安全破坏。Solaris 审计
还提供一种根据可疑操作追溯到特定用户的方法，因此可以起到一种威慑的作用。知道自
己的操作正在被审计的用户很少会尝试执行恶意操作。
要保护计算机系统，特别是网络中的系统，需要在系统进程或用户进程开始之前具备控制
活动的机制。安全性要求系统上安装有在活动发生时用于监视活动的工具，同时还要求在
活动发生后报告活动。Solaris 审计的初始配置要求在用户登录或系统进程开始之前设置参
数。大多数审计活动都涉及监视当前事件和报告符合指定参数的事件。Solaris 审计如何监
视和报告这些事件的信息在第28 章和第29 章中详细介绍。
审计不能防止黑客未经授权的侵入。但是，审计服务可以报告特定用户在特定日期和时间
执行了特定操作之类的信息。审计报告可以按登录路径和用户名来标识用户。此类信息可
立即报告给终端和文件，以供以后分析。因此，审计服务提供的数据有助于确定以下内容
：
系统安全如何受到威胁
需要关闭哪些漏洞来确保期望的安全级别
审计术语和概念
以下术语用于说明审计服务。某些定义包含更完整说明的链接。
表27–1 Solaris 审计术语
术语定义
Audit class（审计
类）
一组审计事件。审计类提供选择一组要审计的事件的方法。有关更多信息，请参
见第521 页中的“审计类和预选”。
Audit directory
（审计目录）
二进制格式的审计文件的仓库。有关审计目录类型的说明，请参见第522 页中的
“审计文件”。
Audit event（审计
事件）
被审计的与安全相关的系统操作。为了便于选择，将事件分为各个审计类。有关
可以审计的系统操作的介绍，请参见第520 页中的“审计事件”。
Audit policy（审
计策略）
一组可以在您的站点中启用或禁用的审计选项。这些选项包括是否记录某种审计
数据，同时还包括是否在写满审计跟踪时暂停可审计的操作。有关更多信息，请
参见第531 页中的“确定审计策略”。
Audit record（审
计记录）
存储在审计文件中的审计数据。一条审计记录描述一个审计事件。每条审计记录
由多个审计标记组成。有关审计记录的更多信息，请参见第521 页中的“审计记
录和审计标记”。
Audit token（审计
标记）
审计记录或审计事件字段。每个审计标记描述审计事件的一个属性，例如用户、
程序或其他对象。有关所有审计标记的说明，请参见第585 页中的“审计标记格
式”。
阅读(509) | 评论(0) | 转发(0) |
