Websphere MQ 主题和 SSL

Question

我试图了解 MQ 主题在行业中的使用有多普遍。 以及带有 SSL 的 MQ？

谢谢， 伙计

Answer 1

发布/订阅
在 WMQ v7 之前，Pub/Sub 既可以作为 WMQ 的单独组件使用，也可以作为 WebSphere Message Broker 功能的一部分使用。现在在 v7 中，pub/sub 是 WMQ 不可或缺的一部分，并允许主题级别的安全性。有一定数量的 pub/sub 采用正在发生，因为它现在作为原生功能融入 WMQ。

另一个影响 WMQ 发布/订阅的因素是更多的人通过 WMQ 文件传输版接触到它。 WMQ FTE 将文件传输状态作为出版物提供，许多使用此产品的人正在编写监视这些主题的应用程序，以提供各种自定义功能。一旦他们开始使用 pub/sub，其中许多商店就会开始看到它的其他用途。

Pub/Sub 还解决了一些常见的消息传递问题，例如当前正在写入队列的应用程序，并且出现了将该消息的副本提供给另一个消费者的新要求。在 v7 之前，将应用程序从写入队列切换到写入主题有点侵入性，并且需要更改 JMS 应用程序的配置或更改其他类型代码的代码。解决该问题的最简单方法是使用将副本写入两个或更多队列的应用程序或出口来拦截消息。从 v7 开始，可以为为队列编写的应用程序提供主题的别名。生产者仍然认为它正在写入队列，但 WMQ 正在将消息发布到主题。然后，消费者可以直接订阅，或者在需要队列的遗留代码的情况下，管理订阅可以导致主题上的消息被传递到队列。我看到很多 pub/sub 都可以满足这些需求。

在某些情况下，pub/sub 是合适的解决方案，并且仅出于这个原因使用它。过去，对单独组件、管理技能或 WMB 许可证的要求是采用的障碍，导致部分发布/订阅应用程序被重新设计为点对点。使用 WMQ 中内置的 pub/sub，这些障碍被消除或至少显着减少，这导致更多的采用，因为它是解决手头问题的正确架构。

总的来说，我会说 WMQ pub/sub 在 v7 中已经成为主流。由于 v6 已于 2011 年 9 月宣布终止使用，因此今年将大规模迁移到 v7，随后将更多地采用 pub/sub。

SSL/TLS
至于 SSL，WMQ 安全正在接近主流。我不会说 SSL 是标准 - 只是现在 - 但在过去的两三年里，我在 IMPACT 和欧洲 WebSphere 技术会议上的 WMQ Hands-On Security Lab 会议的需求已经足够多。我recently wrote...

术语“受信任的内部网络” 被创造来区分那部分 来自内部的网络 防火墙外的目的地。但 本文中使用的“受信任”一词 上下文是相对的。它不是 应该表明内部 网络被隐式信任，只有 它比事物更值得信赖 在防火墙之外。很遗憾， 该术语有时被解释为 毫不夸张的说。我有客户 很认真地告诉我定义 我们信任“受信任”上的一切 内部网络”，这就是我们称之为 它那个。当然，这夸大了 情况如此，因为即使是最坚定的 相信内部的信徒 网络仍然强制执行基于密码的 登录服务器、数据库和 应用程序。所以内部网络 是受信任的，但只是在一定程度上， 甚至在内部网络上 身份验证和授权是 必不可少。

虽然 SSL（实际上是 TLS）通道会加密，但它们也会进行身份验证。随着越来越多的人意识到他们需要在“受信任的”内部网络上对 WMQ 连接进行身份验证，SSL 已成为实现此目的的常用方法。当然，对于内部和外部连接的 WMQ 通道上的隐私（加密）和完整性服务的要求也越来越高，这也推动了 WMQ SSL 通道的采用。

现在 SSL 更加普遍，当人们不完全了解 WMQ 安全性时，会出现许多次要挑战。这些现在是WMQ listserve 和MQSeries.net 上的常见主题这一事实证明了SSL 的采用水平。其中一些次要问题是在 QMgr 的密钥库中包含未使用的证书颁发机构根证书，或者缺少 QMgr 通道设置，如 SSLPEER（按可分辨名称过滤连接）或 MCAUSER（将授权映射到特定用户帐户）。人们经常启用 SSL，但忽略了这些其他设置中的一个或多个，并且没有达到他们预期的安全级别。由于您必须启用 SSL 才能让这些事情出现问题，所以正如我的一个朋友所说的“奢侈问题”。接受 SSLPEER 设置的挑战总比完全不应用 SSL 要好得多。

总结...
所以我想对这两个问题的简短回答是，在 WMQ 中使用 pub/sub 和 SSL 是很常见的。现在两者都处于急剧上升的趋势，如果我正在编写新的应用程序，我肯定会使用 SSL，并且会毫不犹豫地在需要的地方使用 WMQ pub/sub。