评论专栏: T.Rob Wyatt：有关 WebSphere MQ 安全方面您所不知道的一些内容

目前 WebSphere MQ 的安全状况

作为 IBM Software Services for WebSphere (ISSW) 的成员，我访问过各种各样的客户站点，并帮助他们解决有关 WebSphere MQ 的问题。尽管在少数情况下是必需的，但我总是要求进行一次安全评估。毕竟，如果有人认为他们的系统并不很安全，那么他们希望知道究竟出了什么问题。在开始进行这项工作时，我希望能够找出具体的问题，但很少能够实现这个目的。因此，当我发现对于进行测试的大多数站点，能够获得匿名的管理访问权限时，我有些震惊。在有些情况下，WebSphere MQ 网络不安全的原因是因为数据本身并不是非常关键或非常敏感。但是在大多数情况下，当管理员对 OAM 授权概要（在许多情况下还包括 SSL）进行配置的时候，他们相信消息传递网络是安全的，但实际上，我可以很容易地获得访问权限。即使我的经验仅代表了很少一部分的 WebSphere MQ 系统安装，但我们所有的人都需要再次审视有关 WebSphere MQ 安全的问题。

回页首

究竟存在什么问题呢？

这个问题过于广泛，以致于很难提供确定性的答案，但是我可以将我所见到的情况告诉您。

• 我曾碰到过这样一位客户，他费尽心思将所创建的、应该具有较低权限的 ID 记录到通道的 MCAUSER 中。他们甚至说明了应该通过 MCAUSER 中的无效 ID 来禁用 SYSTEM.DEF.SVRCONN。但是，他们却没有在任何地方对 SYSTEM.AUTO.SVRCONN 进行保护，包括在生产环境中。这个用户知道如何对客户端通道进行授权，但却不是很清楚应该授予哪些权限以及为什么要这样授权。不要通过死记硬背的方法来学习安全方面的知识，必须理解相关的基础原则，并在教材中示例的基础上对其进行应用。

• 另一个管理员创建了一些客户端连接通道，并将其配置为使用 SSL。开发人员可以通过 SSL 隧道进行连接，通过 OAM 概要对其访问权限进行控制。但这个系统信任所提交的任何 ID，对于开发人员来说，提交不同的 ID 非常简单，甚至是管理 ID。参考手册说明了目标 QMgr 必须理解客户端通道提交的 ID 以获得访问权限，并且还详细描述了 SSL 配置。该管理员严格按照手册中的内容进行操作，但没有得到希望的结果，这是因为他没有完全理解这两个系统之间的交互过程。

要解决这个问题，我们需要消除一些疑问以澄清某些常见的误解，并将所介绍的这些内容应用于实际情况中。但在进一步介绍之前，先对有关内容做一个概述。

回页首

基本的安全概念

• 身份验证在一定的程度上保证了某个标识是真实的。可行的身份验证等级包括：

  • 在该范围的最下面是匿名访问，或者没有任何身份验证：我们无法了解您的身份，并且我们对此并不在意。

  • 在此之上是简单断言，您可以在其中表明自己的身份，而我可以根据您的陈述来接受您的声明。可以将其看作“信誉系统”。

  • 继续向上是无处不在的质询/响应，它同时需要 ID 和密码。

  • 最后是强身份验证，其中使用两种或者更多的方法对一个标识进行验证，如密码和加密密钥。

• 身份验证域提供了一个上下文，可以在其中对 ID 进行验证。独立的 UNIX® 服务器作为自身的身份验证域。用户 ID 和密码存储在其本地文件中，并且在任何其他上下文（如在另一台服务器上）中是没有意义的。可以由多台服务器组成更大的身份验证域，这些服务器包括 UNIX NIS 和 Microsoft® Windows® Active Directory。

• 跨域身份验证适用于需要在包含相应资源的域的外部对某个标识进行身份验证的情况，然后将其传递到域的内部。当远程域受到信任并且可以自己进行身份验证时，这种方法最为有效。

