使用 Guardium 和 WebSphere Application Server 监视应用程序用户的数据库活动

在不更改应用程序的情况下在池化连接环境中监视应用程序用户的数据库活动的一种方法

某些审计需求要求能够追溯特定的数据库活动,从而追究特定活动的用户责任。在使用池化数据库连接并由应用程序本身负责身份验证和授权的应用场景中,实现这一点尤为困难。本文将展示一个适用于 WebSphere® Application Server 应用程序的通用方法,该方法支持数据库活动监控解决方案,比如 InfoSphere® Guardium®,以便可靠地将应用程序用户分配给数据库活动,无需更改相应的应用程序。

Sven Herschel, 认证 Guardium Technical 销售专家, IBM

作者的照片Sven Herschel 已有 9 年的 IT 专家、软件架构师和需求工程师方面的从业经验,在数据库、Web 开发和数字认证方面有深厚的背景,Sven Herschel 是 IBM 的 InfoSphere Guardium 客户端技术专家。他负责从首次联系到现场概念验证的整个预售周期。在工作中,他会亲身体验客户对数据库安全性和规范性的需求。



Marc Schwind, 软件工程师, IBM

Marc SchwindMarc Schwind 于两年前加入 IBM,在位于德国 Boeblingen 的 IBM Development Lab 担任 WebSphere Business Process Choreographer 团队的软件开发人员。他在 Stuggart 完成了信息技术方面的学习。



2012 年 11 月 05 日

概述

某些规范需求,比如 PCI-DSS 和 SOX,要求审计公司数据库上的特定活动,并为负责相应活动的人员指派活动。同时,越来越多的应用程序由自身负责对用户进行身份验证和授权,而不是将这些交由数据库来处理。在这种情况下,根本不可能追踪数据库级别上的个人操作,因而无法追踪负责某个活动的应用程序用户。现有的、通常专有的方法取决于重新身份验证或可信上下文等数据库功能,允许应用程序切换拥有数据库连接权限的用户,所以支持适当的监控。

通常,重新身份验证和可信上下文都是特定于供应商的,并且要求经过重新身份验证的用户了解数据库。如果应用程序用户的数量很多,尤其对于可能需要支持大量用户的 Web 应用程序来说,才方法变得非常不切实际,因此,如上所述,很少在应用程序开发中采用该方法。

本文为所有 WebSphere Application Server 应用程序提供了一个通用方法,该方法不需要更改现有应用程序,它启用了 InfoSphere Guardium 之类的数据库活动监视工具来实现应用程序前端用户与其相应数据库活动之间的可靠匹配,将身份验证和授权分别留给了应用程序或应用程序容器,最后,仅需对所有大型关系数据库管理系统做微小的修改。

挑战

在典型的应用程序中,比如 J2EE 应用程序,容器会维护一个数据库连接池,通过运行该应用程序的技术用户进行身份验证。应用程序用户仅对该应用程序进行身份验证,不对数据库进行身份验证,最终结果是,数据库服务器上的任何数据库记录或监视方法都没有获得有关应用程序用户的信息,如图 1 所示。

图 1. 典型的应用程序拓扑,数据库层上没有应用程序用户信息
典型的 3 层式应用程序架构,向技术人员提供了对数据库的访问。数据库中没有应用程序用户信息

为何这一点如此重要?

有些合规性规范,比如 PCI-DSS 和 SOX,要求关注数据治理,还有可能要求对数据库进行监视,从而查看何时、何人访问了哪些数据。此外,内部需求可能要求监控具有特权的用户,以便保护数据不会受到非授权访问,并使得 DBA 的工作变得更透明。

在 PCI-DSS 中,监控焦点取决于对信用卡信息的所有访问。想要通过采用了池化连接的应用程序来监视对信用卡信息的访问,则必须确定进行数据库访问的技术用户背后的实际应用程序用户。如前面所述,由于数据访问和用户管理是分离的,所以该任务会变得很复杂。


本文提供的方法

概述

