第 28 章 规划 Solaris 审计

本章介绍如何针对 Solaris 安装设置审计服务。特别是，本章介绍了您在启用审计服务之前需要考虑的问题。以下是本章中规划信息的列表：

• 规划 Solaris 审计（任务列表）

• 确定审计策略

• 控制审计成本

• 有效审计

有关审计的概述，请参见第 27 章，Solaris 审计（概述）。有关在站点上配置审计的过程，请参见第 29 章，管理 Solaris 审计（任务）。有关参考信息，请参见第 30 章，Solaris 审计（参考）。

规划 Solaris 审计（任务列表）

以下任务列表介绍了规划磁盘空间及要记录的事件时所需执行的主要任务。

任务	参考
确定非全局区域的审计策略	如何在区域中规划审计
规划审计跟踪的存储空间	如何规划审计记录的存储
确定要审计的对象及内容	如何规划要审计的对象及内容

规划 Solaris 审计（任务）

您需要选择审计的活动类型，同时需要收集有用的审计信息。审计文件不断增大，可能会很快占满可用空间，因此应该分配足够的磁盘空间。您还需要仔细规划要审计的对象及内容。

如何在区域中规划审计

如果您的系统实现了区域，则可以进行两种审计配置：

• 可以单独配置非全局区域。

• 可以在全局区域中为所有区域配置审计。

1. 确定是否要在非全局区域中自定义审计。

   • 如果不想在非全局区域中自定义审计，请转至步骤 2。

   • 如果要在非全局区域中自定义审计，请考虑以下事项：

     • 还必须配置全局区域。

       要根据非全局区域中的审计配置文件收集审计记录，必须在全局区域中设置 perzone 审计策略。

       ---

       注 –

       如果使用自定义名称服务文件实现非全局区域，则应设置 perzone 审计策略选项。名称服务文件包括 /etc/password、/etc/shadow 和 nsswitch.conf。有关不设置 perzone 选项的信息，请参见审计和 Solaris Zones。

       ---

     • 区域中的审计配置文件由此区域的审计守护进程读取。

       每个区域都运行自己的审计守护进程，具有自己的审计队列，并收集自己的审计日志。这些操作由计算机集中执行。

     • 各个区域都可以设置除 perzone 和 ahlt 以外的所有策略选项。这些策略选项在全局区域中设置。

     如果在每个区域中自定义审计配置文件，应使用如何规划要审计的对象及内容规划每个区域。可以跳过第一步。还必须使用如何规划审计记录的存储规划每个区域。

2. 确定是否需要单映像审计跟踪。

   单映像审计跟踪将正在审计的系统视为一台计算机。全局区域会在系统上运行唯一的审计守护进程，并收集每个区域的审计日志。仅可在全局区域中自定义审计配置文件。

   此配置将所有区域视为单一系统的一部分。要区分区域审计记录，可以设置 zonename 策略。然后，可以使用 auditreduce 命令，按区域来选择审计事件。有关示例，请参见 auditreduce(1M) 手册页。

   要规划单映像审计跟踪，请使用如何规划要审计的对象及内容进行规划。从第一步开始。还必须使用如何规划审计记录的存储规划每个区域。

如何规划审计记录的存储

审计跟踪需要专用文件空间。审计文件的专用文件空间必须可用且安全。各个系统都应具有多个为审计文件配置的审计目录。作为首要任务之一，在任何系统上启用审计之前，都应决定如何配置审计目录。以下过程介绍了规划审计跟踪存储时要解决的问题。

开始之前

如果要实现非全局区域，请在使用此过程之前完成如何在区域中规划审计。

1. 确定您站点所需的审计量。

   针对审计跟踪平衡磁盘空间可用性和站点的安全需求。

   有关如何在保持站点安全的同时降低空间需求，以及如何设计审计存储的指南，请参见控制审计成本和有效审计。

2. 确定要审计的系统。

   在这些系统上，至少为一个本地审计目录分配空间。有关如何指定审计目录的信息，请参见示例 29–3。

3. 确定要存储审计文件的系统。

   确定要保存主审计目录和辅助审计目录的服务器。有关为审计目录配置磁盘的示例，请参见如何创建审计文件的分区。

