InfoSphere Guardium应用程序用户翻译

最新推荐文章于 2021-10-14 19:19:45 发布

cuyi7076

最新推荐文章于 2021-10-14 19:19:45 发布

阅读量459

点赞数

文章标签：数据库 python linux mysql java

原文链接：https://www.ibm.com/developerworks/data/library/techarticle/dm-1105fivemethods/index.html

版权

InfoSphere Guardium是一个IBM数据库活动监视系统。它为整个组织中的数据库提供了影响较小的审核和安全性。借助它，组织可以以细粒度的详细级别跟踪数据库内部发生的情况，而对入侵性和性能的影响却最小。

应用程序用户转换是识别最终用户在哪个应用程序上执行哪些数据库事务的过程。它需要跟踪最终用户，应用程序层以及数据库的活动。由于创建数据库连接是一项相对昂贵的操作，因此如果每次应用程序用户登录时都必须创建一个新的数据库连接，将会对性能产生较大的影响。为解决此问题，应用程序服务器将创建可重复使用的连接池，通过它们进行应用交易交易。创建连接池后，将使用一个功能强大的数据库用户登录该数据库。然后，应用程序将承担对使用连接池从数据库中提取的任何数据进行访问控制的责任。

图1.通过连接池进行数据库访问

该图显示了三个应用程序用户：fbrooks，kzuse，并确保被合并到单个数据库中：通过连接池的APPS

连接池的结果是一个更快的应用程序。不幸的是，这还会导致丢失有关哪个应用程序最终用户执行特定数据库事务的信息。这是个问题。对于有严格审核要求的任何数据库环境，识别应用程序最终用户都是至关重要的。例如，在医疗保健行业中，了解哪些最终用户正在访问电子保护健康信息（EPHI）可能是美国《医疗保险可移植性和责任法案》（HIPAA）的合规要求。在金融部门，应用程序用户识别可改善财务跟踪和责任制，这有助于遵守2002年《萨班斯-奥克斯利法案》（SOX）。

本文概述了如何使用五种不同的方法来配置InfoSphere Guardium以解决此问题。它还研究了如何为特定应用选择最佳方法。

在较高的级别上，Guardium中的五种应用程序用户标识方法如下：

内置应用程序用户翻译
使用Guardium Application Event API识别用户切换
分析存储过程中的模式
基于应用服务器的S-TAP代理
数据库和应用程序服务器API

内置应用程序用户翻译

Guardium支持各种现成的应用程序。这些应用程序包括Oracle电子商务，PeopleSoft，Siebel，SAP和Business Objects。 Guardium开发组织对每个应用程序进行了研究，并在应用程序执行SQL中寻找模式。他们发现，每个人在事务期间执行SQL语句中始终标识其用户。通过在SQL中标识这些模式，Guardium可以提取哪个应用程序最终用户正在执行数据库事务。

Siebel示例

为了帮助演示此功能，本文详细研究了Siebel CRM应用程序用户翻译。每当Siebel中发生事务时，就会为受影响的表更新一个指示最终用户的字段。可以将Guardium配置为在Siebel事务处理期间提取该信息。

例如，当您在Siebel中更新收入编号时，SQL UPDATE事务记录在Guardium中，类似于以下内容：

UPDATE SIEBEL.S_REVIN 
  SET DB_LAST_UPD_SRC='User'.DB_LAST_UPD=current timestamp-current timezone, 
  LAST_UPD='2-11-04-19.49.43.000000',LAST_UPD_BY='8SIA-7ZPPT',
  MODIFICATION_NUM=0000000000000000,ACCNT_ID='1-4YR' 
  WHERE ROW_ID='UA1-1V1TV AND MODIFICATION_NUM=0000000000000000

图2说明了如何在Guardium中记录此SQL。

图2.更新收入数字时，Siebel CRM运行的UPDATE SQL语句

带SQL ID，时间戳，会话ID，服务器IP，源程序，数据库用户名和完整SQL的Guardium屏幕

