审计是规则遵从和安全计划的核心组成部分，也是目前IT部门中普遍实行的做法。关系数据库是第一款嵌入审计功能、并将其作为本地平台功能的企业级应用程序。然而，这次尝试却给审计带来了不好的名声。厂商只是提供了最基本的功能，却没有给数据库管理员提供所需要的性能和易管理性，因此管理员们至今仍对审计功能感到厌恶，并依旧抵制使用数据库审计跟踪功能。
数据库管理员对本地审计功能感到厌恶是有其合理性的：本地审计的性能和数据管理效果曾带给他们梦魇般的遭遇，此外，审计跟踪并不是为了目前它们所从事的任务而设计的。虽然存在着这些不足，但是法规遵从所需的精确、完整的交易记录却是关系数据库审计跟踪所能够提供的。
安全和规则遵从的需要促使人们去使用数据库审计功能，这些日志文件也给人们提供了洞察数据库活动的独特视角。 数据库厂商正致力于优化产品的审计性能，减小历史遗留问题，但用户依然需要谨慎部署，从而避免目前已知的问题。
什么是数据库审计
数据库审计是指对审计和事务日志进行审查，从而跟踪数据和数据库结构的变化。数据库可以这样进行设置：捕捉数据和元数据的改变，以及存储这些资料的数据库所做的修改。典型的审计报告应该包括以下内容：完成的数据库操作、改变的数据值、执行该项操作的人，以及其他几项属性。这些审计功能被植入到所有的关系数据库平台中，并确保生成的记录文件具有较高的准确性和完整性，就好像在数据库中存储的数据一样。此外，审计跟踪还能把一系列的语句转化为合理的事务，并提供业务流程取证（forensic）分析所需的业务环境。
不过，审计功能也存在限制，例如不能对数据访问语句（通常称之为SELECT语句）进行审计。另外，本地数据库审计很难捕捉到用户认可的原始查询（query）和变量（variables），只能从综合的角度对事件做出记录，而日志则可以捕捉到改变前后的数据值。这也使得审计跟踪在检测已改变的内容时，比检测已访问的内容更为有效。
对数据库活动和状态进行取证检查时，审计可以准确的把握事件的本质。对SELECT语句（用户查看数据时会使用）进行检查时，因为本地平台缺乏对这些语句的收集能力，即便利用高级选项实现了这项操作，也会导致性能受到极大损失。既然有简单的方法可以高效地对SELECT语句进行登记（cataloging）（例如，登入失败、尝试查看信用证信息），为什么企业还要选择在本地数据库审计功能上增加其他的数据收集资源。不管怎样，内置的数据库审计功能可以生成事务认证和法规控制的核心信息。
数据库审计的促进因素
在对一些特定的数据库审计创建工具和收集工具进行分析之前，让我们先来探究一下为什么需要加入这些功能。你所在的企业可能存在下面所提的一项也或是所有需求。
规则遵从：法规控制在一些领域起着关键性的作用，例如在管理变动、业务流程验证、系统故障，或生成具有一定准确性和一致性的安全事件材料等方面。这也是数据库审计在欺诈检测方面如此重要的原因所在。此外，数据库审计对与萨班斯-奥克斯利（Sarbanes-Oxley）法案相关的法规遵从也具有重大的意义。管理变动、事务历史记录、特定事件报告通常都是法规控制所要求的。PCI-DSS额外控制也是非常重要的，因为系统权限更改、或管理行为和系统功能的变更都需要进行仔细的审查。
你需要时刻谨记的是，数据库审计并没有在各种规则遵从（包括SOX、PCI-DSS、HIPAA、FERPA或美国国家隐私条例）中被明确地列为一项必须具备的要求。在实践中，审计为政策执行所必要的元素（如，业务流程、数据使用、以及管理任务）都提供了精确、简洁的历史记录。因为所有企业应用程序都需要数据库的支持，并且是数据状态（业务处理的净结果）的唯一权威，所以数据库是实行控制最合理、也最有效的地方。因此，大多数以跟踪特定用户群体、对象或数据元素为核心任务的审计工作都需要进行数据库审计。
安全：数据的安全和隐私是使用数据库审计功能的另一个主要促进因素，比以上所述的几点因素重要得多。捕捉失败的登入、查询，以及管理功能的误用是对系统探查能力进行检测的一种途径。对能够暴露数据的视窗（views）插件进行监控、使用系统功能的公共许可、为普通用户提供管理能力的权限更改，这些都是很常见的使用案例。对谁在何时、何地进行了何种操作等属性进行取证分析，能够提供非常不错的提示信息，以显示数据库的使用是否合法，或是否有可能受到潜在的攻击。为防止数据库被篡改，审计跟踪提供了足够的信息以确定更改的类型，并帮助用户理解必需的纠正措施。通常情况下，审计跟踪用于辅助SIEM（安全信息和事件管理）以及日志管理等安全工具，进行相关性和安全事件的通知。
操作: 数据库审计功能最初是为帮助数据库管理员审查数据库活动而设计的，使得他们可以理解如何分配资源以及对何处的查询做出调整。尽管目前已经有了完成上述任务的工具，并且性能也不错，数据库审计仍然在进行着故障分析和业务流程分析，从而确保数据库的可靠性。因为你可以设想下述场景：当灾难性的故障发生了，你会问“刚才发生了什么事？”，此时，如果进行审计跟踪的话，你可以极为简便的恢复系统。
数据库审计工具及其应用程序
有四种基本平台可以用于创建、收集和分析数据库审计，它们是：本地数据库平台、系统信息/事件管理及其日志管理、数据库活动监控和数据库审计平台。
1. 本地审计：指的是使用本地数据库来进行数据获取，但使用数据库系统本身对事件进行存储、分类、过滤和报告。IBM、微软、甲骨文和Sybase针对这种情况都提供各自不同的解决方案，但本质上都是去获取相同的信息。虽然数据通常存储在数据库中，但却可以导出到纯文本文件、或以XML数据形式提供给其它的应用程序。本地功能的使用节省了与获取、部署和管理专用审计工具相关的成本，但却使得数据库产生了额外的性能开销，对基本的收集和存储也只能进行有限的管理，并且需要人为的进行管理。本地审计发生在数据库范围内，并且只适用于对安置在单个设施内的数据库进行分析。
2. SIEM和日志管理：安全信息和事件管理（SIEM），以及与之类似的日志管理工具都具备了收集审计文件的能力，但却比本地数据库工具提供了更多的功能。请记住，这些工具不会像本地审计那样会导致数据库的开销，从而减轻了数据库的大部分负担，但这需要一个专门的服务器对其进行存储和处理。除了数据库审计日志，这些工具还从网络设备、操作系统、防火墙和应用程序中收集信息。SIEM 和日志管理可以提供综合报告、数据收集、异构数据库支持，数据聚合和压缩能力，这些都是本地数据库审计所不具备的优点。LogLogic和Splunk等公司推出的日志管理系统，专门设计成能够容纳大量数据的系统，并且更专注于管理和报告。而由ArcSight公司和EMC公司安全部门RSA等厂商所推出的SIEM，则被设计成更适用于接近实时的网络安全设备监视，从而更深入地分析事件之间的关联和安全报警等信息。然而，SIEM和日志管理之间的区别可能会逐渐模糊起来，这是因为大多数的厂商都能同时提供两个平台，尽管两者没有完全整合在一起。#p#
3. DAM：数据库活动监控平台被设计成用于监控数据库活动中的威胁，并执行规则遵从控制。诸如Application Security、Fortinet、IBM、Netezza和甲骨文这样的供应商，提供了异构数据库中的事件获取。大多数供应商提供了多种方式来获取信息，包括收集来自网络、数据库所在的操作系统和数据库审计日志等多方查询（queries）信息。DAM 工具被专门用于高速数据检索和实时政策执行。像SIEM工具一样，DAM 工具可以收集来自异构数据库和多数据源的数据，并被设计成用于分析和报警。而与SIEM不同的是，DAM并不是专为数据库而设计的，它更加专注于在应用程序级进行数据库分析，而不是在网络级或系统级上进行。除了对数据库的操作进行取证（forensic）分析，DAM还提供了诸如活动阻塞、虚拟打补丁、过滤（filtering）和评估等高级功能。
4. 数据库审计平台：一些数据库厂商提供了专门数据库，这与日志管理服务器很相似。这些数据库由一个专用的平台组成，它存储从本地数据库审计中获取的日志文件，并把多个数据库的日志文件收集到一个中央位置上。其中一些平台还提供了异构数据库日志文件收集器。报告、取证分析、把日志文件聚集为共同的格式，以及安全存储，这都是此种平台可以带来的好处。虽然这些平台不提供多数据来源、或像DAM那样进行细致的分析，不具备SIEM那样的关联和分析能力,也不像日志管理简单易用，但对于那些专注于数据库审计的IT运营而言，这是一个性价比很高的方法，可以用来生成安全报告和存储取证方面的安全数据。
数据库审计的选择过程
为了有助于进行数据库审计的选择过程，你需要考虑以下各平台类型的特点，以及每个供应商的解决方案。按重要性排序如下：
数据来源：在本文中所描述的信息主要来源是数据库的审计日志，这是由数据库引擎创建的。然而，审计日志随数据库的不同而有所变化，在某些情况下有多种信息都可以归在审计日志这一类。此外，一些平台可以创建某个用户对数据库操作的活动日志。虽然这种日志并不如本地平台所创建的那样准确，但它却能包含所有SELECT语句，并具有更好的引导性能。你需要仔细检查来自不同数据源的哪些数据可用，并看看信息是否足够满足你的安全、运营和规则遵从的要求。
规则遵从：由于依照产业和政府的法规是采用数据库审计解决方案的主要动力，你需要审查政策和供应商提供的产品报告。这些报告能帮助你迅速满足规则遵从的要求，并降低在定制方面的成本。
部署：用户对所有解决方案描述最大的投诉是部署时需要面对很多难题。安装、配置、政策管理、减少误报、自定义报告或数据管理，这些也是用户需要解决的问题。正是由于这个原因，你需要将资源集中从而进行实地比较，以评估工具的优劣。此外，针对一两个数据库的部署进行测试是不够的，你需要在多个数据库之间制定计划以进行一些可扩展性测试，从而模拟真实世界的情景。当然，这增加了概念验证（proof-of-concept）过程的负担，但从长远来看这是值得的，因为厂商存在的UI问题、政策管理和体系结构的不合理选择，只会在实际测试中才会表现出来。
性能：它与供应商平台的关系不是很大，但和数据库本身的数据审计选项联系得更加紧密。目前存在着多个版本和选项，并且本地审计的性能变化也很快，因此你需要运行一些测试。你可能还需要平衡你想收集的数据和你需要的数据，并寻找以制定最少的政策来满足需求的途径，因为政策越多意味着在所有系统上花的经费也更多。
整合：你需要对合作供应商在工作流程、故障报告（trouble-ticketing）、系统与政策管理产品的整合方面进行验证。
审计日志包含很多对审计人员、安全专家和数据库管理员有帮助的信息，但是它们会影响到性能。对于数据库审计可以的提供任何新奇事物，你都需要通过了解其可能增加的负担。审计会引起一些性能上的损失，而根据你执行的情况，损失可能会很严重。但是，这些问题是可以缓解的，并且对于一些商业问题而言，数据库审计日记是规则遵从和安全分析必不可少的环节。
除了本地数据库审计（位于数据库资源上层），我们描述的所有工具都被部署为一个独立的设备或软件。所有数据库审计都提供了中央政策（central policy）和数据管理、报告，并提供数据聚合（data aggregation）功能。SIEM（安全信息和事件管理）、日志管理和数据库活动监控供应商为可扩展性提供了一个层次部署模型，在该模型中多台服务器或设备被分布在大型的IT组织中，以改善用户对处理和存储的需求。
聚合数据使得正被收集的巨大数据量的管理和报告变得容易。此外，信息收集被放在中央服务器中可以保护处理日记不被篡改。
究竟那种方法更适合你，这取决于你的需求、你需要解决的业务问题，以及你愿意为解决问题而投入多少时间和金钱。一个好消息是你可以有大量的选择，比如让自己的数据库管理员去进行数据库本地审计从而获得基础的信息，或者对成千上万的设备进行数据聚合操作。
【编辑推荐】
