WebSphere MQ 在分布式平台和 z/OS 上的安全性比较

本文比较 WebSphere MQ 在使用 OAM 的分布式平台和使用 RACF 的 z/OS 上的安全性。对于熟悉这两个平台之一的安全性的读者而言,本文将帮助他们了解如何在另一个平台上设立安全性。虽然所有平台对大部分相同的 WebSphere MQ 对象进行保护,比如队列和通道等,但是可以保护什么以及如何实施保护在分布式平台和 z/OS 平台上相差很大。

Tom Schneider, 团队主管,Integrated Technology Delivery,WebSphere MQ, IBM

Tom Schneider 的照片Tom Schneider 从 WebSphere MQ 首次发布开始就一直与之打交道,他从事 z/OS 平台上的产品支持超过 20 年。



2010 年 4 月 15 日

简介

本文对如何在分布式平台(尤其是 UNIX® 和 Windows®)和 z/OS 上实现 IBM® WebSphere® MQ 安全性进行比较。本文有两个主要目标:

  • 帮助已熟悉一个安全实现的读者熟悉另一个安全实现。
  • 通过比较实现安全性的不同方式,从全新的视角描述您熟悉的平台的安全性。

OAM 和 RACF

在分布式平台和 z/OS 上实现 WebSphere MQ 安全性的重要差别是:分布式平台使用 Object Authority Manager (OAM),而 z/OS 使用 RACF。实际上,在分布式平台上可以安装不同的授权服务,类似地,在 z/OS 平台上可以配置不同的外部安全管理器。不过,本文假设使用 OAM 和 RACF,并基于该假设讨论分布式平台和 z/OS 上的安全性。

OAM 是一个用于分布式平台的 WebSphere MQ 组件。由于没有常用的实用程序来保护 WebSphere MQ,因此编写了该组件。RACF 通过类来实现安全性,即用于保护特定类型的资源的 RACF 实体。由于可以为 RACF 定义新的类,因此随着 WebSphere MQ 的发展已有越来越多的类被添加到 RACF,比如用来保护队列的 MQQUEUE 类。

OAM 将授权记录或概要文件储存在一个队列上:SYSTEM.AUTH.DATA.QUEUE。相反,RACF 将摘要文件储存在 RACF 数据库中,因此 z/OS 上的安全性独立于队列管理器进行定义。即使还没有创建队列管理器也可以定义用于保护队列管理器资源的 RACF 概要文件。类似地,可以删除队列管理器和支持它的所有数据集,但是 RACF 概要文件仍然存在,除非您从 RACF 数据库删除它们。

在不同的平台上,谁有权管理安全性也有所不同。在分布式平台上,在 mqm 组中的用户可以通过发出 setmqaut 命令来授予或收回访问权限。在 mqm 组中的用户还可以通过发出 dmpmqaut 和 dspmqaut 命令来转储或显示权限。因此 mqm 组不仅包含队列管理器的管理员,而且还包含安全性管理员。在 z/OS 上可以 将定义 WebSphere MQ 使用的 RACF 类中的概要文件的权限授予作为队列管理器管理员的用户。但是还可以保留定义概要文件的特权,将访问这些概要文件的特权授予 RACF 管理员,这种情况更加常见。对于这种情况,可以由 WebSphere MQ 管理团队之外的团队来控制队列管理器的安全性。队列管理器的管理员甚至没有权限显示定义了什么概要文件或者这些概要文件的访问列表。

OAM 和 RACF 的另一个显著的区别是 RACF 为所有概要文件定义一个 Universal Access (UACC)。UACC 为概要文件设置一个默认的访问级别。任何没有被授予访问权限的用户或组将由 UACC 授予访问权限。在下面比较通用概要文件时将讨论 UACC 及其实现。OAM 和 RACF 还有其他功能上的差别,本文的末尾将讨论其中的一部分。

如何授予访问权限?

