《程序用户的数据库活动》由会员分享，可在线阅读，更多相关《程序用户的数据库活动（9页珍藏版）》请在金锄头文库上搜索。
1、 版权所有 IBM 公司 2012商标 使用 Guardium 和 WebSphere Application Server 监视应用程序用 户的数据库活动第 1 页，共 9使用 Guardium 和 WebSphere Application Server 监视应用 程序用户的数据库活动在不更改应用程序的情况下在池化连接环境中监视应用程序用户的数据库 活动的一种方法Sven Herschel 认证 Guardium Technical 销售专家 IBMMarc Schwind 软件工程师 IBM2012 年 11 月 05 日某些审计需求要求能够追溯特定的数据库活动，从而追究特定活动的用户责
2、任。在使用池化数据 库连接并由应用程序本身负责身份验证和授权的应用场景中，实现这一点尤为困难。本文将展示 一个适用于 WebSphere Application Server 应用程序的通用方法，该方法支持数据库活动监控解 决方案，比如 InfoSphere Guardium，以便可靠地将应用程序用户分配给数据库活动，无需更 改相应的应用程序。概述某些规范需求，比如 PCI-DSS 和 SOX，要求审计公司数据库上的特定活动，并为负责相应活动的人 员指派活动。同时，越来越多的应用程序由自身负责对用户进行身份验证和授权，而不是将这些 交由数据库来处理。在这种情况下，根本不可能追踪数据库级别上的个
3、人操作，因而无法追踪负责 某个活动的应用程序用户。现有的、通常专有的方法取决于重新身份验证或可信上下文等数据库功 能，允许应用程序切换拥有数据库连接权限的用户，所以支持适当的监控。通常，重新身份验证和可信上下文都是特定于供应商的，并且要求经过重新身份验证的用户了解数 据库。如果应用程序用户的数量很多，尤其对于可能需要支持大量用户的 Web 应用程序来说，才方 法变得非常不切实际，因此，如上所述，很少在应用程序开发中采用该方法。本文为所有 WebSphere Application Server 应用程序提供了一个通用方法，该方法不需要更改现有应 用程序，它启用了 InfoSphere Guar
4、dium 之类的数据库活动监视工具来实现应用程序前端用户与其相 应数据库活动之间的可靠匹配，将身份验证和授权分别留给了应用程序或应用程序容器，最后，仅 需对所有大型关系数据库管理系统做微小的修改。developerW Guardium 和 WebSphere Application Server 监视应用程序用 户的数据库活动第 2 页，共 9挑战在典型的应用程序中，比如 J2EE 应用程序，容器会维护一个数据库连接池，通过运行该应用程序的 技术用户进行身份验证。应用程序用户仅对该应用程序进行身份验证，不对数据库进行身份验证， 最终结果是，数据库服务器上的任何数据库记录或监视方法都没有获得有关
5、应用程序用户的信息， 如图 1 所示。图 1. 典型的应用程序拓扑，数据库层上没有应用程序用户信息为何这一点如此重要？有些合规性规范，比如 PCI-DSS 和 SOX，要求关注数据治理，还有可能要求对数据库进行监视，从 而查看何时、何人访问了哪些数据。此外，内部需求可能要求监控具有特权的用户，以便保护数据 不会受到非授权访问，并使得 DBA 的工作变得更透明。在 PCI-DSS 中，监控焦点取决于对信用卡信息的所有访问。想要通过采用了池化连接的应用程序来 监视对信用卡信息的访问，则必须确定进行数据库访问的技术用户背后的实际应用程序用户。如前 面所述，由于数据访问和用户管理是分离的，所以该任务会
6、变得很复杂。本文提供的方法概述本文提供的方法是将应用程序用户信息作为元数据传输到数据库中，这样数据库活动监视工具就可 以处理该数据了。同时，数据库管理系统 (DBMS) 会忽略转换后的元信息，因此 DBMS（包括 DB 活动、其权限系统、 身份验证和授权方案）和 WebSphere Application Server（包括其连接池工具）都不会受到影响，并 会和以前一样高效运作。此外，因为该方法对于应用程序是非侵入性的，因此不必更改应用程序本 身。通过实现一个自定义 DataStoreHelper 类来完成此操作，该类用于截取每个事务，并负责识别应用程 序用户，然后将其传递给 Guardium
7、 系统进行监视和评估。先决条件要使此方法生效，必须满足以下先决条件。1. 应用程序必须使用在 WAS 中配置并通过 JNDI 名称提供给应用程序的 WebSphere 连接工具。这 确保了添加后续开发的 DataStoreHelper 对于应用程序是无害的。 2. 该应用程序使用了 WebSphere 应用程序安全性，因为基于应用程序用户的代码是静态地从 com.ibm.websphere.security.auth.WSSubject 类 API 中获得的。 Guardium 和 WebSphere Application Server 监视应用程序用 户的数据库活动第 3 页，共 9实现在
8、配置用于您的应用程序的 DataSource 时，WebSphere Application Server 允许指定一个数据存储 helper 类。这个 helper 缩小了数据库供应特定代码与通用 javax.sql.DataSource 接口之间的差距。通常此处 不需要指定一个自定义 helper 类，因为 WebSphere Application Server 会为最常用的数据库提供默 认数据存储 helper 类。在本文的用例中，这展示了将应用程序用户身份传送给 Guardium 系统的一个完美插接点 (plug point)，因为 DataStoreHelper 接口定义了一个 d
9、oConnectionSetupPerTransaction(.) 方法，该 方法允许在使用连接之前基于事务拦截连接。此方法旨在获取目前已登录的用户的姓名，在使用它 来执行实际应用程序相关语句之前，将其包含于在连接上执行的特殊 SQL 语句中。通过 Guardium 系统很容易监视以下假脱机 SQL 语句，并建立某个连接与负责当前事务中已执行的 语句的应用程序用户之间的关联，如清单 1 所示。清单 1. 基于事务传递当前应用程序用户名public void doConnectionSetupPerTransaction(Subject subject, String user,Connecti
10、on conn, boolean reauth,Object properties) throws SQLException StringBuffer sql = new StringBuffer();sql.append(“SELECT GuardAppEvent:Start,GuardAppEventUserName:“);sql.append(WSSubject.getCallerPrincipal();sql.append(“ FROM SYSIBM.SYSDUMMY1“);Statement stmt = conn.createStatement();stmt.execute(sql
11、.toString(); 乍一看，您可能觉得通过静态调用 WSSubject 从线程中获得主体名称的做法有点奇怪，因为已经传 入了一个主题和一个用户名。但仔细观察您就会发现，该主题是由 J2C 层使用的主题（技术用户的 主题），用于对数据库进行身份验证。在大多数情况下，传入的用户为 null。仅在应用程序使用基于组件的身份验证直接提供用户名和密 码时，才会设置该值，并且用户会再次成为技术用户。通过实现 doConnectionCleanup(Connection conn)，还可以向 Guardium 系统通知释放与当前用 户有关的连接的时间。惟一的区别在于，SQL 语句解会发送 GuardA
12、ppEvent:Released，而不是 GuardAppEvent:Start，如清单 2 所示。清单 2. 在释放连接时传递当前应用程序用户名public boolean doConnectionCleanup(Connection conn) throws SQLException StringBuffer sql = new StringBuffer(); sql.append(“SELECT GuardAppEvent:Released,GuardAppEventUserName:“); sql.append(WSSubject.getCallerPrincipal(); sql.a
13、ppend(“ FROM SYSIBM.SYSDUMMY1“);Statement stmt = conn.createStatement(); stmt.execute(sql.toString(); return super.doConnectionCleanup(conn); developerW Guardium 和 WebSphere Application Server 监视应用程序用 户的数据库活动第 4 页，共 9配置 1. 在编译和压缩 DataStoreHepler 之后，将 jar 文件放到 WAS 安装的 /lib 文件夹中。 2. 登录到 WAS Administra
14、tive Console。 3. 在 DataSource 的配置页面中，选择 Specify a user defined data store helper，然后提供 DataStoreHelper 类的完整包和类名，如图 2 所示。 图 2. 指定一个自定义 DataSourceHelper 类4. 保存设置并重启 WebSphere Application Server。DataStore helper 配置已完成并可以使用。结果 对于本文，可通过打开两个浏览器窗口来测试配置，有两个叫做 marc 和 sven 的不同的用户登录到 了应用程序。应用程序本身已通过技术用户连接到数据库，因
15、为通常不推荐使用实例所有者身份将 应用程序连接到数据库。然后，该应用程序查询了一个敏感表。如图 3 所示，所有查询都来自使用 相同技术用户的同一个数据库会话 (3719)。图 3. Guardium Activity 日志将前端用户分配给数据库查询还要注意的是，在 Event User Name 列中已经清楚地标记了前端/应用程序用户，并指派了该用户在 其会话中执行的语句。任务完成。可能的扩展 目前正向数据库传递的元数据可应用于 DB2 数据库系统，因为对于 SYSIBM.SYSDUMMY1 而言，假 脱机选择是一个问题。对于其他数据库系统，必须修改该语句，以反映提供了相应的 DBMS 的假脱
16、 机表。相关示例如下。 Guardium 和 WebSphere Application Server 监视应用程序用 户的数据库活动第 5 页，共 91. DB2: SELECT GuardAppEvent:Start,GuardAppEventUserName:insert username FROM SYSIBM.SYSDUMMY1 2. Oracle: SELECT GuardAppEvent:Start,GuardAppEventUserName:insert username FROM DUAL 3. MS-SQL: SELECT GuardAppEvent:Start,GuardAppEv