可以将Guardium配置为提取此语句的用户ID（8SIA-7ZPPT）和用户名（FBROOKS）。如图3所示：

图3：Guardium从Update语句中提取用户ID并将其映射到用户名

此示例说明了如何通过正确配置Guardium，审计员和合规性专业人员如何轻松查看哪个应用程序用户正在执行哪个数据库事务。

组态

现在已经研究了Siebel示例，本文将研究内置的应用程序用户转换配置。 Oracle E-Business，PeopleSoft，Siebel，SAP和Business Objects的配置不同，但是每个配置都有一些共同的线程。

第一步是在Guardium管理控制台中配置转换过程，如图4所示。

图4：管理控制台中的“应用程序用户转换”菜单

在“应用程序用户转换面板”中指定了应用程序数据库的一系列参数。如果Guardium需要连接到数据库以便将用户ID导入到用户名映射，则还需要提供数据库用户名和密码（对于Oracle E-Business和Siebel，这是必需的）。当直接在SQL模式中公开用户名时，仅需要指定应用程序的IP和端口号，例如，PeopleSoft和Business Objects。

图5：Siebel，业务对象，Oracle电子商务和PeopleSoft的示例配置

图5显示了Siebel，业务对象，Oracle电子商务和PeopleSoft的示例配置。

将这些参数输入到Guardium管理控制台后，必须重新启动Guardium检查引擎，以使应用程序用户转换生效，如图6所示。

图6：Guardium中的检查引擎配置

这是PeopleSoft和Business Objects所需的全部。 Oracle E-Business和Siebel需要额外的步骤来将映射从应用程序用户ID导入到应用程序用户名。为了导入映射，必须运行“应用程序用户翻译导入过程”，然后将其安排为定期运行。可以在管理控制台中找到此过程的运行控件，如图7所示。

图7：映射导入的配置对话框

配置和运行内置的“应用程序用户转换”后，您可以查看一些预包装的Guardium报告以查看应用程序用户活动。例如，对于Oracle电子商务，提供了EBS Processes Database Access和EBS Application Access报告。您可能需要在Guardium中填充一些组，才能使这些报告正确运行。要查看哪些组需要填充，请查看“报表查询定义”，如图8所示。

图8：EBS应用程序访问报告的查询定义

EBS应用程序访问报告的查询定义。为了使此报告正确运行，必须填充两个组：EBS App服务器和EBS DB服务器

您还可以构建自己的报告来显示应用程序用户数据。为此，请创建一个报告，然后从“ Access Period和“ App User Name实体中添加“ App User Name字段。查看报告时，请确保启用了“ 别名 ”。

有关SAP的一些特殊说明

在“应用程序用户转换”配置面板中，SAP在“应用程序类型列表”（已观察到SAP）中具有一个条目。要使SAP Application User Translation正常工作，不需要使用面板进行配置。仅出于历史原因将其保留在管理控制台中。相反，要为SAP配置应用程序用户转换，您需要在Guardium中填充SAP App Servers和SAP DB Servers组，如图9所示。

图9：要配置的两个组以配置SAP Application User Translation

一旦填充了应用程序服务器和数据库服务器IP，检查引擎就必须重新启动才能使应用程序用户转换生效。

DB方法

Siebel和SAP还有一个尚未讨论的附加选项，它是基于DB的转换，如图10所示。

图10：在管理控制台中为Siebel和SAP选择的DB应用程序用户转换

实际上，这里没有翻译。 Guardium只会导入应用程序已捕获的审核数据。这是一种较旧的，更具侵入性的方法，因此，建议使用已观察到的方法。如果必须使用数据库方法而不是遵循数据库方法，则必须启用SAP和Siebel的审核功能。对于Siebel，这意味着必须将Docking: Transaction Logging参数设置为TRUE 。对于SAP，必须将rdisp/vb_delete_after_execution参数设置为2 。此外，对于SAP，必须定期运行带有DELETE的rsm13002事务以清除报告。

InfoSphere Guardium应用程序事件API