4. 命名审计目录。

   创建计划使用的所有审计目录的列表。有关命名约定，请参见二进制审计文件名称约定。

5. 确定哪些系统要使用哪些审计目录。

   创建一个列表，显示哪个系统应使用哪个审计目录。此列表有助于您平衡审计活动。有关图解，请参见图 30–1 和图 30–2。

如何规划要审计的对象及内容

开始之前

如果要实现非全局区域，请在使用此过程之前完成如何在区域中规划审计。

1. 确定是否需要单映像审计跟踪。

   如果计划以不同的方式审计各个系统，请从下一步开始。应该针对每个系统完成其余的规划步骤。

   单映像审计跟踪将正在审计的系统视为一台计算机。要为某个站点创建单映像审计跟踪，安装中的每个系统都应进行如下配置：

   • 与其他所有系统使用相同的 audit_warn、audit_event 、audit_class 和 audit_startup 文件。

   • 使用相同的 audit_user 数据库。此数据库可以位于名称服务中。

   • 在 audit_control 文件中具有相同的 flags、naflags 和 plugin 项。

2. 确定审计策略。

   使用 auditconfig -lspolicy 命令查看可用策略选项的简短说明。缺省情况下，仅打开 cnt 策略。有关更全面的介绍，请参见步骤 8。

   有关策略选项的影响，请参见确定审计策略。有关如何设置审计策略的信息，请参见如何配置审计策略。

3. 确定是否要修改事件到类的映射。

   在多数情况下，缺省映射便已够用。但是，如果添加新类、更改类定义，或者确定某特定系统调用的记录无用，则可能需要将某个事件移动到其他类。

   有关示例，请参见如何更改审计事件的类成员关系。

4. 确定要预选的审计类。

   添加审计类或更改缺省类的最佳时机是在启动审计服务之前。

   audit_control 文件中 flags、naflags 和 plugin 项的审计类值适用于所有用户和进程。预选类可以确定是只针对成功情况对审计类进行审计，还是只针对失败情况对其进行审计，或者同时针对两种情况对其进行审计。

   有关如何预选审计类的信息，请参见如何修改 audit_control 文件。

5. 确定系统范围预选审计类的用户例外情况。

   如果决定使用系统范围预选审计类以外的方式来审计某些用户，请修改 audit_user 数据库中单个用户项。

   有关示例，请参见如何更改用户审计特征。

6. 确定最小可用磁盘空间。

   当审计文件系统上的磁盘空间低于 minfree 百分比时，auditd 守护进程将切换到下一个可用审计目录。然后，此守护进程将发送一条警告，指出已超过软限制。

   有关如何设置最小可用磁盘空间的信息，请参见示例 29–4。

7. 决定如何管理 audit_warn 电子邮件别名。

   只要审计系统需要通知您出现了需要管理干预的情况，就会运行 audit_warn 脚本。缺省情况下，audit_warn 脚本会向 audit_warn 别名发送电子邮件，并向控制台发送消息。

   要设置别名，请参见如何配置 audit_warn 电子邮件别名。

8. 决定当所有审计目录已满时需要执行的操作。

   缺省情况下，当审计跟踪溢出时，系统还会继续工作。系统会对已删除的审计记录进行计数，但是不会记录事件。要获得更大的安全性，可以禁用 cnt 策略，同时启用 ahlt 策略。当审计跟踪溢出时，ahlt 策略将停止系统。

   有关如何配置这些策略选项的信息，请参见示例 29–14。

9. 决定是否收集 syslog 格式以及二进制日志格式的审计记录。

   有关概述信息，请参见审计文件。

   有关示例，请参见如何配置 syslog 审计日志。

确定审计策略

审计策略确定本地系统审计记录的特征。策略选项由启动脚本设置。启用审计服务的 bsmconv 脚本会创建 /etc/security/audit_startup 脚本。audit_startup 脚本执行 auditconfig 命令来建立审计策略。有关此脚本的详细信息，请参见 audit_startup(1M) 手册页。

