保护 WebSphere MQ File Transfer Edition V7 的安全

WebSphere MQ File Transfer Edition (FTE) 是 IBM 的一款新产品,它为托管的文件传输操作提供了一个企业级平台。保护该产品需要先了解 FTE 组件如何同时与文件系统和 WebSphere MQ 交互。本文将介绍该组件体系结构,并详细描述加强 FTE 网络所需的网络设计和配置任务的示例用例。

T.Rob Wyatt, 高级管理顾问, IBM

T.Rob Wyatt 是一名高级管理顾问,主要负责 IBM Software Services for WebSphere。他帮助客户管理、设计和保护 WebSphere MQ。他的前几篇文章介绍 WebSphere MQ 管理方面的内容,发布在 IBM WebSphere 开发人员技术期刊 上。他出席过 IMPACT 以及 European Transaction and Messaging 会议。T.Rob 每月还在 WebSphere MQ 播客上主持 The Deep Queue。


developerWorks 专家作者

2009 年 7 月 17 日

引言

IBM® WebSphere® MQ File Transfer Edition(以下简称 FTE)可与现有的 MQ 网络集成来提供托管的文件传输功能。从体系结构角度看,FTE 的构造与其他任何 WebSphere MQ 应用程序一样——它与队列管理器连接,并将消息放入队列中或从队列获取消息。从这个意义上而言,它是通过身份验证和访问控制进行保护的,与其他任何 MQ 应用程序都非常类似。但是,与大多数消息传递应用程序不同的是,FTE 从消息传递领域到操作系统的文件和目录服务跨越了安全领域边界。该文件和目录服务的安全模型与 WebSphere MQ 所使用的安全模型大相径庭。管理员必须切实有效地实现贯穿这两个领域的安全性,因此,必须区分用户与管理员之间的职责,并且在多数情况下强制实施多个终端用户角色,且每个角色都具有独特的访问权限。

本文将介绍 FTE 的体系结构,以便了解应保护哪些需求以及有哪些可用的安全控制。然后将介绍以下用例:同一企业中的两个不同部门都需要托管文件传输功能,并且要求能够对不同的部门强制实施单独的访问控制。本文的结尾是一个清单,其中包含本文中描述的所有任务。

组件体系结构

存在许多不同版本的 FTE,具体使用哪种版本取决于是以绑定模式还是以客户端模式连接到队列管理器。除功能性组件外,每个版本还包括含有远程工具和文档包的安装媒体。在配置时,将要求管理员提供三种队列管理器的详细信息,它们分别是:代理队列管理器、命令队列管理器和协作队列管理器。新手可能会感到无从下手,但是在理清头绪之后,该集群其实相当简单。FTE 是一个称为代理的长时间运行的守护进程,它附带的工具可让用户向该代理提交命令并查询其状态。除此之外,其他内容都只是一些配置详细信息。

图 1 显示了 FTE 的典型安装,图中没有画出队列管理器。该图显示了发送方代理和接收方代理,各方都有自己的命令队列。文件传输由用户或管理员管理,方法是直接或使用所提供的工具将消息放到发送代理的命令队列中。代理进程对命令消息作出响应,通过 WebSphere MQ 移动文件,然后将活动日志发布到 SYSTEM.FTE 主题上。用户、管理员和应用程序然后可以订阅 SYSTEM.FTE 主题上的状态更新。

图 1. WebSphere MQ File Transfer Edition 组件
图 1

术语

每个 FTE 组件都需要访问队列管理器。最简单的情况是,用户和代理都可以连接到同一个队列管理器。另一种极端情况是,可以跨网络分发代理和用户,并让 WebSphere MQ 负责路由命令和它们之间的数据通信。在讨论拓扑时,有必要基于角色区分不同的节点。如前所述,它们被称为代理队列管理器、命令队列管理器和协作队列管理器。

每个 FTE 代理与一个 V6.0 或更高版本的队列管理器关联。该代理及其队列管理器可以驻留在同一服务器上,或者该代理可以使用 WebSphere MQ 客户端通道与远程队列管理器通信。部署了该代理后,管理员将创建一组队列供该代理使用。由于该队列名称包括代理的名称,因此一个队列管理器可以承载多个代理。这种安排非常普遍,稍后将解释其原因。

命令队列管理器

