IBM Cognos 最佳实践: 阻止向 IBM Cognos 8 环境发布包

文档性质:技术;产品:IBM Cognos 8;关注领域:安全性

这种技术使用 servlet 筛选器防止 Framework Manager 向给定的 IBM Cognos 8 环境发布包。示例文件包含文档和实现此技术的二进制代码。

Cognos Proven Practices Team, Cognos 最佳实践团队, IBM

Cognos 最佳实践团队。



2011 年 6 月 02 日

免费下载:IBM® Cognos® Express V9.5 或者 Cognos® 8 Business Intelligence Developer Edition V8.4 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

简介

目的

本文档描述一种防止通过导入部署之外的其他方法向现有的 IBM Cognos 8 环境发布新的包的技术。在某些情况下,通常是在生产环境中,不希望通过 IBM Cognos 8 Framework Manager 向环境发布包,或者由于安全原因不允许这么做,本文档介绍的技术可以满足这一需求。

适用性

这里描述的技术适用于支持的任何操作系统上的所有 IBM Cognos 8.4 版本。但是,只在 Windows 上的 IBM Cognos 8.4. FP2 和 IBM Cognos 8.4.1 中测试过。

由于这种技术的性质,如果不修改代码,它可能与 IBM Cognos 8 BI 的老版本或未来的版本不兼容。

例外与除外责任

这种技术需要修改 IBM Cognos 8 应用程序的部署文件,因此完全得不到技术支持,这里只是 “按原样” 提供它。

只在独立的 IBM Cognos 8 BI 系统上测试过此技术。在集成的 BI+FPM 系统中使用此技术可能会有副作用。

本文档假设读者熟悉 Java servlet 的规范,尤其是 servlet 筛选器、log4j 和 Java 编程。


发布包的 “风险”

报告、分析或指示板等 IBM Cognos 8 BI 内容直接或间接地基于包。包包含用于把数据源的技术对象映射到可在报告和分析中使用的对象的元数据。这可以是一对一映射,对于 IBM Cognos PowerCubes 或 Essbase cubes 等 OLAP 型数据源或者其他关系数据源,仅仅是链接。这种映射被称为模型,即为了便于用户使用而建模的数据源结构表示。

创建包有两种方法:通过 IBM Cognos 8 Framework Manager (FM) 发布它们,从而显式地创建包;通过添加 IBM Cognos PowerCube 等 OLAP 数据源隐式地创建包,在这种情况下数据源创建向导会自动地创建包。

这使包成为 IBM Cognos 8 部署中的中心对象。新包的发布或创建由五个概念控制:

  1. 对存储包的位置的写访问
  2. 对 IBM Cognos 8 Framework Manager 或 SDK 的访问
  3. 内部 Dispatcher URI 的物理访问
  4. 创建新数据源的权限
  5. 导入部署的权限

我们来简要讨论一下这五个概念。

注意,对于更新现有的包,除第一个概念(对存储包的位置的写访问)之外其他概念都适用。对包的写访问不但由包对象授权设置控制,还受到包安全设置(包内部的授权设置)的影响。

对存储包的位置的写访问

包必须保存在 IBM Cognos 8 内容领域中的文件夹中。这要求(通过 FM 或数据源创建向导)创建包的用户对此文件夹有写权限。