本文提供的方法是将应用程序用户信息作为元数据传输到数据库中,这样数据库活动监视工具就可以处理该数据了。

同时,数据库管理系统 (DBMS) 会忽略转换后的元信息,因此 DBMS(包括 DB 活动、其权限系统、身份验证和授权方案)和 WebSphere Application Server(包括其连接池工具)都不会受到影响,并会和以前一样高效运作。此外,因为该方法对于应用程序是非侵入性的,因此不必更改应用程序本身。

通过实现一个自定义 DataStoreHelper 类来完成此操作,该类用于截取每个事务,并负责识别应用程序用户,然后将其传递给 Guardium 系统进行监视和评估。

先决条件

要使此方法生效,必须满足以下先决条件。

  1. 应用程序必须使用在 WAS 中配置并通过 JNDI 名称提供给应用程序的 WebSphere 连接工具。这确保了添加后续开发的 DataStoreHelper 对于应用程序是无害的。
  2. 该应用程序使用了 WebSphere 应用程序安全性,因为基于应用程序用户的代码是静态地从 com.ibm.websphere.security.auth.WSSubject 类 API 中获得的。

实现

在配置用于您的应用程序的 DataSource 时,WebSphere Application Server 允许指定一个数据存储 helper 类。

这个 helper 缩小了数据库供应特定代码与通用 javax.sql.DataSource 接口之间的差距。通常此处不需要指定一个自定义 helper 类,因为 WebSphere Application Server 会为最常用的数据库提供默认数据存储 helper 类。

在本文的用例中,这展示了将应用程序用户身份传送给 Guardium 系统的一个完美插接点 (plug point),因为 DataStoreHelper 接口定义了一个 doConnectionSetupPerTransaction(...) 方法,该方法允许在使用连接之前基于事务拦截连接。此方法旨在获取目前已登录的用户的姓名,在使用它来执行实际应用程序相关语句之前,将其包含于在连接上执行的特殊 SQL 语句中。

通过 Guardium 系统很容易监视以下假脱机 SQL 语句,并建立某个连接与负责当前事务中已执行的语句的应用程序用户之间的关联,如清单 1 所示。

清单 1. 基于事务传递当前应用程序用户名
public void doConnectionSetupPerTransaction(Subject subject, String user,
                                            Connection 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.toString());
}

乍一看,您可能觉得通过静态调用 WSSubject 从线程中获得主体名称的做法有点奇怪,因为已经传入了一个主题和一个用户名。但仔细观察您就会发现,该主题是由 J2C 层使用的主题(技术用户的主题),用于对数据库进行身份验证。

在大多数情况下,传入的用户为 null。仅在应用程序使用基于组件的身份验证直接提供用户名和密码时,才会设置该值,并且用户会再次成为技术用户。

通过实现 doConnectionCleanup(Connection conn),还可以向 Guardium 系统通知释放与当前用户有关的连接的时间。惟一的区别在于,SQL 语句解会发送 ‘GuardAppEvent: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.append("' FROM SYSIBM.SYSDUMMY1");
                
Statement stmt = conn.createStatement();
stmt.execute(sql.toString());
return super.doConnectionCleanup(conn); 
}

配置

  1. 在编译和压缩 DataStoreHepler 之后,将 jar 文件放到 WAS 安装的 /lib 文件夹中。
  2. 登录到 WAS Administrative Console。
  3. 在 DataSource 的配置页面中,选择 Specify a user defined data store helper,然后提供 DataStoreHelper 类的完整包和类名,如图 2 所示。
    图 2. 指定一个自定义 DataSourceHelper 类
    技术用户展示了用于指定自定义 DataSourceHelper 的 DataSource config 对话框
  4. 保存设置并重启 WebSphere Application Server。DataStore helper 配置已完成并可以使用。

结果

对于本文,可通过打开两个浏览器窗口来测试配置,有两个叫做 marcsven 的不同的用户登录到了应用程序。应用程序本身已通过技术用户连接到数据库,因为通常不推荐使用实例所有者身份将应用程序连接到数据库。然后,该应用程序查询了一个敏感表。如图 3 所示,所有查询都来自使用相同技术用户的同一个数据库会话 (3719)。