FTE 附带一些命令行工具和一个 Eclipse 插件,可让用户和工具将命令发给网络中的各种代理。在有两个代理连接到单个队列管理器的小型网络中,可以将该工具配置为直接连接到同一队列管理器。但是,在具有许多代理队列管理器的分布式网络中,让该工具直接连接到每个代理队列管理器来发出命令不符合实际,也没有必要。而是将该工具配置为连接到与所有代理连接的单个队列管理器,依靠 WebSphere MQ 相应地路由命令消息。该工具连接的任何队列管理器都称为命令队列管理器。除了可以解析到每个代理队列管理器的路由外,此队列管理器没有什么特别之处。这里不需要运行 FTE 代码,所需的队列仅仅是由该工具在运行时创建的临时动态队列。任何 V6.0 或更高版本的队列管理器都可以正常运行。而且不需要所有用户都连接到同一命令队列管理器,事实上,期望的部署是将多个用户按角色组合到不同的命令队列管理器中。

协作队列管理器

协作队列管理器是 FTE 网络中的所有组件共有的一个组件。代理中出现的任何重大事件都会导致该代理在协作队列管理器承载的 SYSTEM.FTE 主题上发布一条消息。需要知道 FTE 网络上发生什么情况的任何用户和应用程序都可以订阅这些发布的消息。命令行工具和 Eclipse 插件都需要连接到协作队列管理器才能使用发布的消息。代理没有此项要求,因为发布的消息可以从代理队列管理器跨 WebSphere MQ 网络发送给协作队列管理器。在协作队列管理器上运行不需要实际的 FTE 代码。所有的工作都可以通过使用本机 WebSphere MQ 功能来完成。由于要使用 pub/sub 功能,因此 FTE 要求此队列管理器为 V7.0 或更高版本,除此之外,此队列管理器没有任何特别之处。

部署拓扑

FTE 网络的最简单示例是单一队列管理器,该管理器将代理队列管理器、协作队列管理器和命令队列管理器的所有角色整合在一起。尽管可以这样做,但是,如果只是将一个文件从服务器上的一个目录移动到同一服务器上的另一个目录,此方法没有多大用处。要让 FTE 网络走出实验室并能够在实际中应用,需要做的第一件事就是将代理进程分发到要使用或提交文件的服务器上。这将得到如图 2 中所描述的拓扑,该拓扑有一个队列管理器和一个包含三个节点的网络,其中代理是使用 WebSphere MQ 客户端通道连接的。在此情况下,队列管理器同时提供协作、命令和代理队列管理器这三个角色的服务:

图 2. 带有单个队列管理器的小型 FTE 网络
图 2

图 2 中所示的小型网络在管理、许可成本和效率之间找到了平衡。尽管该文件的逻辑移动是从 Agent01 移动到 Agent02,但物理数据路径却通过队列管理器。这将导致该文件穿过两个网络跃点传输——先从 Agent01 到队列管理器,再从队列管理器到 Agent02。这样可以减少移动部分,且只用一个 MQ 许可证,但是,如果有大量的 FTE 通信,则所占用的网络带宽将超过所传输的实际数量的两倍。

通过与代理一起联合定位队列管理器,大容量 FTE 网络可解决这一问题,如下图 3 中所示。在此拓扑中,命令和状态消息仍流经同时用作协作队列管理器和命令队列管理器的单一队列管理器,但是,数据通过 WebSphere MQ 通道直接在两个代理队列管理器之间流动,如发送方/接收方对。

图 3. 带有本地代理队列管理器的分布式 FTE 网络
图 3

由于此分布式拓扑提供了用于检查客户端与队列管理器到队列管理器连接安全性配置的上下文,因此将使用该拓扑说明本文其余部分的讨论。可以将相同技术的子集用于保证更简单用例(其中所有组件都部署到单个队列管理器中)的安全性。

文件和操作系统安全性

是应用程序还是基础结构?

对于 FTE 代理是业务应用程序还是 WebSphere MQ 的一个基础结构组件,这是一个上下文问题。如果我们将 FTE 视为业务应用程序,则该解决方案只需在应用程序的服务帐户下运行它,并与任何其他非管理应用程序一样将该帐户授予 WebSphere MQ。这将授予 FTE 代理根据需要读取、删除和创建应用程序文件的访问权,WebSphere MQ 使用最小的安全权限就可以执行这些操作。不过,这意味着维护和支持 FTE 将分发到各种应用程序支持团队,这些支持团队必须维持特定级别的 WebSphere MQ 管理技术,并且相互之间保持协作以确保 FTE 配置的兼容性。这样做不但扩展性不太好,而且还会与企业托管的文件传输解决方案目的相冲突,其中包括集中管理,以及管理员与最终用户之间的职责分离。许多商店都想以最少权限安全模型实现法规遵从性,或者仅因为它是一种最佳实践。实现职责分离是实现此最少权限模型的关键,因此,此处讨论的配置将在其自己的服务帐户下实现 FTE 代理,且对 WebSphere MQ 以及业务应用程序文件和进程仅有有限的访问权。