OAM 以单独授权的方式授予访问 WebSphere MQ 对象的权限,比如 altusr、browse、chg、clr、connect、crt、get 和 put 等。这允许分散地授予权限,例如,一个用户可以浏览(browse)或向队列发布(put)内容,但不能从队列获取(get)内容。此外,可以使用授予队列的 API(get 或 put)访问权限的概要文件来授予管理员权限,比如创建队列(crt)或删除队列(dlt)的权限。

对于 RACF,它有一组针对所有普通资源的权限:NONE、READ、UPDATE、CONTROL 和 ALTER。这些权限不仅仅用于为 WebSphere MQ 定义的类,还用于所有 RACF 类。因此,这些权限没有直接映射到特定于 WebSphere MQ 的动作,比如 get 或 browse。此外,在 RACF 中以累加的方式授予权限。例如,如果一个组有了 CONTROL 访问权限,那么除了 CONTROL 提供的权限之外,该组中的用户还将获得 READ 和 UPDATE 提供的访问权限。下表给出了当用户拥有列出的访问级别时能够执行哪些 MQI 动作。

表 1. MQQUEUE 类的访问级别
访问级别可以执行的访问
NONE不能访问
READ浏览和查询 (MQINQ)
UPDATEPut 和 READ 允许的任何访问权
CONTROL没有为 MQQUEUE 类定义,因此可以执行 UPDATE 具有的访问权
ALTERMQSET 以及 UPDATE 和 READ 允许的任何访问权

以累加的方式授予访问权限解释了为什么队列的 RACF 安全实现不允许单独授予 get 和 put 访问权限。如果用户能够对保护队列的 MQQUEUE 概要文件进行 UPDATE 访问,那么它将同时获得 get 和 put 访问权限。

进一步说明为什么在 RACF 中不能单独授予 GET 和 PUT 权限

没有为 MQQUEUE 类定义 CONTROL 访问权限,即仅使用 READ、UPDATE 和 ALTER,因此如果授予 CONTROL 权限,它将提供与 UPDATE 相同的访问级别。即使为 MQQUEUE 定义了 CONTROL 访问权限,并假设使用它来授予队列的 put 权限,仍然未解决不能独立授予 get 和 put 访问权限的问题。对于这种情况,拥有 UPDATE 访问权限的用户将能够对队列执行 get 操作,并且拥有 CONTROL 访问权限的用户能够对队列执行 put 操作,但是这也将让消息脱离队列,因为 CONTROL 将提供已经分配给 READ 和 UPDATE 的特权。

此外,由于 RACF 仅提供 5 个访问级别(NONE、READ、UPDATE、CONTROL 和 ALTER),并且 NONE 表示不能访问资源,所有仅剩下 4 个可以分配给任何概要文件的访问级别。这要求 RACF 在不同的类中使用几个不同的概要文件来控制对资源的访问。例如,对于队列,使用一个 MQQUEUE 概要文件来控制对该队列的访问,但是 MQADMIN 类中的其他概要文件用于控制上下文和用户安全性。MQCMDS 类中的概要文件控制对 DEFINE QLOCAL 等命令的访问,这些命令用于定义和修改队列。MQADMIN 类中的其他概要文件控制命令资源的安全性,即定义具有特定名称的队列的权限,例如任何以 APP1 开头的队列。尽管这意味着用于 z/OS 安全性的 RACF 概要文件提供更细的粒度和灵活性,但它们也带来复杂性,因为必须通过定义一组概要文件来保护一个队列。

下表比较了 setmqaut 能够为队列提供的权限和在 z/OS 上获得类似权限所需的 RACF 类、概要文件和访问级别:

