数据库审计工具及其应用程序
有四种基本平台可以用于创建、收集和分析数据库审计，它们是：本地数据库平台、系统信息/事件管理及其日志管理、数据库活动监控和数据库审计平台。
1. 本地审计：指的是使用本地数据库来进行数据获取，但使用数据库系统本身对事件进行存储、分类、过滤和报告。IBM、微软、甲骨文和Sybase针对这种情况都提供各自不同的解决方案，但本质上都是去获取相同的信息。虽然数据通常存储在数据库中，但却可以导出到纯文本文件、或以XML数据形式提供给其它的应用程序。本地功能的使用节省了与获取、部署和管理专用审计工具相关的成本，但却使得数据库产生了额外的性能开销，对基本的收集和存储也只能进行有限的管理，并且需要人为的进行管理。本地审计发生在数据库范围内，并且只适用于对安置在单个设施内的数据库进行分析。
2. SIEM和日志管理：安全信息和事件管理（SIEM），以及与之类似的日志管理工具都具备了收集审计文件的能力，但却比本地数据库工具提供了更多的功能。请记住，这些工具不会像本地审计那样会导致数据库的开销，从而减轻了数据库的大部分负担，但这需要一个专门的服务器对其进行存储和处理。除了数据库审计日志，这些工具还从网络设备、操作系统、防火墙和应用程序中收集信息。SIEM 和日志管理可以提供综合报告、数据收集、异构数据库支持，数据聚合和压缩能力，这些都是本地数据库审计所不具备的优点。LogLogic和Splunk等公司推出的日志管理系统，专门设计成能够容纳大量数据的系统，并且更专注于管理和报告。而由ArcSight公司和EMC公司安全部门RSA等厂商所推出的SIEM，则被设计成更适用于接近实时的网络安全设备监视，从而更深入地分析事件之间的关联和安全报警等信息。然而，SIEM和日志管理之间的区别可能会逐渐模糊起来，这是因为大多数的厂商都能同时提供两个平台，尽管两者没有完全整合在一起。
3. DAM：数据库活动监控平台被设计成用于监控数据库活动中的威胁，并执行规则遵从控制。诸如Application Security、Fortinet、IBM、Netezza和甲骨文这样的供应商，提供了异构数据库中的事件获取。大多数供应商提供了多种方式来获取信息，包括收集来自网络、数据库所在的操作系统和数据库审计日志等多方查询（queries）信息。DAM 工具被专门用于高速数据检索和实时政策执行。像SIEM工具一样，DAM 工具可以收集来自异构数据库和多数据源的数据，并被设计成用于分析和报警。而与SIEM不同的是，DAM并不是专为数据库而设计的，它更加专注于在应用程序级进行数据库分析，而不是在网络级或系统级上进行。除了对数据库的操作进行取证（forensic）分析，DAM还提供了诸如活动阻塞、虚拟打补丁、过滤（filtering）和评估等高级功能。
4. 数据库审计平台：一些数据库厂商提供了专门数据库，这与日志管理服务器很相似。这些数据库由一个专用的平台组成，它存储从本地数据库审计中获取的日志文件，并把多个数据库的日志文件收集到一个中央位置上。其中一些平台还提供了异构数据库日志文件收集器。报告、取证分析、把日志文件聚集为共同的格式，以及安全存储，这都是此种平台可以带来的好处。虽然这些平台不提供多数据来源、或像DAM那样进行细致的分析，不具备SIEM那样的关联和分析能力,也不像日志管理简单易用，但对于那些专注于数据库审计的IT运营而言，这是一个性价比很高的方法，可以用来生成安全报告和存储取证方面的安全数据。
数据库审计的选择过程
为了有助于进行数据库审计的选择过程，你需要考虑以下各平台类型的特点，以及每个供应商的解决方案。按重要性排序如下：
数据来源：在本文中所描述的信息主要来源是数据库的审计日志，这是由数据库引擎创建的。然而，审计日志随数据库的不同而有所变化，在某些情况下有多种信息都可以归在审计日志这一类。此外，一些平台可以创建某个用户对数据库操作的活动日志。虽然这种日志并不如本地平台所创建的那样准确，但它却能包含所有SELECT语句，并具有更好的引导性能。你需要仔细检查来自不同数据源的哪些数据可用，并看看信息是否足够满足你的安全、运营和规则遵从的要求。
规则遵从：由于依照产业和政府的法规是采用数据库审计解决方案的主要动力，你需要审查政策和供应商提供的产品报告。这些报告能帮助你迅速满足规则遵从的要求，并降低在定制方面的成本。
华友协同办公管理系统(华友OA)，基于微软最新的.net 2.0平台和SQL Server数据库，集成强大的Ajax技术，采用多层分布式架构，实现统一办公平台，功能强大、价格便宜，是适用于企事业单位的通用型网络协同办公系统。 系统秉承协同办公的思想，集成即时通讯、日记管理、通知管理、邮件管理、新闻、考勤管理、短信管理、个人文件柜、日程安排、工作计划、工作日清、通讯录、公文流转、论坛、在线调查、
部署：用户对所有解决方案描述***的投诉是部署时需要面对很多难题。安装、配置、政策管理、减少误报、自定义报告或数据管理，这些也是用户需要解决的问题。正是由于这个原因，你需要将资源集中从而进行实地比较，以评估工具的优劣。此外，针对一两个数据库的部署进行测试是不够的，你需要在多个数据库之间制定计划以进行一些可扩展性测试，从而模拟真实世界的情景。当然，这增加了概念验证（proof-of-concept）过程的负担，但从长远来看这是值得的，因为厂商存在的UI问题、政策管理和体系结构的不合理选择，只会在实际测试中才会表现出来。
性能：它与供应商平台的关系不是很大，但和数据库本身的数据审计选项联系得更加紧密。目前存在着多个版本和选项，并且本地审计的性能变化也很快，因此你需要运行一些测试。你可能还需要平衡你想收集的数据和你需要的数据，并寻找以制定最少的政策来满足需求的途径，因为政策越多意味着在所有系统上花的经费也更多。
整合：你需要对合作供应商在工作流程、故障报告（trouble-ticketing）、系统与政策管理产品的整合方面进行验证。
审计日志包含很多对审计人员、安全专家和数据库管理员有帮助的信息，但是它们会影响到性能。对于数据库审计可以的提供任何新奇事物，你都需要通过了解其可能增加的负担。审计会引起一些性能上的损失，而根据你执行的情况，损失可能会很严重。但是，这些问题是可以缓解的，并且对于一些商业问题而言，数据库审计日记是规则遵从和安全分析必不可少的环节。
除了本地数据库审计（位于数据库资源上层），我们描述的所有工具都被部署为一个独立的设备或软件。所有数据库审计都提供了中央政策（central policy）和数据管理、报告，并提供数据聚合（data aggregation）功能。SIEM（安全信息和事件管理）、日志管理和数据库活动监控供应商为可扩展性提供了一个层次部署模型，在该模型中多台服务器或设备被分布在大型的IT组织中，以改善用户对处理和存储的需求。
聚合数据使得正被收集的巨大数据量的管理和报告变得容易。此外，信息收集被放在中央服务器中可以保护处理日记不被篡改。
究竟那种方法更适合你，这取决于你的需求、你需要解决的业务问题，以及你愿意为解决问题而投入多少时间和金钱。一个好消息是你可以有大量的选择，比如让自己的数据库管理员去进行数据库本地审计从而获得基础的信息，或者对成千上万的设备进行数据聚合操作。
