安全审计打造固若金汤的数据堡垒(三)

　　在安全审计系列的文章(一)和文章(二)中，我们介绍了审计数据库的登入和登出，审计使用数据库的源头等。本文我们将介绍安全审计中的审计数据库错误等内容。

　　审计数据库错误

　　审计由数据库返回的错误也是很重要的，它是你应实施的首个审计日志之一。从安全的观点来看，这尤其重要。例如，在许多情况下，攻击者会进行很多尝试直至得逞。攻击者可以使用基于UNION的攻击，他需要猜测数据表的正确栏数，直到他得到正确的数字，数据库将会不断地返回一个错误代码，表明SELECT语句所选择的栏数不匹配。如果你记录了所有的错误，就可以确认这种攻击并做出响应。失败的登录是需要进行记录和监视的错误之一，即使你并没审计数据库的登录。最后，任何失败的提升特权的试图操作都表明攻击正在发生。

　　从质量的观点看，错误审计也很重要，它符合合规要求。我们应该确认并修复漏洞和应用程序错误，而记录SQL错误通常是确认这些问题的一种简单方法。因而，即使你关心的是安全问题，将这种信息提供给应用程序的所有者也很有意义，因为谁都不愿意运行存在着问题的代码。幸运的话，这些错误甚至会向你指出那些影响响应时间和可用性的问题。

　　数据库厂商都支持详细的错误审计，你可以参考具体的数据库环境指南。在Oracle中，你可以使用系统触发器：

　　下一步，创建一个可用于新登录的触发器：

　　在SQL Server中，你可以使用审计特性或跟踪特性。如果你选择使用跟踪特性，你需要使用sp_trace_event来建立与错误有关的正确事件。这包括下表所示的事件ID：

　　多种DB2事件监视器与错误审计相关，并且你必须使用这些事件类型。对于所需要的每一种类型，你都应当过滤那些与错误相关的记录。例如，你应当为拒绝访问(ACCESS DENIED )记录选择检查(CHECKING)记录，并在VALIDATE类型中查看AUTHENTICATE_PASSWORD 和 VALIDATE_USER事件。

　　虽然在有些环境中，记录错误和审计错误是可能的，但外部的审计系统更加普遍。如果你监视所有进入的SQL请求和响应，跟踪和报告所有的错误是很简单的，且不会给数据库带来任何额外负担。可以使用任何一种标准集来报告错误，这种信息对于制定基准是很益的。

　　如果你的应用环境不太完善，制定基准就显得很重要。不是每一个数据库和应用环境都十全十美，在多数环境中，有些应用程序会产生数据库错误，即使是在生产过程中也会如此。事实上，应用程序所产生的错误是重复性的：在大体相同的地方发生了相同的错误，这类错误往往是由缺陷引起的，且这些缺陷并不会发生改变。如果制定了错误基准，却突然发现其它方面所产生的错误，或者你看到了完全不同的错误代码，那么你该调查发生了什么问题。

　　存储过程和触发器的来源变更审计

　　由于数据库木马使用了灵活但却完全过程化的编程语言，要隐藏恶意代码是很容易的。因此，你应采取最佳方法来审计这些结构的所有变更。

　　有几种方法可实现这种审计。最简单的方法是基于配置控制的，可以通过定期(如每天)从数据库中检索代码并将其与前一段时期所检索的代码相比较来实施这种审计。通过使用一些工具和脚本程序(如diff)，这种方法相对易于实施。

　　第二种选择是使用一个外部的数据库安全和审计系统。这种系统可以实时地对创建或修改命令向管理员发出警告，并且很轻松地就生成可以详细描述各种变化的报告，下图显示的就是触发器的变更：

　　第三个选择是使用内置的数据库特性。例如，在SQL Server中，你可以使用Recompile事件来跟踪对存储过程的变更：

　　在多数数据库环境中，这种特性是通过DDL审计来支持的，虽然从命令中析取源代码并以一种易于审计的方式维持代码并不容易。