WebSphere MQ 安全性炙手可热

核心提示： 战略性修复更新通道代码您将要进行的第一件事是升级到 WebSphere MQ V6.0.2.2 或应用通道安全修复程序，如果您无法升级或应用修复程序，WebSphere MQ 安全性炙手可热(3)，可以采用避开这个问题的方法，即在未使用的通道上设置无效的 SSLCIPH 值，甚至在启用 SSL

战略性修复

更新通道代码

您将要进行的第一件事是升级到 WebSphere MQ V6.0.2.2 或应用通道安全修复程序。如果您无法升级或应用修复程序，可以采用避开这个问题的方法，即在未使用的通道上设置无效的 SSLCIPH 值。这将导致在执行可利用的代码前任何连接尝试都失败。没有任何办法消除合法使用的通道上的这个漏洞，但对于这些通道，启用 SSL 并对特定的 SSLPEER 值进行筛选至少能够限制潜在的攻击者数量。

身份验证

应用了修复程序或升级后，您可以采取哪些步骤来保证队列管理器的安全？如果有用户或应用程序以绑定模式连接（使用共享内存），操作系统将使用 ID 和密码对其进行身份验证。如果服务器具有合理的安全性，则本地登录也是安全的。问题在于，您如何对远程连接用户、以客户端模式连接的应用程序以及来自其他队列管理器的连接进行身份验证。

到队列管理器的远程连接通常通过通道进行。没有为通道提供用户 ID 时，身份验证检查将针对与运行通道的进程关联的用户 ID 进行——该 ID 总是具有所需的相应权限。MCA 通道（两个队列管理器之间的通道）可以配置为基于消息 Header 中包含的 ID 进行授权，但没有身份验证，消息 Header 中的 ID 无法得到信任。

MQI（客户端）通道的情况也是类似。WebSphere MQ 客户端代码将传递用于对其进行调用的登录用户 ID，但这只是一个缺省值。编程接口允许从应用程序内设置在客户端连接请求中出现的 ID。这将覆盖从系统获得的 ID。显然，除非能够安排对其进行身份验证，否则这些 ID 也无法获得信任。

您可能此时会认为，启用 SSL 将提供所需的身份验证。这也对，也不对。使用客户机通过 SSL 通道连接时，SSL 协议将使用通道代理启动和终止。SSL 提供的身份验证并没有扩展到 API 调用。建立连接之后，SSL 交换之外的所有东西（连接请求、API 调用）都会像没有 SSL 时一样工作。因此，即使队列管理器配置为仅接受来自 John Doe 的 SSL 身份验证连接，MQ API 仍然允许 John 在其连接请求中断言一个不同的身份。如果 John 断言 Jane Doe 的身份，队列管理器将毫无疑问地接受，甚至在启用 SSL 的通道上也是如此。如果 John 选择断言 mqm ID，则将获得管理权限。