FTE 运行在 UNIX、Windows 和 z/OS 上,且其中的每一个操作系统都具有自己的安全机制。使用 z/OS,访问基于文件名称中的限定符,且创建概要相对方便,这些概要可让 FTE 基于文件名称中的通用高级限定符与最终用户交换文件,所以将其留给读者演练。不过,在 Windows 或 UNIX 上,访问基于文件所有权、目录所有权和组关系。因此,为了获得必要的细粒度访问,有必要进行所有权和权限的某些映射。其目标就是设计一套如下所示的访问规则:

  • FTE 代理是可以处理 FTE 可执行文件和配置文件的唯一帐户
  • 代理和最终用户都可以读取、写入和删除要传输的文件
  • 只有业务帐户才具有对其他业务资产(如应用程序配置文件)的访问权

文件创建和所有权

当 FTE 代理交付文件时,该文件最终将由 FTE 服务帐户所有,且最终用户不会自动拥有对它的访问权。在 UNIX 上,可以将 umask 属性设置为让新创建的文件可全球写入,这可解决该问题,但是几乎无法取得执行最少权限访问原则的资格。较好的方法是设置 umask,这样,新文件可分组写入,并可按组授予访问权。但是,应使用什么组?

新文件的组属性从所有者的主要组继承。如果将组关系作为共享访问权限的机制,则 FTE 服务帐户的主要组不能是私有组,但是必须至少包含一个最终用户或应用程序服务帐户。这使最终用户或应用程序能够读取和删除 FTE 代理在运行时创建的文件。这将导致一系列要求,其中包括 FTE 代理的一个管理服务帐户,该代理配置了包含一个或更多业务帐户的主要组。

这可确保运行时文件安全,但是可能会公开构建时文件。如果 FTE 服务帐户用来执行安装,则这些安装文件将由包含非管理帐户的同一组所拥有。这使最终用户和业务应用程序能够读取、写入和删除 FTE 系统和配置文件。要解决此问题,FTE 系统文件的组关系应更改为 FTE 服务帐户的主要组以外的其他组。FTE 服务帐户应注册为此组的辅助成员。

为了向相反方向(业务用户创建文件、FTE 代理使用文件的位置)移动文件,在该应用程序服务帐户上必须执行类似的主要组和辅助组映射。在此用例中,目标是为 FTE 代理提供对业务帐户创建的文件的访问权,以便向其他位置传输,但是不授予 FTE 代理对业务资产(应用程序配置文件)的访问权。这就增加了一个要求,即 FTE 代理和业务用户的服务帐户必须具有相同的主要组,以便对彼此的文件执行双向读取/写入访问。

图 4 显示了帐户和组的示例映射:

图 4. 帐户及其主要和辅助组的映射
图 4

在 Windows 上,新文件的所有权从创建该文件的用户继承,这与在 UNIX 上一样,但是该文件不像 UNIX 文件那样拥有组所有权。幸运的是,只要向 fteuser 组授予对将包含新文件的文件夹的完全访问权,组关系的同一访问模型在 Windows 上同样能够良好地运行。尽管在 Windows 上可以完全基于用户 ID 权限设置授权,但最好使用前面所介绍的组模型,这是因为该模型可以跨两个平台运行。

运行 FTE 代理

FTE 代理不需要队列管理器的管理权限。遗憾的是,定义启动 FTE 代理的 WebSphere MQ 服务将授予管理权限,因为该代理是作为该队列管理器的子进程启动的。此处的危险不太大,不会使用 FTE 代理来控制 MQ 对象,而是可能用于覆盖 WebSphere MQ 配置文件。例如,在缺省配置中,可以将命令作为 mqm 运行的 FTE 代理获取 qm.ini 文件。攻击者可以编辑 qm.ini 禁用 Object Authority Manager,然后使用同一 FTE 代理用修改的 qm.ini 覆盖合法的 qm.ini。下一次启动该队列管理器时,所有安全性将都被偷偷禁用。避免此类攻击的最好办法是创建用于运行 FTE 代理的服务帐户,并将该服务帐户从 mqm 组中排除。

沙箱

沙箱功能可让管理员在文件系统中的任何位置将一个目录指定为根目录或 FTE 代理。在沙箱外访问文件的任何尝试都将被拒绝。通过编辑 agent.properties 文件和添加 sandboxRoot 属性(该属性带有与指定目录的完全合格目录名称相等的值)可启用该沙箱。

