Websphere MQ 主题和 SSL

发布于 2024-10-08 12:24:48 字数 63 浏览 3 评论 0 原文

我试图了解 MQ Topics 在业界的使用有多普遍。还有带 SSL 的 MQ？

谢谢，盖伊

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

挖个坑埋了你 2024-10-15 12:24:48

发布/订阅
在 WMQ v7 之前，Pub/Sub 既可以作为 WMQ 的单独组件使用，也可以作为 WebSphere Message Broker 功能的一部分使用。现在，在 v7 中，pub/sub 是 WMQ 的组成部分，并允许主题级安全性。发布/订阅之所以得到一定程度的采用，只是因为它现在作为本机功能融入到 WMQ 中。

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

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

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

总的来说，我想说 WMQ pub/sub 已经在 v7 中成为主流。由于 v6 已宣布将于 2011 年 9 月终止生命，因此今年将大规模迁移到 v7，从而导致更多的 pub/sub 采用。

SSL/TLS
至于 SSL，WMQ 安全性已接近主流。我不会说 SSL 已经成为常态，但在过去的两三年里，它的需求量足以让我的最近写了...

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

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

现在 SSL 越来越普遍，当人们不完全了解 WMQ 安全性时，就会出现许多次要挑战。事实上，这些现在是 WMQ listserve 和 < a href="http://mqseries.net" rel="noreferrer">MQSeries.net 证明了 SSL 采用的水平。其中一些次要问题是 QMgr 密钥库中包含未使用的证书颁发机构根证书，或者缺乏 QMgr 通道设置，例如 SSLPEER（按可分辨名称过滤连接）或 MCAUSER（将授权映射到特定用户帐户）。人们经常启用 SSL，但忽略了其中一项或多项其他设置，因而没有达到他们预期的安全级别。由于您必须启用 SSL 才能解决这些问题，正如我的一位朋友所说，这是“一个奢侈的问题”。接受 SSLPEER 设置的挑战比根本不应用 SSL 好得多。

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

Pub/Sub
Prior to v7 of WMQ, Pub/Sub was available either as a separate component of WMQ or as part of the functionality of WebSphere Message Broker. Now in v7 pub/sub is integral to WMQ and allows topic-level security. There is a certain amount of pub/sub adoption that is occurring just because it is now baked into WMQ as native functionality.

Another factor influencing uptake on WMQ pub/sub is that more people are being exposed to it through WMQ File Transfer Edition. WMQ FTE makes status of file transfers available as publications and many people with this product are writing applications that monitor these topics to provide a variety of custom functionality. Once they start using pub/sub, many of these shops begin to see other uses for it.

Pub/Sub also solves some common problems with messaging such as an application that currently writes to a queue and a new requirement comes up to get a copy of that message to another consumer. Prior to v7, switching an app from writing to a queue to writing to a topic was somewhat invasive and required configuration changes for JMS apps or code changes for other types of code. The simplest way to address the problem was to intercept the message with an application or exit that wrote copies to two or more queues. As of v7 an application that was written for queues can be provided with an alias over a topic. The producer still thinks it is writing to a queue but WMQ is publishing the messages to a topic instead. Consumers can then either subscribe directly or, in the case of legacy code that requires a queue, an administrative subscription can cause the messages on the topic to be delivered to a queue. I am seeing a lot of uptake on pub/sub to address these kinds of requirement.

There are also the cases where pub/sub is the appropriate solution and it is used for that reason alone. In the past the requirement for separate components, administrative skill or a WMB license were barriers to adoption that caused a certain portion of pub/sub apps to be reworked as point-to-point. With pub/sub built into WMQ, these barriers are eliminated or at least significantly reduced which leads to more uptake simply because it is the right architecture for the problem at hand.

In general, I would say that WMQ pub/sub has gone mainstream with v7. Since v6 end-of-life has been announced for September 2011, there will be a mass migration to v7 this year and subsequently even more adoption of pub/sub as a result.

SSL/TLS
As for SSL, WMQ security is approaching mainstream. I wouldn't say SSL is the norm - just yet - but over the last two or three years it is in enough demand that my WMQ Hands-On Security Lab sessions at the IMPACT and European WebSphere Technical conferences have had overflow attendance. I recently wrote...

The term "trusted internal network"
was coined to differentiate that part
of the network that was internal from
destinations outside the firewall. But
the term "trusted" as used in this
context is relative. It was not
supposed to indicate that the internal
network was trusted implicitly, only
that it was more trusted than things
outside the firewall. Unfortunately,
the term is sometimes interpreted
quite literally. I have had clients
quite earnestly tell me by definition
we trust everything on the "trusted
internal network", that's why we call
it that. Of course, this overstates
the case, because even the staunchest
believers in trusting the internal
network still enforce password-based
login to servers, databases, and
applications. So the internal network
is trusted, but only up to a point,
and even on the internal network
authentication and authorization are
essential.

Although SSL (TLS, actually) channels encrypt, they also authenticate. As more people realize that they need to authenticate WMQ connections on the "trusted" internal network, SSL has been a common method of achieving that. Of course, there is also a growing requirement for privacy (encryption) and integrity services on the WMQ channels for both internal and external connections and this is driving adoption of WMQ SSL channels as well.

Now that SSL is more common, there are a number of secondary challenges that pop up when people do not fully understand WMQ security. The fact that these are now common topics on the WMQ listserve and on MQSeries.net attests to the level of SSL adoption. Some of these secondary issues are the inclusion of unused Certificate Authority root certs in the QMgr's keystore, or lack of QMgr channel settings like SSLPEER (which filters connections by distinguished name) or MCAUSER (which maps authorizations to a specific user account). Frequently people enable SSL but overlook one or more of these other settings and do not achieve the level of security they had intended. Since you must have enabled SSL for these things to present an issue, it is as a friend of mine says "a luxury problem." It is much better to be challenged by SSLPEER settings than not to have applied SSL at all.

In summary...
So I suppose the short answer to both of these questions is that use of pub/sub and SSL in WMQ is quite common. Both are on a sharp upward trend right now and if I were writing new applications I would definitely use SSL and would not hesitate to use WMQ pub/sub where called for.

回复收藏 0 原文

~没有更多了~