【IT168 技术文档】计划今年下半年发布的 DB2 版本中的审计工具有了增强，将帮助公司满足规章和安全性需求。
最近引人注目的数据泄露增加了公司确保企业数据库免受侵入的压力。许多行业和政府的法规要求有适当的审计来巡查数据访问。DB2 "Viper 2" for Linux, Unix, and Windows（现在的测试版的代号，正式版在下半年发布）包括有效增强的审计工具，它将帮助公司应对这些压力。
本文将阐述有效的审计技术。更重要的是，本文将展示怎样用 "Viper 2" 中新的审计工具来分析审计数据，以发现趋势和避免数据入侵。
审计是许多法规中的一种关键需求，包括：
- PCI Data Security Standard，主要信用卡公司（例如 Visa，American Express，Discover 和 Diner's Club）的协作成果，要求审计和监控数据存储，以保护信用卡持有人的私人信息。
- California Senate Bill Number 1386 修正 California Civil Code，以提供涉及私人信息的安全漏洞的法律声明。由于这个法案被通过，其他33个州采用了相似的数据保密法。审计遵从这个法律是至关重要的，因为必须报告和公开所有的安全漏洞。
- Sarbanes-Oxley (SOX)重新设计了联邦法规。它们涉及到公司正式的通信、高级管理人员、审计者、有价证券分析师、合法律师等的财务报表。Section 103 要求公司保留所有审计相关的记录（包括电子记录）至少七年。
- Health Insurance Portability and Accountability Act (HIPAA) 被设计来保护所有形式的私人健康信息，因为患者有权要求保护他们的健康信息。因此，审计服务要求支持以下规定的实现，要求“访问权限的建立和修改，日志监控”和“预防数据入侵”。
全世界有许多要求审计的法规，多到本文无法一一列举。您可能已经被要求实现一些类型的审计解决方案，来让您的公司遵从商业法规条令的调整。
但是审计并不只是对法规遵从来说是至关重要的。大多数公司当作一个标准商业惯例来使用审计，以确保企业数据的安全性。审计个人和某些部分的数据总是好的。公司使用审计方式的一些例子包括：
- 审计商业用户。任何企业中都有一些人可以无限制地访问非常敏感的数据。财务和HR中的人就是例子。有时公司审计这些个人，以确保正确地使用财务数据和员工数据。
- 审计 IT 用户。由于工作的需要，一部分 IT 用户可以访问整个生产系统。这种没有限制的访问常引起审计者的关注，因而需要为此生成报告，以确保数据完整性。
- 审计敏感数据。有很多形式的敏感数据：员工和客户的私人数据和财务数据、公司的财务数据或机密数据（例如调查数据）都可以被认为是敏感数据。
IT 和审计部门已经认识到，数据库审计收集的信息包含了大量的信息。审计数据不仅包含所有数据库访问的序时记录，还能提供对数据如何被访问的行为方面的洞察力。
当实现一个审计和报表系统时，您可以选择多种方式。本文将抛开实现的细节，描述收集审计数据的一些基础技巧。
DB2 提供了一个审计工具，通过它可以生成和维护用于一系列预定义的数据库事件的审计跟踪。该审计工具生成的记录保存在审计日志文件中，它们提供了关于谁做了什么，怎么做，在哪里做，何时做的大量的信息。通过分析这种日志文件，可以揭露一些使用模式，从而发现不正当的或可疑的活动。
DB2 "Viper 2" 包括对审计工具的重要增强。一个值得注意的变化是数据库级而不是实例级上的审计。通过这项增强，可以只审计那些包含敏感数据的数据库。也可以审计实例级事件，但是现在使用特定数据库中的审计策略来实际指定审计数据库请求和数据库用户的规范。另一项重要的增强是归档审计记录的功能，这对于遵从要求保留历史审计数据的法规（例如 HIPAA 和 SOX）来说十分重要。
审计策略控制数据库级的审计；这些审计策略是 DB2 "Viper 2" 中新引入的。审计策略提供了之前版本的 DB2 中没有提供的粒度。在 DB2 "Viper 2" 之前，需要审计所有表和所有用户。而审计策略对 DB2 系统的干扰更少，因为它们允许缩小审计范围。
审计策略定义要审计的操作的类型。审计策略不会被指定给特定的用户或对象；相反，它被用于定义要审计的事件。这种配置的优点是，很容易独立地更改要审计的事件或对象。可以用一个审计策略指定多个要审计的数据库操作。例如，您可能想创建一个名为 PowerUser 的审计策略，该审计策略规定所有需要 SYSADM、SYSMAINT 或 SYSCTRL 权限的操作都将被审计。表 1 显示了一个审计策略规定要审计的动作。
定义好审计策略之后，必须发出审计语句，以便将那个策略与数据库中的特定对象相关联。审计语句指定应该与审计策略相关联的特定对象。这种对象可以是整个数据库、一个表、一个特定的用户、一个组、一个角色或者一个受信任的上下文名称。表 2 显示了可以使用审计语句指定的对象。
DB2 "Viper 2" 引入了两种新的数据库对象，用于解决有关数据库安全管理的客户需求：
- 数据库角色。这种新的对象将一个或多个特权或数据库权限组成一组，它可以被授给用户、组、PUBLIC 或其他角色。这个特性支持与特定任务功能相关的特权的抽象，因而可以使安全管理变得更容易。
- 受信任上下文关系。现在可以在 DB2 中将受信任上下文关系定义为对象。在一个多层环境中，有时需要在所有层中保留每个终端用户的身份和特权，并提供审计数据库中的终端用户活动的功能，以便控制多层应用程序的安全性。应用程序可以通过一个受信任上下文建立一个受信任的连接，以允许将用户的身份传递到数据库服务器，用于审计和特权管理。
审计记录存储在审计文件中，这些文件是活动日志文件。为了分析审计数据，必须首先归档审计日志文件。通过归档，可以无限期地保留审计数据，可能是保存在某种离线存储上。归档审计数据之后，再通过提取过程创建审计文件，对于审计的每种类型的数据库操作创建一个文件。建议将数据提取到以逗号分隔的格式中，并将数据装载到 DB2 中，以便于分析。DB2 "Viper 2" 文档中包含了关于如何管理整个审计过程，包括提取数据和创建 DB2 审计查询表的信息。
图 1 显示了新的 DB2 "Viper 2" 审计工具。DB2 实例和数据库可以分开来审计。通过定义一个实例级审计配置，并发出 db2audit start 命令，可以审计实例级操作。可以使用审计策略对每个数据库进行审计。每个数据库包含一个或多个审计策略，这些审计策略描述需要审计的所有数据库操作。定义好审计策略后，审计语句就可以指出哪些数据库对象与那些审计策略相关联。用审计策略和相关联的审计语句激活数据库审计后，就可以生成审计记录，并将它们存储在数据库审计日志文件中。审计日志文件应该周期性地（或定期）归档。归档过程将创建审计归档文件，这些文件中包含针对被审计的所有数据库操作和相关操作的按时间排序的审计记录。
然后，将归档日志记录提取到审计摘要文件中，每个文件对应于一种类型的被审计的数据库操作。还可以选择将它们装载到 DB2 中，以便于查询和分析。一种很好的做法是将这些审计记录装载到一个单独的、与一般访问绝缘的 DB2 数据库中。
提取出审计文件后，就可以将数据装载到 DB2 表中，并开始分析和生成报告。这里需要理解记录的布局以及满足审计需求所需的相关数据。为了理解记录的布局，我们来考察一些常见的审计需求。我将解释如何审计每种场景，以及如何为审计部门或 IT 管理部门生成有用的报告。
场景 1：审计失败的登录尝试或对未授权的数据的访问。审计失败的登录尝试对于防止对数据库的未授权的访问十分关键；发现这方面的趋势有助于防止入侵。如果要审计所有失败的登录尝试，可以使用 VALIDATE 审计事件创建一个审计策略。如果要减少审计记录的数量，可以指定失败的状态。创建好审计策略之后，对数据库发出审计语句。这种审计将有效地报告所有失败的登录尝试。
Select timestamp, appname, applid, userid, execid, from audit.validate where status < 0 order by execid, userid, timestamp;
虽然很多用户偶尔也会输入错误的密码，但还是可以查找用不正确的密码对同一个 userid的重复尝试，或者使用类似用户 ID 的重复尝试。时间戳可以表明这些是否为重复的尝试。应用程序 ID（applid）将包含尝试连接到 DB2 的客户机的 TCP/IP 地址，并且可以标识出发出尝试的登录所在的计算机。可以将该信息与执行 ID（execid）相结合，以识别那台计算机上的用户。首先调查该用户是否为合法的 DB2 用户，如果是，再调查失败的登录尝试是不是因为用户忘记了 userid 或密码。如果该用户不是系统上的合法用户，那么系统管理员应该判断为什么这台计算机要尝试连接到 DB2。
据估计，多达 80％ 的数据泄露是由员工、业务伙伴或拥有对数据库的合法访问权的其他个人执行的。这些人获得对数据库的访问权后，便尝试读取他们本来不能访问的数据。这些类型的数据泄露很容易从审计数据中发现。
使用 CHECKING 类型创建审计策略（以减少产生的审计记录的数量，指定失败的状态）。审计语句将数据库与 CHECKING 审计策略相关联。由于每个对象只能有一个活动审计策略，因此可能需要为包含 VALIDATE 和 CHECKING 类型的数据库创建一个审计策略。
执行清单 2 中的查询将返回一个报告，该报告显示曾经尝试访问他们无权访问的对象的所有用户。通过检查 authid，可以确定用户向操作系统进行认证时所使用的 ID。应用程序名称可以帮助确定用户如何访问 DB2，对象名称可以帮助查明用户试图访问的特定对象。如果看上去是可疑的活动，那么可能需要审计 authid，查找可疑行为的更多模式。
Select timestamp, appname, userid, authid, objschema, objname, objtype from audit.checking where status < 0 order by userid, authid, timestamp;
场景 2：审计超级用户。有些法规要求审计有系统管理或安全管理特权的用户。审计这些 IT 用户的最有效的方法是创建一个审计策略，在创建时指定要审计的事件。很可能，审计部门会关心这些用户修改的或者在其上运行 SQL 的任何对象，以及这些用户可能颁发的任何特权。审计者可能还想知道这些用户是否修改过任何审计配置。为满足这些需求，审计策略必须指定以下数据库操作：AUDIT、EXECUTE、OBJMAINT、SECMAINT 和 SYSADMIN。创建好审计策略后，可以对要审计的权限：SYSADM、SYSMAINT、DBADM、SECADM 或特定的用户，发出AUDIT 语句。这里需要运行不同的查询来为审计的每种类型生成报告。清单 3 显示了一个查询，可以使用这个查询为 DB2 数据库中授予或撤销的所有安全特权生成报告。当按用户进行审计时，很可能需要按用户创建一个报告，并列出那个用户名下的所有审计活动。
Select authid, event, grantor, grantee, granteetype objtype, objschema, objname, status from audit.secmaint order by grantor, grantee;
场景 3：审计敏感数据。审计部门最常见的要求是审计敏感数据的能力。这个要求通常牵涉到员工或客户的数据隐私权。有些法规要求揭露所有违反安全的对私有数据的访问。获得这种数据的惟一方法是使用审计跟踪。
为了审计敏感数据，需要创建一个审计策略，以确保在某些表上执行的所有 SQL 都被捕捉。这需要审计策略指定 EXECUTE 事件要被审计。如果审计者想看到输入主机变量或参数占位符，那么可以指定 WITH DATA。创建好审计策略后，可以指出要用审计语句来审计哪些表。激活审计语句后，在指定的表上执行的 DML 语句将被记录下来。如果要生成一个显示在特定表上执行的所有 DML 语句的报告，可以使用清单 4 中的查询。
Select timestamp, authid, appname, rowsmodified, rowsreturned, stmttext, event from audit.execute order by timestamp, userid;
审计数据包含公司可通过多种方式使用的大量信息。对于要求获得对敏感用户或数据的完整的审计报告的审计部门（或客户），为满足他们的要求，可以将第三方报告生成工具与我展示的那些查询结合使用。很多第三方的审计工具还可以简化审计实现和报告生成的管理。这些工具使用 DB2 审计工具，并允许非 IT 用户（例如审计部门）管理这个过程。
记住，审计数据比仅仅满足数据保密需求更重要。审计数据包含关于数据如何被查询的有价值的信息，并且可以提供数据访问模式和行为方面的关键趋势。通过分析这些趋势，可以重新设计数据模型，以帮助提高用户生产率，并为更准确、更及时的决策分析提供便利。数据挖掘技术可以帮助分析行为和趋势，并快速识别当前系统中的可疑活动。
DB2 "Viper 2" 中的审计工具提供了一个全面的审计集合、归档和决策支持基础设施，因而可以回答谁在何时何处对什么数据执行什么操作的问题。请下载 DB2 "Viper 2" beta 版，自己试一试。