前面描述的攻击(其中强制让 FTE 代理覆盖关键服务器配置文件)假定该代理是使用缺省设置安装的。具体来说,必须将沙箱功能设置为禁用才能执行此类攻击。这是否意味着启用沙箱就不需要用来运行该代理的专用服务帐户了?这取决于安全性要求。按照深入的防护原则,强烈建议您同时实现沙箱功能和服务帐户隔离。如果攻击者发现该代理中的漏洞,该配置就会无法进入相对安全状态,而是暴露管理权限。对于任何 FTE 安装来说,应该将启用沙箱作为强制性要求,作为基本的文件系统安全性要求。

沙箱属性是单个值,而不是一个阵列。如果有多个目录要提交或使用文件,您必须为每个目录配置不同的代理,且每个都有适当的沙箱属性值。

防止文件转发攻击

关于配置文件的最后关注事项是该代理能否读取和写入最终用户数据。所描述的对 qm.ini 文件的攻击取决于可读/写代理的可用性。在具有超过两个代理的网络中,类似的攻击将文件提供给中介代理,然后让代理将该文件中继给攻击者没有直接访问权的第三方代理。由于代理使用与最终用户一样的命令队列互相通信,因此通过阻止对远程代理的命令队列的访问无法阻止该通信。但是,您可以做的是通过再次编辑 agent.properties 文件将这些代理配置为只读或只写。将 maxSourceTransfers 属性设置为零可使该代理拒绝传输出站文件。类似地,将 maxDestinationTransfers 属性设置为零可使该代理拒绝接受入站文件。尽管从语法上看,将这两个值都设置为零是正确的,但不建议这样做,因为这会完全禁止该代理传输任何文件。如果在一台服务器上部署了两个代理,一个作为文件发送方,一个作为文件接收方,配置它们可使其沙箱目录不重叠,从而防止遭受文件中继攻击。

代理队列管理器的基本 MQ 安全性

对代理队列管理器具有管理访问权的任何人员都可以驱动代理被配置执行的任何操作。显然,保护队列管理器免受管理性访问是保护 FTE 代理的先决条件。有关保护队列管理器的详细讨论不在本文范围之内,此处只进行简单的概述。有关 WebSphere MQ 安全性的详细信息,请参见本文结尾的参考资料

对于使用绑定模式(共享内存而不是 SVRCONN 通道)连接到队列管理器的本地用户,使用操作系统身份验证就足够了。对于这些用户,需要将他们从 mqm 组中排除,并使用 setmqaut 命令向队列管理器对象授予适当的权限。

真正的挑战是保护远程连接用户和连接不受其他队列管理器的危害。在 MCAUSER 属性中没有低权限帐户的任何入站通道都能够管理队列管理器和 FTE 代理。保护远程连接的策略就是严格验证连接请求,然后确保与经过验证的身份相对应的 MCAUSER 值是针对该通道配置的。

保护任何队列管理器的第一步都是通过设置任何 SYSTEM.DEF.* 和 SYSTEM.AUTO.* 通道的 MCAUSER('nobody') 来禁用任何不能合法使用的入站通道。

SYSTEM.ADMIN.SVRCONN 通道一般由管理员和最终用户一类的人员用来通过 WebSphere MQ Explorer 访问队列管理器。一般情况下,使用 SSL 证书来验证这些连接,然后使用通道安全性出口(如 BlockIP2)将 SSL 证书动态地映射到该通道实例的 MCAUSER 值。这样,许多用户可以通过使用各种 MCAUSER 值同时安全地访问单个通道定义。在此配置中,该通道通常使用 MCAUSER('nobody') 或其他低权限帐户定义,因此,如果出口发生故障,该通道不会暴露管理权限。

另外,通过在该通道上适当运用 SSLPEER 和 SSLCAUTH 以及静态 MCAUSER 值,在不使用出口的情况下也可以获得同样级别的安全性。运用此策略,您必须定义多个 SVRCONN 通道,使每个安全角色有一个通道。例如,管理员将使用一个带有 MCAUSER('mqm') 或 MCAUSER(' ') 的通道。最终用户将通过一个或多个附加通道连接,其中 MCAUSER 被配置为带有与低权限帐户对应的非空值。在所有这些安全配置中,交互用户将使用 SSL 进行身份验证。启用该通道的 SSLCAUTH 属性可以强制用户的 MQ 客户端提供证书,任何未使用的证书权限都将从队列管理器的 SSL keyring 中删除。