表 2. OAM 授予的访问权限和 RACF 中提供的类似访问权限的对比
概要文件 APP1.QUERY 的 setmqaut 访问权限该访问权限提供的行为RACF 访问权限RACF 类和其中的概要文件该访问权限提供的行为
browse浏览队列READMQQUEUE hlq.APP1.QUERY浏览(和在队列上执行查询)
chg修改队列ALTERMQADMIN hlq.QUEUE.APP1.QUERY修改队列(还需要对修改 MQCMDS 类中的队列的命令的访问权限)
clr清除队列ALTERMQADMIN hlq.QUEUE.APP1.QUERY清除队列(还需要对 MQCMDS 类中的 CLEAR QLOCAL 命令的访问权限)
crt定义队列ALTERMQADMIN hlq.QUEUE.APP1.QUERY定义队列(还需要对在 MQCMDS 类中定义队列的命令的访问权限)
dlt删除队列ALTERMQADMIN hlq.QUEUE.APP1.QUERY删除队列(还需要对在 MQCMDS 类中删除队列的命令的访问权限)
dsp显示队列n/an/a只要用户能够对 MQCMDS 类中的队列发出 DISPLAY 命令,就不需要针对该队列的特定授权
get从队列获取消息UPDATEMQQUEUE hlq.APP1.QUERY获取(和发布)消息,以及 READ 提供的权限
put将消息发布到队列UPDATEMQQUEUE hlq.APP1.QUERY发布(和获取)消息,以及 READ 提供的权限
inq在队列上执行查询READMQQUEUE hlq.APP1.QUERY在队列上执行查询(和浏览)
passall传递所有上下文READMQADMIN hlq.CONTEXT.APP1.QUERY传递所有或身份上下文
passid传递 ID 上下文READMQADMIN hlq.CONTEXT.APP1.QUERY传递所有或身份上下文
setMQSET 队列ALTERMQQUEUE hlq.APP1.QUERYMQSET 队列(以及 UPDATE 和 READ 已经提供的所以权限)
setall设置所有上下文CONTROLMQADMIN hlq.CONTEXT.APP1.QUERY设置所有上下文(以及 READ 和 UPDATE 为该概要文件提供的访问权限)
setid设置 ID 上下文UPDATEMQADMIN hlq.CONTEXT.APP1.QUERY设置身份上下文(以及 READ 和 UPDATE 为该概要文件提供的访问权限)

表中的 RACF 概要文件应该以队列管理器作为前缀命名(或者如果队列管理器属于一个队列共享组,还可以使用队列共享组的名词作为前缀)。这通过以上例子中的 hlq 表现出来。例如,如果它们是针对队列管理器 CSQ1 进行定义的,那么 MQQUEUE 类的概要文件的名称应该为 CSQ1.APP1.QUERY。此外,MQADMIN 类概要文件包含针对用于资源安全性命令的概要文件的字符串 QUEUE,或者用于控制对消息 CONTEXT 的访问的概要文件的字符串 CONTEXT。

授予 browse 和 put 访问权限的示例

下面的命令基于 WebSphere MQ 文档的一个例子,它展示了用于授予 GROUP1 browse 和 put 访问权限以及回收 get 访问权限的 setmqaut。以下命令是对队列管理器 QMGR1 上的队列 APP1.QUERY 执行的:

示例 1. 针对 APP1.QUERY 队列的 setmqaut 命令
setmqaut -m QMGR1 -t queue -n APP1.QUERY -g GROUP1 +browse -get +put

接下来是一个几乎等效的 RACF 命令,假设为队列 APP1.QUERY 专门定义了一个 APP1.QUERY 队列。这将能够向 GROUP1 授予对队列管理器 CSQ1 上的队列 APP1.QUERY 执行浏览、查询、获取或发布消息的权限。

示例 2. 针对概要文件 APP1.QUERY 的 RACF PERMIT 命令
PERMIT CSQ1.APP1.QUERY CLASS(MQQUEUE) ID(GROUP1) ACCESS(UPDATE)