到 IBM Cognos 8.4 为止,包可以放在包括 MyFolders 在内的任何地方。这意味着,即使用户对任何其他位置都没有写访问权,他们仍然对自己的 MyFolders 有写访问权,除非完全禁用了 MyFolders(参见 Technote 21339400:http://www.ibm.com/support/docview.wss?uid=swg21339400)。向除所有者用户和 System Administrators 角色的成员之外的其他人提供对 MyFolders 的访问权是不可能的。

对 IBM Cognos 8 Framework Manager 的访问

发布包是通过使用 IBM Cognos 8 Framework Manager 完成的。这个胖客户机只可用于 Windows 操作系统,它使用 IBM Cognos 8 SDK 与 IBM Cognos 8 通信。因此,应该具备连接 IBM Cognos 8 的 SDK 应用程序所需的前提条件。前提条件是:

  • 能够访问内部 Dispatcher URI
  • 完成身份验证会话所需的有效 IBM Cognos 8 凭证

IBM Cognos 8 Framework Manager 附带一个 IBM Cognos Configuration 实例,它使用两个属性指定 Gateway URI 和内部 Dispatcher URI。Gateway URI 用于处理身份验证,内部 Dispatcher URI 用于发布包。必须能够从驻留 FM 的计算机访问这两个 URI(见 2.1.3 节)。

内部 Dispatcher URI 的响应必须不是除 HTTP 200 – OK 外的任何其他返回码。如果出现任何其他返回码,比如 HTTP 401 – AuthenticateHTTP 302 – Found,访问会失败。这意味着 FM 目前不支持显式地处理返回码。使用一个 Microsoft Foundation Classes (MFC) 浏览器控件(基本上是嵌入式 Internet Explorer)访问 Gateway URI,因此 FM 支持与处理 HTTP 返回码有关的所有浏览器功能。

为了让 FM 正常工作,必须通过 IBM Cognos Configuration 保存一个配置。这是为了让 FM 能够确定 Gateway URI 和内部 Dispatcher URI。在通过 IBM Cognos Configuration 保存配置时,有另一个重要的步骤 — 在 FM 上设置密码学信息。如果没有密码学信息,FM 就无法建立到 IBM Cognos 8 系统的可信连接,就不能接收数据库凭证和其他敏感信息。但是,连接 IBM Cognos 8 Gateway URI 以执行身份验证不需要密码学信息,发布包也不需要密码学信息。在以明文保存未加密的 配置的情况下,可以完成这两个任务;当无法访问内部 Dispatcher URI 或 FM 无法向 IBM Cognos 8 系统的 Content Manager (CM) 注册时,就是这种情况。

Framework Manager 没有为它的功能提供授权。也就是说,有权访问 FM 的用户可以使用它提供的所有功能,但是由 IBM Cognos 8 控制的功能除外(例如访问数据源)。它的设计目标是控制通过访问 FM 或 SDK 应用程序发布包的能力。对于现有的包,可以根据分配给包的权限执行授权。可以为包定义管理用户,允许他们更新包的内容。但是,FM 只在更新现有的包时检查权限。对于新的包,访问 FM 并具备 2.1.1 节提到的条件就够了。

对内部 Dispatcher URI 的物理访问

任何基于 SDK 的应用程序(包括 IBM Cognos 8 Framework Manager)都通过内部 Dispatcher URI 连接 IBM Cognos 8。要想让驻留 FM 或 SDK 应用程序的计算机能够连接 IBM Cognos 8 系统,必须能够通过网络访问这个 URL。如果不可能执行这种访问,FM 或基于 SDK 的其他客户机就无法正常工作。

与基于 SDK 的其他 IBM Cognos 8 客户机不同,FM 并不给它发送的请求加标记或填充 HTML 客户机变量,因此不可能区分 FM 请求与发送给 Content Manager 的其他请求。

创建新数据源的权限

每当创建新的 OLAP 数据源时,都会隐式地发布一个包。可以使用 IBM Cognos 8 授权特性分配创建新数据源的权限。在默认情况下,只有 Directory Administrators 和 System Administrators 角色的成员具有创建新数据源的权限。

导入部署的权限

通过部署创建新的包也由 IBM Cognos 8 授权特性控制。在默认情况下,System Administrators 角色和其他 Administrator 角色的成员具有创建并运行导入和导出的权限。

为什么会希望防止创建包?

在大多数情况下,最好为 IBM Cognos 8 系统建立两个单独的环境 — 开发环境和生产环境。通常,在开发环境 (DEV) 中开发内容(报告、指标、分析报告等等);检查并批准内容之后,把它们迁移到生产环境 (PROD) 中。通过 FM 或隐式地把包直接发布到 PROD 是相当少见的。一般情况下,都是使用 IBM Cognos 8 的部署功能把开发的内容从 DEV 迁移到 PROD。

上面这种做法意味着通常不希望在 PROD 环境中创建包,因为这会绕过法律要求的检查和批准过程。因此,确实可能需要防止在特定的 IBM Cognos 8 环境中创建包。

防止创建包有多种原因,下面是一些例子:

  • 希望对发布到生产系统的数据强制执行批准过程。
    这种过程的目的是防止不准确的数据被发布到生产系统中,从而导致错误的决策。降低未经检查的数据进入生产系统的风险对于 BI 系统非常重要,这主要是为了消除人为错误,但是也可以防止恶意的内部用户发布伪造或篡改过的数据。
  • 希望简化运营。
    通常,由运营部门的技术人员维护和管理 PROD 环境,由数据建模师或熟悉数据的其他管理用户发布包。这会形成依赖关系并需要可能对于 PRDO 环境不可行的权限。运行部署是纯粹的技术活动,可以由技术人员独立完成。
  • 希望执行多租用者部署。
    多租用者系统可能允许租用者知道系统上其他租用者或数据的存在,也可能不允许。如果允许用户发布或创建包,他们就会不知不觉或不情愿地向其他租用者暴露相关信息。
    如果租用者实际上是企业中的多个项目,那么一些用户可能同时参与多个项目。如果他们在不同的项目中担任不同的角色,就会产生问题。例如,一个用户在项目 A 中是数据建模师,而在项目 B 中只是消费者(即他可以访问项目 B 的数据)。如果他由于项目 A 的需要有权访问 FM,就也能够发布基于项目 B 数据的包。

尽管可以用其他方法解决上面所有示例的问题,尤其是为 IBM Cognos 8 内容从 DEV 到 PROD 的迁移实现确定的迁移过程,但是第三个示例描述的情况可能必须使用这里讨论的技术。

重申一下,降低不适当的包进入 PROD 的风险的最好方法是全面地设计迁移过程。迁移过程不但必须考虑到技术性运营需求(比如谁有权访问什么地方和要使用什么硬件),还必须满足所有安全需求,包括按必要性分配权限以及把访问权控制在尽可能低的级别。IBM Cognos 8 提供许多支持安全需求的特性,包括把用户身份验证交给数据源以利用数据源的安全措施、对 IBM Cognos 8 内容对象和名称空间结构的细粒度授权以及基于包的安全设置。

阻止 FM 访问的方法

如果环境或流程需要阻止 FM 访问,最好根据 2.1 节 描述的概念开发相关的战略。本文档中提供的技术应该作为其他方法都无效的情况下的最后一招。

重申一下,发布或创建新包的相关概念是:

  1. 对存储包的位置的写访问(2.1.1 节
  2. 对 IBM Cognos 8 Framework Manager 或 SDK 的访问(2.1.2 节
  3. 内部 Dispatcher URI 的物理访问(2.1.3 节
  4. 创建新数据源的权限(2.1.4 节
  5. 导入部署的权限(2.1.5 节

现在,通过分析这些概念,推导出防止不希望的 FM 访问的最佳方法。

2.1.1 节 指出,可以撤消对 MyFolders 的访问权。但是,这是一个全局修改,会全局地对所有用户禁用 MyFolders。使用 MyFolders 有合理的理由,因此只有在整个系统中都不需要/想要 MyFolders 的情况下,第一种方法才是可行的。另一个问题是,有权运行导出/导入或创建数据源的用户总会找到某个位置来保存包。禁止写访问应该作为与其他措施结合使用的额外措施。依赖于取消写权限是不够的。

第二个概念(控制对 FM 或 SDK 的物理访问,见 2.1.2 节)与控制对 MyFolders 的访问权差不多。尽管它对于控制公司环境中胖客户机软件的交付是可行的,但是用户有可能把 FM 复制到另一台计算机上并运行它,而不安装或向 IBM Cognos 8 Content Manager 注册,这会带来风险。仅仅限制对 FM 或 SDK 应用程序的物理访问同样是不够的。应该在服务器端上降低风险,而不是在客户端上。

尽管前面提到的两种方法都不提供全面的保护,但是如果与还未提到的其他方法结合使用,后者(控制对 FM 的物理访问)很有意义。

阻止 FM 访问的最有效方法是防止对内部 Dispatcher URI 进行未经批准的网络访问(见 2.1.3 节)。

这可以在 OSI 层模型的任何层上以物理方式实现(例如根据子网、客户机 IP 和/或端口阻止访问),也可以使用 IBM Cognos 8.4 中引入的 Dispatcher Password 特性以逻辑方式实现。

Dispatcher Password 特性的目的是防止在 IBM Cognos 8 中添加安装。它用密码保护密码学信息的建立,从而阻止在 IBM Cognos Configuration 中保存配置。

尽管它相当有用,但是这个功能不足以防止用户访问内部 Dispatcher URI。正如前面指出的,FM 在发布包时不需要密码学信息,但是使用 Dispatcher Password 至少可以防止通过 FM 获取信息。另外,同一计算机上驻留的其他客户机可能要求向安装客户机软件的人暴露密码。如果这个人也是用户(这在公司环境中不常见,但是也不罕见),那么密码提供不了任何保护。这个用户可以在系统中添加 FM,这会完整地保存并建立密码学信息。

不幸的是,导致 Dispatcher Password 无效的场景(即系统上同时存在 SDK 应用程序、IBM Cognos 8 Go! Office 或 IBM Cognos Go! Dashboard 等其他客户机软件)也与阻止对特定 IP 的网络访问相抵触。在这个场景中,无法根据网络信息阻止访问,必须根据客户机应用程序阻止访问。但糟糕的是,正如前面提到的,不可能识别 FM 发送的请求,这意味着无法把 FM 请求与 IBM Cognos 8 系统中各处发送出的其他请求区分开。

最后两个概念(2.1.4 节和 2.1.5 节讨论的控制创建新数据源和导入部署的权限)只需使用开箱即用的授权功能即可实现。应该只向可信的管理员授予创建数据源和运行导入/导出的权限。

总之,防止 FM 访问的最有效战略是:

  • 根本不公开内部 Dispatcher URI
    如果其他基于 SDK 的客户机都不需要访问内部 Dispatcher URI,就适用此方法。
  • 只按白名单方式允许网络访问
    这意味着防火墙有一个已知的客户机 IP 和端口条目列表,它们有权访问内部 Dispatcher URI。只有这些显式指定的条目有访问权,所有其他请求都被阻止。如果存在其他 SDK 应用程序,可以让它们在最终用户领域外的特定主机上运行。
  • 使用 Dispatcher Password 防止保存配置
    如果在同一计算机上没有其他客户机,应该使用 Dispatcher Password 防止建立密码学信息。这也有助于防止从数据源获取数据。
  • 部署 servlet 筛选器以完全防止发布
    如果以上方法都无法应用,能够访问 FM 的物理安装的任何人都可能发布包(至少发布到他们的 MyFolders)并运行可能包含敏感或机密数据的报告。需要一种能够在每个场景中防止 FM 访问的可靠方法,本文档余下的部分描述此方法。它使用 servlet 筛选器阻止创建和更新包的请求。

servlet 筛选器

servlet 是一种 Java 程序,它们接收基于 HTTP 协议的请求,返回基于 HTTP 协议的响应,它们通常使用 HTML 或 SOAP。为了扩展这个概念,从 Java Servlet Specification version 2.3 开始,引入了 “servlet 筛选器”。筛选器位于通信通道上 servlet 前面。它们可以动态地拦截发送到 servlet 容器中部署的 servlet(或 JSP)的请求和返回的响应。筛选器可以以多种方式操纵收到的请求和/或响应。还可以把多个筛选器链接起来,这样请求和响应在发送到和离开 servlet 的途中必须经过筛选器链。

图 1. 筛选器链
筛选器链

筛选器可以把大型 web 应用程序的代码模块化,成为可重用的单元,可以使用它们实现以下功能:

  • 处理身份验证或授权
  • web 应用程序的日志记录和审计跟踪
  • 把应用程序的响应转换为想要的输出格式(XSLT、本地化)
  • 通信流压缩

关于 servlet 筛选器的更多信息,参见 Java Servlet Specification http://java.sun.com/products/servlet/2.5/docs/servlet-2_5-mr2/index.html

本文档描述的技术使用一个 servlet 筛选器阻止 FM 请求。


方法

下面几节描述的技术在 IBM Cognos 8 Dispatcher servlet 前面实现一个 servlet 筛选器,从而阻止更新/创建包的所有请求。在接收来自外部 FM 或 SDK 应用程序的请求的每个 IBM Cognos 8 Dispatcher 上,都必须部署这个筛选器。IBM Cognos 8 BI Modeler 的 IBM Cognos Configuration 只允许指定一个 Dispatcher URI,而且 SDK 程序通常使用固定的 Dispatcher URI,所以需要部署筛选器的 Dispatcher 应该很容易确定。

servlet 筛选器

这个 servlet 筛选器在 Java 类 “FMFilter.class” 中实现,这个类打包在本文档附带的 FMFilter.jar 文件中。还有一个适用于 JBoss 应用服务器的版本 (FMFilter_jboss.jar)。需要这个单独的版本是由于与 log4j 日志记录相关的技术条件。JAR 是用 IBM JDK 5 编译的。

这个筛选器根据特定的条件检查传递给 IBM Cognos 8 Dispatcher servlet 的每个请求。如果请求要求更新/创建包,就会阻止请求。所有其他请求都被放行。如果阻止了请求,就会模拟表示失败的 Content Manager 响应,这导致发出调用的客户机显示错误,向用户表明此操作已经被阻止。

图 2. 在发布时来自 FM 的错误消息
在发布时来自 FM 的错误消息

这个筛选器实现一种评估方法,从而识别表明应该阻止请求的条件。这确保开销非常小,筛选器的性能影响应该可以忽略不计,但是没有做过正式的性能测试。

它并不阻止导入和导出部署,所以仍然可以通过这个特性导入包。

为 Tomcat 安装 servlet 筛选器

要想在您的环境中安装 servlet 筛选器,应该对每个 Dispatcher 实例执行以下步骤:

  • 停止 IBM Cognos 8。
  • 把 FMFilter.jar 复制到 C8_ROOT/webapps/p2pd/WEB_INF/lib/FMFilter.jar
  • 编辑 C8_ROOT/webapps/p2pd/WEB_INF/web.xml 以引用筛选器。
    <description> 元素后面,第一个 <servlet> 元素前面插入:
    	<filter>
    		<filter-name>FMFilter</filter-name>
    		<filter-class>com.ibm.ba.cognos.fmblock.FMFilter</filter-class>
    	</filter>
    	<filter-mapping>
    		<filter-name>FMFilter</filter-name>
    		<url-pattern>/servlet/dispatch/*</url-pattern>
    	</filter-mapping>
  • (可选)要想启用日志记录,应该编辑文件 C8_ROOT/webapps/p2pd/WEB_INF/classes/log4j.properties
    在文件中的特定部分中添加
    ### IBM Cognos P2PDFilter Logging ###
    log4j.logger.com.ibm.ba.cognos.fmblock.FMFilter=WARN, P2PDFile

    # P2PDlog is set to be a File appender using a PatternLayout.
    log4j.appender.P2PDFile=org.apache.log4j.FileAppender
    log4j.appender.P2PDFile.File=../logs/P2PDFilter.log
    log4j.appender.P2PDFile.Append=true
    log4j.appender.P2PDFile.Threshold=DEBUG
    log4j.appender.P2PDFile.layout=org.apache.log4j.PatternLayout
    log4j.appender.P2PDFile.layout.ConversionPattern=%d %-5p [%c{1}] %-80m%n

    保存文件。
  • 启动 IBM Cognos 8。

为 JBOSS 安装 servlet 筛选器

要想在您的环境中安装 servlet 筛选器,应该执行以下步骤:

  • 停止 IBM Cognos 8。
  • 把 FMFilter_jboss.jar 复制到 C8_ROOT/webapps/p2pd/WEB_INF/lib/FMFilter.jar。一定要注意,这个 jar 文件已经改名为 FMFilter.jar。
  • 编辑 C8_ROOT/webapps/p2pd/WEB_INF/web.xml.noCM 以引用筛选器。在 <description> 元素后面,第一个 <servlet> 元素前面插入:
    	<filter>
    		<filter-name>FMFilter</filter-name>
    		<filter-class>com.ibm.ba.cognos.fmblock.FMFilter</filter-class>
    	</filter>
    	<filter-mapping>
    		<filter-name>FMFilter</filter-name>
    		<url-pattern>/servlet/dispatch/*</url-pattern>
    	</filter-mapping>
  • 构建应用程序文件并部署到 JBOSS。
  • (可选)要想启用日志记录,应该编辑文件 {JBOSS_ROOT}/server/{profile}/conf/log4j.xml。在第一个 <category> 元素前面添加新的 appender:
    <appender name="P2PDFILE"
           class="org.jboss.logging.appender.DailyRollingFileAppender">
          <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
          <param name="File" value="{C8_ROOT}/logs/P2PDFilter.log"/>
          <param name="Append" value="false"/>
          <param name="DatePattern" value="'.'yyyy-MM-dd"/>
          <layout class="org.apache.log4j.PatternLayout">
             <param name="ConversionPattern" value="%d %-5p [%c{1}] %-80m%n"/>
          </layout>
       </appender>

    在根 <category> 元素前面添加新的 category:
       <category name="com.ibm.ba.cognos.fmblock.FMFilter" additivity="false">
         <priority value="WARN" />
         <appender-ref ref="P2PDFILE"/>
       </category>
    注意:如果还希望在 JBOSS 控制台中看到日志消息,应该删除 category 中的 additivity 属性。
  • 保存 log4j.xml 并启动 IBM Cognos 8。

使用 servlet 筛选器日志记录监视 FM 访问

在可以从 IBM Cognos 8 Framework Manager 接收请求的所有 Dispatcher 中部署 servlet 筛选器之后,使用 FM 发布包这种操作就会被阻止。

servlet 筛选器在处理期间使用 log4j 记录一些信息,建议启用日志记录(但不是必需的)。日志文件名为 “P2PDFilter.log”,它会被写到 C8_ROOT/logs 文件夹中。它的内容取决于在 log4j 配置中指定的日志记录级别。

默认的日志记录级别应该是 WARN,它只在已经阻止了请求的情况下在日志文件中写消息。消息包含时间戳和由应用服务器分配给请求的请求 ID。这样就可以把它与基于应用服务器的日志记录相互匹配。最后,它记录发送请求的客户机的 IP。

示例:2010-08-31 14:50:32,031 WARN [FMFilter] Request[8F38EA1C74C5D3DE2429040676D26E1E] was blocked, ClientIP:x.x.x.x

如果把日志级别设置为 INFO,那么每当有请求经过 servlet 筛选器时都记录一个条目,无论是否把请求转发给 Dispatcher。

如果把日志级别设置为 DEBUG,就会提供上面提到的所有信息以及请求和响应的完整内容,但是这会影响性能,应该只在排除故障时使用。


下载

描述名字大小
示例代码Blocking_Framework_Manager_Publishing.zip266KB

参考资料

学习

获得产品和技术

讨论

  • 参与 developerWorks 博客 并加入 developerWorks 中文社区,developerWorks 社区是一个面向全球 IT 专业人员,可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。

条评论

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=677506
ArticleTitle=IBM Cognos 最佳实践: 阻止向 IBM Cognos 8 环境发布包
publish-date=06022011