• 授权的目的是对每个 ID、每个角色、或者每个概要进行访问控制。授权是一个绝对的概念，对于任何访问请求，要么返回“Yes”，要么返回“No”。一个给定的资源可能支持许多不同的功能（CONNECT、OPEN、CLOSE 等等）以及许多不同的选项（INPUT、OUTPUT、BROWSE、INQUIRE 等等），但对授权请求的响应始终可以归结为“Yes”或“No”。

在配置 WebSphere MQ 安全的过程中最常见的错误是，不理解授权和身份验证之间的差异，或者对这些功能的实现进行了不正确的假设。既然我们已经清楚了这些术语的定义，那么让我们来研究一下可能导致漏洞的误解。

回页首

疑问 #1：对 WebSphere MQ API 调用进行了身份验证

WebSphere MQ 仅在 API 调用的过程中提供授权。对于本地处理的情况，由基础 OS 执行身份验证。这通常是足够的，只要不是任何人都可以使用 root 进行访问。但是，当另一个 QMgr 产生了一些消息，并且这些消息通过通道到达，如果确实需要进行身份验证，那么以远程的方式对这个 ID 进行身份验证。在这种情况下，验证失败的原因是发生了跨域身份验证。

设置 PUTAUT(DEF) 和 MCAUSER(' ') 的缺省通道，对于到达的消息具有全面的管理权力。要确保其安全：

1. 必须在远程系统中进行身份验证和授权，并且
2. 我们必须信任该远程系统。

例如，如果远程系统中的一个较低权限的 ID 经过授权可以将消息直接放到传输队列中，那么该用户可以将消息提交到本地 QMgr 中的任意队列，而不需要进行进一步的授权。删除对传输队列的授权将强制该用户只能将消息放到 QRemote 定义中，从而将消息限制到特定的授权目标。

我们可以设置通道中的 PUTAUT(CTX) 以强制进行本地授权，但这需要每个授权的 ID 在本地身份验证域中进行注册。对于许多 WebSphere MQ 用户，他们所使用的网络包括各种平台的混合，如 Windows、UNIX 和大型机系统，这样做并不是很实际。但如果您的机构使用了 PUTAUT(CTX)，下面将告诉您，通常我在安全评估的过程中如何侵入系统：我在自己的便携式计算机中定义了一个 SDR 通道，它与您的 RCVR 具有相同的名称，并且使用常用的管理 ID 来发送消息。这样做的原因是，进行身份验证的远程 QMgr 是受到信任的，但并没有经过身份验证。只有在可以信任远程域并对其进行身份验证时，才能够使用跨域身份验证。

通过将 SSL 配置为对通道连接进行身份验证，可以解决这个问题，这样一来，到达的消息仅来自于受信的系统。使用 PUTAUT(DEF)，将 MCAUSER 设置为 WebSphere MQ 管理团队所拥有的较低权限的非登录 ID，然后将这个 ID 授权给应用程序队列和 DLQ。这相当于使用了一个空白的 MCAUSER，因为只使用了一个授权概要，但至少它是较低权限的概要。如果使用了集群，您还必须将较低权限的 MCAUSER 授权给 SYSTEM.CLUSTER.COMMAND.QUEUE。不要将其授权给任何传输队列。相反，如果需要多跃点路由，可以使用 QRemote 定义。

回页首

疑问 #2：使用 SSL 和 OAM 可以提供很强的安全性

将 SSL 配置为根据证书中的专有名称进行筛选，这样可以提供一种有效的身份验证方式。Object Authority Manager (OAM) 中定义的授权策略可以基于用户 ID 和组成员身份进行访问控制。这里的问题在于，认为这两者组合在一起就能够提供安全的配置。许多人并不清楚的是，这两种功能之间根本不会进行交互！它只是一种基本的工具，可用来限制允许连接到通道的用户，但是 SSL 功能不能扩展到 API 调用，也不能保证 MQMD 中的 ID 对应于证书的拥有者。

