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

总览

若干合规性要求（例如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静态检索的应用程序用户。

实作

配置数据源以将其与您的应用程序一起使用时，WebSphere Application Server允许您指定数据存储帮助程序类。

该帮助程序弥合了数据库供应商特定代码与通用javax.sql.DataSource接口之间的鸿沟。通常，不需要指定定制的帮助程序类，因为WebSphere Application Server为最常用的数据库提供了默认的数据存储帮助程序类。

在本文的案例中，这代表了将应用程序用户身份传输到Guardium系统的完美插入点，因为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);
}

组态

编译并震撼DataStoreHepler之后，将jar放入WAS安装的/lib文件夹中。
登录到WAS管理控制台。
在DataSource的配置页面中，选择指定用户定义的数据存储帮助器 ，然后提供DataStoreHelper类的完整包和类名，如图2所示。

图2.指定一个定制的DataSourceHelper类
保存设置并重新启动WebSphere Application Server。 DataStore帮助程序配置已完成并可以使用。

结果

在本文中，通过打开两个浏览器窗口对配置进行了测试，并且该应用程序使用了两个不同的用户marc和sven登录 。应用程序本身通过技术用户连接到数据库，因为在大多数情况下，通常不建议使用实例所有者将应用程序连接到数据库。然后，应用程序查询一个敏感表。从图3中可以看到，所有查询都来自使用相同技术用户的同一数据库会话（3719）。

图3. Guardium活动日志，将前端用户分配给数据库查询

另外，请注意，前端/应用程序用户已在“ 事件用户名”列中明确标记，并为其分配了在其（应用程序）会话中执行的语句。任务完成。

可能的扩展

由于针对SYSIBM.SYSDUMMY1发出了虚拟选择，因此正在传输到数据库的当前元数据适用于DB2数据库系统。对于其他数据库系统，必须修改此语句以反映各个DBMS随附的虚拟表。示例包括以下内容。

DB2：从SYSIBM.SYSDUMMY1中选择“ GuardAppEvent：Start”，“ GuardAppEventUserName：[插入用户名]”
Oracle：从DUAL中选择“ GuardAppEvent：Start”，“ GuardAppEventUserName：[插入用户名]”
MS-SQL：SELECT'GuardAppEvent：Start'，'GuardAppEventUserName：[插入用户名]'
PostgreSQL：SELECT'GuardAppEvent：Start'，'GuardAppEventUserName：[插入用户名]'

替代解决方案

您可以使用以下替代解决方案来应对这一挑战。

应用程序日志记录。
重新认证/可信上下文。
日志收集和基于时间戳的合并。

应用日志

由于该应用程序对所有对应用程序的访问进行身份验证和授权，因此看来该应用程序本身将是监视和记录所有数据访问的明智之地。

但是，这种方法有几个缺点。首先，应用程序日志记录必须保持一致。例如，如果在开发期间日志记录需求发生变化，或者如果开发意外地省略了日志记录过程，则生成的日志将没有太大用处。同样，准确记录需要审核的内容也不是一件容易的事，因为每个记录的数据库访问都需要包括应用程序用户，并且应用程序需要自行确定哪些数据库访问需要审核。

其次，将数据库活动监视直接留给数据库服务器上的专用解决方案还有一个好处，即在应用程序外部进行的访问（例如通过特权用户进行的控制台访问或通过JDBC或ODBC桥的访问）仍将由这些访问者进行监视。基于代理的解决方案。大多数法规遵从性要求使用一种全面的审计解决方案来监视所有数据库访问的100％。

重新认证和可信上下文

当前的数据库系统支持用于设置数据库连接的有效所有者的机制。使用DB2，开发人员可以选择重新认证连接（这通常比打开新连接更有效），或者利用所谓的可信上下文（例如数据库信任（先前）连接的能力）来进行选择。所有者来认证其他用户并用该其他用户替换自己。

两种方法都将满足数据库活动应可追溯到特定用户的要求，因为它们是特定于供应商的，并且通常会引起额外的管理和配置。即使对于较小的应用程序，这通常也不可行。

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

此方法旨在通过比较时间戳合并来自不同来源（例如数据库和应用程序服务器）的活动。

由于这只能是一种启发式方法，因此它本质上将无法以100％的置信度匹配源。因此，本文将不进一步阐述其优缺点，因为它对于前面概述的严格合规方案不是可行的方法。

针对不同方法概述的缺点需要另一种方法，该方法专门针对合规性方案而量身定制，例如，每笔交易将应用程序用户作为元数据传输到数据库。

该元数据被数据库忽略，并且不影响数据库管理系统或应用程序服务器上的数据库连接池。但是，这是由数据库活动监视系统（例如InfoSphere Guardium数据库活动监视器）监视的。

结论

本文为您提供了一种用于WebSphere Application Server应用程序的通用方法，该方法使您能够启用数据库活动监视解决方案（例如InfoSphere Guardium），从而可靠地将应用程序用户分配给数据库活动，而无需更改各个应用程序。

翻译自: https://www.ibm.com/developerworks/data/library/techarticle/dm-1208monitordbactivity/index.html