对于这些命令有几处需要指明:

  • z/OS 命令不仅授予浏览和发布的访问权限,还授予获取和查询的访问权限。还可以仅授予浏览和查询权限,或者在定义了别名队列时仅授予发布权限,或者向 GROUP1 授予访问禁用发布权限的别名的权限,以及访问禁用获取权限的别名的权限。(细节请参见 System Setup Guide)。不过,这要求使用该队列的所有程序都要知道,需要使用两个不同的名称来访问队列,具体情况取决于是否需要浏览或发布访问权限。这个例子表明 RACF 中的 WebSphere MQ 类不像 OAM 那样提供对 MQI 操作的细粒度访问级别。
  • 不管 setmqaut 分配的访问权限如何,以上的命令都允许执行浏览和发布权限,并删除了获取权限。因为 setmqaut 授予的访问权限是分散的,所以通过以上的命令不能知道 GROUP1 使用什么样的访问权限,或者没有必要将 APP1.QUERY 与该命令授予的访问权限分开。例如,不能仅通过查看该命令判断 GROUP1 是否有权限传递 ID 上下文(passid)。在另一方面,RACF 中的 UPDATE 访问权限将取代先前授予 GROUP1 的所以权限,因为访问权限是累加的。

授予传递上下文权限的示例

这个 setmqaut 命令将 get、put 和 passall 权限授予组 GROUP1。

示例 3. 传递所有上下文的样例 setmqaut 命令
setmqaut -m QMGR1 -t queue -n APP1.QUERY -g GROUP1 +get +put +passall

类似地,下面的 PERMIT 命令将允许 GROUP1 获取或发布消息,以及传递所有上下文。

示例 4. 用于传递上下文的样例 RACF PERMIT 命令
PERMIT CSQ1.APP1.QUERY CLASS(MQQUEUE) ID(GROUP1) ACCESS(UPDATE) 
PERMIT CSQ1.CONTEXT.APP1.QUERY CLASS(MQADMIN) ID(GROUP1) ACCESS(READ)

这个例子表明 RACF 中的 WebSphere MQ 类要求将权限授予两个概要文件(一个在类 MQQUEUE 中,另一个在类 MQADMIN 中),以授予获取消息并能够传递它们的上下文的权限。

如何保护连接?

使用 OAM 时,由 connect 授权体授予连接到队列管理器的权限。在下面的例子中,连接到队列管理器 QMGR1 的权限被授予 group1。

示例 5. 授予连接到分布式队列管理器的权限的样例 setmqaut 命令
setmqaut -m QMGR1 -t qmgr -g group1 +connect

在 z/OS 上,MQCONN RACF 类用于保护连接到队列管理器的能力。在 MQCONN 类中为队列管理器定义了 4 个不同的概要文件。对于每个概要文件,NONE 访问级别将阻止访问,READ(或更高)的访问级别允许用户或组进行连接。下面的表对这 4 个概要文件进行描述。

表 3. 在 MQCONN 类中定义的概要文件以及它们保护的访问权限
概要文件READ 访问权限允许什么类型的连接
hlq.BATCH批作业、TSO 应用程序、DB2 储存过程和通过 Unix System Services (USS) 的访问
hlq.CHIN通道启动程序的访问
hlq.CICS对 CICS 地址空间的访问
hlq.IMS对 IMS 控件和应用程序处理区域的访问

(在前面的 MQCONN 例子中,hlq 可以是队列管理器或队列共享组的名称)。

在分布式平台和 z/OS 平台上的连接安全性的一个重要区别是,对于通道启动程序、CICS 和 IMS,连接权限被分配到区域。例如,通道启动程序地址空间的用户 ID 需要连接到队列管理器的权限,但通道本身不需要。它们使用通道启动程序的连接。但是在分布式平台上,任何需要连接到队列管理器的 MCAUSER 都需要具有连接权限。对于 CICS 也是类似的,CICS 区域的用户 ID 必须具有连接权限,但在 CICS 区域中运行的事务的用户 ID 则不需要。

下面是的例子展示了 RACF PERMIT 命令为用户 ID 授予连接到队列管理器 CSQ1 的通道启动程序权限。

示例 6. 将连接到队列管理器 CSQ1 的权限授予通道启动程序的样例 RACF PERMIT 命令
PERMIT CSQ1.CHIN CLASS(MQCONN) ID(CSQ1CHIN) ACCESS(READ)

通用概要文件的区别