除保护客户端连接外,还必须保护入站 MCA 通道,其中包括 RCVR、RQSTR 和 CLUSRCVR 等通道类型,这是因为如果保留缺省设置,这些通道会暴露管理访问权。通过预置服务帐户和私有组可以解决公开问题。该通道的 MCAUSER 属性将使用该帐户名称配置。接下来,将授权该组用于连接和查询队列管理器,并放置和查询有限数量的合法目的地。该组将被明确拒绝访问可用来获取管理权限的队列,如命令队列、任何传输队列和任何初始化队列。

在一个集群中,此配置既需要通道自动定义出口又需要安全出口。CHAD 出口配置安全出口,后者进而将该通道的 MCAUSER 属性设置为适当的服务帐户。

有关保护队列管理器不受管理性访问的详细信息,请参阅:

针对 FTE 代理的 WebSphere MQ 安全性

下面让我们看一下到目前为止都完成了哪些任务:

  • WebSphere MQ FTE 代理在专用的服务帐户下运行,并带有一个公共组和一个私有组。
  • 已授权该代理对自己目录的读取和执行访问权。
  • 已在业务用户帐户所有权下创建了文件库目录。
  • 启用了代理沙箱并指向文件库目录。
  • 已授权该代理对文件库目录的读取/写入/删除访问权。
  • 代理队列管理器验证所有连接并限制低权限用户的管理权限。

接下来的步骤是保护 FTE 应用程序使用的 WebSphere MQ 对象。为此,需要了解用来驱动代理活动的协议。

管理员、最终用户和其他代理都可以通过将消息放入其命令队列来与 FTE 代理交互。该代理不区分是从管理员和其他代理接收到的命令消息还是从最终用户那里接收到的命令消息。因此,从严格意义上说,安全性基于是否能够将消息放在代理的命令队列,具有此级别访问权的任何人都可以驱动该代理被配置执行的任何操作。

由于这些交互工具都从发送端驱动文件传输,因此增强安全性的一种明显方法就是阻止最终用户访问接收代理。在上面图 3 所示的网络中,交互用户和代理之间的管理命令通过不同的通道传输,而不是通过代理到代理之间的通信传输。通过将不同的 MCAUSER 值放在通道中,您可以让 AGENT01 将消息放在 AGENT02 的命令队列中,同时阻止命令队列管理器上的用户将消息放在同一队列中。下面的图 5 显示了如何基于消息路径控制对命令队列的访问。此安全性增强功能依赖于已提及的那些方法。具体来说,就是必须将 AGENT01 配置为仅发送代理,最终用户不得有访问传输或 AGENT01 队列管理器上的其他管理队列的权限——否则,最终用户只需通过 AGENT01 中继修改的文件或直接发送给 AGENT02。

图 5. 基于消息路径保护对代理命令队列的访问
图 5

代理还可以通过彼此的 SYSTEM.FTE.REPLY.<agentname> 队列通信。因此,必须授权 AGENT01 和 AGENT02 之间的通道将消息放在彼此的回复队列中,而当我们采用最少权限模型时,将明确禁止命令队列管理器中的通道将消息放在代理回复队列中。

协作队列管理器

正如前面所提到的,可以将任何 V7 队列管理器指定为协作队列管理器。FTE 网络中的所有代理都将向同一协作队列管理器以及与该协作队列管理器连接的任何应用程序或工具发布更新,以便订阅该代理的发布消息。V7 队列管理器可以接受队列上的 V6.0 样式的发布消息并将它们转换为 V7 主题。这实现了在 V6.0 队列上部署 FTE 代理的可能性,但是这种安排会带来一些安全性后果。

当配置协作队列管理器时,将定义一个名为 SYSTEM.FTE 的队列。接下来,将 SYSTEM.FTE 这一名称添加到特殊的系统名称列表中,从而使该队列管理器的 pub/sub 引擎能够监控新队列发布消息。这时,进入 SYSTEM.FTE 队列的任何格式正确的 RFH2 消息都将转换为 V7 发布消息。在此过程中,执行了两个安全性检查。第一个是对队列的物理访问。在我们的示例中,协作队列管理器远离网络中的所有代理,所以将消息放在该队列上的就是消息通道代理。作为加强基本队列管理器的一部分,该通道的 MCAUSER 属性被配置了低权限用户 ID。在通道的 MCAUSER 中包含该用户 ID 的私有组正是需要授权将消息放在 SYSTEM.FTE 队列上的组。