缺省情况下，禁用大多数审计策略选项来最大程度地减少存储需求和系统处理需求。您可以使用 auditconfig 命令动态启用和禁用审计策略选项。可以使用 audit_startup 脚本永久启用和禁用策略选项。

使用下表确定您站点的需求是否可以解释启用一个或多个审计策略选项而造成的额外开销。

表 28–1 审计策略选项的影响

策略名称	说明	更改策略选项的原因
ahlt	此策略仅适用于异步事件。禁用后，此策略允许在不生成审计记录的情况下完成事件。  启用后，此策略会在审计文件系统已满时停止系统。需要管理干预才能清除审计队列、为审计记录提供空间，以及重新引导系统。只能在全局区域中启用此策略。此策略影响所有区域。	当系统可用性比安全性更重要时，适合使用禁用选项。  在安全性极为重要的环境中，适合使用启用选项。
arge	禁用后，此策略将从 exec 审计记录中忽略已执行程序的环境变量。 启用后，此策略会将已执行程序的环境变量添加到 exec 审计记录。与禁用此策略的情况相比，生成的审计记录包含更多详细信息。	与启用选项相比，禁用选项收集的信息要少很多。  当审计数个用户时，适合使用启用选项。怀疑 exec 程序中使用的环境变量有问题时，也可以使用此选项。
argv	禁用后，此策略将从 exec 审计记录中忽略已执行程序的参数。 启用后，此策略会将已执行程序的参数添加到 exec 审计记录。与禁用此策略的情况相比，生成的审计记录包含更多详细信息。	与启用选项相比，禁用选项收集的信息要少很多。  当审计数个用户时，适合使用启用选项。当您确信所运行的 exec 程序异常时，也可以使用此选项。
cnt	禁用后，此策略将阻止用户或应用程序运行。由于没有可用磁盘空间而导致审计记录无法添加到审计跟踪时，会发生阻止。  启用后，此策略允许在不生成审计记录的情况下完成事件。此策略维护已删除审计记录的计数。	在安全性极为重要的环境中，适合使用禁用选项。  当系统可用性比安全性更重要时，适合使用启用选项。
group	禁用后，此策略不会在审计记录中添加组列表。  启用后，此策略会在每条审计记录中添加组列表作为特殊标记。	禁用选项通常可以满足站点的安全要求。  当需要审计哪些组正在生成审计事件时，适合使用启用选项。
path	禁用后，此策略会在每条审计记录中最多记录一条在系统调用期间所使用的路径。  启用后，此策略会将与审计事件结合使用的每条路径记录到每条审计记录中。	禁用选项在审计记录中最多放置一条路径。  启用选项会将系统调用期间使用的每个文件名或路径输入到审计记录中，作为 path 标记。
perzone	禁用后，此策略针对每个系统只维护一个审计配置。全局区域中运行一个审计守护进程。通过预选 zonename 审计标记，可在审计记录中找到非全局区域中的审计事件。 启用后，此策略会为每个区域维护单独的审计配置、审计队列和审计日志。每个区域中运行单独的审计守护进程版本。只能在全局区域中启用此策略。	当您没有特殊的理由为每个区域维护单独的审计日志、队列和守护进程时，禁用选项很有用。  当您无法仅通过预选 zonename 审计标记来有效监视系统时，启用选项很有用。
public	禁用后，如果预选文件的读取，则此策略不会将公共对象的只读事件添加到审计跟踪。包含只读事件的审计类包括 fr、fa 和 cl。 启用后，如果预选了适当的审计类，则此策略会记录公共对象的每个只读审计事件。	禁用选项通常可以满足站点的安全要求。  启用选项很少有用。
seq	禁用后，此策略不会将序列号添加到每条审计记录中。  启用后，此策略会将序列号添加到每条审计记录中。sequence 标记保留序列号。	当审计顺利进行时，禁用选项便已够用。  当启用 cnt 策略后，适合使用启用选项。利用 seq 策略，可以确定废弃数据的时间。
trail	禁用后，此策略不会将 trailer 标记添加到审计记录中。 启用后，此策略会将 trailer 标记添加到每条审计记录中。	禁用选项会创建一条较短的审计记录。  启用选项会使用 trailer 标记清晰地标记每条审计记录的结束。trailer 标记经常与 sequence 标记结合使用。trailer 标记可以使审计记录的重新同步更简单、更精确。
zonename	禁用后，此策略不会在审计记录中包括 zonename 标记。 启用后，此策略会在非全局区域的每条审计记录中包括 zonename 标记。	当无需跨区域比较审计行为时，禁用选项很有用。  当需要区分各区域中的审计行为并对其进行比较时，启用选项很有用。