从表面上看,分布式平台上与 z/OS 平台上的通用概要文件是相似的。例如,一个星号和两个星号的含义几乎相同。不过,两个平台在如何应用通用概要文件方面存在根本的区别。

在分布式平台上,概要文件没有默认的访问级别(比如 UACC),因此可以将几个不同的概要文件应用到同一个对象。即不同的用户 ID 和组可以分别访问由不同的通用概要文件控制的 WebSphere MQ 对象。下面使用来自 Version 7.0 WebSphere MQ System Administration Guide 的一个例子进行演示:

示例 7. 来自 WebSphere MQ Administration 手册,在 OAM 上如何应用通用概要文件
The following examples show the use of the dmpmqaut control command to dump 
authority records for generic profiles... 
 
This example dumps all authority records with a profile that matches queue a.b.c. 

dmpmqaut -m qmgr1 -n a.b.c -t q 

The resulting dump would look something like this: 

profile: a.b.c 
object type: queue 
entity: Administrator 
type: principal 
authority: all 
- - - - - - - - - - - - - - - - - 
profile: a.b.* 
object type: queue 
entity: user1 
type: principal 
authority: get, browse, put, inq 
- - - - - - - - - - - - - - - - - 
profile: a.** 
object type: queue 
entity: group1 
type: group 
authority: get

在以上来自手册的例子中,实体 Administrator、user1 和 group1 都有不同的访问级别。Administrator 通过一个完全限定的概要文件获得访问权限(即匹配队列名的概要文件)。然而 user1 通过一个通用概要文件获得访问权限,group1 通过另一个通用概要文件获得访问权限。

在 z/OS 上,RACF 通用概要文件以完全不同的方式应用,这是因为受概要文件上的 UACC 的影响。在下面针对队列 A.B.C(在 z/OS 例子中队列的名称被缩略为大写字母)的例子中,如果为 RACF 定义了相同的 3 个概要文件(即 A.B.C、A.B.* 和 A.**),那么完全限定的 A.B.C 概要文件将控制对队列的访问,因为它是最匹配的。被授予访问权限或由于在概要文件的访问列表中而被拒绝授予权限的用户 ID 和组将拥有它们已获得的访问权限,这是很明显的。所有其他用户和组将获得分配给 UACC 的访问权限。

例如,在以下来自 RL (RLIST) 命令的输出中,UNIVERSAL ACCESS(即 UACC)为 NONE,有几个组和用户 ID 也被授予特定的访问级别。(在这个例子中,RL 命令的大部分输出已被更改,仅有显示概要文件名、UNIVERSAL ACCESS 和访问列表的行被保留)。

示例 8. RACF 概要文件的 RLIST 命令
RL MQQUEUE CSQ1.A.B.C ALL     

CLASS            NAME                                                  
-----            ----                                                  
MQQUEUE    CSQ1.A.B.C                                    
                                                                 
LEVEL  OWNER      UNIVERSAL ACCESS  YOUR ACCESS  WARNING         
-----  --------   ----------------  -----------  -------         
 00    MQADMNS         NONE              ALTER    NO             
                       
USER      ACCESS       
----      ------       
GROUP1    ALTER        
MONITOR   ALTER        
CSQ1CIU   UPDATE             
MQ77CIU   UPDATE

在这个例子中 GROUP1 拥有 ALTER 访问权限。但是如果用户 ID USER1 尝试访问该队列(假设 USER1 没有连接到该访问列表中的其中一个组,比如 GROUP1),它的访问将被拒绝,因为 USER1 没有在针对概要文件 CSQ1.A.B.C 的访问列表中,因此它默认使用权限为 NONE 的 UACC。如果还有另一个名为 CSQ1.A.B.* 的 MQQUEUE 类概要文件,并且将它的 ALTER 访问权限授予 USER1,这样也不管用,因为完全限定的概要文件比匹配程度不是很高的通用概要文件具有更高的优先级别。