接下来的安全性检查是,必须授权将包含在消息标头的 MQMD.UserID 字段中的用户 ID 发布到 SYSTEM.FTE 主题上。这类似于在执行 PCF 命令之前队列管理器的命令服务器执行的授权检查,这就是需要加强基本安全性的原因——如果该代理或普通用户和应用程序在网络中的任何位置都有管理权限,则 MQMD.UserID 中的值将不受信任。这意味着先对代理的连接进行身份验证,然后提供从该代理向协作队列管理器的安全路径。对于以绑定模式连接的代理来说,MQMD.UserID 值将是用于运行该代理的服务帐户。对于以客户机模式连接的代理来说,MQMD.UserID 将包含从 SVRCONN 通道的 MCAUSER 继承的值。当消息从代理队列管理器移向协作队列管理器(其中进行安全性检查)时,这些值在该消息中保持不变。关键要确保当遍布于整个网络中的各种代理发来消息时,所有的 MQMD.UserID 值都能通过授权检查发布到 SYSTEM.FTE。

这里有几种策略比较可行。如果 FTE 组件部署在小型封闭网络中,通过 SYSTEM.FTE 队列进行物理访问控制就足够了。具体做法是,此队列管理器上的所有入站通道都使用 MCAUSER 值限制对 SYSTEM.FTE 队列的访问,以便只有代理能够将消息放在此处。然后可以授权 SYSTEM.FTE 主题进行匿名发布。如果该网络使用经典通道,则此策略效果最好,因为没有完善的通道出口,集群将无法按连接应用安全性。当代理在大量独立服务帐户下运行时,此策略也很受欢迎。

另一种替代方法是,为代理提供的每个服务帐户还必须在协作队列管理器上定义,并授予向 SYSTEM.FTE 主题发布的权限。如果 FTE 网络是使用 WebSphere MQ 集群部署的,此策略也颇受欢迎,因为该集群中的所有节点都有权将消息放在 SYSTEM.FTE 队列中。此策略旨在支持跨代理实例重用代理服务帐户,以便将必须在协作队列管理器上定义的 ID 数量降至最低。在此配置中,将在代理的主机服务器上和承载协作队列管理器的服务器上定义每个代理帐户。在定义之后,会将这些帐户放在协作队列管理器上有权访问 SYSTEM.FTE 队列的组中。

最后,可以配置该代理在其发布中将 MQMD.UserID 设置为任何属性值。agent.properties 文件中的 publicationMDUser 属性控制此行为。利用此策略,可以在一个用户 ID 下运行该代理,在另外一个用户 ID 下发布消息。在每个代理都有独立服务帐户的大型 FTE 网络中,此设置允许它们全都使用同一身份发布消息。尽管这听起来是一个非常理想的解决方案,但却要求该代理具有一定数量的管理权限。一般来说,不建议向任何用户授予设置 MQMD.UserID 的能力。如果某个有此权限的帐户被侵害,将无法阻止攻击者将 MQMD.UserID 设置为与管理帐户(如 mqm)对应的值。如果该攻击者然后可以将该消息提交给队列管理器的命令队列,则该队列管理器将完全被侵害。由于 FTE 代理依赖于指向该协作队列管理器的传输队列的直接访问,因此允许这些代理有效设置 MQMD.UserID 将授予它们对协作队列管理器的管理访问权。如果这可以接受,本文中介绍的其他安全性配置将没有必要。不要将此功能用作安全控制。

其他注意事项

作为安全控制的拓扑角色

我们已经了解到,FTE 的 WebSphere MQ 一方将像其他任何 MQ 应用程序一样得到保护。队列安全性基于服务帐户和组。在典型网络中,对 FTE 代理的访问将通过远程连接进行,并且一部分安全策略将通过消息传递网络的物理连接来实现。如果需要不同的访问角色,这些角色将由各种通道的 MCAUSER 属性中的不同服务帐户控制。到目前为止,这些体系结构方面已经建议了一个拓扑,可以为交互式命令与内部代理命令提供单独的路径。因此还将代理划分为仅发送和仅接受对两部分,而且与该队列管理相关的先决条件已针对管理权限扩大而得到加强。

大多数商店不会在其现有的 WebSphere MQ 网络中实现此级别的安全性。例如,如果将代理放在一个 WebSphere MQ 集群中,其中用户被例行授予访问集群传输队列的权限,则任何用户均可驱动任何 FTE 代理。尽管说它是新出现的最佳实践还为时过早,但可以预见,创建 FTE 代理和用户的小型封闭网络必将成为通用的部署模式。可以随现有的队列管理器创建 FTE 队列管理器,使新的 WebSphere MQ 安装保持最小,但是保护新的小型封闭网络要比将安全性修改为支持许多关键应用程序的现有大型网络要轻松得多。

