之前的安全审计系列文章已经出了四篇（一，二，三，四），分别介绍了各种类型的审计。本文是该系列文章的最后一篇，将为你介绍对DML的审计，并作出总结。
审计敏感数据的变更
对数据操纵语言（DML）的审计是另一种常见需求，特别是在财务信息的正确性成为主要问题时。
相关的审计需求包括，全面记录每一次DML活动的新值和旧值。例如，你可能需要为雇员表中存储年金的那一“列”创建审计跟踪线索。在这种情况下，你有两种不同的要求。第一个要求是完全记录对这些值的任何更新，对于每次更新，要记录每个执行更新的用户，使用的客户端和应用程序，以及更新时间和真实的SQL语句。第二个要求是记录上述所有信息，以及记录更新前和后的值。不过情况并非总是一样的，因为通过使用下面的命令，笔者可以将50%的年金归为己有：UPDATE EMP SET BONUS = BONUS * 1.5。
尽管DML的审计跟踪并记录新值和旧值是重要的审计类型。但在使用此技术时仍需小心，要有选择地实施这种审计。有时，人们过分热衷于这种审计，因为简单方便，就为每一次DML操作都启用了这种审计。这在技术上是可能的，但可能会产生巨大的数据量，应该确保你的审计基础架构可以管理这种负荷，特别是在你的审计包括新值和旧值时。例如，单位每天发生大量业务，为了简单起见，每笔业务都仅更新一次值，每个数据库有多个表，每个表有若干个值需要更新，每个表有大量记录。一年后，你会发现你的审计数据库是超过数据库自身的35倍。
因此，在你准备DML审计线索时，应当谨慎地选择需要审计的对象和命令。例如，你可以决定为一个数据库的表集来创建审计，为某些登录名或账户创建审计等。更深入的选择是，你可以选择为哪些表及表中的哪些列来维护新值和旧值。
还可以通过三种主要方法来支持DML审计：使用数据库自身的功能、使用一个外部的审计系统，或使用触发器。
所有数据库都提供了实施DML活动审计的方法。例如，在Oracle中，你可以使用基于redo日志的“日志矿工（log miner ）”工具。因为redo日志会捕获所有的DML活动（包括新值和旧值），“日志矿工（log miner ）”可以析取这种信息，并使其可用。在SQL Server中，你可以使用DOP跟踪事件：
第二种方法，即外部的数据库审计系统，支持基于过滤标准的DML审计，包括数据库对象、用户、应用程序等。这种系统有助于捕获并压缩信息，并便于报告工具的使用，即使数据量很大也不会产生太多问题。
第三种选择是简单地使用自己定制的触发器。这种选择从技术上而言，不如其它的选择，但是如果你从事的并不是一个大规模的审计项目的一部分，而仅仅需要为几个对象创建一个DML审计线索，不妨增加触发器，将信息写到一个特定的审计表中，这种最简单而快捷的方法也许可以帮你顺利进入下一个项目。
审计关于私密问题的SELECT语句
SELECT语句过去并不是审计线索的重点，但最近对私密问题的重视已经改变了这种情况。例如，如果你需要确保客户、合伙人、雇员的机密信息不会从数据库中泄露，就得重视审计SELECT语句。你尤其需要显示出SELECT语句来自哪里（IP地址、应用程序）、谁选择了数据（用户名）、选择了哪些数据等。在DML的审计中，SELECT语句的审计对于整个数据库而言并不现实，你需要重视有重要意义的必要问题。
第一步是根据SELECT线索审计区分出哪些数据重要。例如，人的姓氏不太算机密，但姓氏与身份证号结合在一起就绝对是机密。在数据分类阶段，你应当定义机密信息存在哪里（对象名及列名），以及哪些信息组合是机密信息。
创建SELECT审计线索通常要比其它审计类型更为困难。很明显，在这里，快照并不是一个可行的选择，触发器也不行，所以你只能使用数据库跟踪或外部的审计系统。你还可以选择使用定制日志来构建视图，但这样做要求的工作量太大。在使用内部的数据库特性时，你的选择更为有限。例如，即使你可以跟踪SELECT（例如，下图所示:在SQL Server中使用DOP事件），这也往往是不现实的，因为你要收集太多的信息，并需要应用过滤器。
第二种方法，即外部的数据库审计系统，支持基于过滤标准的DML审计，包括数据库对象、用户、应用程序等。这种系统有助于捕获并压缩信息，并便于报告工具的使用，即使数据量很大也不会产生太多问题。
第三种选择是简单地使用自己定制的触发器。这种选择从技术上而言，不如其它的选择，但是如果你从事的并不是一个大规模的审计项目的一部分，而仅仅需要为几个对象创建一个DML审计线索，不妨增加触发器，将信息写到一个特定的审计表中，这种最简单而快捷的方法也许可以帮你顺利进入下一个项目。
审计关于私密问题的SELECT语句
SELECT语句过去并不是审计线索的重点，但最近对私密问题的重视已经改变了这种情况。例如，如果你需要确保客户、合伙人、雇员的机密信息不会从数据库中泄露，就得重视审计SELECT语句。你尤其需要显示出SELECT语句来自哪里（IP地址、应用程序）、谁选择了数据（用户名）、选择了哪些数据等。在DML的审计中，SELECT语句的审计对于整个数据库而言并不现实，你需要重视有重要意义的必要问题。
第一步是根据SELECT线索审计区分出哪些数据重要。例如，人的姓氏不太算机密，但姓氏与身份证号结合在一起就绝对是机密。在数据分类阶段，你应当定义机密信息存在哪里（对象名及列名），以及哪些信息组合是机密信息。
创建SELECT审计线索通常要比其它审计类型更为困难。很明显，在这里，快照并不是一个可行的选择，触发器也不行，所以你只能使用数据库跟踪或外部的审计系统。你还可以选择使用定制日志来构建视图，但这样做要求的工作量太大。在使用内部的数据库特性时，你的选择更为有限。例如，即使你可以跟踪SELECT（例如，下图所示:在SQL Server中使用DOP事件），这也往往是不现实的，因为你要收集太多的信息，并需要应用过滤器。
如果你选择使用外部的审计系统，务必确保它能够自动完成全部的审计功能。
总结
本系列文章介绍了多种不同的审计线索。为了确保自己的数据库环境的安全，也为了遵循规范或内部要求，你需要实施这些审计。虽然不同的单位有不同需求，但都能够映射到一系列数据库审计功能上。这正是文章的重点所在。
为了选择适合自己需要的审计类型，你需要选择用于实施审计线索的方法和系统，并做出关于架构的决定。这一点很重要，因为审计并非权宜之计，你的部署应当经得起时间的考验。
【编辑推荐】