简而言之,针对给定用户 ID 和组的最佳匹配是应用在分布式平台上的概要文件,但是在该例子中最佳的匹配仅能应用到在其访问列表中包含用户 ID 和组的概要文件。即不同的通用概要文件可以应用到不同的用户 ID 和组。在 z/OS 上,最佳的匹配基于使用的资源的名称本身,而没有考虑哪个用户或组在它的访问列表中。相同的概要文件可以应用到所有用户 ID 和组,因为它们要么在访问列表中,要么受 UACC 的支配。

OAM 实现通用概要文件的方式具有这样的优势:它能够方便地将一组访问级别分配给一组队列(不管已经定义了什么样的概要文件),因为您能够定义一个仅应用到指定组的概要文件。另一方面,RACF 实现可能更加直观,因为相同的概要文件将应用到所有用户 ID 或组。

有 mqm 组和没有 mqm 组的比较

z/OS 和分布式平台上的安全性的最大区别可能就是是否出现用户 ID(在 UNIX 上)和一个具有无限权限的组(在所有分布式平台上)。mqm 用户 ID 和组很重要,原因如下:

  • 队列管理器和它开始的进程在 mqm 下运行,如果有一个用户 ID 在 mqm 组中,在没有设置 MCAUSER 的情况下 mqm 通常默认接收类型通道(RECEIVER、REQUESTER、CLUSRCVR 或 SVRCONN)。
  • mqm 用户 ID 或连接到 mqm 组的用户 ID 还可以被作为队列管理器的管理员的用户使用。
  • mqm 用户 ID 和组基本上不能受到 OAM 实施的安全保护,因为不能回收它们的访问权限。

相反,在 z/OS 上不存在类似的用户 ID 或组。队列管理器和通道启动程序都作为任务运行,并且它们可以在自己的用户 ID 下运行。队列管理器的用户 ID 能够访问所有 WebSphere MQ 对象,并且不需要显式地授予访问权限。另一方面,通道启动程序的用户 ID 一般都是另一个用户 ID。它需要访问许多 WebSphere MQ 资源,但是必须授予每个资源的访问权限 —— 这些权限不是自动授予的。

在分布式队列管理器上,队列管理器、队列管理器进程和队列管理器的管理员都拥有 mqm 权限,这就带来的挑战,因为所有这些用户都使用相同的权限运行,并且在 OAM 上这种权限是不受限制的。在 z/OS 上,您可以限制通道启动程序的用户 ID 和队列管理器的管理员的权限。也就是说,至少有特权可以应用到通道启动程序,让它仅能访问所需的对象和命令。类似地,队列管理器的管理员用户不一定需要访问所有对象或命令。例如,可以将安全性配置为允许管理员定义队列,但不能访问队列上的消息。

最后,在 z/OS 上注意不要将队列管理器或通道启动程序连接到管理员所在的 RACF 组,因为队列管理器或通道启动程序的访问需求一般与队列管理器的管理者的访问需求不一样。因此如果我们作为队列管理器或通道启动程序连接到相同的 RACF 组,那么最小特权不会起作用,因为很可能通过共享 RACF 组向用户 ID 授予它们不需要的访问权限。

概而言之,在 z/OS 上通道启动程序和队列管理器的管理员不需要配置为具有无限的访问权限。因此只需向用户授予它们所需的访问权限。

通道安全性

z/OS 和分布式平台上的通道的安全性有几个显著的区别。首先是使用的连接。在分布式平台上,每个通道都创建自己的连接。在 z/OS 上,所有通道都使用通道启动程序地址空间创建的同一个连接,即与通道启动程序的已开始任务相关联的连接。如果通道启动程序的用户 ID 具有访问 MQADMIN 类的 RESLEVEL 概要文件的更高权限,那么这在 z/OS 上则更加明显。(在前一篇 developerWorks 文章 “WebSphere MQ for z/OS security” 中讨论了 RESLEVEL)。

第二个区别是与一个通道相关联的用户 ID 的数量。在分布式平台上,接收通道有一个用户 ID,即 MCAUSER。MCAUSER 是 mqm 默认的,除非进行了设置(例如,被 MQI 客户端设置)或在通道定义上进行了硬编码。