现在已经研究了内置的Application User Translation，您将检查Guardium Application Event API。与内置的“应用程序用户转换”不同，Guardium Application Event API可以与任何应用程序一起使用，只要当会话的控制权从一个应用程序用户转移到另一个应用程序用户时，可以配置或修改该应用程序以执行SQL语句。

应用程序事件API调用是简单的无操作（no-op）SQL语句，在应用程序用户负责连接池中的连接之前和之后执行。无操作调用告诉Guardium当前哪个应用程序用户正在使用数据库会话。调用不会在数据库上执行任何更改，但可以被Guardium检测到。通常，这些无操作调用在单行特殊表（例如DB2 LUWs SYSDUMMY1表或ORACLE DBs DUAL表）上执行。

对于应用程序用户翻译，Guardium AppEventAPI调用通常采用以下形式：

SELECT 'GuardAppEvent:Start',  'GuardAppEventUserName:user_name' FROM DUMMY_TABLE;
-- SQL Transactions related to the user named user_name
SELECT 'GuardAppEvent:Released'  FROM DUMMY_TABLE;

使用数据库命令行工具可以轻松演示该概念。考虑在DB2 LUW命令行界面中运行以下SQL代码：

SELECT 'GuardAppEvent:Start',  'GuardAppEventUserName:fbrooks' FROM SYSIBM.SYSDUMMY1;
SELECT count(*) FROM ITEMS;
SELECT 'GuardAppEvent:Released'  FROM SYSIBM.SYSDUMMY1;

SELECT 'GuardAppEvent:Start',  'GuardAppEventUserName:kzuse' FROM SYSIBM.SYSDUMMY1;
SELECT count(*) FROM ITEMS; 
SELECT 'GuardAppEvent:Released'  FROM SYSIBM.SYSDUMMY1;

图11：在Linux中从DB2命令行执行Guardium Application Event API

图11显示了如何从Linux中的DB2命令行执行Guardium Application Event API。

如图12所示，Guardium中的会话显示了如何将用户fbrooks归属于第一个SELECT count(*)语句。它还显示了用户如何切换到第二个SELECT count(*)语句的kzuse。

图12：将SELECT count（*）语句分配给应用程序用户

使用Guardium应用程序事件API将SELECT count（*）语句分配给应用程序用户fbrooks，然后将应用程序用户切换到kzuse

通常，Application Event API需要先进行应用程序更改，然后才能使用。每当应用程序用户切换连接池中的会话时，客户都需要修改应用程序代码以执行无操作SQL。但是，有些应用程序具有足够的灵活性，可以使您无需更改代码即可执行无操作SQL调用。

通过存储过程识别应用程序用户

通过存储过程进行的应用程序用户标识与上一节中讨论的Guardium Application Event API相似，因为它使用SQL语句在单个数据库会话中定义用户之间的边界。这次，使用存储过程代替了空SQL语句。如果应用程序用户在池化连接内切换时，应用程序以可预测的方式执行存储过程，则可以将Guardium配置为接管并为用户分配属性。

例如，如图13所示，考虑应用程序是否在单个数据库会话内执行语句集。

图13：使用对set_application_property存储过程的调用来定义具有应用程序用户边界的Oracle数据库会话

图13显示了在Guardium中显示的Oracle数据库会话的示例。用户边界是通过调用set_application_property存储过程来定义的

每次应用程序用户切换池连接时，都会使用参数user_name调用set_application_property。可以将Guardium配置为检测此存储过程调用，并将第二个参数（如图14所示）用作当前应用程序用户名。

图14：配置为将存储过程标识为应用程序用户的边界时的Guardium输出

在将对set_application_property的调用标识为用户中的开关之后，Guardium填充了应用程序用户字段

组态

