数据库安全审计常见8种缺陷
数据库存在的问题及建议
数据库存在的问题及建议一、引言数据库是现代信息系统的核心，它承载着企业的数据资产，为企业的决策和运营提供了重要支持。
然而，在实际使用过程中，我们也会发现一些问题，这些问题不仅影响了数据库的性能和稳定性，也会对企业的业务产生负面影响。
本文将从多个角度分析数据库存在的问题，并提出相应建议。
二、安全性问题1. 数据泄露数据库中存储着大量敏感信息，如客户信息、交易记录等。
如果这些信息被恶意获取或泄露，将会给企业带来极大损失。
因此，在保证数据完整性和可用性的前提下，加强数据库安全措施尤为重要。
建议：（1）加强访问控制：限制用户权限、设置密码策略等；（2）加密敏感数据：对敏感数据进行加密保护；（3）备份与恢复：定期备份数据并测试恢复流程。
2. SQL注入攻击SQL注入攻击是指攻击者通过构造恶意SQL语句来绕过应用程序的身份验证机制或获取未授权访问权限。
这种攻击方式比较常见且难以防范。
建议：（1）过滤用户输入：对用户输入进行过滤，防止恶意注入；（2）使用参数化查询：使用参数化查询语句代替字符串拼接；（3）限制数据库用户的权限：将数据库用户权限控制在最小范围内。
三、性能问题1. 数据库响应时间慢数据库响应时间慢会影响系统的性能和用户的体验。
这种问题可能由于多种原因引起，如大量数据查询、索引失效等。
建议：（1）优化SQL语句：通过优化SQL语句、合理使用索引等方式提高查询效率；（2）分区表：对大表进行分区，提高查询速度；（3）增加缓存：增加缓存可以减少数据库IO操作。
2. 数据库死锁当多个事务同时请求同一资源时，可能会出现死锁问题。
这种问题会导致事务无法继续执行，从而影响系统的性能和稳定性。
建议：（1）合理设计事务：尽量避免长时间占用资源；（2）设置超时机制：设置超时机制可以避免死锁持续时间过长。
四、可维护性问题1. 数据库设计不合理数据库设计不合理会导致数据冗余、难以维护等问题。
这种问题在系统开发初期应该尽量避免。
数据库内部安全审计
数据库内部安全审计一、背景在信息系统的整体安全中，数据库往往是最吸引攻击者的目标，许多网络攻击的根本目的就是获取存放在数据库中的重要信息。
传统的数据库安全保障方法一定程度上提高了数据库系统的安全性，但是它们大多是被动的安全技术，以预防为主，无法有效地制止入侵行为，特别是对于数据库用户( 如数据库管理员等) 的权限滥用等内部攻击常常是无能为力的。
内部威胁问题具体表现为:(1)非故意的授权用户攻击，即用户不小心访问到了通常不访问的敏感信息，严重的是无意间将其错误地修改或者删除了；(2)盗取了正常用户信息的攻击者对数据库进行操作，他们拥有合法的访问权限，对数据库数据进行肆意的盗窃和破坏；(3)心怀不轨的内部工作人员对数据库的恶意攻击。
据统计，数据库安全问题近80%来自数据库系统内部，即数据库系统授权用户没有按照自身授权进行数据操作，而是跨越权限篡改或破坏数据。
根据2013年Verizon的数据泄露调查报告:所有数据泄露事件中76%源自授权用户对敏感数据的访问；在47000多件安全事故中，69%的攻击来自于内部人员。
京东发生的大型数据泄露事件造成5O亿条公民信息流出，导致用户损失数百万元，罪魁祸首就是内部工作人员。
内部原因造成的数据库损失发生率和影响度都远远超过人们的想象。
由于此类安全问题发生在系统集团内部，因此，对数据库的危害极大，并且传统的入侵检测方法和数据库安全规则都不能有效防御这些问题，即使一些防火墙软硬件也无法实时检测内部入侵。
因此，针对数据库系统中用户异常行为检测研究就显得尤为重要。
据统计，传统的数据安全模型是上个世纪 70 年代提出的，并且得到较好发展。
到目前为止，在数据库上实现的安全策略基本上没有变化，仍旧为访问控制、用户认证、审计和加密存储。
安全审计的任务是对用户已经完成的行为，给予回追式的分析，并对该行为的结果给出最终评价。
这些安全机制在数据库管理上取得了较好成绩，但是面对高素质攻击人员、多样化攻击手段和复杂的网络环境，这些安全机制将无法实时监测入侵行为，保护数据库与数据的安全。
十大数据库安全威胁
对数据库结构威胁最严重的十种威胁。
威胁 1 - 滥用过高权限当用户（或应用程序）被授予超出了其工作职能所需的数据库访问权限时，这些权限可能会被恶意滥用。
例如，一个大学管理员在工作中只需要能够更改学生的联系信息，不过他可能会利用过高的数据库更新权限来更改分数。
09年的时候宁夏大学报案，发现他们的学籍数据库遭到改动，很多人的成绩被改了，后来经西夏区警方查实为黑客改动，暴露了数据库在分层管理不严的缺陷。
威胁 2 - 滥用合法权用户还可能将合法的数据库权限用于未经授权的目的。
假设一个恶意的医务人员拥有可以通过自定义 Web 应用程序查看单个患者病历的权限。
通常情况下，该 Web 应用程序的结构限制用户只能查看单个患者的病史，即无法同时查看多个患者的病历并且不允许复制电子副本。
但是，恶意的医务人员可以通过使用其他客户端（如MS-Excel）连接到数据库，来规避这些限制。
通过使用 MS-Excel 以及合法的登录凭据，该医务人员就可以检索和保存所有患者的病历。
这种私自复制患者病历数据库的副本的做法不可能符合任何医疗组织的患者数据保护策略。
要考虑两点风险。
第一点是恶意的医务人员会将患者病历用于金钱交易。
第二点可能更为常见，即员工由于疏忽将检索到的大量信息存储在自己的客户端计算机上，用于合法工作目的。
一旦数据存在于终端计算机上，就可能成为特洛伊木马程序以及笔记本电脑盗窃等的攻击目标。
威胁 3 - 权限提升攻击者可以利用数据库平台软件的漏洞将普通用户的权限转换为管理员权限。
漏洞可以在存储过程、内置函数、协议实现甚至是 SQL 语句中找到。
例如，一个金融机构的软件开发人员可以利用有漏洞的函数来获得数据库管理权限。
使用管理权限，恶意的开发人员可以禁用审计机制、开设伪造的帐户以及转帐等。
威胁 4 - 平台漏洞底层操作系统（Windows 2000、UNIX 等）中的漏洞和安装在数据库服务器上的其他服务中的漏洞可能导致未经授权的访问、数据破坏或拒绝服务。
数据库安全风险分析和解决方案
数据库安全风险分析和解决方案1.数据库安全风险分析经过十多年的发展，目前各行各业的信息系统都已经得到了长足发展，一套高效、安全、可靠的信息系统已经是衡量一个政府或者企业的管理效率的关键指标，政府和企业也都更加依赖于信息系统，所以信息系统能否稳定、安全的运行也是大家越来越关注的话题。
我们稍作统计和回顾，不难发现最近几年信息安全话题讨论越来越激烈，信息安全事件也越来越多。
近期美国“棱镜”事件和英国“颞颥”事件被曝光震惊全世界、2012年震惊中国的互联网用户信息大泄露和三大运营商个人隐私信息批量泄露等。
这些信息安全事件攻击手段多样，但我们不难发现有一个共同的特征，他们的攻击和窃取目标就是用户的隐私数据，而大部分数据的承载主体就是——数据库系统。
所以我们今天对数据库安全进行一些简要的分析。
如果说各类业务系统是基础部件，畅通的网络是血液，那心脏理应就是数据库系统。
其存储了所有的业务数据，牵涉到所有用户的切身利益。
所以其要求各类数据必须是完整的，可用的，而且是保密的。
如果发生数据丢失或者数据不可用，犹如心脏出现问题，其他所有的基础部件也将无法正常工作，直接导致整个业务系统的终止，少则让企事业单位受到经济和名誉的损失，大则直接威胁企业的生存和发展，甚至威胁国家和社会的稳定和安全。
当然承载数据库的服务器以及网络设备、安全设备、存储系统、应用软件等相关配套设置的安全性也是非常重要的，一旦由于内部操作失误、故意泄露或者外部入侵等都可能给业务数据带来致命的安全威胁。
对于数据库，我认为其安全威胁主要来自于几方面，一个是数据库自身安全，一个是数据库运行环境和数据库运行维护过程的安全。
1)首先我们来分析一下数据库自身安全，我们认为中国面临一个最大的安全威胁就在于绝大部分数据库都是采用oracle、sqlserver、mysql等国外数据库系统。
我们无法了解这些国外数据库系统是否留下了后门，是否嵌入了不安全的代码等，最近美国棱镜门就更加印证了我们的结论，因为美国多个通信设备厂家都参与了棱镜计划。
数据库安全防护常见问题解析与应对策略
数据库安全防护常见问题解析与应对策略数据库作为企业数据资产的重要组成部分，存储着各种敏感的信息，包括客户数据、财务数据及其他重要数据。
因此，保护数据库的安全性对于企业来说至关重要。
然而，数据库安全面临着各种不同的威胁和风险，如数据泄露、未授权访问和数据篡改等。
本文将分析数据库安全的常见问题，并提供一些应对策略。
1. 数据库漏洞利用数据库软件常常会存在各种漏洞，黑客可以通过利用这些漏洞来获取对数据库的未授权访问权。
企业应该定期检查数据库供应商的安全公告，及时安装数据库补丁以修复已知漏洞。
此外，与数据库相关的其他软件，如操作系统和网络设备，也需要定期更新和维护。
2. 弱密码弱密码是数据库安全的常见问题。
使用强密码对数据库进行身份验证是关键。
强密码应包含大小写字母、数字和特殊字符，并且长度应至少为8个字符。
对于重要的账户，应该使用多因素身份验证，如令牌或生物识别技术。
3. 数据备份和恢复定期进行数据库备份是防止数据丢失和数据库恢复的重要步骤。
备份数据需要存储在安全的位置，并进行加密保护。
同时，应该通过测试恢复过程来验证备份的完整性和可用性。
4. 数据访问控制数据库访问应该按照“最小权限原则”进行控制，即给予用户只能满足其正常工作所需的最低权限。
管理员账户和系统账户的权限应严格管控，并定期审计和监控这些账户的活动。
5. 数据传输安全在数据传输过程中可能面临泄露或篡改的风险。
为确保数据传输的安全，企业可以使用传输层安全协议（TLS）或虚拟专用网络（VPN）来加密数据。
此外，所有与数据库进行通信的应用程序和用户都应该经过身份验证和授权。
6. 审计和监控数据库的审计和监控是防止未授权活动的关键。
通过记录和审计数据库的访问和活动，可以快速检测到潜在的安全威胁。
此外，使用实时监控技术可以及时发现异常活动并采取相应的措施。
7. 加密与脱敏对于一些关键的敏感数据，如密码和信用卡信息，企业应该使用加密技术来保护数据的机密性。
数据中心存在的安全缺陷
数据中心存在的安全缺陷数据中心在为人们提供极大便利的同时，也无可避免地面临着极其严峻的安全挑战。
因此，如何保证数据中心安全可靠地运行，确保数据中心数据的完整性、准确性和可靠性，就成为了亟待解决的问题。
一数据中心的安全现状数据中心是现代社会的信息资源库，能够提供各项数据服务，它通过互联网与外界进行信息交互，响应服务请求。
由于互联网的高度开放性，使得数据中心也成为了互联网上的一个组成节点，同样也面临着其他节点受到的共同威胁：病毒、蠕虫、木马、后门及逻辑炸弹等。
在少数别有用心的人眼中，数据中心保存的各种关键数据是无价之宝，在经济利益或其他特定目的的驱使下，这些人会利用种种手段对数据中心发动攻击或企图渗透进入数据中心，对数据中心的关键数据进行各种非授权访问和非法操作。
由此可能带来数据中心的关键数据被监听、窃取、仿冒和篡改，服务器运行缓慢、性能下降或死机而无法对外提供数据服务，甚至硬件被损坏，造成重大损失。
由于数据中心在网络中直接担负着汇总数据、整合数据资源、提供数据服务和维护全网运行等任务，是各种网络活动得以安全运行的基础，必须能够提供较快的响应速度，满足全时段提供服务的要求。
因此，数据中心的安全运行就显得至关重要。
二数据中心存在的安全缺陷当前，数据中心为应对种种安全威胁，采取了许多安全机制和防范措施，综合而言，主要采取的应对策略有防病毒技术、防火墙技术、入侵检测技术和数据库安全审计，有效确保了数据中心的可靠运行。
这些技术通过不同机制来应付种种安全威胁，各有所长，取得了极大成效。
然而从实践结果来看，仍然存在不小的缺陷，如下所述：①尽管数据中心安装了不同类型的防病毒硬件或杀毒软件，但是，数据中心安全不仅仅包括防病毒的问题，还包括外来非法侵人检测与安全策略执行等方面，防病毒技术难以完全解决这些方面的威胁。
②数据中心安装软硬件防火墙后，可以通过设定规则来阻止非授权访问，但是仍无法避免垃圾邮件及拒绝服务的侵扰。
数据不安全的各种情形
数据不安全的各种情形
1. 数据泄露：这是数据不安全最常见的情况之一。
数据可能会通过网络攻击、恶意软件、社会工程学等手段被盗取。
一旦数据落入不法分子手中，他们可能会利用这些数据进行欺诈、身份盗窃或其他违法活动。
2. 数据丢失：数据可能会因为硬件故障、软件错误、人为错误或自然灾害等原因而丢失。
数据丢失可能会导致业务中断、客户流失以及经济损失。
3. 数据损坏：数据可能会因为存储设备故障、磁场干扰、病毒或恶意软件等原因而损坏。
数据损坏可能会导致数据无法使用或部分丢失。
4. 数据滥用：员工或第三方可能会滥用其访问权限，读取或修改他们本不应该访问的数据。
这可能会导致数据泄露、数据损坏或其他违规行为。
5. 数据未加密：如果数据在传输或存储过程中未进行加密，那么任何人都可以轻松读取和访问这些数据。
这可能会导致敏感信息泄露，例如信用卡信息、个人身份信息等。
6. 缺乏访问控制：如果没有适当的访问控制措施，任何人都可以访问和修改数据。
这可能会导致数据被误操作、篡改或删除。
为了确保数据的安全性，企业和个人应该采取适当的数据保护措施，例如数据加密、访问控制、备份和恢复、安全培训等。
同时，定期进行数据安全评估和审计，以发现和解决潜在的安全风险。
数据库管理中常见的安全风险及应对策略
数据库管理中常见的安全风险及应对策略随着信息技术的飞速发展和数据的快速增长，数据库管理的安全性显得尤为重要。
数据库管理中存在各种常见的安全风险，包括未经授权的访问、数据泄露、数据篡改等。
本文将探讨这些风险，并提供相应的应对策略。
数据库管理的安全风险主要包括以下几个方面：1. 未经授权的访问：未经授权的访问是数据库管理的最常见的安全风险之一。
违规的用户可以通过各种方式获取数据库的访问权限，并操纵敏感数据。
应对策略：为了防止未经授权的访问，数据库管理员可以采取以下几种策略。
首先，建立严格的访问控制机制，只允许授权用户访问数据库。
其次，定期审查和更新用户权限，及时撤销不需要访问数据库的用户权限。
最后，加密数据库中的敏感数据，以便即使数据库被未经授权的人员获取，也无法破解数据加密。
2. 数据泄露：数据泄露是数据库管理中的另一个重要的安全风险。
黑客或内部恶意人员可以通过各种方式获取数据库中的机密信息，并将其泄露给未授权的人员。
应对策略：为了防止数据泄露，数据库管理员可以采取以下几种策略。
首先，实施严格的身份验证机制，确保只有授权用户可以访问敏感数据。
其次，加密数据库中的敏感数据，以防止数据泄露后被人轻易破解。
此外，定期进行安全性审计，以检测潜在的数据泄露风险。
3. 数据篡改：数据篡改是指黑客或内部人员对数据库中的数据进行非法修改的行为。
数据篡改可能导致信息不准确，给组织带来重大损失。
应对策略：为了防止数据篡改，数据库管理员可以采取以下几种策略。
首先，实施完整性检查机制，确保数据在被修改之前和之后保持一致。
其次，限制对数据库的修改权限，只有授权人员才能进行数据修改操作。
最后，定期备份数据并进行完整性验证，以便在数据篡改发生时及时恢复数据到正常状态。
除了上述常见的安全风险之外，数据库管理还存在诸如文件系统漏洞、SQL注入攻击、暴力破解等安全风险。
面对这些风险，数据库管理员可以采取以下相应的应对策略：1. 定期进行安全性测试和漏洞评估，及时发现并修补数据库中的漏洞，以减少黑客入侵的机会。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
数据库安全审计常见8种缺陷作者安华金和刘晓韬随着信息化的发展，数据库安全问题成为当前政府和企事业单位用户关注的焦点，数据库审计产品已经成为当前信息安全产品的盛宠。
当前在市面上存在着几十种数据库审计产品，这些产品集中起来大约可分四种类型：（1）在网络审计产品的基础上经过简单包装推出数据库审计产品的既有网络审计产品厂商，比如国内几大安全厂商推出的数据库审计产品，安全圈都知道，不再例举；（2）针对数据库通讯协议的特点开发出专门的数据库审计产品的国内细分领域安全厂商，比如安华金和、思福迪、国都兴业、帕拉迪等；（3）国外的数据库审计产品，比如Imperva、Guardium等；（4）OEM第三方的数据库审计产品，OEM对象可能来自国内，也可能来自国外，比如Imperva或韩国的DBInsight。
随着国产化采购政策的推动，处于安全性的考虑，国外数据库审计产品，不在本文的评论范围内。
笔者将重点对国内数据库审计产品常见缺陷进行分析。
以下分门别类，针对最常见的8类数据库安全审计产品缺陷展开讲解。
长SQL语句漏审大多数的SQL语句都在1K以里长度，市面上的数据库审计产品大多都能准确记录下，也能实现正常的解析；但在SQL语句超过1.5K时，很多的数据库审计产品就会发生漏审，或者只能审计下部分SQL语句。
一般Oracle一个通讯包的长度在2K，单一包内能够容纳的语句长度大约在1.4K多一点（大约为1460）；超过这个大小的SQL语句一般会拆分成多包；在Oracle 11g下通常通讯包为2K，最大可以达到8K；对于Oracle数据库没有明确说明可兼容的SQL语句的长度，有的说32K或64K是个临界点，但笔者也曾作过尝试2M做的SQL语句也能发送并被Oracle正常解析。
对于一些数据库审计产品，由于没有将多个SQL通讯包进行有效解析和关联，在发生长SQL语句时会发生无法解析或解析不全的情况；具体表现是，对于长SQL语句并未记录，或仅记录了前半部分。
这种情况的危害是，对于有些业务系统中自身就包含长SQL语句，比如经分系统，报表系统，这些SQL语句会被漏记；同时，一些黑客或攻击人员会利用这样的一些漏洞，进行数据库攻击而不留下痕迹。
比如，若某个数据库审计产品，是基于单包解析机制进行的，则对于超过1.5K的SQL语句无法记录或仅记录了前1.5K，则攻击者可以首先加入1.5K长的注释，然后再写语句，这样会发生漏审或被审计下来的信息无效。
多语句无法有效分割多语句是SQL Server上的一个特定情况。
在其它的数据库管理系统中，语句之间都有明确的分割标识；而在SQL Serve中语句之间可以没有明确的分隔符。
下面是一个示例：use opencms SET NOCOUNT ON select * from opencms.opencms.CMS_LOG where1=1 or ‘a’ =’b’ select * from opencms.opencms.CMS_HISTORY_PROJECTS where 1=1在这些语句之间没有类似于；号这样的明确分隔标识符；它们实际代表了四条语句：use opencmsSET NOCOUNT ONselect * from opencms.opencms.CMS_LOG where 1=1 or ‘a’ =’b’select * from opencms.opencms.CMS_HISTORY_PROJECTS where 1=1 SQL Server会将这些语句不加分割地组织在一个数据库通讯包中发送；对于一些专业化程度不高的数据库审计产品，会将这些语句作为一条语句审计下来。
有效地实现多语句分割，需要非常专业的SQL解析技术。
一些简单的方法，比如用select、use 、set这样的关键字来进行语句分割，稍微复杂的情况就不好处理了；下面这个示例，就无法用这种简单的方法处理：Select * from t1 where t1.col1 = 1 union select * from t2 where t2.col1 = 1 select * from t2 where t2.col1 = 1即使采用稍微复杂一些的技术，比如正则表达式，也很难做到准确切割；非专业化的数据库审计产品都存在这个缺陷。
对无法准确切割多语句的缺陷，在不同的产品中表现不同，所造成的审计问题也不同，但大体可以总结为如下几点：（1）在审计记录中，不能准确记录下每条语句的SQL操作类型，从而造成一些高危操作不能有效地被识别或告警，比如drop、truncate这些语句。
（2）在审计记录中，不能准确记录下每条SQL语句的数据库对象，从而造成对敏感对象的访问不能有效地被识别或告警。
（3）在审计记录中，不能准确地记录每条语句是否执行成功；比如多条语句中第一条语句执行成功，后面的语句执行失败了，往往会被整体记录为一个结果，往往记录的结果是成功。
（4）在审计记录中，不能准确地反馈出每条语句造成的影响行数，从而也无法触发基于影响行的安全策略；往往记录下来的都是第一条语句的影响行，其余语句的影响行都被忽略掉了。
数据库对象解析错误数据库审计产品中一个重要需求是要有效记录下来SQL语句的操作类型、访问对象；根据这些操作类型和访问对象，审计产品可以有效地制订告警策略，可以有效地根据操作类型、访问对象进行事后的追踪与检索。
我国相关部门的数据库审计产品标准中要求：应对数据库网络访问对象的名称进行准确审计，包括数据库服务器名称、IP名称、数据库名称、表、视图、序列、包、存储过程、函数、库、索引和触发器等。
目前国内大多数数据库审计产品都会宣称支持对SQL语句操作类型和访问对象的审计支持；但事实上，很多审计产品的支持能力有限，往往只能支持一些简单语句的解析，比如这样的语句：Select * from tbl1 where col1 > ’1’;但笔者曾经见过一家大型的信息安全厂商的产品，仅仅是在表名前增加一个schema 名称，就发生了令人震惊的错误；这个产品居然将schema名称审计为了表名。
如上面这条语句改为；Select * from user1.tbl1 where col1 > ‘1’;这种数据库审计产品就会将user1记录为表名。
事实上，上面被误报的例子，是一个非常简单的例子，大多数专业的数据库审计产品都不会犯这样的错误。
事实上，真正的挑战要比上面的例子复杂很多。
参数审计错误参数绑定是数据库编程中常用的一种方法，通过这种方法，数据库系统可以减少编译次数，快速执行，提升效率；但这种编程方法将对数据库的审计带来挑战，在笔者所见到的若干数据库审计产品中，在这种情况下都出了不少的错误。
有的是漏审了语句，有的是记录下了操作的语句，但将具体执行时所使用的参数记错了或漏记了。
这些缺陷对于审计产品无疑很是致命。
为了详解这种情况，我们来看一下参数绑定的基本概念。
我们在常规的图形化或命令行工具中，往往都是直接写上SQL语句，比如：Selec t * from person_info where id=’12XXXXX6722’;在这里查询条件是身份证号码。
根据身份证号码查询个人信息，是一种常用功能，也是会重复使用的语句，为了提升效率，编程中可以这么写：String sql1=’Select * from person_info where id=?;’PreparedStatement pStmt = testConn.getConnection().prepareStatement(sql);pStmt.setInt(1, ’12XXXXX6722’);pStmt.execute();下一次再使用时，就不用再发送语句了，可以直接发送：pStmt.setInt(1, ’22XXXXX5399’);pStmt.execute();对于数据库审计系统而言，单纯地记录下来‘Select * from person_info where id=?’是存在缺陷的，因为你无法明确额操作人员到底访问了哪个用户的信息，必须明确下来具体的参数才行。
这就要求将设定的参数，与Prepare的语句有效的关联，形成可视化的审计记录展现: Sele ct * from person_info where id=’12XXXXX6722’;Select * from person_info where id=’22XXXXX5399’;这实际上要求审计系统比起单纯的记录语句要完成更多的工作；其中一个重要任务的就是句柄追踪，本质上SQL语句的执行过程追踪就是句柄追踪过程。
在上面显示的例子中，pStmt.execute()，在通讯过程中并不发送具体的语句，而仅是告知服务器要执行哪个语句句柄，服务器端会根据内部记录的句柄所对应的已经编译完成的SQL语句的执行计划，进行语句执行。
数据库审计要完成相应的工作，需要执行类似的过程，在系统的内部也维护这样的映射关系；同时由于大多数数据库的句柄，是在会话级的，句柄是可重用的，因此在数据库审计中还要有效地维护句柄与session的关联，以及句柄的消亡。
在句柄维护之外，另一个有挑战的工作就是参数的还原。
参数的还原，首要的是要明确参数所对应的句柄；在调用pStmt.setInt(1, ’22XXXXX5399’)时，在网络中发送的包，会标明这个参数是针对哪个句柄的，是针对第几个参数的。
作为数据库审计产品，需要将参数与语句进行映射；更重要地要准确地填回参数所在的位置，上面这个例子由于只有一个参数，没有什么挑战性，参数的绑定情况远比这个复杂。
除了以上列举的4个常见缺陷，在实际情况下还有一些常见的缺陷：错误的应答结果，特别是影响行数解析不正确对于SQL操作是否成功，是数据库审计的基本需求；对数据库操作读取或影响了多少行是用户的实际需求。
但SQL操作成功与否的准确记录，需要仰仗SQL语句的合理切割和句柄的准确追踪及对返回结果集的完全解析；大多数数据库审计产品在多语句情况，或者通过FETCH操作批量获取等环节下，无法准确获得查询执行的正确性以及影响行数。
充满失真率的应用用户关联市场上的数据库审计产品大多数都宣传支持三层关联审计，实现SQL语句与业务用户的关联。
这种基于三层关联审计的技术，是通过http协议中的参数与SQL语句中的参数的匹配，以及时间的匹配来完成的，属于模糊匹配。
这种方法在http参数经过加工后或基于逻辑判断后再发出SQL语句，也即SQL语句的参数与http参数没有直接的匹配关系时将完全失效；在高并发时更是一个灾难。
这种方法的准确率往往很难超过80%。
不够专业化的审计界面这个问题主要是针对基于网络审计而发展来的数据库审计产品，这种产品由于在设计之初就不是专门面向数据库用户的，因此并未按照数据库的访问类别、会话追踪、数据库对象层次进行界面组织，造成这类产品的界面极其不易使用。