z/OS 接收通道有两个用户 ID,通道用户 ID(通常被忽视)和 MCAUSER。针对 TCP/IP 的通道用户 ID 默认作为通道启动程序的用户 ID。如果在通道上使用了 SSL,那么可以选择设置通道用户 ID。要设置的话,可以通过以下两种方式之一进行设置:

  • 把用户 ID 添加到队列管理器的密匙列表中之后与通道的证书关联起来的用户 ID 。
  • 或者是通过 RACF Certificate Name Filter (CNF) 实用程序分配的用户 ID。可以使用 CNF,例如,如果远程队列管理器的证书由 CA 签名,那么只有 CA 的证书出现在本地队列管理器的密匙列表中。

在分布式平台上,MCAUSER 的分配方式是类似的,唯一不同的地方是它不是默认到 mqm 的,而是默认到通道启动程序的用户 ID。在分布式平台上不希望 MCAUSER 是默认的,因为是 mqm 具有访问队列和命令的未受限制的特权。在 z/OS 上,默认到通道启动程序的用户 ID 的通道的影响取决于以下两点:

  • 通道启动程序的用户 ID 对保护队列及其上下文的 MQQUEUE 和 MQADMIN 类的访问级别。
  • 对于 SVRCONN 通道,可以通过通道输入的命令取决于授予通道启动程序的用户 ID 的命令。 默认到通道启动程序的用户 ID 将不提供完全的管理员访问权限。

如前所述,通道启动程序的用户 ID 不应该被授予访问它不需要的资源(队列和命令等)的特权。此外,一定不要将访问 RESLEVEL 概要文件的特权授予通道启动程序的用户 ID,这样做将导致绕过针对通道启动程序和通道的 MQI 安全检查,因为它们使用通道启动程序的连接来连接到队列管理器。

OAM 和 RACF 的功能差别

除了以上讨论的差别之外,OAM 和 RACF 提供的功能也存在差别。

一个非常重要的区别是:在定义对象时默认授予用户 ID 或组的访问权限。对于 OAM,完整的访问权限被授予创建对象的用户 ID。在 UNIX 上,由于访问权限是在组级别上管理的,这意味着 OAM 为用户 ID 提供访问主要组的权限。这要求管理员在创建对象时要作为 mqm 用户 ID 登录,从而仅默认为 mqm 组授予访问权限,或者如果使用个人用户 ID 来定义对象,则要知道该用户 ID 的主要组是什么。例如,如果管理员使用个人用户 ID 登录时定义一个对象,并且该用户的 ID 的主要组为 staff,那么访问权限将授给 staff。很明显,队列管理器的管理员在使用用户 ID 定义 WebSphere MQ 对象时,必须十分关注该用户 ID 的主要组。否则可能将访问权限意外授给其他不应该具有该权限的组,比如 staff。

在 z/OS 上,RACF SETROPTS 设置(ADDCREATOR 或 NOADDCREATOR)控制授予定义概要文件的用户的访问权限。如果使用 ADDCREATOR,那么将把 ALTER 访问权限授予定义概要文件的用户 ID。该权限仅授予用户 ID,而不是它所属的任何组。如果使用 NOADDCREATOR,那么默认情况下不向定义概要文件的用户授予任何访问权限。

由于 OAM 仅包含 WebSphere MQ,因此可以使用 dmpmqaut 命令轻松创建一个供队列管理器使用的 WebSphere MQ 概要文件列表。 在 z/OS 上,针对 WebSphere MQ 的 RACF 概要文件可以分散到多个不同的类中,包括组(以及 WebSphere MQ V7 中的混合类),因此转储包含所有正在使用的概要文件的列表并不是一件简单的事情。必须使用一系列 RLIST 命令来显示各种 WebSphere MQ 类。