到目前为止,所讨论的安全角色已包括管理员、最终用户和代理。但是一个典型要求就是具有几个不同类的最终用户和一个粒度安全模型,粒度安全模型将对这些用户相互访问文件强制实施限制。我们已经了解到,FTE 安全性大部分是通过网络的物理拓扑表示的,小型封闭网络是提供对管理员和最终用户职责划分的一种方法。扩展该模型以便在最终用户角色之间提供粒度性可以通过构建多个封闭的 FTE 网络来实现。例如,可将一个 FTE 网络用于 Personnel,将另一个 FTE 网络用于 Payroll。

安全出口是什么情况?

本产品的这一版本中提供的安全出口点允许自身拦截文件传输操作。没有可以拦截命令的出口点,所以不可能使用出口对命令消息进行身份验证。由于当前产品中的这一限制,因此创建 FTE 代理的封闭网络仍是确保只有合法用户才能将消息放在代理的命令队列中的最佳方法。

高级拓扑

假设需要独立的 FTE 代理封闭网络来支持粒度安全模型,那么怎样才能跨这两个封闭网络安全地交换文件呢?这里重申,说它是新出现的最佳实践还有点为时过早,但是可以预见,通过使用重叠沙箱可以满足这一需要。例如,如果 Personnel 需要将一个新的 Employee Master 文件发送给 Payroll,则可以通过以下方式来实现:让来自两个部门的代理使用不同的代理队列管理器,但将其沙箱配置为指向同一目录。虽然两个代理都可访问沙箱中的文件,但代理命令队列仍然在独立的队列管理器上,且仅能由各自的部门访问。因此,重叠访问可以限制到文件系统,从而使暴露的攻击面最小,并避免通过代理命令队列实现细粒度访问控制的复杂性。

另一个高级拓扑用例是跨企业边界的 B2B FTE 网络。对于任何 B2B WebSphere MQ 网络的建议拓扑是,外部连接终止于加强的网关,然后消息通过此网关中继到内部服务器。对于 B2B 接口的另一个建议是,仅允许从队列管理器(而不是客户端)连接。这两种建议的实践均与允许业务合作伙伴使用 MQ FTE 客户端代理连接到内部文件服务器不同。相反,建议的解决方案是使用两个代理,这两个代理都在各自企业的内部网络中,而且都通过加强的 MQ 网关路由消息。尽管这将在各自的代理队列管理器之间增加两个跃点,但它正是对其他任何 B2B 接口推荐的同一网络拓扑。

更新 FTE 配置文件

所提及的几种配置步骤都需要更改代理配置文件。请不要忘记在修改 agent.properties 文件后重新启动该代理,否则不会获得这些新值。确保检查代理日志文件,以验证新配置是否得到正确分析。具体来说,就是该代理不允许在属性值中的最后一个字符后有空格或其他任何空白。

FTE 安全任务列表

下表概述了本文中介绍的任务。由于还没有充分安装 FTE,没有形成确定的最佳实践,并且产品将会继续完善,因此这些任务列表内容会随时更改。

准备

  1. 确定最终用户所需的不同安全角色。
  2. 确定支持最终用户安全角色的一个或多个 FTE 网络拓扑。
  3. 制定文件传输流并将代理确定为只读、只写或可读/写。
  4. 确定将用来批准在协作队列管理器上发布的策略。
  5. 基于上述步骤中的信息,确定要创建的服务帐户和组,记下在每个组中注册的用户,哪些组是主要组,哪些组是次要组。

代理安装

  1. 为 WebSphere MQ FTE 代理提供服务帐户、公共组和私有组。
  2. 在服务器上安装代理。
  3. 在 UNIX 系统上,FTE 安装文件的组关系是执行该安装的帐户的主要组。将这些安装文件的组更改为 FTE 服务帐户的私有(即次要)组。
  4. 将 FTE 安装和配置文件标识为只读,当然不包括日志文件、跟踪文件或在运行时写入的其他任何文件。
  5. 如果该安装是由 FTE 服务帐户之外的帐户执行的,这时还要更改 FTE 安装文件的文件所有权。
  6. 对于将向其提供或从中使用最终用户文件的目录,向 FTE 公共组授予读取/写入/删除权限。
  7. 将最终用户或应用程序帐户添加到 FTE 公共组。
  8. 编辑 agent.properties 文件。插入 sandboxRoot 属性并将其值设置为等同于最终用户文件目录的完全合格的路径名。
  9. 如果该代理为只读,则将 maxDestinationTransfers 属性添加到 agent.properties 文件中,且将值设置为 0。
  10. 如果该代理为只写,则将 maxSourceTransfers 属性添加到 agent.properties 文件中,且将值设置为 0。