考虑这样一种情况，为开发人员“Joe”颁发了证书，并且他使用客户端通道连接到 QMgr。管理员创建 OAM 概要以允许 Joe 连接到 QMgr 并访问特定的队列。要允许开发人员在桌面中使用 WebSphere MQ Explorer，这是一种常见的配置。遗憾的是，SSL 并不检查 Joe 在进行连接时所使用的 ID 是否是他自己的 ID。事实上，Joe 的用户 ID 与他的 SSL 证书之间不存在任何关联。在连接的过程中，Joe 可以很容易地更改所提交的 ID，并且如果他使用了管理 ID，那么他将获得完全的管理权限。

既然我们了解了 SSL 身份验证不能扩展到 API 调用，下面让我们来详细说明对于 OAM 它究竟执行哪些操作：

• 在配置为根据证书专有名称进行筛选时，SSL 可以确保入站连接来源于受信的系统（尽管我们仍可能需要将 MCAUSER 设置为一个较低权限值）。
• 当这些受信的系统位于兼容的身份验证域中时，SSL 允许我们使用 PUTAUT(CTX)。
• 在与不可信系统（如 B2B 接口）进行通信时，SSL 可以确保这些连接来源于一个特定的不可信系统。

当使用 SSL 时，可以应用“疑问 #1”中所提到的所有安全配置。您还需要一种方式对入站消息执行较低权限的访问策略，这通常可以通过 MCAUSER 来实现。

回页首

疑问 #3：远程系统仅可以通过指定的通道进行连接

从人们对这个问题的认识和确信无疑的态度来说，这并不真的是个疑问。这里的问题是，许多人根本就没有认真思考过这个问题。我知道存在这样一种情况，供应商为每个客户设置了使用专门的 SSL 进行保护的 SDR/RCVR 通道对。他们认为任何客户端都不能假扮另一个客户端，因为每个通道具有唯一的较低权限的 MCAUSER，它可以将入站消息限制于特定的队列。

但该供应商对 WebSphere MQ 的工作方式进行了错误的假设：客户仅使用所分配的通道，而 SSL 将会保证这一点。事实上，SSL 仅对其配置中的通道进行身份验证，却无法防止用户连接到任何未受保护的通道。有一天供应商会惊奇地发现，某个客户端可以使用 WebSphere MQ Explorer 和 SYSTEM.ADMIN.SVRCONN 通道连接到 QMgr，并且具有完全的管理权力。为客户配置 SSL 并相信它们是安全的，但供应商忽略了一个事实，即 SSL 并没有限制客户端可以使用哪个通道。

根据定义，任何接受非本地控制系统的连接的 QMgr 都是不可信的，并且不可信系统应该受到更严格的限制。当允许连接不可信系统时，需要禁用所有的 SYSTEM.* 通道，并且保护其余的通道（甚至包括内部通道），同时使用 SSL 和 MCAUSER。如果远程管理需要使用通道，可以将其配置为使用 SSL 根据证书 DN 进行筛选，并且仅接受来自管理用户的连接。

回页首

总结

请当心，现在数据窃取者的手段越来越高明。他们可能也知道这些方法，并利用它们进行入侵。许多机构开始的时候使用未进行保护的受信网络，并且对于需要更高安全性的业务案例进行特殊的处理。对安全性进行特殊的处理而不是将其作为基本规则，这意味着有时候可能会忽视安全性问题。这种情况的出现是偶然的还是为了满足项目时限和预算有意为之，这与是否会利用该漏洞无关。相反，基准配置应该要求完全安全的系统，并在项目之初考虑到附加的时间、管理、或工具方面的成本。在这种情况下，如果您开始忽视了某些内容，随后又需要确保数据的低风险，那也没有关系！

您不应该在没有获得批准的情况下使用这些方法来进行安全测试。您与数据窃取者面临着相同的法规。事实上您并不会造成任何损害，而且也不会窃取任何数据，但这并不重要，而且实际上也很难证实这一点！在进行安全测试之前，请告知您的公司或业务合作伙伴。

但请仔细地进行安全评估。尽管在本文有限的篇幅中不可能涉及与该主题相关的所有内容，但通过这些示例向您介绍了一些最常见的问题，通过学习这些示例，您应该可以堵住最明显的安全漏洞。如果您需要其他帮助，可以考虑 taking a class、参加 WebSphere 会议或使用来自 ISSW 的帮助。