对于一个数据库环境而言，我们可以生成很多类型的审计记录。在上部分的文章《安全审计打造固若金汤的数据堡垒(一)》中，我们介绍了审计数据库的登入和登出，本文我们将接着介绍其他类型的审计。

　　审计使用数据库的源头

　　与登录活动审计相关的是客户源信息的审计。这包括审计哪个网络节点连接到了数据库（例如，使用一个IP地址还是主机名），并且审计使用哪个应用程序访问了数据库。

　　虽然这种信息是我们在审计数据连接时通常都会捕获的值之一，但在SQL调用水平上捕获这种信息非常重要。除了知道一个用户是使用Excel而不是SAP系统连接之外，你还需要知道某次更新是由Excel电子数据表软件还是由SAP系统执行的。因此，你在每次查询和数据库操作中，应该将源程序收集在审计记录中，特别当IP地址能够唯一确认一个用户时。如果你的架构是基于客户/服务器的，那么源IP地址通常会确认一个唯一的用户。这种情况下，根据用户每次SQL调用的IP地址进行跟踪和报告，这同报告终端用户的数据库操作和数据查看同样有益。另一方面，如果你使用一种应用程序服务器架构，那么IP地址不会帮助你确认和报告终端用户，你需要借助于其它技术。

　　在审计和提供审计信息时，你还得做另一个决定，这与你是提供“原始数据”还是更易于使用的数据有关。例如，上图三中的左侧显示了哪些源程序被用于访问运行在155.212.221.84上的SQL服务器上。这种信息对于了解环境的人员来说非常有用。而上图右侧所提供的信息对一般人来说更有意义，这些人并不关心IP地址是什么，却知道HR（人力资源）数据库是怎么回事。如果相关人员理解与开发者工具登录进入人力资源（HR）数据库有关的风险，这种信息显然更有意义。

　　数据提取问题不仅仅与审计数据库使用的客户源有关。这个问题基本与本文所讨论的所有审计有关。对于源的确认来说，如下图四所示，这尤其重要，其中的IP地址可能没有深刻的意义，但属于节点的主机名甚至标签都可提供很多信息。

　　审计正常操作时间之外的数据库使用

　　与审计数据库登录有关的另外一个问题是，审计在正常操作时间之外的活动。这是一个非常直接的需求，并且是企业和合规所要求的一种审计。

　　审计正常操作时间之外的数据库使用非常必要，这是因为在下班期间所进行的活动通常都是可疑的，它有可能是未授权用户试图访问或篡改数据的一个结果和证明。当然，黑客在伪装过程中通常也会试图破坏数据库。

　　审计下班后的活动时，仅仅跟踪上班时间之外的登入和登出是不够的。一般来说，你还需要捕获执行了哪些活动，这通常在SQL水平上完成。如果这种登入可疑，捕获这种登入在使用了什么工具进行了操作是很重要的。全面审计任何用户在正常操作时间之外的所有活动线索是一种很不错的审计，这有助于满足许多规章性的和内部的合规要求。

　　虽然从直观上看，对下班之后的审计更有意义，但在技术层面上，你必须对其定义保持清晰的头脑，因为多数数据库环境是全天工作的，而且你也不希望生成大量的虚假的警告，尤其是当ETL脚本在正常操作时间之外执行海量的数据上传时更是这样。因而，要很好地实施这种审计，关键在于不能把一些一直在下班后运行的任务作为审计线索的一部分。

　　要排除那些发生在上班时间之外的正常活动，还可以使用另一种方法，即使用一种基准。如果你为你的数据库访问制定了基准，就会看到下面的活动：

　　如果你发现每天晚上这类活动都会发生，那么你对下班后的审计就应当排除这些应用程序（SQLLOADER、ETL）所执行的、使用这些登录名的并且是来自这些IP地址的任何活动。仅审计那些偏离基准的对象有助于减少审计内容。

　　审计DDL活动

　　设计的变更审计，或者更具体地讲，DDL的活动审计一直很重要，并且是最常实施的审计线索之一。这是因为设计的变更审计在安全和合规方面，以及从配置管理和过程方面都很重要。从安全的观点来看，DDL命令都是潜在的最具有破坏力的命令，易被攻击者利用从而破坏系统。窃取信息也会经常涉及到DDL命令（例如，创建另外一个表，在析取数据之前将数据复制到其中）。从合规的观点看，许多规范都要求安全人员(管理员)审计对数据表和视图等数据结构的任何修改。

　　对设计变更进行审计的需求并非总是为了安全原因。有时，这是为了避免错误以及为了快速发现问题。因而，对设计变更进行的审计合规需求，通常与配置管理和IP监控任务的部分需求类似。安全人员需要审计数据库的设计变更，并进行保存，作为将来的参考，或作为一种确认和快速解决错误（这种错误可能会破坏数据的便携性或导致数据受到损害）的方法。另外，DDL活动的审计是为了清除开发者和数据库管理员所引起的错误，以及一些可能会引起灾难影响的错误。笔者的一位客户就由于开发人员的一次变更（开发者认为是自己是在开发服务器上完成的，但实际上却错误地在生产服务器上完成了。）而“宕机”了几乎两天时间。对配置管理过程的紧密控制是很重要的，它是DDL审计的首要动因之一。

　　有三种主要的方法可审计数据库的设计变更：

• 使用数据库的审计特性
• 使用外部的审计系统
• 比较设计快照

　　多数数据库环境都允许你使用审计机制、事件监视器等来审计DDL活动。例如，Oracle允许管理员使用基于DDL的系统触发器：

　　在SQL Server中，你要使用迹函数（trace function）,而在Sybase中，你就得使用本地函数。只要你愿意，你都可以析取信息、生成报告、创建基准。你可能还需要外部的审计工具。这些工具不仅收集你所关心的信息，而且还提供一些高级功能，用以实现报告、警告及制定基准等。

　　第三类审计是比较数据库的设计快照，它并不能给你DDL活动的详细审计，其重要性远不如其它两类审计，但它易于实施。如果你并不实施一种真正的审计基础架构，那你可以将这种审计作为一种临时解决方案。这种方案基于定期收集数据库设计的完整定义，并将其与以前的设计规划相比较。你甚至可以使用diff之类的小工具，因为在这种方法中你要做的一切就是确定是否发生了变化。虽然这种方法极易实施，但是在发生变化时，你却无法跟踪到底是谁做的变更，以及何时、为什么发生变更。此外，如果某人恶意地做了变更，并且利用了它，然后又变回到原先的状态，只要整个过程用时很短，你就无法发现。因而，这个选择有时在配置管理计划中可能是够的，但在一个以安全或合规需求为目标的项目中，这常常是不够的。