基本队列管理器加强

  1. 利用 MCAUSER('nobody') 改变所有的 SYSTEM.DEF.* 和 SYSTEM.AUTO.* 通道。
  2. 提供两个服务帐户和私有组。像加强 WebSphere MQ 安全性中所介绍的那样,我们将 RCVR、RQSTR 和 CLUSRCVR 通道中所用的 ID 称为 mqmmca,将 SVRCONN 通道中所用的帐户称为 mqmmqi。
  3. 利用 MCAUSER('mqmmca') 改变所有用户定义的 RCVR、RQSTR 和 CLUSRCVR 通道。
  4. 利用 MCAUSER('mqmmqi') 改变所有用户定义的 SVRCONN 通道。
  5. 授予 mqmmca 和 mqmmqi 组访问除管理队列之外的所有队列的权限,其中包括命令队列、初始化队列和几乎所有 SYSTEM.* 队列。

这是所有队列管理器的最低基本安全配置。该配置的目的是限制对队列管理器的管理权限。所有其他 WebSphere MQ 安全性均是在此基础配置上构建的,具体来说,能够按每连接授予不同的访问权将需要不少于两个静态 MCAUSER 值。

针对 FTE 代理的 MQ 加强

  1. 对于合法用户可以连接和向其提交传输请求的任何代理来说,都要确定用户命令要到达的通道并授权它们将消息放在 SYSTEM.FTE.COMMAND.<agentname> 队列中。这可以通过该通道定义中的静态 MCAUSER 或设置 MCAUSER 的通道安全出口来实现。任何带有空白 MCAUSER 的通道都会将管理权限向 FTE 代理及队列管理器本身公开。
  2. 将该代理的公共组(示例中的 fteuser)权限授予 SYSTEM.FTE.COMMAND.<agentname> 队列。
  3. 确保在步骤 1 中的通道的 MCAUSER 中配置的用户 ID 是在步骤 2 中授权的组成员。
  4. 将该代理的私有组权限授予所有的 SYSTEM.FTE.* .<agentname> 队列。
  5. 如果该代理正通过客户端通道连接,请确保该通道使用 SSL 对连接进行身份验证,并且验证过的身份在 MCAUSER 字段中结束。
  6. 确保授权指向其他代理的任何入站通道将消息放在本地代理的命令和回复队列中。如果在网络中有几个代理或者有多个本地代理,这可能需要针对 MCAUSER 设置创建多个通道和多个用户 ID。

针对协作队列管理器的 MQ 加强

  1. 如果使用匿名发布,则需要将该组“nobody”访问权授予 SYSTEM.FTE 主题。特定的字符串“nobody”对 WebSphere MQ 非常重要,且表示未经过身份验证的用户。
  2. 另外,创建一个称为 fteagents(注意是复数)的组。
  3. 将 fteagents 组权限授予 SYSTEM.FTE 主题。
  4. 针对用于运行代理的每个服务帐户,在承载协作队列管理器的服务器上用同样的名称创建一个帐户,并在 fteagents 组中注册该帐户。
  5. 为交互式用户创建一个 SVRCONN 通道以便通过 Eclipse 插件连接。
  6. 将新的 SVRCONN 通道的 MCAUSER 设置为用户 ID,该用户 ID 将被批准订阅 SYSTEM.FTE 主题。

针对命令队列管理器的 MQ 加强

我们曾说过,命令队列管理器只不过是 FTE 工具进入网络的一个连接。由于大多数安全配置的重点都放在了连接的入站方,因此,这里除了要确保该队列管理器不受管理侵害以外,不需要其他操作。

  1. 应用基本的 MQ 加强技术对用户进行身份验证并保持非管理性访问。
  2. 确保仅将命令队列管理器指向代理的通道配置为发送文件。

结束语

尽管 FTE 提供了一些有用的安全工具(如沙箱功能),但大多数安全配置都在 FTE 组件的外部。它们包括使用特殊的服务帐户和组、由封闭网络构成的部署拓扑,以及加强基础队列管理器以限制管理访问的先决条件。在需要多个最终用户角色时,此粒度级别将需要隔离的封闭 FTE 网络,且每个最终用户角色一个网络。FTE 网络之间的交互将通过文件系统而不是消息传递网络,因为这样可以将安全暴露降到最低。这些建议将随着产品的成熟和现场测试的好处而发展。除非经过时间的考验,否则任何一个指南都不能称为最佳实践,这些建议也不例外。最后,本文描述的配置任务收集在一个简明的任务列表中,可以将其用作一个起点,然后根据您的具体要求和体验加以利用。

参考资料

条评论

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=WebSphere
ArticleID=407764
ArticleTitle=保护 WebSphere MQ File Transfer Edition V7 的安全
publish-date=07172009