本文将展示一个适用于 ">WebSphere® Application Server 应用程序的通用方法，该方法支持数据库活动监控解决方案，比如 InfoSphere® Guardium®，以便可靠地将应用程序用户分配给数据库活动，无需更改相应的应用程序。
某些规范需求，比如 PCI-DSS 和 SOX，要求审计公司数据库上的特定活动，并为负责相应活动的人员指派活动。同时，越来越多的应用程序由自身负责对用户进行身份验证和授权，而不是将这些交由数据库来处理。在这种情况下，根本不可能追踪数据库级别上的个人操作，因而无法追踪负责某个活动的应用程序用户。现有的、通常专有的方法取决于重新身份验证或可信上下文等数据库功能，允许应用程序切换拥有数据库连接权限的用户，所以支持适当的监控。
通常，重新身份验证和可信上下文都是特定于供应商的，并且要求经过重新身份验证的用户了解数据库。如果应用程序用户的数量很多，尤其对于可能需要支持大量用户的 Web 应用程序来说，才方法变得非常不切实际，因此，如上所述，很少在应用程序开发中采用该方法。
本文为所有 WebSphere Application Server 应用程序提供了一个通用方法，该方法不需要更改现有应用程序，它启用了 InfoSphere Guardium 之类的数据库活动监视工具来实现应用程序前端用户与其相应数据库活动之间的可靠匹配，将身份验证和授权分别留给了应用程序或应用程序容器，最后，仅需对所有大型关系数据库管理系统做微小的修改。
挑战
在典型的应用程序中，比如 J2EE 应用程序，容器会维护一个数据库连接池，通过运行该应用程序的技术用户进行身份验证。应用程序用户仅对该应用程序进行身份验证，不对数据库进行身份验证，最终结果是，数据库服务器上的任何数据库记录或监视方法都没有获得有关应用程序用户的信息，如图 1 所示。
图 1. 典型的应用程序拓扑，数据库层上没有应用程序用户信息
为何这一点如此重要？
有些合规性规范，比如 PCI-DSS 和 SOX，要求关注数据治理，还有可能要求对数据库进行监视，从而查看何时、何人访问了哪些数据。此外，内部需求可能要求监控具有特权的用户，以便保护数据不会受到非授权访问，并使得 DBA 的工作变得更透明。
在 PCI-DSS 中，监控焦点取决于对信用卡信息的所有访问。想要通过采用了池化连接的应用程序来监视对信用卡信息的访问，则必须确定进行数据库访问的技术用户背后的实际应用程序用户。如前面所述，由于数据访问和用户管理是分离的，所以该任务会变得很复杂。
本文提供的方法
概述
本文提供的方法是将应用程序用户信息作为元数据传输到数据库中，这样数据库活动监视工具就可以处理该数据了。
同时，数据库管理系统 (DBMS) 会忽略转换后的元信息，因此 DBMS（包括 DB 活动、其权限系统、身份验证和授权方案）和 WebSphere Application Server（包括其连接池工具）都不会受到影响，并会和以前一样高效运作。此外，因为该方法对于应用程序是非侵入性的，因此不必更改应用程序本身。
通过实现一个自定义 DataStoreHelper 类来完成此操作，该类用于截取每个事务，并负责识别应用程序用户，然后将其传递给 Guardium 系统进行监视和评估。
先决条件
要使此方法生效，必须满足以下先决条件。
应用程序必须使用在 WAS 中配置并通过 JNDI 名称提供给应用程序的 WebSphere 连接工具。这确保了添加后续开发的 DataStoreHelper 对于应用程序是无害的。 该应用程序使用了 WebSphere 应用程序安全性，因为基于应用程序用户的代码是静态地从 com.ibm.websphere.security.auth.WSSubject 类 API 中获得的。