数据库安全最佳实践：数据库审计工具调优

[原译文载于：http://www.searchsecurity.com.cn/showcontent_43172.htm]
 

        数据库管理员受命于创建审计记录以符合安全审计和合规审计的要求，但如果他们仅仅去阅读那些叙述如何进行数据库审计的标准操作手册的话，恐怕会很失望。数据库审计工具都有一些特殊的使用技巧，如果不花费时间合理地规划审计流程，使用这些工具可能会使得数据库运行性能遭受惨重打击。由于进行审计而导致数据库运行性能下降超过50%的例子并不少见。这也就意味着，看起来简单的审计工作可能最终会导致数据库变慢、表空间占满、收集过量事件，以及给自己造成维护和报表生成方面的诸多麻烦。

　　相反，在开展审计工作的时候，首先应该建立一个测试数据库，并进行一些基本的性能测试：先关闭审计选项，建立性能基线，然后将其与在不同审计方式、配置和过滤选项下的审计方案测试后所获得的性能指标进行逐个比较。这样做不仅有助于理解每个审计选项对性能的影响，也可以帮助识别资源瓶颈。相信我，这些信息是你在对生产用数据库服务器进行配置之前就必须清楚的。即使是你正准备将数据库日志发送给SIEM或者日志管理系统的时候，创建并维护审计追踪策略仍然是必不可少的工作，别指望那些系统会去帮你优化审计设置。

　　以下是一些用于审计工具优化的数据库安全最佳实践：

　　审计方式：所有的数据库系统都提供了不止一种收集审计数据的方法，因此你可以简单地通过性能对比来比较不同的审计方式。对于IBM DB2数据库而言，审计有时候会是一个巨大的挑战，但是如果你仅仅审计特定用户的行为（事件），DB2事件监控器的性能可能会表现的好一些。对于 Oracle数据库而言，细粒度的审计机制以及一些审计选项提供了很好的伸缩性，但由于它会产生大量审计数据，同样存在潜在地数据库性能下降的风险。

　　审计选项：试着使用不同的审计选项组合，并进行测试。对于Oralce和DB2数据库，可以比较一下用数据库表存储审计数据和使用操作系统文件系统存储审计数据两种方案。前一种方案有助于进行数据检索，而后一种方案性能更优，并且不会占满表空间。

　　资源和管理：通过资源分配优化有助于审计数据的存储，尤其是打算将审计数据存储到数据库的时候，因为此时数据表很容易被写爆。应该创建一些用于归档审计数据和缩减事件存放库表容量的脚本。对于SQL Trace而言，如果将事件流存储在不同的文件中，并放到指定的驱动器下，性能将会提升。审计进程也会占用不少的内存。DB2的审计缓存大小对于性能会产生很大的负面影响，因此要增加对其所占内存的分配。针对Sybase公司的ASE数据库，为了在审计队列不断增加的时候保持处理和响应性能，需要分配大量的内存。为了提升写磁盘的效率，大部分数据库支持数据块优化，可以对只写（write-only）进行优化，并设置块大小的选项，使其大小为审计数据表行大小的整数倍。

　　过滤：过滤差不多是最重要的优化步骤了。请与您的安全与合规团队进行沟通，找出他们真正想要获取哪些审计信息，而不是仅仅对他们想要的信息知道个大概。从收集到的数据流中过滤出一到两种事件类型可以极大地降低存储和运算的负担。对于像SQL Server的Trace这样的工具而言，在收集数据的时候很好用，但是过滤数据就不是很方便。然而，在大多数情况下，所有的数据库都提供对用户事件、管理员事件、元数据操作事件和系统级事件的过滤功能。例如，对于DB2而言，如果进行细致的过滤，性能负担降低80%不足为奇。所以，请花时间了解你到底需要什么数据，然后将你不需要的数据统统过滤掉。

　　在经过性能验证和比较之前，别轻易下结论说哪种审计方法一定就是好的。花些时间掌握那些审计选项，这样可以大大地减轻你审计工作的负担。