为了使Guardium通过前面显示的存储过程调用来识别用户，需要在Guardium管理控制台中定义一个新的自定义ID过程。过程名称将是应用程序用户切换时由应用程序调用的存储过程的名称，在这种情况下为set_application_property 。为了避免以user_date作为第一个参数的同一过程的调用，可以通过为第一个参数创建条件值来指定第一个参数必须为user_name 。最后，您将指定第二个参数充当“应用程序事件实体”中的“用户名”字段。然后，您可以将Application Event Username字段添加到报表中以查看应用程序用户，如图15所示。

图15：“ Guardium存储过程配置”窗口

图15显示了在这种情况下配置Guardium所需的参数。将set_application_property标识为存储过程，并添加条件，即第一个参数必须为“ user_name”。还指定了实际用户名的位置

这种应用程序用户标识方法对于大量使用存储过程或通过调用存储过程创建用户边界的应用程序是理想的。另外，有些应用程序可能不够灵活，无法调用无操作选择语句来利用Guardium Application Event API，但可以将其配置为进行适当的存储过程调用。对于那些应用程序，这也是一种理想的方法。

应用服务器S-TAP

在某些情况下，不可能或不希望更改应用程序源代码，因此无法使用Guardium Application Event API。该应用程序也可能不使用存储过程来定义用户边界。在某些情况下，可以使用Guardium S-TAP监视网络流量的功能来识别应用程序用户。在这种情况下，S-TAP用于将应用程序最终用户与数据库活动相关联。 S-TAP安装在承载应用程序服务器而不是数据库服务器的计算机上。然后，将其配置为监视到应用程序服务器的传入HTTP流量，过滤掉用户名，并通过应用程序服务器会话ID将其与数据库活动相关联。在Guardium中，这称为应用程序服务器用户标识或应用程序服务器S-TAP。

该方法是有利的，因为它无需更改应用程序或重新配置应用程序服务器即可工作。因此，这是一个非常快速简便的解决方案。缺点是它也不适用于所有企业应用程序。可能的问题包括使用不兼容的身份验证机制来加密或哈希用户名。使用某种形式的登录身份验证，Application Server S-TAP将最适合标准Java Enterprise Applications。

分析应用

配置Application Server S-TAP的第一步是分析应该审核的应用程序。

您需要找出以下三件事：

应用程序服务器的HTTP端口是什么
登录期间如何在HTTP通信中识别应用程序用户名
您如何识别与用户名相关的Java会话ID

尽管有许多可用的工具可用于分析Web流量，但最易于使用的工具之一是名为Live HTTP headers的Firefox插件。安装后，很容易看到在Web登录期间传输的HTTP流量，如图16所示。

图16：按Websphere应用程序的工厂登录屏幕

在本文中，您将以Websphere演示应用程序工厂为例。当使用用户名jon@doe.com登录到应用程序时，您将在Live HTTP标头窗口中看到HTTP流量，如图17所示。

图17：用于登录的HTTP通信

在Plants By Websphere应用程序中，您感兴趣的HTTP调用是对AccountServlet的Post调用，其参数为action=login 。您可以看到用户名在HTML POST调用的内容中传输。实际的用户名的前缀为userid= ，后缀为＆。

Java会话ID是通过调用在Cookie中传输的，其前缀为JSESSIONID= ，前缀为& 。

配置应用程序服务器S-TAP

要启用Application Server S-TAP，您需要使用从HTTP流中检索到的信息来配置Guardium收集器，如图18所示。

图18：Guardium管理控制台

该配置在Guardium管理控制台的“ 管理控制台” ，“ 本地分路器” ，“ S-TAP”控制下进行 。它包含S-TAP的所有主要配置设置，如图19所示。要使其正常工作，在配置S-TAP时，需要将其安装在承载应用程序服务器而不是数据库服务器的计算机上。

图19：Application Server S-TAP的配置

图19显示了“按Websphere划分的工厂”示例的Application Server S-TAP的配置。这些设置与您在HTTP流量中看到的值相对应。 Ports值是托管应用程序的应用程序服务器的HTTP端口号。 Web应用程序使用前缀userid=和后缀&传输应用程序用户名。数据库访问使用前缀JSESSIONID=和后缀&传输，并在HTTP cookie中获取与应用程序用户相关联的会话ID。 Guardium使用模式条目来验证HTTP流中的位置。