控制审计成本

由于审计会占用系统资源，因此必须控制所记录内容的详细程度。当您决定要审计的内容时，请考虑以下审计成本：

• 延长处理时间带来的成本

• 分析审计数据的成本

• 存储审计数据的成本

延长审计数据的处理时间带来的成本

延长处理时间带来的成本是审计成本中最不重要的部分。第一个原因是在执行需要大量运算的任务（例如映像处理、复杂计算等）时一般不会进行审计。另一个原因是单用户系统的成本通常会小到可以忽略。

分析审计数据的成本

分析成本大致上与收集的审计数据量成比例。分析成本包括合并与查看审计记录所需的时间，还包括将记录进行归档并保存在安全位置所需的时间。

生成的记录越少，分析审计跟踪数据所需的时间就越短。下面的存储审计数据的成本和有效审计部分介绍了高效进行审计的方法。有效的审计可减少审计数据量，同时仍保证足够的审计范围以实现站点的安全目标。

存储审计数据的成本

存储成本是最重要的审计成本。审计数据量取决于以下各项：

• 用户数

• 系统数

• 使用量

• 所需的可跟踪与可说明的程度

由于上述因素随站点不同而不同，因此没有公式可预先确定为审计数据存储预留的磁盘空间量。请遵循以下原则：

• 审慎地预选审计类，以减少生成的记录量。

  全部审计（即使用 all 类）会使磁盘空间很快被占满。即使编译程序之类的简单任务也可能生成很大的审计文件。一般的程序在一分钟之内可能会生成数以千计的审计记录。

  例如，通过忽略 file_read 审计类 fr，可以显著减少审计量。通过选择仅针对失败操作进行审计，有时也会减少审计量。例如，与针对所有 file_read 事件进行审计相比，针对失败的 file_read 操作（即 -fr）进行审计而生成的记录会少很多。

• 有效的审计文件管理也很重要。创建审计记录后，通过文件管理可减少所需的存储量。

• 了解审计类

  配置审计之前，应该了解类中包含的事件类型。可以更改审计事件到类的映射来优化审计记录的收集。

• 设计针对您站点的审计方案。

  以可获知的因素为基础，设计您的审计方案。此类度量包括站点所需的可跟踪量，以及管理的用户类型。

有效审计

以下技术可帮助您在更有效地进行审计的同时实现组织的安全目标。

• 任何时刻均只对特定百分比的用户同时进行随机审计。

• 通过合并、减少和压缩文件来降低审计文件的磁盘存储需求。制订对文件进行归档、将文件传送到可移动介质和脱机存储文件的过程。

• 实时监视审计数据有无异常行为。您可以扩展已经开发的管理和分析工具，以便处理 syslog 文件中的审计记录。

  您还可以设置监视某些活动的审计跟踪的过程。可以编写这样一个脚本，在它检测到异常事件时，以触发自动增加对特定用户或特定系统的审计作为响应。

  例如，可以编写执行以下操作的脚本：

  1. 监视所有审计文件服务器上审计文件的创建。

  2. 使用 tail 命令处理审计文件。

     通过对 tail -0f 命令输出内容实施 praudit 命令管道操作，可以在生成记录时产生审计记录流。有关更多信息，请参见 tail(1) 手册页。

  3. 分析此流以查看是否存在异常消息类型或其他指示符，并将分析结果提供给审计者。

     或者，可以使用脚本来触发自动响应。

  4. 经常监视审计目录，以查看是否有新的 not_terminated 审计文件出现。

  5. 如果仍在运行的 tail 进程不再向其文件中写入信息，请终止这些进程。