最后,RACF 还提供一些 OAM 没有的特性。RACF 概要文件上的 AUDIT 参数提供一种方式来审计对概要文件包含的资源的访问尝试,不管访问是否成功。这些审计记录和其他 z/OS 系统信息一起保存在 SMF 数据集中。应该避免 WebSphere MQ 管理员和用户修改 SMF 数据集。RACF 有利于实行职责分离,因为完全从 WebSphere MQ 管理员分离出来的一个或多个组可以控制对安全性概要文件的定义,以及向这些概要文件授予访问权限(和审计这些访问权限)。

结束语

本文讨论了在 z/OS 和分布式平台(比如 UNIX 和 Windows)上为 WebSphere MQ 实现安全性的差别。尽管需要保护的大部分资源在 z/OS 和分布式平台上是一样的,但是用于保护它们的安全性措施之间存在不同之处。尤其需要注意以下差别:

  • 因为 RACF 有一组不特定于 WebSphere MQ 的有限权限(NONE、READ、UPDATE、CONTROL 和 ALTER),所以它通常在不同的 RACF 类中使用不同的概要文件来保护相同的资源,而使用特定于 WebSphere MQ 权限的 OAM 可以使用一个概要文件来保护该资源。
  • RACF 在概要文件上提供一个默认的访问级别 Universal Access(缩写为 UACC)。任何未被专门授予访问权限的用户和组将获得分配给 UACC 的访问权限。OAM 概要文件不存在与 UACC 对应的地方;用户可以包含或未包含在访问列表中。
  • 实现通用概要文件的方式不同。OAM 根据包含用户的用户 ID 或组的概要文件为资源查找最匹配的概要文件。RACF 根据资源名进行严格的匹配。如果用户不在最匹配概要文件的访问列表中,那么它们将获得 UACC 提供的访问权限。
  • 在分布式平台上,mqm 组由队列管理器和队列管理器的管理员使用,也可以被通道用作默认的组。mqm 拥有未受限制的访问权限,因此您不能回收它的访问权限。在 z/OS 上则有所不同,管理员和通道启动程序用户 ID 和其他用户一样受到相同的安全性检查。您应该仅向用户授予它们所需的访问权限。
  • 在 z/OS 上所有通道都使用通道启动程序创建的连接,而在分布式平台上每个通道都有自己的连接。 在 z/OS 上,如果通道启动程序对 RESLEVEL 概要文件的访问权限大于 NONE 访问级别,这就变得非常重要。
  • 通道的用户 ID 数量在分布式平台和 z/OS 上是不同的。MCAUSER 的默认值也不同。
  • 在分布式平台上,在 mqm 组中的用户同时是队列管理器和队列管理器安全的管理员。但是在 z/OS 中,可以由两个完全独立的组控制队列管理器和安全性。

关于这个主题还有很多需要讨论的地方,但是本文指出了两个平台之间的最重要差别。如果您还想到关于该主题的其他重要问题,欢迎以帖子评论的形式发布出来,或者直接和作者联系。

参考资料

学习

获得产品和技术

讨论

  • WebSphere MQ FTE 论坛
    为 WebSphere MQ FTE 技术问题找到答案并与其他用户分享 WebSphere MQ FTE 知识。
  • WebSphere 论坛
    针对特定产品的论坛,您可以从中找到关于技术问题的答案并与其他 WebSphere 用户分享您的技能。
  • 与 WebSphere 相关的活动
    在全球范围内为 WebSphere 开发人员提供的会议、商业展示、网络广播和其他活动。
  • developerWorks blogs
    与 developerWorks 用户、作者、IBM 编辑和开发人员交流。
  • developerWorks Webcasts
    这些由 IBM 专家提供的免费技术会议能够加快您的学习速度,并帮助您在开发最复杂的软件项目时取得成功。这些会议包括时长为一个小时的网络广播,以及在全球范围内举行的半天和全天的现场会议。
  • developerWorks podcasts
    收听有趣的访谈并与其他软件创新者进行讨论。

条评论

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=482821
ArticleTitle=WebSphere MQ 在分布式平台和 z/OS 上的安全性比较
publish-date=04152010