更改参数后，需要应用更改。然后，S-TAP将重新启动，并且状态应该为良好。

图20：应用程序服务器S-TAP报告

配置了Application Server用户标识后，Guardium将在实体Access Period中将应用程序用户名存储在字段Application User中。您可以将此字段添加到报告中。在前面显示的图20中，您可以看到一个包含DB用户名的报告，该用户名是与JDBC数据源关联的用户，而Application User是登录期间使用的实际应用程序用户。

应用程序服务器S-TAP摘要

当内置功能不可用时，Application Server S-TAP是为Java Application Server应用程序识别应用程序用户的一种非常简单的方法。它不需要对现有应用程序进行任何更改，因此使其成为非常有吸引力的解决方案。尽管如此，仍需要考虑一些注意事项。

为了使Application Server S-TAP正常工作，用户名需要在HTTP流中以明文形式传输。一些身份验证机制（例如，基于常规HTTP的身份验证）是经过哈希处理或Base64编码的，因此不受支持。通常，表单登录名将以明文形式发送用户名。

此方法不适用于所有应用程序。这取决于连接池的使用方式。例如，它要求对数据库的访问与处理HTTP请求的同一进程或线程同步。一个很好的例子是基于servlet的应用程序，其中servlet处理HTTP请求，并在此过程中从连接池接收连接以访问数据库。

还不支持HTTPS连接。这通常不是关键问题，因为S-TAP已安装在应用程序服务器上。在正常的企业配置中，只有到Web服务器的流量才经过HTTPS加密，并且Web与应用程序服务器之间的连接是标准HTTP。

数据库和应用服务器API

Guardium并非唯一会遇到将应用程序用户从应用程序层传播到数据库层的问题的审计系统。许多本机数据库审核解决方案具有相同的问题。这些解决方案通过向其系统中添加其他API来解决该问题。随着时间的流逝，构建了可利用这些API的应用程序服务器，从而可以用最少的应用程序开发工作来执行审核。好消息是，Guardium旨在检测这些API的使用并相应地分配适当的应用程序用户。

DB2的示例

为了说明此过程，将讨论IBM DB2 LUW数据库和WebSphere Application Server（WAS）的示例。第一个示例是标准JDBC Connection.setClientInfo API的DB2 LUW实现。考虑如下使用setClientInfo API的应用程序：

Class.forName("com.ibm.db2.jcc.DB2Driver");
Properties props = new Properties();
props.setProperty("user", "guard");
props.setProperty("password", "password");
Connection  connection = DriverManager.getConnection("jdbc:db2://10.10.9.28:50001/orders"
, props);

connection.setClientInfo("ClientUser", "fbrooks");
execSelectOnItems(connection);

connection.setClientInfo("ClientUser", "kzuse");
execSelectOnItems(connection);

这是一个人为的例子。在实际的应用程序中，不会发生像这样的用户名硬编码。而是将应用程序用户作为变量插入。可以通过会话ID来识别用户。常量fbooks和kzuse在这里仅用于帮助演示概念。 execSelectOnItems方法对数据库运行一个简单的SELECT语句，该语句获取名为ITEMS的表中的记录数。 Guardium获取数据库流量，并在调用setClientInfo（“ ClientUser”，“ fbrooks”）之后将所有执行SQL分配给用户fbrooks。无需配置，如图21所示。

图21：setClientInfo调用如何出现在Guardium中

第二个示例是使用可信上下文的DB2连接池。受信任的上下文允许将DB2 LUW配置为信任IP /用户名对。然后，它允许您有选择地在切换数据库用户名期间跳过重新认证和重新连接。与setClientInfo API不同，通过受信任的上下文切换用户名将允许DB2强制执行与该用户相关联的任何访问控制。实际的DB2用户正在切换。有了受信任的上下文，您将获得高性能以及使用现代数据库附带的所有访问控制机制的能力。关于可信任上下文的另一件好事是Guardium将选择用户开关。对于Guardium而言，该开关看起来像是一种特殊的connect语句。为了说明这一点，请采用以下将在应用程序服务器中执行的代码。