图 3. Guardium Activity 日志将前端用户分配给数据库查询
技术用户展示了使用技术用户实现数据库连接的一个典型拓扑

还要注意的是,在 Event User Name 列中已经清楚地标记了前端/应用程序用户,并指派了该用户在其会话中执行的语句。任务完成。

可能的扩展

目前正向数据库传递的元数据可应用于 DB2 数据库系统,因为对于 SYSIBM.SYSDUMMY1 而言,假脱机选择是一个问题。对于其他数据库系统,必须修改该语句,以反映提供了相应的 DBMS 的假脱机表。相关示例如下。

  1. 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','GuardAppEventUserName:[insert username]'
  4. PostgreSQL: SELECT 'GuardAppEvent:Start','GuardAppEventUserName:[insert username]'

备用解决方案

您可以采用以下备用解决方案来解决这个难题。

  • 应用程序日志
  • 重新身份验证/可信上下文。
  • 日志收集和基于时间戳的合并。

应用程序日志

由于要对针对应用程序的所有访问进行身份验证和授权,所以应用程序本身显然是监视和记录所有数据访问的一个明智之选。

此方法有一些缺陷。首先,需要持续记录应用程序日志。例如,如果在开发过程中日志需求发生变化,或者在开发过程中意外忽略了日志操作,那么所得到的日志的用处不是很大。此外,需要审计的日志记录工作任务繁重,因为每条记录的数据库访问都需要包含应用程序用户,并且应用程序需要自行确定哪些数据库访问需要审计。

其次,如果在数据库服务器上采用专门的解决方案来监视数据库活动,那么还能增加监视应用程序之外的访问的优势,比如特权用户进行的控制台访问,或者通过 JDBC 或 ODBC 进行的访问,这些访问仍会受到基于代理的解决方案的监视。大多数合规法规需要一个对所有数据库访问进行 100% 监控的全面的数据解决方案。

重新身份验证和可信上下文

当前的数据库系统支持为数据库连接设置有效所有者的机制。凭借 DB2,开发人员可以选择对某个连接进行重新身份验证,这通常比打开一个新的连接更有效,开发人员还可以充分利用可信上下文优势,比如数据库的一项能力:信任(以前的)连接所有者对不同用户的身份验证,并使用该用户替代自己。

这两种方法都能满足将数据库活动追溯至某个用户的要求,因为这些方法都是特定于供应商的,通常需要进行额外的管理和配置。而这通常不太可行,甚至对于更小的应用程序也是如此。

日志收集和基于时间戳的合并

该方法旨在通过比较时间戳,整合来自不同来源(比如数据库和应用服务器)的活动。

因为这只是一个启发式方法,所以无法与来源 100% 匹配。因此,本文不会进一步详细讨论其优缺点,因为它对于前面概括的严格合规场景而言不是一个可行的方法。

针对不同方法概括出来的缺点证实了另一个方法,该方法是专门为合规场景而量身定做的,比如基于每个事务将应用程序用户作为元数据传递给数据库的场景。

数据库会忽略这个元数据,该数据不会影响数据库管理系统或者应用服务器上的数据库连接池。尽管如此,它仍会受到 InfoSphere Guardium Database Activity Monitor 之类的数据库活动监视系统的监视。


结束语

本文提供了用于 WebSphere Application Server 应用程序的一个通用方法,允许您启用类似 InfoSphere Guardium 的数据库活动监视解决方案,以可靠的方式为应用程序用户分配数据库活动,无需更改相应的应用程序。


下载

描述名字大小
本教程样例源代码 SampleGuardiumDataStoreHelper.zip10KB

参考资料

学习

获得产品和技术

讨论

  • 加入developerWorks 中文社区。探索开发者推动的博客、论坛、组和维基,同时与其他 developerWorks 用户进行交流。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=844406
ArticleTitle=使用 Guardium 和 WebSphere Application Server 监视应用程序用户的数据库活动
publish-date=11052012