Object[] objects = new Object[6];
Properties properties = new Properties();
byte[] cookie = new byte[1];
Connection con;
DB2ConnectionPoolDataSource ds1 = 
new DB2ConnectionPoolDataSource();	      
ds1.setServerName("10.10.9.28");
ds1.setPortNumber(50001);
ds1.setDatabaseName("orders");
ds1.setDriverType (4);
	 
objects = ds1.getDB2TrustedPooledConnection("guard", "password", properties); 
DB2PooledConnection pooledCon = (com.ibm.db2.jcc.DB2PooledConnection)objects[0];
cookie = (byte[])objects[1];
con = pooledCon.getDB2Connection(cookie, "fbrooks", null, null, null, null, properties);
execSelectItems(con);
con = pooledCon.getDB2Connection(cookie, "kzuse", null, null, null, null, properties);
execSelectItems(con);

在应用程序服务器中执行此代码的方式类似于Guardium中图22中的示例。

图22：用户如何在受信任的上下文中切换显示在Guardium中

可信上下文看起来像对Guardium的特殊CONNECT语句。 Guardium掌握了这一点并标识了应用程序用户（这时也是数据库用户）

“ DB用户名”字段指定应用程序服务器最初登录时使用的用户。这是可信上下文的可信用户。应用程序用户字段指定连接池中使用的当前用户。数据库和应用程序用户之间的界限开始变得模糊，因为kzuse和fbrooks实际上是具有数据库级特权的数据库用户，但同时也是应用程序用户。其他数据库也存在类似的API，Guardium也应该能够使用其中的大多数。

前面显示的受信任上下文和setClientInfo示例都涉及应用程序如何直接访问API。对于大多数企业应用程序，它们将这类调用留给应用程序服务器。 WebSphere是可以进行调用的此类应用程序服务器之一。下一节将讨论自动使用DB2可信上下文的WebSphere。

WebSphere示例

您可以将WebSphere 7配置为在应用程序资源引用的登录配置内使用DB2受信任的上下文。当您执行此操作时，可以将WebSphere配置为自动利用可信上下文，如图23所示。有关如何配置它的详细说明，请参见资源部分。

图23：配置为在WebSphere中使用可信上下文的数据源资源引用

您还可以配置WebSphere以使用诸如数据存储助手之类的插件来调用Guardium Application Event API或数据库API。 developerWorks文章“ 在WebSphere中开发特殊的DataStoreHelper插件以在资源部分插入Pre和Post SQL ”对此进行了更详细的描述。 WebLogic也具有类似的功能。它称为过程凭证映射。在资源部分中，也可以找到有关如何配置WebLogic进行凭据映射的资源。

结论

数据库审核软件的关键问题之一是识别与数据库活动相关的应用程序最终用户。发生此问题的原因是出于性能原因，应用程序服务器实现了数据库连接池。

您已经了解了五种不同的技术来识别Guardium中的应用程序用户。它们每个都有其优点和缺点，并且适用于某些情况，如下所示。

对于Siebel或SAP等受支持的应用程序，内置的“应用程序用户转换”当然是最佳的选择。
如果可以修改应用程序SQL调用，那么Guardium Application Event API是确保跟踪应用程序用户的最稳定，最可靠的方法。
对于许多使用存储过程调用进行自己的用户管理的应用程序，分析存储过程中的模式是一种可行的解决方案。
如果无法更改应用程序源代码，并且所涉及的应用程序是标准Java Enterprise Application，则Application Server S-TAP可能是解决此问题的快速简便的方法。
如果Application Server和Database支持用于应用程序用户传播的API，则可以启用它。

在本文中，我们描述了数据库审核软件中的应用程序用户标识问题。我们概述了Guardium中用于应用程序用户识别的可用技术，并演示了如何实现它们。我们还提供了有关何时应使用它们的指南。

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